以下文章来源于CKL的思考空间 ，作者CKL的思考
一直以来，作为研发人员，我们关注的都是研发任务的端到端交付（从需求澄清到需求交付），很少有人会去关注需求本身是否给产品或者企业带来多少真正的价值（如激活了多少存量用户、吸引了多少新用户等等）。今天我们跳出研发的角色，聊一聊需求的端到端交付管理。
上图直观的反映了当下交付需求的不确定性。往常，我们只需要根据合同或者行业成熟的解决方案，定期交付我们的产品，然后按合同收款即可。但是现在时代发生了变化，产品已经过剩，业务的波动性、不确定性、复杂性以及模糊性，导致我们不可能再按部就班的进行产品交付。因为客户的需求变的不那么明确，世界的变化也太快。“躺赢”的时代结束了，“躺枪”的时代来临了。多少产品是被降维打击给弄消失了的。
如果一个需求最终客户不买单，或者不乐意去使用，那么它的研发过程无论多么优秀，都是研发人员的自嗨。所有需求都是为了交付业务价值，是实现价值交付的关键。我们通过业务意向交付产品，继而运营验证发展、探索新的思路，支撑、加速业务愿景或者目标的实现。在这个过程中，产品缺乏对应的抓手来验证新特性对运营的影响有多大，需要研发团队提供对应的生产数据（通过埋点或者日志分析），当我们提供了足够丰富的数据支撑时，才能更好的帮助我们验证、探索新的方向。
在以往的模式下，研发团队更多的是在关注把概念转化成产品的过程。在这个过程中，产品提出需求（“正确的事”），研发负责把对应的Idea落地成产品（“正确地做事”），最后由测试和产品一起来验证最终的产物（正确的验证结果）。但是我们缺少了对产品价值的验证（是不是正确的事？）。传统的瀑布式研发过程中，往往到了项目上线后，我们才有机会去验证产品的商业价值是否能够被兑现，在需求比较明确的产品形态中，这类研发过程是可以高效地进行。
但我们现在身处的是VUCA时代，市场环境瞬息万，如果我们等到最后才去验证价值，万一出错，那么很有可能被市场抛弃。在敏捷的理念支撑下，我们可以做到快速验证产品的商业价值，当数据反馈的结果不如我们的预期时，我们可以有调整的余地以及快速的响应变化。面对失败，我们会提前感知，做到快速失败、安全失败及经常性的失败。
快速失败：在敏捷的体系下，我们的发布节奏会变快，这就给我们提供了更多试错的机会成本。原来2个月或者半年发布一个版本，我们的试错周期是2个月或者半年，但是当我们把节奏变成2周或者3周时（这个会根据每个团队进行调整），我们试错的机会是不是变多了呢？客户并不需要全部功能都实现后再去体验产品，往往他们只对其中的某些功能感兴趣。
安全失败：因为验证的次数变多了，那失败也会变的安全些。当我们现在某些功能有问题或者与客户的真实需求不匹配后，在传统的模式下，我们要到最后才能发现，那么可调整的空间就很小了，客户不满意，往往意味着项目的失败。但是在敏捷的环境中，因为我们的发布周期变短，和客户沟通验证的机会变多，那么可调整的时间也会变多，可以更及时的做出修改，是不是更安全了呢？
经常失败：经常失败并不意味着真的失败，而是因为我们的目标也是在不断调整的。举个例子，在大草原上，猎豹捕捉羚羊，猎豹从A点出发，羚羊从B点出发，最终在C点，猎豹把羚羊抓住了。从最终的结果来看，猎豹跑的每一步都可能是错的，正确的做法是它应该直接跑到C点，但是这并不可行。我们的产品其实也是一样的，当我们经过了多次的失败，验证了很多错误的尝试后，剩下的，很有可能才是正确的路。
如何验证需求是否真的产生了价值，需要我们通过埋点等手段，获得真实的数据后，再做判断。
在当下的敏捷环境中，有很多优秀的敏捷实践，例如Scrum、XP、Lean、看板等众多流派。其中Scrum是应用最广泛的一种实践模式。它相对简单（3355，具体在这里不展开介绍），团队适应的可操作性也会强些。在上图中，我们通过Scrum的常规流程，很好的映射了那些“正确”的事。但这些还是在研发领域的解决方案，我们并没有很好的机制去判断“正确的事”它是不是正确的。
如何选择“正确的”事儿？敏捷中有一个名词叫MVP（Minimum Viable Product最小可行产品），如上图，用户的需求是需要一辆车，图一呢，就是从车轮子到车底盘到车架到完整的汽车的过程，在这个交付过程中呢我们的车都是不可用的，再来看第二幅图，从一个滑板到滑板车到自行车到摩托车再到汽车，在这个交付过程中的每个阶段，我们都有车可用。回到实际的产品交付过程，我们面对一堆的需求，第一反应其实就是我们能够交付哪些功能，而真正我们期望的是MVP方式交付。
在上面的例子中，虽然这个过程客户也会骂娘，但至少能够解决客户的一部分痛点，建立信任（这个很重要），而且，客户的真实需求真的是要一辆车么？这个其实也是有待讨论的。因为客户的需求可能并不是一辆车，他也许只是想从A地到B地转一圈。下图其实就是一个经典的需求不对称。是不是很熟悉。
最后，我们如何尽可能快而稳定地进行业务验证，做好支持服务呢，总结下来有以下几点：
对于正确的事，我们希望：高价值的业务优先被验证，需要分解成MVP，以便于交付验证。
团队对于MVP的确认形式，希望做到业务可验收，研发可交付，测试可验证及最后的部署可交付（符合INVEST原则）。研发团队按一定的流程规范正确地做事。最后得到一个可验证的结果，通过线上真实数据的获取和分析，便于产品同学验证价值，加速业务最终愿景或者目标的实现。
后续将详细拆解“正确的确认方式”，敬请期待。
