之前已经聊过产品年度规划、需求价值评估的话题，本篇继续细化到日常迭代执行层面的需求排期。
需求排期是基于已排序好优先级的需求池，在一定资源约束下，权衡多种因素，对需求进行对比和选择，选出最优先实现的一组需求并配置研发资源。一次需求排期可能是一次产品版本发布，也可能仅是一个研发迭代周期并不发布版本。
需求排期本质来说更像一个投资决策行为，核心是为了追求当下最佳ROI。对于商业B端产品是为了收入增长，对于自研或定制软件是为了领导&用户满意度。（下文中，会将市场收入与领导&用户满意度等同，统一用市场收入替代，以避免行文冗余）
随开发迭代节奏定期做需求开发优先级排序，是对年度规划的修正，是对市场变化的响应，是为了提升短期市场收入、产品竞争力、议价能力、客户响应感知满意度等而做的资源配置优化决策。
除了已完成优先级排序的待排期需求清单，还需要综合权衡多种要素，如：
B端产品很怕过度追求用户体验和技术，更应该追求收益最大化。功能型产品经理很容易陷入打磨UI/UE细节，而技术负责人则容易陷入追求新技术、更好架构、更少技术债中。最终可能忽视业务价值、缺少成本控制意识，让产品看起来很牛但没多大用。
迭代需求排期决策，应该由承担市场收入考核压力最大的人来主导，或者让主导决策的人承担更多的市场收入考核压力，以避免产品与市场脱节。
哪个需求优先实现，ROI是一个重要衡量因素。但如何定义需求价值，如何评估开发成本是个难点。靠一个人或一群人拍脑袋，过于主观，缺乏可解释性、一致性和可衡量性。尽可能低成本的追求相对量化，有助于提高决策质量。
比如，每次排期选需求时，给每个决策人100个价值点数，由各个决策人给待排期的需求分配价值点，最后对需求价值点求均值作为排期参考。
追求绝对准确的需求价值量化值耗费时间精力，没有必要，定价值本身也存在一定的主观性。
业务方希望多做需求的压迫和研发团队希望不过度劳累的反抗普遍存在，也就造成了可能出现研发团队评估工作量时虚高的情况。为了缓解这种问题，可以借助“开发容量”和“工时点评估”方法。
比如，一个5人开发团队，2周为一迭代周期，我们可以定义这个开发组迭代开发容量为400工时点。在评估需求成本时，开发团队及多角色共同参与，各自给出工时点预估，最后对工时点求平均值作为成本参考。
关于需求排期、开发优先级的方法论很多，本质都是“权衡维度+对比排序”。没必要纠结于用哪个方法论，只要参考决策的人对关键权衡要素及其权重大小达成一致，把所有权衡思考落到相对量化的价值点上对比着排即可。
如果迭代内只放少量几个大需求，则大量小需求会积压，整体需求交付周期会增加，容易给客户一种响应慢、效率低的感知。为了平衡外部感知，需要做迭代内需求做均衡，适当增加一些小需求响应。
需求可以分为优化类、新功能、Bug、技术类（非功能、技术债、架构改造等）等，迭代时需要对需求类型做平衡。如果缺乏约束，可能出现研发团队做大量技术类需求，多个迭代后市场和客户感知产品没啥变化和价值增加。可以约束如：每个迭代技术类需求工作量占比不超过20%，每个迭代需要有新功能类需求，每次大版本发布需要有卖点宣传类需求等。
迭代内需求变更可能造成时间不足、质量下降等影响迭代目标达成，需要有变更管理机制保障开发节奏。比如，有变更的需求则不计入本次迭代目标；有变更的需求则直接推迟到下个迭代，本迭代根据剩余工作容量选择清晰的小需求补充进来。
迭代内可能出现需要紧急响应并发布的需求，处理方式类似于需求变更。比如，将未开始或完成度低的需求从本迭代中踢出。通常来讲，紧急需求对开发节奏影响大，需要严格管控，在某些大型公司甚至会有专门的紧急需求管理流程。
有些需求很重要，业务场景也基本清晰，但技术实现有很大不确定性，这种需求要不要排入迭代？如果不排入，可能就会长期拖下去。所以，建议还是排入迭代，但不做交付要求。就算整个迭代该需求进展不大，也值得投入时间持续攻坚。不能因为难，就无限期拖延高价值需求。
这次话题里，笔者最想谈的是关于价值相对量化的思路，其他更多是对以往内容及本文话题完整性的补充。
本文由人人都是产品经理作者【产品晓说】，微信公众号：【产品晓说】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。