共计 3236 个字符，预计需要花费 9 分钟才能阅读完成。
摘要： 对标市面主流产品，更新差别个性，让产品追随市场变动。
本文分享自华为云社区《我的项目上线后，如何缩小客户对交付成绩的质疑》，原文作者：麻利的小智。
背景
背景形容
早些年前，软件行业刚刚衰亡，过后的软件产品性能简略，用处繁多，软件研发办法也都遵循“打算 –> 需要剖析 –> 设计 –> 编码 –> 测试 –> 运维”这样一个流程循序渐进的开发，最初产品根本能满足客户的需要。这种研发办法被很多公司沿用至今，可与之前不同的是，客户对我的项目交付成绩的质疑越来越多。
有家公司就问了相似的问题：“我的项目上线后客户提出质疑，导致交付呈现问题，项目管理上如何操作能够防止或缩小这种状况的产生？”在交换过程中，咱们理解到该公司在应用传统的瀑布模型进行研发，同时也理解了客户次要有哪些方面的质疑。
质疑形容
客户质疑大抵有三方面，一方面：交付成绩和合同要求对不上：客户认为合同明明说的是 A，可是产品做进去的性能却是 B，比方地处东南的客户吃饺子，想蘸点老陈醋，签了份合同让公司提供“饺子蘸料”，接单的是西南人，依据“蘸料”开发了一瓶酱油，于是客户认为本人表述的足够清晰，是公司外部治理不善造成性能开发谬误；另一方面，产品按需要研发，然而整个研发过程中，客户始终没有接管到研发团队对于产品或研发进度的信息，导致客户对我的项目的焦虑，从而对产品产生质疑；还有一方面，有的产品按需要正确开发，也定时向客户汇报进度，可交付时客户认为性能不够，在当下市场没有竞争力就像当下做电商不反对挪动领取；这些质疑让公司很头疼。
你是否也经验着同样的问题？如何缩小客户对交付成绩的质疑？
问题剖析
上文提到的质疑能够概括为：单方对需要了解不统一，产品性能布局没有随市场变动而刷新和沟通有余引发客户不理解状况而焦虑。接下来咱们揣测下产生这些质疑的起因。
单方对需要了解不统一
需要被制订后，可能没有做进一步廓清，导致开发人员了解有误，照着本人的想法开发出偏离料想的产品；或者客户想表白的意思是 A，然而因为本人表述有问题，需要形容成了 B，那天然无奈开发出令人满意的交付成绩。
还有一种状况更要命：客户在制订需要的时候本人只有一个含糊的想法，具体要做的本人也不分明，这种状况按计划做出的产品想令客户称心就只能靠运气了。
沟通有余，客户因不理解状况而焦虑
咱们试想一种场景：小张在网上买了个手机想要送给女朋友作为生日礼物，眼看生日快到了，商品显示已发货，却始终看不到具体的物流信息，客服也不告知小张商品目前是啥状况，换做你是小张，你急不急，就算商品按时达到，也会因为物流过程不可见而而很难获得好评。
理论生产中也是一样，客户下了订单之后，研发团队始终闷头干活，不与客户沟通我的项目进度，客户一样会因为不理解我的项目停顿而焦虑，最终对交付成绩产生质疑。
产品性能布局没有随市场变动而刷新
正所谓打算不如变动，传统研发模式是打算驱动，而市场是瞬息万变的，想要占领市场，需要变更在劫难逃。打算就像一张地图，一条路经验世事变迁会产生很多变动，依照一张两年前的地图找下面标注的店铺很可能走了半天也找不到中央；同样，照着两年前制订的打算做出的产品，按交付时的背景去扫视它，会给人一种“乃不知有汉，无论魏晋”的感觉，客户难免会对产品提出质疑。
解决措施
传统研发模式的交付相似流水作业：做完打算和需要，就能够依照打算进行开发，而后交付验收。在这种研发模式中，客户参与度相似 U 型：客户在打算阶段和定义需要阶段参加较多；之后我的项目进入研发阶段，客户参与度骤降甚至不参加；最初交付阶段客户参加进来，进行验收工作。客户在研发阶段参与度升高，很容易造成单方对产品沟通不到位：比方需要被谬误了解没人疏导；市场上呈现新性能，产品想不到变通等，这些“不到位”最初都会转化成对交付成绩的质疑。为防止这种状况，能够尝试做麻利转型，客户对交付成绩的质疑在劫难逃，但麻利能够大大减少客户的质疑。
麻利开发的价值观是：“个体和互动重于流程和工具；可工作的软件重于八面玲珑的文档；客户单干重于合同会谈；响应变动重于遵循打算，只管右侧重要，但左侧更重要”。麻利按迭代进行交付，每个迭代持续时间不会很长；同时麻利更重视给客户带来的价值，客户（或客户代表）能够全生命周期的参加并影响整个我的项目。下图是传统开发和麻利开发客户在不同生命周期参与度比照。
麻利具体能够从哪几个方面缩小客户对交付成绩的质疑呢？
应用规范的用户故事办法剖析和记录需要，确保单方了解统一
传统研发模式以打算为导向，应用具体的文档比方：概要设计、具体设计记录需要，这种办法有他的长处，然而毛病也比拟显著：首先制作打算须要破费很长的工夫，其次需要形容过于产品化，不易解读。
麻利开发以价值为导向，区别于传统研发模式的文档，麻利开发应用用户故事记录需要：用户故事是站在用户的角度去形容需要，并且给出用户期待实现的价值，这样开发人员更容易开发出客户真正想要的性能（用户故事细节详见《“用户故事等于需要阐明”——你肯定没有写好用户故事》）。
举个例子，应用用户故事形容需要：客户吃饺子想要一瓶蘸料，用户故事能够写成：“作为成长在山西的小王，我想要一瓶饺子蘸料，以便于让饺子吃起来更美味”。通过用户故事能够看出，客户是“成长在山西的”，所以饺子蘸料可能是老陈醋而不是酱油，交付起来会比“客户想要一瓶蘸料”精确很多。
另外用户故事并不是写好之后就变化无穷的。用户故事的“INVEST”准则中的“N（可商议的）”准则要求用户故事是能够商议的。当开发人员不了解用户故事中的需要，能够将问题抛出来，由产品负责人进行廓清，直到单方对需要的了解达成共识。下图是应用 DevCloud 编写的用户故事，以及需要剖析探讨。
综上所述，应用规范的用户故事记录需要，能够解决单方对需要了解不统一的问题，从而缩小客户对交付成绩的质疑。
通过评审会等形式与客户放弃定期或不定期的沟通交流
麻利开发方法泛滥，Scrum 是最支流的麻利办法之一。Scrum 中有四个流动：打算会议，每日站会，评审会议，回顾会议，每个流动都帮忙着团队更好的践行麻利，更高质量的交付，各流动详细信息如下：
从表中能够看出，打算会议，每日站会，评审会议都是围绕产品发展的。评审会议在每个迭代行将完结时发展，定期邀请客户加入评审会议是最间接无效的与客户沟通的办法：会上团队向客户演示迭代交付成绩，客户通过演示理解产品曾经具备哪些性能，哪些性能没有实现，哪些性能和现实中有偏差，对于偏差局部能够和开发团队沟通，后续迭代进行改良。
如果客户很忙或者工夫不稳固，不能参加每次评审会议，那么可不定期邀请客户加入每日站会，站会每天晚上都进行，客户能够在有空或有趣味的时候参加。每日站会不是必须和客户一起发展，然而通过站会客户能理解到小局部交付成绩以及团队工作状态，缩小焦虑。客户不加入会议的话，可由产品负责人在评审会议完结后整顿评审会议纪要，通过访问，电话，邮件等模式告知客户，让客户理解以后我的项目进度，缩小焦虑，从而缩小对交付成绩的质疑。
对标市面主流产品，更新差别个性，让产品追随市场变动
除了廓清需要、加强与客户的沟通等伎俩之外，咱们还能够带着客户，用产品对标市面上其余主流产品，找到差别并更新，缩小客户的质疑。比方一款电商产品的结算性能在打算时未思考挪动领取，只反对网银领取，按传统模式运作我的项目的话，最终交付时产品不会反对挪动领取，应用起来会很麻烦；如果应用 Scrum 运作我的项目，能够在我的项目进行过程中，或者评审产品的领取性能时，对标支流电商产品，这时候会发现挪动领取是目前最支流的在线领取形式，产品须要反对挪动领取，所以可将“结算性能反对挪动领取”作为一个优先级高的新需要退出我的项目，并与产品负责人协商下个迭代或尽可能快的实现这个需要，让产品的领取性能追随市场变动，减少产品的竞争力。
参考附录
Kenneth S.Rubin:Scrum 精华. 北京：清华大学出版社
Scrum Guide
点击关注，第一工夫理解华为云陈腐技术~
