团队如何有效应对越来越多的需求？

很多团队成员经常会感叹：为什么需求总是像潮水一样？我们也在做敏捷，但是为什么感觉快不起来呢？ 

业务提需求的速度远远大于研发的处理能力，需求的累积就像蓄水池一样，越来越多是必然的结果。后续需求等待排期的压力也会越来越大，导致研发不得不疲于奔命，依靠加班缓解这种紧张的局面。

靠加班终究不是解决问题的最佳方法。问题的关键是，这些需求池中的需求都是有价值的吗？依据二八原则， 80%的价值是由20%的需求创造的，如果能有效筛选出20%的高价值需求，及早淘汰掉80%无价值或者低价需求，不仅能极大提升交付速度，同时可节省大量研发成本。

什么方式才能更有效的淘汰那些80%的无价值或者低价需求呢？ 

延迟决策， 在需要的时候才开始做，过早或者过晚都会造成浪费。这是精益所强调的准时制（JIT, Just In Time） 。JIT是精益理论的重要组成部分。

过晚， 延误了时机会造成利益的损失；但是在缺乏足够有效信息或者真实反馈的情况下，仅凭借假设过早大批量的开始，同样会造成巨大的损失。可以想一下，有多少投入了研发大量精力和成本后上线的需求， 实际利用率很低或者收益率很低。

要做到JIT，就要舍弃那种一次性详细计划一个大盘子需求的思维，不仅周期长， 且存在浪费。

推荐的做法是：开始只对少量紧急且高价值的需求进行详细的方案设计(其余需求适度进行规划)，然后快速进入迭代开发（通常是前1-2个迭代） 。在1-2迭代进行过程中，产品经理会进行3-4迭代（大致的时间范围）的详细方案设计。这期间会参考前面完成需求的反馈情况，及时作出增删改的需求调整。如图1项目实例：

这样做的益处是：每次进入开发前，都有调整需求的过程，使得需求更接近真实的场景，从而减少了开发资源的浪费；另外，因迭代周期很短（通常2周），每次迭代开始前， 产品和业务都不得不通过2/8原则进行艰难的抉择，进入下一轮迭代的都是经过筛选的高价值需求。

精益创业也表达了类似的思维。在进入正式开发前，对业务模式的假设进行快速轻量级的试错与验证（过程中可能会有少量开发， 是以验证为目的）。在获取一定的信息，保证基本可信度的前提下再进入正式开发。这也是一个循环持续迭代的过程。如图2： 

除了有效的筛选需求，能够快速的交付需求才能算是理想的过程。

目前很多项目/需求的开发过程是这样的：经过长时间的BRD+PRD沟通、撰写和评审， 需求给到研发团队，开始按照迭代持续交付，上线后再经过较长时间的ROI验证。这样的模式，好比一个人担扁担一样，两头沉，尽管想快跑，但是整个人还是力不从心。

 这是一种畸形的敏捷模式，局部虽然得到优化，但是整体的交付过程依然是缓慢的。 

真正的敏捷是从源头开始，端到端全链路的敏捷。JIT已经融入到敏捷思维中，从需求源头就开始参与到敏捷的过程中。

上图案例1可以看出，需求分析与需求开发不是顺序进行的，而是小批量、持续并行的：持续进行需求筛选、持续迭代计划、持续研发交付，这样需求才能像流水一样更快速的从源头到用户使用。

能够有效的实施上述模式并非易事。实现难点主要来自需求上游。

有的业务或产品可能会说，20% 的核心需求我需要， 那80%的非核心需求也不能舍弃。这里需要澄清的是， 剩余80%的需求并不是一刀切掉，需求的筛选是一个动态调整且持续的过程，每次都要筛选出20%高价值的需求，目的是每次开发交付的都是最接近业务场景或者最能获得预期利益的需求。

还有一种客观情况，研发团队会承接多个条线业务方的需求，有的业务或产品之所以一次性规划设计一个大盘子的需求，是为了能够占住资源。然而锁定资源、锁定工期、锁定工时、锁定需求范围，就算这些条件完全满足了，交付出来的产品就能获得预期的市场收益吗？

JIT+敏捷模式是以价值为导向，以持续交付真正有用的功能为宗旨， 对上述约束（资源、工时、范围、工期等）给予了灵活性，体现了很强的适应性。在应对资源竞争的情况时，有很多估算方法，可以估算一个大致的工作量、工期以及需要的资源，但不拿这些做考核团队的指标。每轮迭代团队都会以价值为目标对约束做相应的调整。业务和产品需要对这种模式下的变更有充分的理解和包容，给调整留有余地，保持灵活性，并实现从管控思维到适应性思维的转变，而不是仅盯住上线日期，最终目的是实现业务价值。

综上，JIT+敏捷模式如果能高效的执行，需要打破业务、产品和研发之间看不见的墙，需要建立统一战线，抛开那种契约式的思维，彼此信任，深度持续紧密配合。如果抱着“我这部分做完了， 剩下就是你的责任”这样的思维，上述模式是跑不成的。