项目上线后，如何减少客户对交付成果的质疑

背景

背景描述

早些年前，软件行业刚刚兴起，当时的软件产品功能简单，用途单一，软件研发方法也都遵循“计划-->需求分析-->设计-->编码-->测试-->运维”这样一个流程按部就班的开发，最后产品基本能满足客户的需求。这种研发方法被很多公司沿用至今，可与之前不同的是，客户对项目交付成果的质疑越来越多。

有家公司就问了类似的问题：“项目上线后客户提出质疑，导致交付出现问题，项目管理上如何操作可以避免或减少这种情况的发生？”在交流过程中，我们了解到该公司在使用传统的瀑布模型进行研发，同时也了解了客户主要有哪些方面的质疑。

质疑描述

客户质疑大致有三方面，一方面：交付成果和合同要求对不上：客户认为合同明明说的是A，可是产品做出来的功能却是B，比如地处西北的客户吃饺子，想蘸点老陈醋，签了份合同让公司提供“饺子蘸料”，接单的是东北人，根据“蘸料”开发了一瓶酱油，于是客户认为自己表述的足够清晰，是公司内部管理不善造成功能开发错误；另一方面，产品按需求研发，但是整个研发过程中，客户一直没有接收到研发团队关于产品或研发进度的信息，导致客户对项目的焦虑，从而对产品产生质疑；还有一方面，有的产品按需求正确开发，也定时向客户汇报进度，可交付时客户认为功能不够，在当下市场没有竞争力就像当下做电商不支持移动支付；这些质疑让公司很头疼。

你是否也经历着同样的问题？如何减少客户对交付成果的质疑？

问题分析

上文提到的质疑可以概括为：双方对需求理解不一致，产品功能规划没有随市场变化而刷新和沟通不足引发客户不了解情况而焦虑。接下来我们推测下产生这些质疑的原因。

双方对需求理解不一致

需求被制定后，可能没有做进一步澄清，导致开发人员理解有误，照着自己的想法开发出偏离预想的产品；或者客户想表达的意思是A，但是由于自己表述有问题，需求描述成了B，那自然无法开发出令人满意的交付成果。

还有一种情况更要命：客户在制定需求的时候自己只有一个模糊的想法，具体要做的自己也不清楚，这种情况按计划做出的产品想令客户满意就只能靠运气了。

沟通不足，客户因不了解情况而焦虑

我们试想一种场景：小张在网上买了个手机想要送给女朋友作为生日礼物，眼看生日快到了，商品显示已发货，却始终看不到详细的物流信息，客服也不告知小张商品目前是啥情况，换做你是小张，你急不急，就算商品按时到达，也会因为物流过程不可见而而很难获得好评。

实际生产中也是一样，客户下了订单之后，研发团队一直闷头干活，不与客户沟通项目进度，客户一样会因为不了解项目进展而焦虑，最终对交付成果产生质疑。

产品功能规划没有随市场变化而刷新

正所谓计划不如变化，传统研发模式是计划驱动，而市场是瞬息万变的，想要占领市场，需求变更在所难免。计划就像一张地图，一条路经历世事变迁会发生很多变化，按照一张两年前的地图找上面标注的店铺很可能走了半天也找不到地方；同样，照着两年前制定的计划做出的产品，按交付时的背景去审视它，会给人一种“乃不知有汉，无论魏晋”的感觉，客户难免会对产品提出质疑。

解决措施

传统研发模式的交付类似流水作业：做完计划和需求，就可以按照计划进行开发，然后交付验收。在这种研发模式中，客户参与度类似U型：客户在计划阶段和定义需求阶段参与较多；之后项目进入研发阶段，客户参与度骤降甚至不参与；最后交付阶段客户参与进来，进行验收工作。客户在研发阶段参与度降低，很容易造成双方对产品沟通不到位：比如需求被错误理解没人引导；市场上出现新功能，产品想不到变通等，这些“不到位”最后都会转化成对交付成果的质疑。为避免这种情况，可以尝试做敏捷转型，客户对交付成果的质疑在所难免，但敏捷可以大大减少客户的质疑。

敏捷开发的价值观是：“个体和互动重于流程和工具；可工作的软件重于面面俱到的文档；客户合作重于合同谈判；响应变化重于遵循计划，尽管右侧重要，但左侧更重要”。敏捷按迭代进行交付，每个迭代持续时间不会很长；同时敏捷更注重给客户带来的价值，客户（或客户代表）可以全生命周期的参与并影响整个项目。下图是传统开发和敏捷开发客户在不同生命周期参与度对比。

敏捷具体可以从哪几个方面减少客户对交付成果的质疑呢？

使用标准的用户故事方法分析和记录需求，确保双方理解一致

传统研发模式以计划为导向，使用详细的文档比如：概要设计、详细设计记录需求，这种方法有他的优点，但是缺点也比较明显：首先制作计划需要花费很长的时间，其次需求描述过于产品化，不易解读。

敏捷开发以价值为导向，区别于传统研发模式的文档，敏捷开发使用用户故事记录需求：用户故事是站在用户的角度去描述需求，并且给出用户期待实现的价值，这样开发人员更容易开发出客户真正想要的功能（用户故事细节详见《 “用户故事等于需求说明”——你一定没有写好用户故事》）。

举个例子，使用用户故事描述需求：客户吃饺子想要一瓶蘸料，用户故事可以写成：“作为生长在山西的小王，我想要一瓶饺子蘸料，以便于让饺子吃起来更美味”。通过用户故事可以看出，客户是“生长在山西的”，所以饺子蘸料可能是老陈醋而不是酱油，交付起来会比“客户想要一瓶蘸料”准确很多。

另外用户故事并不是写好之后就一成不变的。用户故事的“INVEST”原则中的“N（可商议的）”原则要求用户故事是可以商议的。当开发人员不理解用户故事中的需求，可以将问题抛出来，由产品负责人进行澄清，直到双方对需求的理解达成共识。下图是使用DevCloud编写的用户故事，以及需求分析讨论。

综上所述，使用标准的用户故事记录需求，可以解决双方对需求理解不一致的问题，从而减少客户对交付成果的质疑。

通过评审会等方式与客户保持定期或不定期的沟通交流

敏捷开发方法众多，Scrum是最主流的敏捷方法之一。Scrum中有四个活动：计划会议，每日站会，评审会议，回顾会议，每个活动都帮助着团队更好的践行敏捷，更高质量的交付，各活动详细信息如下：

从表中可以看出，计划会议，每日站会，评审会议都是围绕产品开展的。评审会议在每个迭代即将结束时开展，定期邀请客户参加评审会议是最直接有效的与客户沟通的方法：会上团队向客户演示迭代交付成果，客户通过演示了解产品已经具备哪些功能，哪些功能没有完成，哪些功能和理想中有偏差，对于偏差部分可以和开发团队沟通，后续迭代进行改进。

如果客户很忙或者时间不稳定，不能参与每次评审会议，那么可不定期邀请客户参加每日站会，站会每天早晨都进行，客户可以在有空或有兴趣的时候参与。每日站会不是必须和客户一起开展，但是通过站会客户能了解到小部分交付成果以及团队工作状态，减少焦虑。客户不参加会议的话，可由产品负责人在评审会议结束后整理评审会议纪要，通过拜访，电话，邮件等形式告知客户，让客户了解当前项目进度，减少焦虑，从而减少对交付成果的质疑。

对标市面主流产品，更新差异特性，让产品跟随市场变化

除了澄清需求、增强与客户的沟通等手段之外，我们还可以带着客户，用产品对标市面上其他主流产品，找到差异并更新，减少客户的质疑。比如一款电商产品的结算功能在计划时未考虑移动支付，只支持网银支付，按传统模式运作项目的话，最终交付时产品不会支持移动支付，使用起来会很麻烦；如果使用Scrum运作项目，可以在项目进行过程中，或者评审产品的支付功能时，对标主流电商产品，这时候会发现移动支付是目前最主流的在线支付方式，产品需要支持移动支付，所以可将“结算功能支持移动支付”作为一个优先级高的新需求加入项目，并与产品负责人协商下个迭代或尽可能快的完成这个需求，让产品的支付功能跟随市场变化，增加产品的竞争力。

参考附录

Kenneth S.Rubin:Scrum精髓. 北京：清华大学出版社

Scrum Guide

DevOps 敏捷开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。