第六步：撰写详细的需求文档。
《框架图》下载西乔的模版。可视化表现产品的框架、布局、细节、部分交互。
《流程图》》下载西乔的模版。理出产品的逻辑关系。
《功能需求文档》》下载西乔的模版。 罗列 功能、应用、交互上细节，分离基础件，作为开发分工和系统及数据构造的 基础文档。
第七步：商讨需求文档
尽量召集甲方所有相关部门的负责人 一起召开这次会议，商讨需求文档。
在阅读到你的需求文档之前，可能甲方的大部分人都对产品没有可视和具象的理解。也从未关注到细节和逻辑关系。所以需要产品经理从全局角度和逻辑线索讲解文档。
更可能发生的状况是，没有人坚持看完或仔细看过你写的文档。
所以这次会议是一场耐心和体力的考研。
文档作者需要 分别向各个部门指出他们需要关注和拍板的地方，听取他们的建议，将任何变动要求都分类记录。
安抚情绪。解答困惑。控制需求变动。
第八步：定稿需求文档
分职能（部门）类建立表格文档。将会议协商中所有 分歧性意见和变动意见 都逐条写下。抄送所有相关负责人。并要求他们纠正分歧和确认变动。
所有会议中可能被提出但是未出现在此邮件文档中的 意见，不会列入需求文档中。当然允许可以书面反馈补充。
根据确认过的反馈回复，修改需求文档。直到需求文档定稿。
协商讨论和文档修改可能经过2~3轮。所以需要项目经理提前提醒客户注意，搜集需求和文档定稿的 时间线里程碑。如果这个阶段耗时过久，会严重延误整个项目进度。要求客户尽量集中地谨慎地提出建议和修改。
三种武器：
需求问卷：无论是面对专业还是不专业的客户，交流中都有很多没考虑到的遗漏点，这些他们看不到的点往往是最关键的点，也有可能是被客户故意规避掉的点。
此时撰写一份需求问卷非常有效。
问卷里提出重要的全局性的问题，需要客户逐条书面回答。
某些问题可以提供多个选项答案，及补充区域。
某些问题 需要确凿的态度，Yes或NO。
不要提出需要客户写一大段表述性文字的问题。
需求问卷精简扼要，有针对性，重要，不要浪费客户的时间，不要把写字的工作量丢给客户。
书面确认：
书面确认 一方面包括 ：所有讨论结果、建议 和变更 都要有书面文字备查。电话和开会上说说的这些口头表达都没有效应。这一点一开始你就要声明，甚至有必要写在合同里。
另一方面包括：你要尽量提供书面的可视化的东西 来让甲方确认。
甲方很难完备或是提供适合工程使用的文档。所以千万不要在项目初期的需求文档上省懒。
邮件抄送：
邮件抄送一种明确职责的方法。对方可能不看你的邮件，但代表你告之过。
尽可能地抄送重要邮件给战略层，可以能避免一些重大问题的出现。
结语：
到此看起来，搜集和确定需求真是一件耗时耗力的工程。
其实在理想的工程项目时间分配中，1/3的时间用于确定所有需求和开发文档。 1/2的时间用于测试，解决bug，安全测试、压力测试等。真正用于开发的只应该占1/6。
当然web项目的开发肯定达不到这个理想状况。但是也由此可见需求阶段的重要性和工作量。这一阶段省一分力或有一分遗漏，到了项目后期可能需要十分力来弥补。
作者：西乔 项目经理 产品顾问 创立Magicome公司提供web技术开发项目外包开发及产品端顾问咨询。 联系方式：arthur369@gmail.com
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
