供应链式项目管理

供应链式项目管理

最近我们重新规划和设计敏捷项目总体流程，对需求伊始直至项目上线的目标、指标、时间节点和责任人都做了定义。但当我们制定更详细的计划时，发现一

个严重的问题：这是一个“梦幻日程计划”。在项目生命周期管理的探索与实

践上，我们经历过瀑布式、迭代式、增量式以及混合的Scrum敏捷式，如果只

针对项目管理而言，我相信在一个Sprint周期内，做到“一切尽在掌握”是可行的，但放眼至一个季度甚至半年的最终目标上，梦幻计划的完美主义的思想

又成为了另一个极端。

为了让计划更加务实，我们需要采用尽可能短的时间盒管理项目，2周是一个

理想并充满挑战的周期，但我们相信只要控制好Sprin就t可以实现它。

项目自始至终周期过长，会造成心理放松，对于项目危机感缺失，以至于造成

前期浪费时间，后期加班赶时间的窘相。所以我们需要通过不断地迭代，在一

次次循环中完成可交付的增量，基于事实的决策远比前端预测型决策更为有效。——Reinhardt

从远期看，我们的产品上线目标和最终运营目标都充满挑战，并且时间只剩半年。为了让不可能的任务更有说服力，我尝试着制定整整6个月的计划，但计

划刚刚开始我就结束了这个愚蠢的想法 ——未来的Idea充满了未知。虽然scrum敏捷能带给我们更强的控制力，但从产品创建的生命周期看，2周时间盒显然给需求的产出带来了极大的困扰：如果需求的定义仅限2周，只有鬼知道

这两周的量能否满足下一个项目Sprint的胃口，这还没有考虑不同功能和需求的大小。一个用户体验改 进与一个成长体系的需求量，放在两个同样长度的时间盒显然是不公平的，更何况产品经理还需要对页面设计、制作进行协调以及

参与Spring周期结束时的部署验收。

在一个复杂又充满挑战的项目中，为了避免这个问题，同时又发挥Scrum敏捷

式项目管理的优点，可以采取“供应链管式项目管理”方法。

在传统制造业企业中，为了保证生产的稳定，制造商会有一定的原材料库存。

但随着供应链管理思想的深入发展，越来越多的制造商整合供应链资源，与供

应商共同管理库存，以确保在生产最经济的情况下满足市场的变化，即“柔性

供应链”。

在互联网项目管理中，可以简单的抽象需求、设计、页面制作为供应商，总设、开发、测试为制造商，库存即“待开发需求池”。与传统制造业不同的是， 互联网项目团队可以简化为2个供应链中的节点，供应商为制造商提供生产原材料，制造商将其加工测试后交付给市场。

相比Scrum敏捷式项目管理，供应链式项目管理强调了“库存”的价值，产品

需要在下一个时间盒开始前保持“待开发需求池”的水量；开发需要确保能够

及时消耗掉库存中的Backlog。 这使得团队成员的注意力更容易集中在最重要

的部分（设计或者开发），而不是无效率的沟通。换句话说，传统的Scrum项

目管理的流程更像是一条大河，上游需要确保充足稳定的水量以确保下游的承

受能力；下游需要保持足够的消化能力以避免洪水泛滥或者干涸。供应链式的

项目管理就是在河道上建起了一座大坝，只要保证水库中的水在安全范围以内，无论洪峰还是大旱（需求暴增或需求锐减），下游生产都可以确保 安全与效率。管理的焦点可以集中在“待开发需求池”的安全范围以及优先级。

供应链式项目管理是更宏观的管理，它阐述了产品管理与项目管理的上下游关系。纯粹的Scrum可能更适合老外那种程序员也是产品经理的创业作风，我看

过几乎所有被奉为圣经的项目管理书籍都将定义需求作为一个项目的起始，这

表面看起来无比正确，却如同鸡肋般既没有说清楚如何定义需求（推荐《用户

体验的要素》），又给国内的项目经理和程序员造成了困扰。

产品（供应商）：

产品从“需求池”到“待开发需求池Backlog”，需要经历线框图、需求文档、页面设计、页面制作4个环节，产品设计的迭代由产品经理全权负责，在需求

池挑选高优先级的目标，设计并交付最终完整需求至待开发需求池中，需求需

要以“情景故事”为单位打包，并区分优先级；需求包的优先级需要满足正态

分布曲线，如水库在每个Spring开始前，安全范围为5-15个情景故事，当有

10个故事时，2个优先级为1，6个优先级为2，2个优先级为3。

技术（制造商）：

技术在下一个时间盒迭代开始前一周，由项目经理根据团队承受能力与产品共

同确认Sprint Backlog，并立即进行需求和用例评审。一旦范围确定，即可立

即展开项目（在需求线框图出来后，测试与架构师就可以介入开展前期工作了），并用燃尽图等工具进行监控。后面只需要保持好节奏，相信掌控项目的

感觉会让你身心舒畅。

我并不清楚供应链式项目管理思想是否有人进行过类似尝试，它的本质是对敏

捷项目时间盒内的需求与开发进行解耦，需要需求提前至少一个时间盒完成并

冗余在待开发需求池内，把为了增强项目控制力而压缩的2周Sprint还给项目程序员和测试工程师。它的困难在于，需求为了保证待开发需求池的安全范围

而必须承担足够的压力，还好我相信这种压力是我们可以承受的。

这只是一个产品经理对项目管理的思路，实践后会进一步总结，如果你有更好

的主意，欢迎与我分享。