摘要：对标市面主流产品，更新差别特性，让产品跟随市场变化。
本文分享自华为云社区《项目上线后，如何减小客户对交付成果的质疑》，原文做者：敏捷的小智。运维
背景
背景描述
早些年前，软件行业刚刚兴起，当时的软件产品功能简单，用途单一，软件研发方法也都遵循“计划-->需求分析-->设计-->编码-->测试-->运维”这样一个流程循序渐进的开发，最后产品基本能知足客户的需求。这种研发方法被不少公司沿用至今，可与以前不一样的是，客户对项目交付成果的质疑愈来愈多。ide
有家公司就问了相似的问题：“项目上线后客户提出质疑，致使交付出现问题，项目管理上如何操做能够避免或减小这种状况的发生？”在交流过程当中，咱们了解到该公司在使用传统的瀑布模型进行研发，同时也了解了客户主要有哪些方面的质疑。工具
质疑描述
客户质疑大体有三方面，一方面：交付成果和合同要求对不上：客户认为合同明明说的是A，但是产品作出来的功能倒是B，好比地处西北的客户吃饺子，想蘸点老陈醋，签了份合同让公司提供“饺子蘸料”，接单的是东北人，根据“蘸料”开发了一瓶酱油，因而客户认为本身表述的足够清晰，是公司内部管理不善形成功能开发错误；另外一方面，产品按需求研发，可是整个研发过程当中，客户一直没有接收到研发团队关于产品或研发进度的信息，致使客户对项目的焦虑，从而对产品产生质疑；还有一方面，有的产品按需求正确开发，也定时向客户汇报进度，可交付时客户认为功能不够，在当下市场没有竞争力就像当下作电商不支持移动支付；这些质疑让公司很头疼。测试
你是否也经历着一样的问题？如何减小客户对交付成果的质疑？ui
问题分析
上文提到的质疑能够归纳为：双方对需求理解不一致，产品功能规划没有随市场变化而刷新和沟通不足引起客户不了解状况而焦虑。接下来咱们推测下产生这些质疑的缘由。编码
双方对需求理解不一致
需求被制定后，可能没有作进一步澄清，致使开发人员理解有误，照着本身的想法开发出偏离预想的产品；或者客户想表达的意思是A，可是因为本身表述有问题，需求描述成了B，那天然没法开发出使人满意的交付成果。url
还有一种状况更要命：客户在制定需求的时候本身只有一个模糊的想法，具体要作的本身也不清楚，这种状况按计划作出的产品想令客户满意就只能靠运气了。spa
沟通不足，客户因不了解状况而焦虑
咱们试想一种场景：小张在网上买了个手机想要送给女友做为生日礼物，眼看生日快到了，商品显示已发货，却始终看不到详细的物流信息，客服也不告知小张商品目前是啥状况，换作你是小张，你急不急，就算商品按时到达，也会由于物流过程不可见而而很难得到好评。.net
实际生产中也是同样，客户下了订单以后，研发团队一直闷头干活，不与客户沟通项目进度，客户同样会由于不了解项目进展而焦虑，最终对交付成果产生质疑。设计
产品功能规划没有随市场变化而刷新
正所谓计划不如变化，传统研发模式是计划驱动，而市场是瞬息万变的，想要占领市场，需求变动在所不免。计划就像一张地图，一条路经历世事变迁会发生不少变化，按照一张两年前的地图找上面标注的店铺极可能走了半天也找不到地方；一样，照着两年前制定的计划作出的产品，按交付时的背景去审视它，会给人一种“乃不知有汉，不管魏晋”的感受，客户不免会对产品提出质疑。
解决措施
传统研发模式的交付相似流水做业：作完计划和需求，就能够按照计划进行开发，而后交付验收。在这种研发模式中，客户参与度相似U型：客户在计划阶段和定义需求阶段参与较多；以后项目进入研发阶段，客户参与度骤降甚至不参与；最后交付阶段客户参与进来，进行验收工做。客户在研发阶段参与度下降，很容易形成双方对产品沟通不到位：好比需求被错误理解没人引导；市场上出现新功能，产品想不到变通等，这些“不到位”最后都会转化成对交付成果的质疑。为避免这种状况，能够尝试作敏捷转型，客户对交付成果的质疑在所不免，但敏捷能够大大减小客户的质疑。
敏捷开发的价值观是：“个体和互动重于流程和工具；可工做的软件重于面面俱到的文档；客户合做重于合同谈判；响应变化重于遵循计划，尽管右侧重要，但左侧更重要”。敏捷按迭代进行交付，每一个迭代持续时间不会很长；同时敏捷更注重给客户带来的价值，客户（或客户表明）能够全生命周期的参与并影响整个项目。下图是传统开发和敏捷开发客户在不一样生命周期参与度对比。
敏捷具体能够从哪几个方面减小客户对交付成果的质疑呢？
使用标准的用户故事方法分析和记录需求，确保双方理解一致
传统研发模式以计划为导向，使用详细的文档好比：概要设计、详细设计记录需求，这种方法有他的优势，可是缺点也比较明显：首先制做计划须要花费很长的时间，其次需求描述过于产品化，不易解读。
敏捷开发以价值为导向，区别于传统研发模式的文档，敏捷开发使用用户故事记录需求：用户故事是站在用户的角度去描述需求，而且给出用户期待实现的价值，这样开发人员更容易开发出客户真正想要的功能（用户故事细节详见 《 “用户故事等于需求说明”——你必定没有写好用户故事》 ）。
举个例子，使用用户故事描述需求：客户吃饺子想要一瓶蘸料，用户故事能够写成：“做为生长在山西的小王，我想要一瓶饺子蘸料，以便于让饺子吃起来更美味”。经过用户故事能够看出，客户是“生长在山西的”，因此饺子蘸料多是老陈醋而不是酱油，交付起来会比“客户想要一瓶蘸料”准确不少。
另外用户故事并非写好以后就一成不变的。用户故事的“INVEST”原则中的“N（可商议的）”原则要求用户故事是能够商议的。当开发人员不理解用户故事中的需求，能够将问题抛出来，由产品负责人进行澄清，直到双方对需求的理解达成共识。下图是使用DevCloud编写的用户故事，以及需求分析讨论。
综上所述，使用标准的用户故事记录需求，能够解决双方对需求理解不一致的问题，从而减小客户对交付成果的质疑。
经过评审会等方式与客户保持按期或不按期的沟通交流
敏捷开发方法众多，Scrum是最主流的敏捷方法之一。Scrum中有四个活动：计划会议，每日站会，评审会议，回顾会议，每一个活动都帮助着团队更好的践行敏捷，更高质量的交付，各活动详细信息以下：
从表中能够看出，计划会议，每日站会，评审会议都是围绕产品开展的。评审会议在每一个迭代即将结束时开展，按期邀请客户参加评审会议是最直接有效的与客户沟通的方法：会上团队向客户演示迭代交付成果，客户经过演示了解产品已经具有哪些功能，哪些功能没有完成，哪些功能和理想中有误差，对于误差部分能够和开发团队沟通，后续迭代进行改进。
若是客户很忙或者时间不稳定，不能参与每次评审会议，那么可不按期邀请客户参加每日站会，站会天天早晨都进行，客户能够在有空或有兴趣的时候参与。每日站会不是必须和客户一块儿开展，可是经过站会客户能了解到小部分交付成果以及团队工做状态，减小焦虑。客户不参加会议的话，可由产品负责人在评审会议结束后整理评审会议纪要，经过拜访，电话，邮件等形式告知客户，让客户了解当前项目进度，减小焦虑，从而减小对交付成果的质疑。
对标市面主流产品，更新差别特性，让产品跟随市场变化
除了澄清需求、加强与客户的沟通等手段以外，咱们还能够带着客户，用产品对标市面上其余主流产品，找到差别并更新，减小客户的质疑。好比一款电商产品的结算功能在计划时未考虑移动支付，只支持网银支付，按传统模式运做项目的话，最终交付时产品不会支持移动支付，使用起来会很麻烦；若是使用Scrum运做项目，能够在项目进行过程当中，或者评审产品的支付功能时，对标主流电商产品，这时候会发现移动支付是目前最主流的在线支付方式，产品须要支持移动支付，因此可将“结算功能支持移动支付”做为一个优先级高的新需求加入项目，并与产品负责人协商下个迭代或尽量快的完成这个需求，让产品的支付功能跟随市场变化，增长产品的竞争力。
参考附录
Kenneth S.Rubin:Scrum精髓. 北京：清华大学出版社
Scrum Guide