第八步：定稿需求文档

　　分职能(部门)类建立表格文档。将会议协商中所有 分歧性意见和变动意见 都逐条写下。抄送所有相关负责人。并要求他们纠正分歧和确认变动。

　　所有会议中可能被提出但是未出现在此邮件文档中的 意见，不会列入需求文档中。当然允许可以书面反馈补充。

　　根据确认过的反馈回复，修改需求文档。直到需求文档定稿。

　　协商讨论和文档修改可能经过2~3轮。所以需要项目经理提前提醒客户注意，”搜集需求和文档定稿”的时间线里程碑。如果这个阶段耗时过久，会严重延误整个项目进度。要求客户尽量集中地谨慎地提出建议和修改。

　　三种武器：

　　需求问卷：

　　无论是面对专业还是不专业的客户，交流中都有很多没考虑到的遗漏点，这些他们看不到的点往往是关键的点，也有可能是被客户故意规避掉的点。

　　此时撰写一份需求问卷非常有效。 问卷里提出重要的全局性的问题，需要客户逐条书面回答。

　　某些问题可以提供多个选项答案，及补充区域。

　　某些问题 需要确凿的态度，Yes或NO。

　　不要提出需要客户写一大段表述性文字的问题。 需求问卷精简扼要，有针对性，重要，

　　不要浪费客户的时间，不要把写字的工作量丢给客户。

　　书面确认：

　　书面确认 一方面包括 ：所有讨论结果、建议 和变更 都要有书面文字备查。电话和开会上说说的这些口头表达都没有效应。这一点一开始你要声明，甚至有必要写在合同里。

　　另一方面包括：你要尽量提供书面的可视化的东西 来让甲方确认。甲方很难完备或是提供适合工程使用的文档。所以千万不要在项目初期的需求文档上省懒。

　　邮件抄送：

　　邮件抄送一种明确职责的方法。对方可能不看你的邮件，但代表你告之过。尽可能地抄送重要邮件给战略层，可以能避免一些重大问题的出现。

　　结语：

　　到此看起来，搜集和确定需求真是一件耗时耗力的工程。

　　其实在理想的工程项目时间分配中，1/3的时间用于确定所有需求和开发文档。 1/2的时间用于测试，解决bug，安全测试、压力测试等。真正用于开发的只应该占1/6。 当然web项目的开发肯定达不到这个理想状况。

　　但是也由此可见需求阶段的重要性和工作量。这一阶段省一分力或有一分遗漏，到了项目后期可能需要十分力来弥补。

　　四 16

　　如何逃离垃圾客户(下)项目管理

　　Tags: 项目管理， 失败案例， 控制客户， 故事

　　20 Comments »

　　《如何逃离垃圾客户(上)》

　　故事三：朋友介绍的好机会

　　C：高级程序员，5年代码工作经验。在职，工作清闲，偶尔接点私活。

　　外地人，在北京漂着，8K月薪税前，偶尔需要加班，有个职业普通的女朋友，买房甭想，打车掂量掂量。宅男，回家了看看资料看看美剧，长时间持续的代码工作，视力不如，脖子和腰也经常不舒服。

　　C经常想，不知道有多少程序员过着像这样的生活，不好不坏，无力改变，也没有理由去改变。

　　好在他性格温和，人缘很好，经常会有朋友介绍一些私活给他，除了挣点钱，对生活也是一种填充。

　　C一个挺铁的哥们跳槽到一家传统行业的公司，公司需要开设电子商务的业务，找到了C帮忙搭个系统，费用也不低，C欣然承应。

　　客户公司不大，对互联网有一定了解，由市场部门和C沟通接洽。 他们并没有太明确的想法，希望和现行跑的大部分网店差不多行。C用开源系统搭个一个，按照客户的要求建了分类，录入了一些测试数据。

　　客户总是不知道自己要的是什么，但是知道什么是自己要的。

　　有了可视的DEMO，客户也有了想法。他们提出要根据自己的业务特色增加预订货物和预定管理的流程。

　　而此时C还没有和客户签订正式的合同，只明确了开发费用的总数，也没有具体写明任务清单。因为有朋友在这，这家公司做传统行业也有不少年，信誉上问题不大。所以C也比较放心。先花了一两周改造了开源程序的流程。

　　客户提出界面的风格和品牌形象不太匹配。C找了一堆开源皮肤，让客户挑一个。客户挑了几个分别换上试试。两周又过去了。

　　客户提出商品的缩略图尺寸不够大，图像质量不够好。C修改了GD库和图片压缩的参数。

　　客户又提出缩略图列表页 图片有横版有竖版不够整齐。C只好又修改了缩略图截取的程序。

　　此时已经过去了6周，C开始催促朋友，先把预付结了吧。朋友甚至有点惊讶：“还没把预付给你吗?我赶紧帮你催催。”

　　客户持续像挤牙膏一样地挤出需求。加个水印啦，添加一种排序关系啦，改下分页啦。 预付还是没有到位，补签合同显然也不太现实，朋友每周都在表示抱歉，表示一定帮忙落实费用，总是有些财务上的预算上的付款期上的理由。

　　C已经意识到自己已经掉进了一个大坑：项目时间持续流失，客户意见时常反复，需求零敲碎打但都不复杂，总体来看也并没有脱离当初定好的项目框架：利用现成的开源代码搭建一个客户需要的网店系统。可是到现在为止所耗费的工程时间和工作量已经足够自己重写一套了。

　　爆发的临界点终于到了。客户看了竞争对手的网店，发现了很多新功能，所用的开源系统是同一个，只不过使用了新的3.0版本。 客户要求也对自己的系统进行升级。

　　C性格再好也忍不住了：“我以前专门提醒过：已经对系统进行了那么多的定制化改造，如果升级，所有定制化需求都得全部重新改一遍。使用开源系统如果要升级不能做太多改造，如果要定制化得放弃升级!

　　客户：“当初也是你建议我们使用开源系统的.”

　　C：“你们又想控制成本，又想节省时间，又不知道自己要什么，需求又总是反复，开源系统是好的选择了。“

　　客户：“但是你看，现在很多我们需要的功能没有，这个问题总得解决吧……”