写文档时每个产品经理应该具备的素质，但是要写出一份能够被人阅读，有指导意义的文档确是困难的。
产品需求文档，production requestion document, 顾名思义，描述产品的需求。需求并不是设想，也不是计划，而是实实在在的可执行的东西。
不要为了文档而写文档
现实中有太多老学究&新闻联播稿式的文档，空洞、形式，让人恼火却又不得不习惯。正如《幸福课》中的一个笑话提到的：
一份发布于世界知名刊物的心理学论文，据统计，仅有3个人阅读，一个是作者自己、一个是导师，还有一个是——作者的妈妈！
风格朴素，明晰易懂
无论是互联网，还是软件产品，作为从业者，特别是产品经理，在书写的时候，都会咱在自己专业的角度，想当然的认为其他人（程序员、UI、市场）都能看懂。而实际情况往往相反。
有目录和提纲，有调理
大部分文档，并不是很正式的，有时候往往是为一件小事或小项目而作的，书写者为了省事和方便，或者美其名曰简明扼要，只是把关键的细节交代下，这也无可厚非。但是这样问题就来了，因为阅读者是出于工作目的，作为指导文档区执行的，这种发散兼跳跃的散文诗歌文怎么可以胜任呢？当然，书写着往往信誓旦旦的说明已经足够了，再多就啰嗦，其实，合理的啰嗦还是应该的，至少，需要给文档加上一个目录。
考虑到大部分文档都需要用word书写的，本站的这篇文章可以作为添加目录的扫盲文：
更改的技巧
我本来想写成“忌反复修改”，但是想了想，再结合实际情况，还是改成了“更改的技巧”。毕竟，再有耐心的人，对于朝令夕改也会产生逆反和排斥，虽然有时候反复是不可避免的。如图所示是需求规划简直让人抓狂。
当然，更改的同时，做好版本控制还是非常必要的，这里面最好的方法也就是命名了，我的经验是，一份文档，或者一个原型的文件夹，可以采取软件行业规范的方法，驼峰命名法。
XX产品设计需求 版本号_作者名_日期.doc 这样的格式，如 专题网站需求文档V1.0_杨宁_20120501.doc
本文有一条评论