他们纠正分歧和确认变动。所有会议中可能被提出但是未出现在此邮件文档中的意见,不会列入需求文档中。当然允许可以书面反馈补充。根据确认过的反馈回复,修改需求文档。直到需求文档定稿。协商讨论和文档修改可能经过2~3轮。所以需要项目经理提前提醒客户注意,搜集需求和文档定稿的时间线里程碑。如果这个阶段耗时过久,会严重延误整个项目进度。要求客户尽量集中地谨慎地提出建议和修改。三种武器:需求问卷:无论是面对专业还是不专业的客户,交流中都有很多没考虑到的遗漏点,这些他们看不到的点往往是最关键的点,也有可能是被客户故意规避掉的点。此时撰写一份需求问卷非常有效。问卷里提出重要的全局性的问题,需要客户逐条书面回答。某些问题可以提供多个选项答案,及补充区域。某些问题需要确凿的态度,Yes或NO。不要提出需要客户写一大段表述性文字的问题。需求问卷精简扼要,有针对性,重要,不要浪费客户的时间,不要把写字的工作量丢给客户。书面确认:书面确认一方面包括:所有讨论结果、建议和变更都要有书面文字备查。电话和开会上说说的这些口头表达都没有效应。这一点一开始你就要声明,甚至有必要写在合同里。另一方面包括:你要尽量提供书面的可视化的东西来让甲方确认。甲方很难完备或是提供适合工程使用的文档。所以千万不要在项目初期的需求文档上省懒。邮件抄送:邮件抄送一种明确职责的方法。对方可能不看你的邮件,但代表你告之过。尽可能地抄送重要邮件给战略层,可以能避免一些重大问题的出现。结语到此看起来,搜集和确定需求真是一件耗时耗力的工程。其实在理想的工程项目时间分配中,1/3的时间用于确定所有需求和开发文档。1/2的时间用于测试,解决bug,安全测试、压力测试等。真正用于开发的只应该占1/6。当然web项目的开发肯定达不到这个理想状况。但是也由此可见需求阶段的重要性和工作量。这一阶段省一分力或有一分遗漏,到了项目后期可能需要十分力来弥补。
全文预览
