敏捷需求管理的why

在上一篇起手式里已经提过，敏捷项目管理的管理核心目标是价值，那么在开始一个敏捷项目的第一步，一定是确定这个项目的价值目标到底是什么。那到底怎么确定呢？我们从一个最常见的场景开始：

KBU：我们想做一个APP，这个APP可以让买我们车子的用户来使用，他们可以通过这个APP来预约保养，维修，也能在这个APP上下单购买零配件。

这个场景，我相信很多IT的从业者都经历过，业务部门的人员找到IT人员，提出一些想法，然后IT的人员开始和业务部门讨论需求，业务部门要这个功能，要那个功能，而IT的人员则收集这些功能，做可行性分析，然后定预算，发包，采购，一切按照既定的流程和制度把这件事情推进下去。

但是，如果用敏捷的方法来做这个项目，这些行为都发生的太早。

IT人员问的第一个问题应该是：WHY？为什么你需要这些功能？这个时候，KBU会根据他们的直觉反应告诉你他们的答案，这些答案往往是，我们要让用户有更好的体验，我们要为用户提供更好的服务，或者我们要提高售后服务的效率，等等等等，这些回答都不错…..但是……还远远不够。

我们第二个问题还是WHY？我们为什么要让用户有更好的体验？为什么要为用户提供更好的服务？为什么要提高售后服务的效率。

这时，KBU往往会一脸懵逼，什么？这样的问题也要回答？？是的，这些问题非常值得回答，回答这些问题的过程其实是KBU和IT一起去探索和发现这个软件系统真正的价值目标。这些问题的答案，最终会指向一个目标，而这个目标应该和公司的经营目标相关联。就拿我们这里举的例子来说，来看看我们是怎么来探索的：

这是真实发生的对话场景，经过一系列的提问和探索，我们识别出，KBU要的那么多功能，最终指向的目标是：通过APP引流更多的配件销售，以提高售后配件的销售额。

对于KBU提出的其它需求，也可以用这样的方法去探索和发现真正的目标。关于需求探索和分析的过程，可以参考5个WHY的方法，直到问到和公司经营目标，愿景和使命相关联的项目目标。但是光用5个WHY还不够，这里还有更多的技巧，包括同理心，放下已知，关注全貌，等等。这些方法 Eric 老师做过一个分享《问对了问题，才能搞定客户》里都有提到，这个讲座干货很多，有兴趣的同学可以自己去搜索一下。（只是我个人并不喜欢“搞定”这个词）

总结一下，一个软件系统的价值目标应该和公司的经营目标相关联，公司作为一个经营实体，盈利是最最根本的目标，如果没有办法找到一个软件项目和公司经营目标的关联，那这个软件系统的定位很有可能存在很大的问题。以下是一些比较合理的目标：

营收增长

降本增效

提高质量

风险控制

而下列则是一些不合理的目标定位，对于这样的目标，应该继续问WHY，直到问出和上述目标相关的程度：

    x        领导要求

    x        创新

    x        政治任务

    x        提高KPI

到了这里，我们终于踏出了一步，很小的一步，但也是很重要的一步。第一式 WHY到怀疑人生，并不一直在问WHY，也会问一些WHAT，也会问一些HOW，最终得到的一个结论，是一个符合SMART（Specific, Measurable, Achievable,Reasonable, Timely）要求的描述：

继续围绕我们上面的例子展开，现在Specific已经完成了，并且是符合Relevant的要求了，我们接下来需要界定价值目标的边界。这个增加营收的目标，我们应该怎么界定它的边界？我们有这些选项：

• 以APP上下的订单金额作为目标

• 以APP上完成支付的金额作为目标

• 以一段时间内的整体增量作为目标

• 以一段时间内的总销售额作为目标

如果说我们把价值目标界定在“在APP上下单或者支付”，那么这个项目努力的方向会是引导用户在APP上完成下单，这很有可能导致的结果是，把原先就在线下订购的用户转变成APP订购，这对整体的增收是不会有帮助的，这不是我们希望看到的结果。事实上，用户有可能是通过APP引流的，但不一定在APP上下单或者消费，我们或许不必太在意他是通过什么渠道下单和支付的。基于以上的考虑，我们最终的目标边界是：通过APP引流更多用户，以增加售后配件营收。

到这里也许有同学们会有疑问，销量增加，也有可能是因为别的因素导致的，比如说增加了广告的投入，或者增加了促销的力度，那到时候怎么说的清楚到底是不是这个APP带来的收益呢？这是个很好的问题。企业确实需要关注营收波动背后的因素，将来可以更有针对性的调整经营策略。但是围绕这个问题可以展开很多的探讨，这并不是我们当下最关注的东西，所以就不展开了。

接下来一步，要完成Measurable，即可衡量的。既然我们做这个APP的目标是为了增加售后营收，那么要增加多少呢？什么数字才是合理的呢？首先，我们需要知道当前的真实状况。同学们应该都知道，一个品牌的汽车，一般来说每年需要更换的零配件都是差不多一致的，比如第一年只要换两次机油机滤，第二年可能要换火花塞了和两次机油机滤了，第三年多半要换两次机油机滤，还有空滤，汽滤了……一个汽车厂商一定有这个市场上的车辆和车主数据，如下表（数字都是瞎编的，但是逻辑是成立的）：

注：忠诚度是指采购原厂零配件的车主比例

根据上表，我们可以计算出当前的实际一年的售后配件销售额。然后，我们要定一个预期的数值，具体定数值的方法和过程这里就不展开了，我相信不同的项目，不同的领域，不同的团队做法都不一样，也不可能存在一个统一的方法。在这个例子里，姑且把这个数值定在3000万，那么我们现在Measurable也完成了。

通过以上的分析，我们就能看清这个项目努力的方向，即提高年限较高车辆的车主的忠诚度，这样做的收益是最高的。明确了这一点以后，我们可以更广泛的开拓我们的思路，比如说对于年限已经较高的车辆车主，我们需要采用更丰富的手段让他们能看到，了解到并下载这个APP；我们可以考虑和二手车的销售或者新车置换的环节打通，让这些车主继续购买我们的车子。

所以总结一下Achievable，我们定的价值目标，需要是可达到的，基于现实和客观分析的结果，当然也不能违反法律法规，或者公司的一些硬性规定。

最后说一下Timely，任何项目都有一个时间目标，很多项目对于时间约束都很随意。对于时间目标，我们也需要问WHY，为什么要定这个时间，不是早一点，也不是晚一点？有的时候，项目的时间目标是由某一个领导拍下来的，不容妥协，这种情况下，更需要去了解清楚领导为什么要定这个时间，他这么坚定的要求这个时间节点一定是由某些因素驱动的。充分理解时间目标背后的驱动因素，能帮助我们在后续的分析过程中可以更好的围绕这个驱动因素做文章，有更好的指导原则去排列需求的优先级。

最终我们的例子的SMART描述是这样的：通过APP的售后功能引流更多的售后配件销售，在2018年实现售后配件3000万的增收。

在SMART描述是有了，但是还有一件事情需要关注一下，那就是管理好分析过程中的各种假设，事实上管理假设是应该贯穿在整个项目过程中的工作。对于假设管理，我总结的思路是这样的：

首先我们要发现和识别我们做的假设，然后对于不同的假设，我们可以采取满足，打破和验证这3种不同的策略。

回到我们刚才的例子，我们定下3000万的配件增收的目标的时候，实际上我们就做了一个假设：我们把车主忠诚度的提高到了某一个数值。因为在车辆总量和零配件售价不变的情况下，我们只能通过提高忠诚度来提高配件销售，只有忠诚度提高到某一个数值的时候，才能实现3000万的增收目标，所以对于这个假设，我们需要采用的策略就是满足它。本质上说，这个APP就是为了满足这个假设而设计和开发的。

另外举一个需要打破假设的例子，我曾经了解过一个工作流的系统的一个需求变更请求，KBU希望我们可以在一个流程的某一个节点增加一个功能，这个功能是做附件是否上传的判断，用于阻止员工在必须上传附件的时候没有上传附件而把流程提交到下一个环节。本身看这个功能其实挺合理，而且也不难，但是实际情况是由于一些历史原因，这个工作流系统经过了很多年的演变，各个功能的耦合度很高，要实现这个功能的复杂度非常高，技术上评估下来大概需要好几个星期，而且存在很高的风险会引入新的问题。这个时候我们可以审视一下这个功能需求背后KBU做的假设：员工会忘记提交工作流所必要的附件。如果这个假设不成立，那我们也不需要冒着风险去折腾这件事情了。所以我们就去调查了一下，发现过去的很长一段时间内，真正经常忘记提交附件的员工只有1个人，所以其实这个假设是不成立的。即使这个假设成立，在我们面临的实际情况下，我们也应该去分析一下到底是实现这个功能的成本高，还是打破这个假设的成本高，比较一下，就很容易得到更合理的答案。

第三种管理假设的策略，就是验证。验证假设也分成两种情况，第一种情况是对外部依赖的假设。比如说我们要做一个电商平台，需要和第三方提供的支付接口做对接，我们现在排的计划是在3月底可以完成系统的上线。那这里的假设就是支付接口会在3月中旬的时候就能就绪，以留出几个星期的时候让我们可以对接联调，这个3月底的时间目标才有可能达到。对于这样的假设，我们就需要持续的去验证是否还成立，这个假设一旦不成立的话，那我们的时间目标也会被影响。第二种情况更多的适用于一些未知领域或者创新领域，比如说我们有一个想法，但是我们并不知道这个想法是不是可以真正的得到收益，这个时候我们会主动的做一些假设，比如说假设市场上存在某种用户群体，并假设这个用户群体有多少数量，然后基于这个假设去设计和构建我们的系统，那对于这样的假设，我们也需要要设计一些对应的方法和手段去验证，如果这个假设是成立的，那我们可以继续这个产品的迭代，否则，那我们的产品可能就需要中止。

这里再容我展开一下对于主动做假设并去做验证的这种策略，同学们是否还记得上面提到过的一些不合理的价值目标？里面有一条是“领导要求”。讲道理，对于领导要求，我们应该尝试去理解领导为什么要提这些要求，只有摸清领导要求背后的真实意图，才能真正交付出领导想要的东西。

但是我遇到很过情况，KBU对于“领导为什么要提这个要求”这个问题的反馈是“我不清楚，我也没法问”。

OK，我们权且就当这种情况真切的摆在我们面前好了，这个时候我们也可以用到“假设-验证”的策略。我们问不到了解不到，但我们可以猜啊！我们一条一条的假设领导的真实意图，然后围绕他的真实意图去一点点的分析，一点点的构建，一点点的验证，我想，没有任何领导会拒绝下属们尝试去做出他真正想要的东西吧？

最后需要强调一点的是，找到价值目标是一个IT和业务部门共同探索的过程，而不是一个问与答的对峙，更不应该把它当做划清职责边界的工具。业务部门需要厘清他们功能需求背后真正的驱动力，IT也同样需要知道，因为这个目标是大家共同认可和努力的方向，基于对一个共同目标的认知，可以从源头上消灭很多部门和部门之间的利益冲突。

总结一下第一式的要领：

软件的目标应该和公司的经营目标相符合

需要澄清价值目标的边界

管理好各种假设

共同探索，而非职责边界

本文由@合气大蒜 原创发布于管理圈，未经许可禁止转载。