现如今，很多企业在项目研发的体系中走的基本是敏捷流程。对于敏捷开发而言，其中最关键的要素是增量开发和需求渐近。
因此，对于敏捷开发大家最关心的是如何做好需求的精益管理？如果需求管理做不到位的话，敏捷就算运行得多么流畅也没有意义。在整个敏捷开发过程中，精益管理和敏捷运作相辅相成，两个同等重要。
为此，5月30日，解放号社区推出的【如何应对外包中的撕逼大战】系列课第二课中软国际培训学院高级讲师马爽在荔枝微课上为大家直播分享了《精益求精需求管理》话题，本次课程从精益思想、产品愿景、用户画像、用户故事四个方面进行了分析和讲解，干货满满，赢得了学员的一致好评。
简介：西北工业大学软件工程硕士，曾就职与微软亚洲工程院、IBM中国系统技术实验室，历任软件测试经理、软件开发负责人，现任中软国际 华为业务群 流程IT iBuy产品经理，熟悉Scrum XP等敏捷方法，有丰富的敏捷实施经验，在产品推行敏捷过程中承担过敏捷教练，指导过多个开发团队的敏捷转型。
人类经历了机器革命和工业革命后，正处于一场信息技术革命和数据爆炸的浪潮之中，在瞬息万变的时代中，谁能真正掌握住市场需求的变化，就能成为真正的赢家。
但在对软件项目的调查中发现，人们往往会把大量的精力投入到价值性不高的事情上，对于价值性高的事情只投入20%的精力，这是什么原因呢？
在原来的产品远景上，瀑布式开发更多强调的是计划。在软件开发过程中，如果按照计划推演，根本前提是我们能一次性完成需求的澄清和描述，然后根据需求推演计划，最终完成项目的管理和软件的开发。
在信息爆炸的时代，需求讯息万变，我们往往不能在前期就一次性做好需求的澄清和规划，这就导致在瀑布式开发中研发和资源的大量浪费，可见传统式的研发体系远远不能适应市场需求这种短而快的变化，也不能适应现在这种软件开发模式。况且，不断地进行需求的更改和计划的把控，这对研发项目本身就是一个痛苦的过程。
从上图可看出：一个渐进的过程，如果没有回馈和需求精益管理方式的话，就会完全脱离客户的真实需求，因此需要双向的需求传递方式来实现这个渐进的过程。
需求精益管理是敏捷的一个配套方法论。需求精益管理搭配敏捷需要做什么？从我们的观察、判断、决策、行动，每一个迭代都需要有一个回馈。回馈主要是用于跟客户确定需求，进一步的需求论证，保证真正实现客户的预期。
精益思想的提出，要推演到二战结束时期，最早是由日本丰田提出的。
二战结束后，在所有物资都耗尽的情况下，丰田不得不考虑需求的精益和定制化的生产，考虑它与原先的生产模式有什么区别？其中原先生产模式最典型的代表就是福特。福特拥有完整的生产线，这种生产线工作流的定义最就是不考虑真正的市场，只按照产能来定计划，能生产多少就生产多少，至于销售量就是销售和市场的问题，这种我们认定属于粗放型的模式，比较适合福特的大规模的生产。但是到了日本的丰田，考虑到资源的匮乏，它并不能采用这种粗放型的生产模式。为此，丰田考虑的是定制化需求，量需生产，根据客户不同定制化的需求来生产不同的产品，适配客户真正的需求。从这可以看出，把握市场瞬息万变的变化，就是丰田需求精益管理的来源。
求需价值驱动和计划驱动有什么区别？
计划驱动：计划关注完成任务，前期定范围，由范围来推成本和时间。关键问题是，投入成本和时间之后，反向推演的时候发现范围已经变化了。
需求价值驱动：在既定的成本和有限的时间里去反推，通过快速迭代的方式不停地跟客户回馈，最终验证需求渐近，以此来推演版本迭代的开发，这就是需求价值驱动跟瀑布式研发的根本区别。
如果想做好需求精益管理的话，必须规划远大的产品远景。
历来，在各种大型的成功产品中，至少要有3-5年的远景和坚定的信念才能成功。
比如华为：从交换机起步把握住了市场的需求。可是随着通讯时代的技术变革，人类对资讯的要求越来越高，而华为顺应时代的变化，以前固话的费用比较高，现在座机免费安装，降低移动资费，华为为人类的通讯生活提供了便利和优质的体验。
比如淘宝：马云能够快速察觉市场需求的变化，主动地挖掘市场需求。通过自身的需求远景去创建需求市场，以至于马云打造了电商的神话。马云经过多年经营，绑定了用户消费者的习惯，卖家的习惯，通过大数据把握住了时代的变化。马云看到市场的需求变化，然后根据自己的切实需要，把握产品的远景，保证技术方向符合需求变化。因此，淘宝的不可复制，取决于马云能快速响应需求的变化，把握电商时代的需求。
再比如滴滴：滴滴先是看到了资源共享的需求，然后集中了很多司机来实现利益的共同体，服务我们人类的出行需求，最终改变了人类的出行方式，让我们出行更便利。
以上这些产品，最典型的标志是对产品的远景有坚定的信念。俗话说：“一个产品看不到自己的需求远景，是做不好产品的。”
我们再来看一个典型的远景案例：中国高铁现状
在以前，北上广的经济圈坐车需要一天以上。小经济圈坐车最少也得2小时以上，而且用户体验相当差。为了改善这种体验，国家对于高铁的目标规划为：三大经济圈的通行时间要缩短到8小时以内，小经济圈缩小到1小时以内，达到上班通勤时间。
规划了需求远景后，那如何做好产品呢？最关键的是干系人分析。
干系人分析中最关键的考量指标：
用户对产品感兴趣的程度；
用户对产品成败影响的程度。
干系人核心用户群:
第一层：项目经理、产品经理、客户方和合作方的代表；
第二层：QC人员、开发人员、运营人员；
第三层：运营商、物流等等。
在很多经典的案例中，就是因为产品干系人的不明造成项目的失败。比如国内的大型的公路项目，因为没有考虑环保人士的诉求，导致了项目的停工和改期重新规划。因此，我们应该近可能多地穷尽产品的干系人。
而在干系人分析中，应该更多考虑用户的画像，这是一个共情的概念。所以我们要先思考是站在自己的角度还是站在甲方的角度？用户想要什么以及用户需求的来源？如果不能站在用户角度考虑问题，就不能真正理解用户的需求，为什么？怎么做？
对于用户画像，我们应该更多考虑用户的特征，用户在什么条件下会提出这样的需求，对产品的期望如何？可以这么说，干系人的分析和识别，对项目后期不停的回馈和沟通起到关键性的作用。
用户画像出来之后，我们开始进入用户体验的推演。
实际上，用户体验的推演就是一个情景模式，在一个用户场景中开始整个工作流的推演，发现用户的痛点在哪，用户的期望是什么？
在这里给大家讲一个联合国组织尼泊尔保温箱的案例。
在贫穷落后的尼泊尔国家，婴儿出生后的存活率非常低。因为在当地昼夜温差大，导致婴儿没有得到及时的保暖，为此联合国想要快速解决这个问题，便研发了一项高科技产品——保温箱，这款保温箱不仅有恒温功能，还有报警监控，可以随时关注婴儿的体温状况，保证婴儿的存活率。但是，实际的反馈却是婴儿的死亡率根本没有下降，为什么呢？经过反馈发现，尼泊尔那些贫穷落后的国家连电都没有，保温箱根本用不了，这对于婴儿存活率提升这个问题可见不是一个切实可行的方案。后来，他们决定采用先进科技的隔热材料，研发了一款保温被褥才得以问题解决。
事实证明，并不是高大上的产品就真正适合用户使用，切合用户的生活场景的产品才是用户需要的。
需求是渐进的，我们要通过快速的迭代完成增量开发。
首先，我们一定要先做需求原型，再做产品开发。
需求原型做出来后，我们再用demo show的方式跟用户推演工作流程的功能变化。通过这么一个流程，其作用是核对用户的真实需求，我们通过定义原型可以极大程度规避需求渐进和需求不明的风险。如果没有需求原型匆忙上线，可能就会发现最终完成的不是用户真实想要的效果。因此，前期需求原型图相当重要。
对于用户的需求，产品原型分为低保真、中保真、高保真3种模型（3种模型的区别见下图）。
其次，就要考虑到快速迭代，而迭代就是需求渐近和增量式开发。
在敏捷的概念中，更多的时候我们要进行功能需求的拆解和解耦。如果需求不能解耦，就没有办法通过增量式开发快速迭代，这就需要我们考虑需求的拆解节奏。这就涉及到用户故事，用户故事不是研发的最小单位，它是用户验收的最小单位，它讲求的是能够单独验收。如果说我们用过敏捷项目，就要考虑用状态墙。不管是手动维护的还是电子版的状态墙，我们都是把所有的需求通过feature、testsotry的方式放到状态墙中，来看整个进度处于需求澄清中，开发中，测试中，客户验收中，还是什么状态，看看它们之间相关的关系，整个的场景和版本的变化，都是在状态墙中演进的。所以，建议状态墙放在项目中，通过每日早会的方式去过各种需求进度和整个需求渐进过程。
如果要通过敏捷的方式来拆解团队的话，我认为一个敏捷scrum团队人员最好不超过10个人。因为很多敏捷团队都是通过快速迭代和小团队规模的渐进方式来达到软件快速研发任务。
那对于一个大型的项目应该怎么办？我们可以通过需求的分解来进行大项目的管理，再通过层级套用的方式开始研发任务和项目管理的拆解，达到需求的管理和敏捷演进。
接下来，我们来看一下需求管理的场景识别。
一个完整的场景识别分为：用户场景、用户用例和用户故事，这里主要讲一下用户故事。
用户故事是描述业务需求的一种模式，遵循Invest原则。用户的故事必须是一个最小单元，可以解耦。用户的故事有一个标准的概念，用户故事首先必须是一个最强的科研单元。
对于用户故事这个关键环节，主要是它能够描述出用户的基本动作。比如说：用户想要什么？如何去达成？这就是一个标准的用户故事。
如果说敏捷迭代中我们进行需求管理，首先要把所有的需求拆解成用户故事，再把需求放入backlog（需求池）里，最后进行需求价值管理。对于需求的价值管理主要是根据用户的迫切性、资源的消耗、实现的风险、技术的可实施性来进行精益需求管理的排序，然后根据需求的排序定用户故事。
而在用户故事拆解时，我们首先要考虑用户基于什么样的角色？希望做什么？通过什么样的方式去达成？
其中，用户故事最基本的要素分为以下6个要素：
1.可以独立交付，可验收；
2.可以进行协商，可以单独定义并进行功能的演进和开发；
3.必须是有价值的；
4.可以去被估算工作量的；
5.可以测试的；
6.一个合适大小，在一个用户故事不应该超过5人，否则没法进行快速迭代和需求管控。
用户故事拆解完毕后，我们根据价值排序，把需求放入需求池里，再将排序需求放入迭代版本中开始渐进开发，最终通过持续集成、增量交付针对产品主线达到需求渐进和增量式开发软件鉴定的模式。
因此，我们把敏捷迭代中的关键过程分为：
进行收集需求的精益管理；需求的排序；
根据需求的优先级开始版本迭代；
在迭代的过程中通过我们的DevOps的方式进行回馈，跟用户讨论需求变化；
在下一个迭代中进行持续的改进；
通过这种快速的迭代的和这种需求精益管理的这种方式来达到软件智能快速开发。
由此可见，敏捷的迭代和需求的精益管理是相辅相成的。
对于评估人员来说，在优先级定义方面，一个需求它到底优先级高不高，要不要排入迭代版本并不是一个简单的过程。
一般在需求排序中，我们要考虑以下个几个方面：
是否能解决用户的关键性痛点；否能响应市场的观念性变化；
是否有足够的市场粘度粘性，来帮助我们绑定用户；
风险和资源耗费能否在版本预期之中，快速演进规模范围之内。
需求的价值排序，这是一整套的科学方法论，不过其中有几个关键定义需要注意：
Must have：必须要有的，权重更高，其前提是可投入资源是可以达到的，60%-80%；
Should have：我们应该去做的，用户有非常大的预期，也是用户想要的；
Could have：可以根据版本规划适当的排布；
Won’t Have：是可以不做的，没有多大价值，必须避免。
在这4个定义中，must have是权重最高的，必须要做的，达到了一个版本的60-80%，但并不是说should have和could have就不做。在技术变革和演进中，Should have和Could have也要预留一定的空间，保证产品不断地更新换代，技术更新。
需求排序好后，接下来最重要的一个环节是对于工作量的估算。目前流行的两种工作量的估算方法如下：
1.经验估算法
经验估算法一般是针对类似的功能以及功能的复杂度与历史的经验值对比，来推演出新的story的工作量估算，从而实现迭代容量和版本技术的排布。
经验估工法的优点是简便易行，工作量小，制定定额快，并有一定群众基础。缺点是单凭经验，技术根据不足，受估工人员主观因素的影响大，难免出现偏高或偏低等现象，因而定额的准确性较差。
2.Delphi法
Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术要求有多种相关经验人的参与，互相说服对方。
在一个敏捷团队中，Scrum master不是一个专业的岗位，更多是充当敏捷教练和引导员的作用，讲求的是共同承诺和集体管理，以及每个成员的效益最大化，提升成员的工作积极性。所以在一个敏捷团队中，不要用计划式的方式去硬性摊派工作，更多的是通过像DD交付方式，让大家主动认领工作，实现承诺，所以我们更多采用Delphi法。
Delphi法是通过Scrum master做需求澄清，每个人通过投票的方式来评估开发这个功能需要多少开发量。从中抽出两名人员（一个工作量最多的和一个工作量最少），分别讲一下为什么做这项工作需要这个工开发量，然后进行二次投票，达成共识后，推进投票的演进，不断确定目标的一致性和科学性。当然，投票过程不是无休止循环下去，需要一个技术领袖进行仲裁，实现技术的验收。
需求精益管理更多的是一种概念，理性地站在用户的角度去思考用户的痛点，分析用户的需求，规划产品的远景。再通过敏捷迭代进行需求架构，对原先设计版本推演进行产品快速迭代和需求渐近，而在每个版本迭代中都要有回馈的过程，运用DevOps的方式去跟用户认证需求的变化和需求的演变。
在整个过程中，通过精益需求管理决策的方式，就可以达到明确应对需求的瞬息万变的目的，通过推进需求的快速开发达到契合用户的真正需求，从而实现产品的成功。
解放号社区系列课：“如何应对外包中的撕逼大战”系列课程下期活动预告
活动时间：6月6日晚20:00~21:00
课程主题：《如何避免项目交付后扯皮》；
主讲：中软国际解放号特邀讲师白仕云；
课程形式：荔枝微课在线直播
