3.3 甲方乙方——商务项目全过程
需求分析已经开始，其中一个业务主管对项目组的抱怨非常大！
事情是这样的：开发工作分成多个子系统，每个子系统有一个小组在分头整理需求。但这名主管还要求安排一名人员跨系统统筹，负责统一各子系统业务规范。
比较强烈的一个要求是统一各个业务子系统的代码表。代码表是一张参数表，例如，凭证种类中“ 01代表身份证，02代表户口本”，操作的时候从小键盘输入数字比鼠标操作快得多，能减少操作时间，便于系统存储和查询。
但原来各个子系统是由不同厂商开发的，编码不同，客户希望改变现状。但是，项目组的技术人员对这样的工作不重视，迟迟没有理会。这让主管非常恼火，多次在会议上强调这项工作的重要性。
为了应付此事，技术人员出了个评估报告，说明如果真的要统一，不光要花大量时间去梳理，而且会多出很多额外的工作。比如，维护各个子系统的对应关系就需要很大的工作量；如果使用动态的参数表，每次操作都从数据库中读取数据可能会影响系统性能等。
客户的业务主管不是技术专家，对这些解释听不太懂，但对这样的反馈非常不满，认为都是在找“借口”。小M知道之后找到了这位业务主管进行协商。
3.3.1 需求背后的需求
客户主管终于等到有人关注这个问题，于是打开了话匣子，向小M说明了提出这个需求的背景。
原来，这是“综合服务窗口”的要求。以前客户办理不同的业务需要到不同的窗口，这样服务网点里有的队伍很长，有的队伍很闲，工作效率低，客户满意度也低。而“综合服务窗口”要求同一个柜员能够处理多种业务，因此，客户到任何一个窗口都可以办理业务，这样既可以提高工作效率，也可以提高客户满意度。
以前，不同业务系统由不同的厂商开发，业务流程和界面差异较大，代码表也是各有各的标准。但因为一个窗口只用一个子系统，不会有太大问题。但如果改成“综合服务窗口”，如果有的业务中“身份证”代码是01，有的业务中代码是02，则会引起很大的混乱。
小M经常在项目组里听到“综合服务窗口”这个词，不过刚刚才闹明白是怎么回事。为了获得更多信息，忙问业务主管在哪里可以看到这些需求的详细说明。主管很诧异，“这是项目立项的时候就提出的业务流程改进方案啊，你可以去看看招标书，投标的时候你们就承诺了，不会现在不认账吧？”
小M只看过合同，还真没看过标书。于是找来了这些文件，发现其中不仅有对”综合服务窗口”的详细描述，还有很多其他方面的业务需求。而几乎所有的功能需求，都是围绕着这些业务需求提出来的，这些“需求”背后的“需求”，让小M对很多分歧恍然大悟。
这是因为，虽然甲乙双方在谈需求，但出发点不同，造成了双方关注点和思维方式不同。客户关注的是系统如何支持业务流程，背后的需求是“实现业务目标”。技术人员关注的是合理技术方案，背后的需求是“工作量”、“实现难度”和“系统性能”。就拿这个例子来说：
从客户角度考虑，业务目标之一就是“提高工作效率、提高客户满意度”。为了实现这样的业务目标，流程改进方案就是实现“综合服务窗口”。为了支持“综合服务窗口”，就需要业务规范统一，因此提出了“代码表一致”、“统一维护”和“子系统对应”等需求。
从技术人员角度考虑，上述需求只会影响到“界面操作”，不是一件重要的事情，但付出的代价很大：需要在数据库保存代码表，要为子系统作映射表，还要统一进行维护；而为了实现这个技术方案，需要付出额外的工作量、牺牲系统性能、增加了实现难度，如图3-5所示。
由于最根本的出发点不同，在双方进行沟通的时候，尽管在谈同样的需求，但是一面的出发点是“提高工作效率、提高客户满意度”，另一方面的出发点是“工作量”、“难度”和“性能”，不一样的思维，不一样的语言，沟通不畅就可以理解了。
3.3.2 双方眼中的不同生命周期
甲方、乙方眼中的生命周期有什么不同呢？小M眼中“项目”的起点，在客户眼中已经是“执行”阶段了。因为在小M进入项目之前，客户的“项目”早已经开始了，已经做了大量的论证和分析工作。这个过程有点像接力赛，但是因为遗漏了接棒之前的信息，所以造成了一些偏差。
小M按照客户所说的一些项目的关键点，结合项目管理中的生命周期概念重新进行了梳理。发现客户眼中生命周期是这样的，如图3-6所示。
第一，启动项目，目的是识别需求。最初的“需求”是来自业务部门，比如工作效率低、客户满意度低等。为了解决这个业务问题，客户内部对需求进行了确认，提出了主要的改进方法和改进目标，计算投资收益比，分析厂商所应具备的条件，最终完成了可行性分析。根据可行性分析结果，客户批准了预算，完成了立项，项目就产生了。之后一个小组与咨询公司一起细化了项目的需求和各种规格，发出了《招标书》。小M看到的很多业务需求，就是这个阶段产生的。
第二，组织和准备，目的是确定解决方案。各个符合资质的厂商收到了招标书之后，根据规格提交了《标书》介绍自己的解决方案，以及报价。最终客户根据公司实力、方案优劣和报价情况，选择了小M所在的公司，进行商务谈判并最终签订合同。小M在这之后才正式开始接手项目，这也是乙方眼中的项目开始。
第三，执行项目工作。目前小M要做的就是带领项目组完成合同规定的任务。这时，项目成败的责任通过合同转移到了小M的公司头上。小M要代表公司与客户确认项目目标和范围，制定计划，协调资源完成需求、设计、实施工作，直到项目顺利上线。上线标志着完成了项目交付成果和执行阶段的结束，但是，项目并没有结束。
第四，结束项目。系统上线之后，小M的项目组要移交工作成果，将系统交接给维护人员，结清各种款项。这时对小M来说项目可以结束了，项目的责任又重新回到了客户身上。但是，对于客户来说项目还没有结束。客户在接受新的系统之后，要使用系统实现原定的业务目标，根据运行的情况评估“工作效率是否提高、客户满意度是否提高”，从而确定项目的成败。
如此看来，小M只是经历了项目中的一段。由于没有参加论证阶段，所以可能遗漏一个非常重要的信息——客户“为什么要做这个项目”。客户一定知道在项目完成之后，“可以解决什么问题，能带来什么价值”，这才是客户心中的项目成功标准。
3.3.3 客户为什么做这个项目
客户为什么要做这个项目？这是最本质的业务需求。需求分析确定的功能需求，都是从业务需求推导出来的，都必须为业务需求服务。
举个例子，客户去买衣服的时候，一定知道自己为什么要买衣服吧？可能是“御寒”，可能是“漂亮”，也可能是“体面”，也可能是因为在打折。
一般的营业员会问客户颜色、款式和面料等方面的要求，拿到一件就努力说明“这件衣服最适合你”，可能一件一件不停地试，但客户始终都会挑出其他的毛病。
而有的营业员会努力弄清楚你为什要买，问你什么场合穿。然后，再帮助客户作出取舍，如果为了御寒会强调保暖性能，并请你适当牺牲漂亮；如果是为了漂亮，就要找款式新颖、颜色流行的，强调价格是合理的；如果为了“体面”就要找面料和做工好的，就要适当牺牲价格；如果是为了便宜就要强调性价比，并对比以前的价格。
小M他们犯的错误，是第一种营业员的错误。上来就聚焦在功能需求上，一下子扎在了功能需求如何实现上，而忽略了 “客户为什么做这个项目”。
这样看来，“按期交付”只是项目的最低要求。交付的成果能“解决客户的问题、给客户带来价值”，才能让客户成功，才能让客户满意。
想让客户满意，就一定要站在客户立场上考虑问题；站在客户立场上考虑问题，就要了解客户的业务，弄清楚客户为什么有这样的要求；如果弄清楚了这个“为什么”，对于什么是重要的、什么是不重要就容易判断了。
想到这里，小M和技术人员再次找到了业务主管，认真倾听了主管的需求，并一起讨论解决办法。讨论中发现了一些重要信息。例如，其实代码表并不经常改动，所以每次从数据库访问的方式确实不可取。而比较合适的替代方案是帮助客户建立一个数据字典管理各种代码表，并在需求分析的过程中进行维护。而开发的时候，可以通过一个小程序自动根据数据字典产生下拉列表。为了便于项目结束后客户能自己维护，还专门设计了一个使用方便的小工具。
这个方案开发工作量不大，对性能没有影响，主要工作由客户方面承担，还可以保证客户的长期维护。因此，客户的业务主管对这样的结果非常满意。其实，项目组并没有按照客户最初的要求去工作，但是在了解了客户真正的需求之后，提供了一个更好的解决方案，达到了双赢的局面。
3.3.4 经验与教训
由于甲乙双方的立场不同，关注点不同，很多事情会产生分歧。要想获得客户的满意，必须从客户的角度看问题，了解客户表面需求背后的“需求”，因为这是客户判断项目成败的标准。
