【精彩预告】用友集团开发管理部总经理罗涛将于5月21日在上海MPD工作坊进行《破解4小时上线传说》的3小时分享。
通过一个故事引入互联网+产品开发的迭代思路、价值发掘和发布规划等核心思想和工具，将结组利用小图团队的力量使用影响地图、用户故事地图、无代码验证等演练手段在3个小时的工作坊内快速发布一个产品，带领学员在操作中理解精益和敏捷。
文章来源：公众号 ：msup（ID：msupclub）关注回复“体验工坊”有惊喜。
导读：在面对需求的变化无常、人员的变动和技术的更新时，对客户价值的识别尤其重要，这是产品成败的关键。如何在产品研发过程中精准定位用户价值，并针对用户价值分析用户场景、划分场景迭代计划，从而优化研发产品管理、研发项目管理、激发团队战斗力、提升客户满意度，建立新的研发模式，不断改进个体的沟通模式，启发大家的思路，形成了团队新的工作风格？
通过实践我们在产品需求管理中形成了一套符合团队实际的工作方法论，教练出一支可以持续交付的高绩效团队，培养一批敏捷改进的骨干和积极分子，对完成新产品的研发起到了关键作用。
本案例从集团某行业研发中心产品研发团队的实际情况出发，主要分享该团队在产品需求、开发管理等方面，以及客户价值的定位、场景的分析、迭代的规划、方案的验证等方面所做的创新，深度介绍新产品研发的POA、MVP、影响地图和故事地图的实际应用和具体效果。每个部分都会分享项目真实的体验，希望读者能从本中获得启发和灵感。
一、案例启示
基于价值的产品发掘、定义、分析和交付是打造高绩效团队的前提和基础。
价值是产品成败的关键，做项目之前首先要确定能给客户提供什么价值；
需求是在场景中的需求；
快速验证帮助产品实现客户价值的最佳方法。
二、案例背景
一年以前，XX研发部刚和原来的部门分开，过去的一年半里团队没有发布过任何版本、人员流动非常频繁，这些原因导致整个团队士气低落。研发负责人和需求经理找到我，看能不能帮他们进行敏捷转型。
我首先做团队调研，发现相关方处于互相看不顺眼的状态：
客户方典型没有建立信任感。客户常说“你做的东西根本不是我要的！”；“你不懂我啊！”，“要我等这么长时间！”，“根本没提供给我任何的价值呢！”；“要想上线，这个必须这么改一下！”；“你们都是按照我说的在做，业务水平不如我，那就听我的吧。”
产品团队很痛苦。一方面被客户逼，被客户骂，一方面在开发面前，面对超出预期的交付周期，要面对“你说的这个需求到底是哪个客户会这么用？”；“你又不懂技术，这个没法实现，必须换方案。”等类似的质疑和争吵。
开发团队更痛苦。天天996、007加班加点做出来的产品，产品团队一句“这根本不是我要的”就退回了！说不清为什么加这个功能，手头工作还没做完新的变更又来了。好不容易做完了，用户不接受，说产品理解错了…
以上问题造成产品需求与市场脱节，所做的产品客户方不认，并且由于薪酬和发展等原因，核心人员流动很大，而市场又存在更多的需求需要去满足。所以团队有强烈的诉求通过引入新的研发过程来改变现状，并希望能在年内推出新的产品在客户处实施上线。
三、案例复现
3.1 策略与效果
图1 打通产品研发的任督二脉
为了敏捷改进更好地落地，并且发挥敏捷的真正意义，我根据了解到的现状和团队进行了深入沟通，确定了“从加强产品管理入手，发掘真正的用户价值，并快速研发产品，帮助用户实现价值改进目标，从而利用产品来吸引客户”的策略。我把准确发掘产品价值称为任脉、快速研发产品称为督脉，要想这个策略落地，必须打通产品研发的任督二脉（如图1）。
经过近一年的迭代尝试，目前团队基本上打通了研发的任督二脉。打通后团队的感觉主要有：
业务分析更为聚焦。整体构建后，大家全部聚焦在要完成的共同目标上，共同参与，为产品出力；与客户的交流更为顺利。使用客户能听明白的语言，客户更容易理解，我们也更能控制产品发出的质量；
产品开发速度提升。产品开发的速度很快，每次的范围小了，也更聚焦了，演示时客户的参与度也更高，效果很好；
开发更有动力。每次与客户交流后颇有成就感，客户有期待，我们有动力，项目有进展。打通后团队现状是：
大团队第一阶段敏捷改进已结束,目前正在进行第二轮改进——小的特性团队,端到端交付；各环节目标一致,干劲十足；
把其他部门的团队合入该部门一起管理。
3.2 案例复现
下面具体说说案例的实践经过。
首先，我们需要在团队建立产品的用户思维，即所有的产品或服务要对用户有用，也就是说一定是对用户有价值的。基于这个出发点去判断产品需求优先级。
另外，建议产品经理要对用户思维辩证思考，用户思维不是盲目跟随用户看他需要什么我就做什么，而是深入共情用户，基于用户的场景，给出用户超预期的产品和服务。
3.2.1 需求优先级排列
之前团队进行产品需求分析和优先级排序的方法基本上有以下几种：
谁腿粗、嗓门大谁说了算：典型的管控型团队，“职级高的”“会吵架的”“经验老的”拥有话语权，这时候产品长啥样就得听领导的了，用户，谁在意呢！
技术先进代替客户需求：这是技术主导型团队经常出的状况，我们使用了最新最好的技术，用户就应该买单。
以上两种方法在语言上的典型表现是以“我认为”或“我想”开始发言，都是从自己出发，而不是从客户价值出发的思路。
那么该如何改进呢？
第一、引入用户画像（Persona），针对不同场景对用户进行分类，给每类用户建立用户画像（具体操作可参考相关书籍）。提醒一点：我们的用户画像是为特定场景服务的，所以不要脱离场景去制作它。
第二、制作用户路径图。通过移情图发现用户实际的痛点和利益点，并基于此制作用户路径图。用户路径图是针对具体场景、根据不同职能描述各职能在不同时间在做什么。到目前为止，我们都是在真实地描述用户的业务实际场景，并没有加入我们自己的主观意识。
第三、绘制人性矩阵。我们分析用户的行为中暗含的基本人性，研究用户心理是喜欢还是厌恶这种感觉。针对不同的用户心理，思考我们提供的产品或服务是否可以为用户实现某种用户价值。
到此，我们还是在研究用户行为，因为要让用户习惯使用我们的产品和服务，第一步就是要发现他们在具体场景下的行为习惯，并研究这种行为背后的心理和人性，然后通过提供超预期的产品和服务，逐步改变他们在具体场景下的行为习惯。
第四、确定业务需求优先级。完成了这些之后，我们就要基于客户价值确定业务需求的优先级。需要提醒的是：客户的优先级有可能是出于政治方面的考虑，这在平时经常容易被忽略，但是在企业级市场这一点很可能最后决定成败。所以，虽然有时我们觉得某些需求不是真正的业务需求，我们也得听从业务代表或客户的意见。
同时我们发现：如果项目不按照客户的价值排优先级，我们很有可能无法识别关键的成功因素。因为产品需求从用户中来，我们必须明确用户到底需要什么，然后把不同需求都列出来再确定优先级，这样产品逻辑才会更清楚。
基于客户价值进行优先级排序的常用方法主要有两种：
● MoSCoW方法
● Kano方法
以敏捷计划应用来说，敏捷团队和客户为开发协作选择用户故事，这些用户故事必须进行优先级处理。优先级处理常以价值和风险为基础，可运用MoSCoW 和Kano 方法和通过风险-价值、成本-价值指标执行。
要提醒的是，虽然在计划期间用户故事会做优先级处理，但敏捷团队和客户应以逐步完善（即增加知识和观点）为基础定期迭代审查优先级。
图2 Kano方法
Kano方法把需求分为以下四类（如图2所示）：
第一种 基础需求，是最基本、必须有的需求；
第二种 期望需求，满足这个需求用户会觉得你的产品还可以；
第三种 兴奋需求，这个很重要，它会让用户觉得你的产品太牛了，然后他们就会帮你传播，帮你制造好口碑；
第四种 反向需求，这是用户不想要的，也许你做了会挣到钱，但用户可能会骂你怎么搞这种东西出来。
基础需求肯定要做。否则产品就不成立。你能想象买个手机不提供通话功能吗？
期望需求尽量多做。期望需求的满足会带来用户满意度的线性增长，做得越多用户数越多。
兴奋需求最希望做。能够提升品牌度和口碑的兴奋需求投入较少，但带来的价值是呈指数型增长的，所以产品要时刻发掘这种需求。
反向需求尽量不做。
另外，对于企业级应用来说：
用户主路径上的关键需求必须做，并且必须按场景做全。也就是说，你提供的应用或服务的整个路径要跑得通，不能说采购下单了要付款的时候畅捷支付不能用、企业网银也不能用，这就有问题，至少要满足主流的支付方式。所以主场景路径一定要先做，分支场景路径可以到后面再做。
符合企业和项目目标的需求优先做。也就是立项时参照的企业目标是什么。这个根据企业的情况而定，如果是要保证现金流和利润，就满足挣钱；如果是让用户体验更好，就把用户体验放在第一位。这是团队自己根据企业目标设定的，和企业愿景、使命和战略息息相关。
用户覆盖面广的优先做。一般情况下参考2/8原则，有些功能可能只有20%的人在用，有些80%的人在用，这时候就优先做80%用户需要的功能。但如果你的目的是战略预研或树立某种品牌形象，那就要考虑让10%的愿意尝鲜的所谓内行和推销员去做口碑推广。
3.2.2 两大神器——影响地图、用户故事地图
下面介绍任督二脉打通的两大神器：
● 影响地图
● 用户故事地图
首先要明确产品设计的核心是什么？
关注给用户带来的价值，而非实现难度
关注给用户带来的便利，而非商业模式
关注你可以为用户做什么，而非有多少竞品
关注用户逻辑，而非运营手段，运营不是目的
没有脱离场景的用户需求，所以在定义需求的时候一定要明确用户的场景，以及用户需要获得的价值，如图3。
图3 用户 场景
打通任脉--影响地图
经过一个阶段的教练，团队就产品研发的目的达成共识：研发出好的产品，利用产品吸引用户。团队的所有活动都是围绕为用户创造价值而展开的。在团队内推动敏捷改进，其目的是为了更快和更高效地提供用户所需要的价值。
在产品分析阶段能够精准定位用户价值是非常重要的。所以我为团队引入了影响地图这个神兵利器。通过学习得知：对产品开发价值本质的认知是基础，只有把它们应用到实践中才有意义。而“影响地图”就是一个从产品开发本质出发的价值定义和价值发现的实践。
影响地图（图4所示）指出：产品是为人服务的，必须通过影响人的行为才能实现目标。这也是“影响地图”名称的由来。为完成从目标到功能的映射，影响地图要回答两个问题：
对什么人产生什么样的影响可以帮助目标的实现；
提供什么样的产品功能（或服务）才能产生这样的影响。
图4 影响地图
这是一张模拟的影响地图，其逻辑结构如图5：
图5 影响地图逻辑结构
从这张地图可以看出，目标、角色、影响都是从使用者的角度来进行定义的，而功能则是从系统提供者的角度来进行定义的。这样就在用户价值和系统功能之间进行了映射，明确了用户价值的实现依赖，并为开发实现功能给出了明确的价值定义，确保了团队对用户价值和功能的一致认可，避免了沟通上的浪费。
我和团队一起开发了很多套影响地图，因为每个干系人都有多个价值诉求，而其中很多都是我们系统的直接干系人，所以必须分析每一个价值，并绘制影响地图。如图6所示：
图6： 团队绘制影响地图局部
要注意的是影响地图不应该专属于某个职能，也不应该是某一时刻的静态规划。开发过程中，团队持续交付功能、获得反馈及其它信息输入，深化对产品的认知。随着认知的深化，影响地图不断地被修正、拓展。这一过程需要各个职能共同参与，影响地图是管理人员、业务人员、开发和测试人员共享的完整图景。
对于业务人员，他们不再是简单地把需求列表扔给开发团队，并等着最后的结果。通过影响地图，业务人员和开发人员一同完成从目标到产品功能的映射，明确其中的假设，并在迭代交付中验证这些假设，当假设被证明或否定后，应该对影响地图做出调整，如继续加强或停止在某个方向上的投入，或调整投入的方式。
对于开发人员，他们的目标不再限定于交付功能，而是拓展至交付业务目标。开发者除了知道交付什么功能，也了解为谁开发、为什么要开发。这样就可以更加主动和创新地思考，有依据地做出决策和调整。
对于测试人员，除了参与上面的规划和验证活动外，测试的责任不再局限于检查产品是否符合预定的功能，而是验证产品是否产生了预期的影响。如果没有对用户产生期望的影响，即便完美符合功能定义，也不是高质量的产品。
通过使用影响地图，团队取得了如下效果：
开发团队共同确认需要提供的用户价值，有了共同的愿景；
统一了做事情的目的和原因；
厘清了客户业务和我们提供功能之间的差异和联系；
更高效地沟通；
没有了过去“抱大腿”“纯技术”的现象。
在这个过程中，可以同步和用户确认所需功能的价值体现，减少了团队在开发过程中的路径偏差。
打通督脉—用户故事地图
做到这一步，我们拥有了体现用户价值的用户故事列表(ProductBacklog)，但还是以传统的条目化模块化列表呈现，团队在开发时还是不能尽快交付用户价值。这时团队的状况是：
传统的条目化模块化列表
无法明确用户场景
无法进行全景规划和讨论
需求无场景，讨论起来太复杂，非常费时
具体来说，当我带领团队完成影响地图之后，在使用敏捷开发的具体方法开展开发活动时，发现了一个问题：在2C的软件开发中使用用户故事基本没有问题，因为这些软件通常流程都不长，没有复杂的业务依赖和流程逻辑。而企业级应用流程通常较长，涉及多个角色和更多的环节，只使用用户故事会出现只见树木不见森林的问题，不能很好地确保backlog覆盖了最重要的用户体验路径，并且不能很好地按照场景进行优先级规划。
这就不得不说说用户故事的问题了，根据相关书籍资料，主要如下：
只见树木不见森林，重要的待办项容易淹没在各种细节中看不到全貌，因而难以排列优先；
不能方便地了解系统提供功能的完整性；
不能方便地了解系统提供的工作流以及价值流；
不能方便地利用递增和迭代的方式确定发布计划以及发布目标。
也就是说，用用户故事在我们开始进行产品或项目规划的时候，首先需要梳理出一个backlog，在其中按照优先级列出要实现的场景和具体功能。这时我们遇到的问题是：如何确保backlog覆盖了最重要的用户体验路径？是否我们当前所规划的场景确实可以为用户提供价值？这些问题单纯使用用户故事不能很好地得到解决。
所以必须要打通督脉，我采用的工具是用户故事地图。用户故事地图聚焦于需求梳理阶段，帮助我们解决这些问题。
为了让团队更好地使用这个工具，我增加了场景说明并且将用户活动定位为用户的业务活动，而将task定位为系统提供的功能，根据具体场景将在场景中的用户需求用对应于task的用户故事来表现。发布可以包含多个场景，但一个场景不能被分到多个发布。如图7所示。
图7 用户故事地图
我们规划发布时要先进行场景的优先级排序，用户故事的优先级由所属场景决定，当我们规划迭代时，场景及其故事会被整个放入迭代，而不能单独放入。
我们进行一段时间的试验，获得的改进效果如下：
按照场景进行需求阐述，统一了团队语言，提高了研发效率；
场景化的优先级排序，交付客户更有价值；
多层次计划，有了高层次视图；
开发、咨询、实施有了统一的表现形式；
每次开发迭代都能提供有价值的产品，提供了团队自信度、动力和效率；
提高了客户满意度。
周天循环方法-快速验证
使用用户故事地图解决了场景规划和迭代规划问题，但是在具体的实现方案上，还存在如下问题：
同一场景不同角色会有不同的解决方案，大家开会讨论，谁也不服谁，变成了吵架大会；
用户对产品不满意；
Sponsor也不满意。
这时团队已经有了很好的敏捷思维，为了提升发布质量、避免不必要的浪费，我们引入了进行周天循环的方法-快速验证，即无代码客户验证。该方法指在需求分析阶段，根据发布计划、需求和设计，将下一发布需要做的场景使用线框图进行绘制，如果可能，将核心功能制作成纸板模型，带着这些模型，在发布计划开始之前和客户进行面对面的确认和沟通，确保我们所做的设计是符合或超过用户需求的，如图8所示。
通过这种方式加快了用户反馈的频率，提升了客户满意度，降低了需求变更数，提升了生产率和产品质量。同时，当产品需求和产品开发意见不一致时，双方各自按照自己的设想，制作线框图原型，拿到客户和相关干系人处进行PK，以确定最符合客户预期的方案，增强了产品和开发的理解，化解了双方的对立，强化了沟通交流的效率。
图8 某项目线框图原型
通过这次改进，我们取得了如下效果：
快速编制原型，快速和客户确认；
开发和产品各自出方案，以客户价值和客户认可为依据；
快速开发；
促进对客户价值和客户体验的深度挖掘和实现；
促进了人员技术和业务能力的提升。
关于MPD
MPD是Make Professional Discovery的缩写，MPD工作坊是一个围绕岗位角色发展的实践课堂，是由全球软件、互联网企业教练、一线研发团队带头人联合开发的角色胜任能力模型，是一种持续实践、创新驱动的团队管理提升培养项目。
MPD工作坊按照软件研发中心的岗位职能划分，以产品经理、团队经理、 架构师、开发经理、测试经理作为五个分会场命名，以促进角色的共鸣思考、深度探讨、相互交流。
