软件开发是一项精密的多种专业角色协作的过程。随着团队的壮大如何在沟通协调复杂度升高的情况下保持效率需要结合软件工程的最佳实践和现状来做一些调整。将组织看作一个整体对外排期似乎是比较简单的按照战略和业务的优先级结合性价比好像就可以了。但在实际执行中遇到一些问题1高优先级需求来时一拥而上需求未定型时就开始编码需求变更后造成浪费2试图在需求由客户给到产品经理时确定上线时间但在全面分析系统中所涉改动点后发现工作量太大需延期3产品经理感觉自己的需求在一个月内没法进入开发就不再细化需求出文档。开发某任务中途阻塞可能是业务变化或者某事需领导确认发现无可以开始开发的其它业务需求。缺乏需求池作为缓冲我们强调整全生命周期各角色端到端跟进的owner意识仍可将研发过程抽象为一个简单的管道产品--UI--开发--测试。输入组织战略和业务目标给产品经理输出需求原型和文档开发接收产品和UI的输入后输出代码测试接收这些输入后进行测试最终部署上线。已经讨论思考得比较完善的想法在撰写需求文档仍会发现新的问题再做优化。需求评审会上觉得完善的原型动手开发时才想到细节和异常情况。这对于产品经理和开发人员来说是正常的优秀的人会有更高的预见性评估更准确而流程设计上应兼容大多数情况应将产品和开发的排期分开中间建立需求池作为缓冲。产品的排期决定产品经理团队的工作安排按业务优先级产出需求原型文档放入需求池。这里如果讲性价比成本会有两种含义1产品经理出文档的难易程度 2开发团队实现需求的成本。重点关注产品团队的需求质量和人均速度。需求池的准入条件是开发人员可直接开始开发无需再与上游确认信息而等待。开发自主提出的性能优化、规范改造、数据一致性防重复等也可放入。开发的排期决定开发团队的工作安排有开发人员就绪后从需求池中按优先级取出根据工作量和版本周期确定提交测试和上线的时间。需考虑技能因素比如入职了一位前端小姐姐而后台开发们还在上个版本的开发中即从需求池拿一个纯前端交互优化的需求纳入版本开始开发虽然业务上其它需后台开发的需求更重要也是下个版本了。有些需求跟技术方案强相关比如AR地图产品经理不能独立完成需求怎么办简单的产品跟资深开发直接沟通技术可行性和建议的方案复杂的放一个poc技术验证的任务到需求池开发完成demo后继续进行需求设计需求完成后重新参与排期。这样开发接手的都是稳定的需求返工减少。如果在产品排期阶段需要向用户反馈上线时间可以先评估大致的时间开发排期后再反馈更精确的。可以用人均需求开发量和质量来评价开发人员的工作。让大家专注在自身专业的领域上。WOSWeek Of Stock在零售中指库存可卖多少周。开发过程中可参考某项目需求池中的需求可供开发团队工作多久比如有2个月以上就增加开发人员或产品经理转做其它项目。如果只有一周意味着产品团队出个短差到印度就会开发人员的等待空闲。因此各项目需求池的大小需要定期关注。评价一个组织的整体效能可以有多个指标比如从产生原始需求到程序上线的时间一般来说越短越好。以及人均实现的需求量越多越好。Talk is cheap ,show me the prototype document of product managers and the code of developers.