软件开发是一项精密的，多种专业角色协作的过程。随着团队的壮大，如何在沟通协调复杂度升高的情况下保持效率要结合软件工程的最佳实践和现状来做一些调整。
将组织看作一个整体，对外排期似乎是比较简单的，按照战略和业务的优先级，结合性价比好像就可以了。但在实际执行中遇到一些问题：
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.
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！