产品和开发分层的缓冲需求池

软件开发是一项精密的，多种专业角色协作的过程。随着团队的壮大，如何在沟通协调复杂度升高的情况下保持效率？需要结合软件工程的最佳实践和现状来做一些调整。
 

将组织看作一个整体，对外排期似乎是比较简单的，按照战略和业务的优先级，结合性价比好像就可以了。但在实际执行中遇到一些问题：
1）高优先级需求来时一拥而上，需求未定型时就开始编码，需求变更后造成浪费；
2）试图在需求由客户给到产品时确定上线时间，但在全面分析系统中所涉改动点后发现工作量太大需延期；
3）产品经理感觉自己的需求在一个月内没法进入开发，就不再细化需求出文档。开发某任务中途阻塞（可能是业务变化或者某事需领导确认），发现无可以开始开发的其它业务需求。（缺乏需求池作为缓冲）

我们强调整全生命周期各角色端到端跟进的owner意识，仍可将研发过程抽象为一个简单的管道，产品--UI--开发--测试。输入组织战略和业务目标给产品经理，输出需求原型和文档，开发接收产品和UI的输入后，输出代码，测试接收这些输入后进行测试，最终部署上线。

已经讨论思考得比较完善的想法，在撰写需求文档仍会发现新的问题再做优化。需求评审会上觉得完善的原型，动手开发时才想到细节和异常情况。这对于产品经理和开发人员来说是正常的，优秀的人会有更高的预见性，评估更准确，而流程设计上应兼容大多数情况，应将产品和开发的排期分开，中间建立需求池作为缓冲。

产品的排期决定产品经理团队的工作安排，按业务优先级产出需求原型文档放入需求池。这里如果讲性价比，成本会有两种含义1）产品经理出文档的难易程度 2）开发团队实现需求的成本。重点关注产品团队的需求质量和人均速度。

需求池的准入条件是开发人员可直接开始开发，无需再与上游确认信息而等待。开发自主提出的性能优化、规范改造、数据一致性防重复等也可放入。

开发的排期决定开发团队的工作安排，有开发人员就绪后，从需求池中按优先级取出，根据工作量和版本周期确定提交测试和上线的时间。需考虑技能因素，比如入职了一位前端小姐姐，而后台开发们还在上个版本的开发中，即从需求池拿一个纯前端交互优化的需求纳入版本开始开发，虽然业务上其它需后台开发的需求更重要，也是下个版本了。

有些需求跟技术方案强相关，比如AR地图，产品经理不能独立完成需求怎么办？简单的，产品跟资深开发直接沟通技术可行性和建议的方案，复杂的，放一个poc技术验证的任务到需求池，开发完成demo后继续进行需求设计，需求完成后重新参与排期。

这样开发接手的都是稳定的需求，返工减少。如果在产品排期阶段需要向用户反馈上线时间，可以先评估大致的时间，开发排期后再反馈更精确的。可以用人均需求开发量和质量来评价开发人员的工作。让大家专注在自身专业的领域上。

WOS=Week Of Stock在零售中指库存可卖多少周。开发过程中可参考：某项目需求池中的需求可供开发团队工作多久？比如有2个月以上，就增加开发人员，或产品经理转做其它项目。如果只有一周，意味着产品团队出个短差到印度，就会开发人员的等待空闲。因此各项目需求池的大小需要定期关注。

评价一个组织的整体效能，可以有多个指标，比如从产生原始需求到程序上线的时间，一般来说越短越好。以及人均实现的需求量，越多越好。

Talk is cheap ,show me the prototype document of product managers and the code of developers.