需求文档不是原型图。
需求文档不仅包括原型图，还包括很多其他文档。
要搞清这个问题，首先要明确需求文档的目的。需求文档就是上游工序向下游工序输出要求的文档。产品经理需要通过它向项目组所有成员传递详细的工作任务。无论是程序员、UI设计师还是项目经理，拿到这些文档就可以开始工作了，而不是需要口头与产品经理反复沟通甚至开会。如果真是这样，就不叫高效的需求文档，甚至还会耽误进度、产生矛盾。
那么程序员需要什么？没错，他必备的是一份原型图。但是，一份完整的原型图动辄几十页，甚至上百页，程序员完全理解可能至少要3天，看完后面可能还会把前面给忘了。而程序员刚开始工作的时候，是需要估算工作量、安排工作计划的，所以程序员还需要一份需求清单（注：原型图、需求清单都属于需求文档），用来估计所有需求模块大致的难点分布和工作量。需求清单中需要列出所有的模块，再把模块分成子模块，每个子模块用一句话来描述大致是什么功能。
与此同时，当项目组其他成员由表及里理解这个功能的时候，最好能忽略次要环节，抓住流程的主线。产品经理心里有这条主线，后面理解需求就会主次分明、容易上手，从而省去了跟产品经理反复沟通的时间。所以，我们还需要简单地给出主流程图和页面架构图。
产品经理同时也不要忽略了自己的需求。一份需求文档在开发的过程中会经过好多次变更，每一次变更，如果不做记载，只是口头说，那么往往会导致下面的问题:项目组成员忘记了某个变更；沟通中出现错误，并且无法追责—因此就无法避免下次再犯。
因此 ，我们还需要一个需求变更表格，记录每次的修改。
另外，如果产品经理还监管项目进度，就需要做出项目时间的规划。Project（比较盛行的项目管理软件）太复杂，简单地用Excel画一个项目里程碑表格，既能说明所有的团队开发内容，又能说明责任人和完成的时间节点、验收的标准，还能直接打印出来贴在主要成员的桌子前，这就可以让团队任务明确而没有拖延的余地和理由，增加不同团队间的协作性，从而以较低的成本大大提高项目管理的效率。
网友评论