供应链式项目管理.docxVIP

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