供应链式项目管理.docxVIP

PAGE 1 PAGE 1 供应链式项目管理  最近我们重新规划和设计机敏项目总体流程，对需求伊始直至项目上线的目标、指标、时间节点和责任人都做了定义。但当我们制定更具体的计划时，发觉一个严重的问题：这是一个“梦幻日程计划”。在项目生命周期管理的探索与实践上，我们经历过瀑布式、迭代式、增量式以及混合的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，并马上进行需求和用例评审。一旦范围确定，即可马上绽开项目（在需求线框图出来后，测试与架构师就可以介入开展前期工作了），并用燃尽图等工具进行监控。后面只需要保持好节奏，相信掌控项目的感觉会让你身心舒服。  我并不清晰供应链式项目管理思想是否有人进行过类似尝试，它的本质是对机敏项目时间盒