​项目管理到项目集管理和敏捷方法

从单个项目的管理到到多项目协同再到组织级项目管理的实施推广，项目经理的角色也在不断发生变化和调整。面对复杂多变的市场环境，如何以交付价值为导向，具有 Owner 意识的推动项目的执行和落地呢？最近在公司内部做了一次小的分享，整理成文章分享出来，欢迎讨论交流。另外，文中提到的案例基于真实情况均作了大量的裁剪、加工甚至改变了项目的决策和走势，如有雷同，纯属巧合。

作为 IT 项目管理者，你是否遇到过下面的问题

• 需求还不确定，怎么做后续的项目评估，怎么接着向下推进？

• 之前的项目失败了，我们要接盘，用户和客户的诉求是什么？

• 客户现在要的和最初说的不一样，是改还是不改？

• 项目做的好好的，怎么说砍就砍呢？

• 怎么项目的上线时间又双叒叕要提前（延后）？

对于传统的瀑布模式下的项目管理者，这些真实的问题，每一个都面临着变更、风险和挑战；涉及到的沟通、协同数不胜数，劳力劳神。随着 IT 项目复杂度的发展，越来越多的项目可能会遇到类似的问题，难道是项目本身出了问题？

VUCA¹ 是一个缩写，代表了易变性、不确定性、复杂性和模糊性，1987 年在领导力相关理论中描述条件或者状态，美军的军事院校用 VUCA 描述冷战结束后的世界环境，2002 年左右被更频繁的使用。在项目管理领域，这组词汇表达对项目所处环境或者项目本身面临的挑战。我们把上面提到的问题对应起来，对 VUCA 会有更深切的体会。

• V=Volatility（易变性）是变化的本质和动力，也是由变化驱使和催化产生的

• U=Uncertainty（不确定性）缺少预见性,缺乏对意外的预期和对事情的理解和意识

• C=Complexity（复杂性）企业为各种力量，各种因素，各种事情所困扰

• A=Ambiguity（模糊性）对现实的模糊，是误解的根源，各种条件和因果关系的混杂

面对出现的各种复杂情况，在项目管理领域，是快速求变，还是固守现状？答案是非常明显的。现在也已经有了许多有效的方法和工具。针对面临的实际状况，我推荐从下面两个方向入手：

通过上表可知，项目管理和项目集管理一字千言，项目集管理在项目管理扎实的方法论基础上从组织的角度对项目的收益做了延展，更关注项目集整体效益最大化。基于战略目标的收益，对项目做大幅裁剪，这种思想本身跳出了原来项目管理的框架，站在对组织更有利的视角看待项目的管理，为项目和组织之间建立了重要的纽带。

在项目集视角下的项目是一种“工具”或者说“功能实现单元”的体现，可以根据组织的实际需要对项目进行变更和裁剪，甚至及时取消项目集中的项目。在项目管理范畴内做如此多变的调整本身是不太可想象的。项目集和项目的关系可以类比成人体中组织和细胞的关系（注意：千万不要滥用类比，这里仅用来比较项目集和项目的关系本身，提供一个方便理解的角度）。

从项目经理的角度，在单个项目上，增加项目集管理的维度的思考和行动也有助于理解项目集管理本身。对单个项目来说，除了目标、质量导向的范围、进度、成本管理，能够站到公司的战略角度去理解项目的收益，并且对收益本身做拆分和量化，在项目验收后的收益交付环节持续的组织运营管理工作，突破固化的项目经理思维，为自己在组织中的发展和成长赢得机会。

敏捷²开发的思路由来已久，是否落到实处却是一件冷暖自知的事情；敏捷的核心在面向交付，快速迭代，拥抱变化；这意味着需要结合组织文化做适度裁剪。如果能够直接落地 Scrum 或者其他方法论并获得收益最好，但这并不容易，无论是团队的结构、人员的素质要求甚至工具、工作模式均要发生改变。所以建议的可行的方案还是要寻找更贴合组织发展现状的切入点，从思维上转变，到规划设计上的转变，在切换中快速见到效果，继续推动团队的工作协同方法论的迭代。在这个过程中还有许多的细节问题需要处理，交付型项目面对不同客户的实际需要，也要针对性调整。比如对文档的关注与迭代可能会和系统的交付并不在一个节奏上。这些看似简单的问题可能不断叠加形成了复杂的 Issue，所以调整过程切忌一刀切，慢慢来，比较快。

我们在实际工作中遇到了一个项目，金额不高，从绝对的成本收益的角度是一个值得做的项目。但是公司决定砍掉这个项目，如果站在项目经理的角度，这件事情并不是那么容易理解和接受的。但是站在项目集的角度，理解起来就容易多了，这个项目虽然绝对成本收益结果是盈利的，但是加上时间维度却并不如此。项目最大的问题是回款周期太长，无法有效实现短期目标，所以最终决定中止了项目。站在战略角度，如果项目不能有效的符合战略目标的需要，要么调整，要么牺牲。没有什么项目是绝对一层不变的。项目需要和公司战略保持一致性，战略调整，收益发生了变化，项目必须要跟进调整。

项目到了交付阶段客户对结果不满意，经过深入细致的沟通才发现是在初期虽然双方也制定了项目需求说明书，但是对同样的条款的理解确有巨大的偏差，或者说对需求说明书的实质性内容并没有做面向交付的解读。项目团队的开发结果和客户想要的结果有巨大的差异。当时的具体的处理方案是基于MVP 原则，让客户快速看到可能的结果，达成一致后基于结果快速迭代，最终完成了交付。这个项目是一个典型的适用敏捷方法管理的案例，如果项目初期就采用敏捷思路，以交付为目标，让客户看到效果并快速反馈，能规避大量的风险。

这是一个神奇的项目，也越来越普遍，特别是在现在科技快速发展的时期，合同都签了，却没看到需求，只有一个方向...还要基于此评估工作量，做整体的项目计划安排。真是太难了...在传统的瀑布模型下，常见的做法是压着客户讨论需求，一定要做到需求明确再推动后续的工作执行。这样做容易带来的负面效应是客户的抵触心理强烈，并且认为你们没有快速启动项目，后续变更风险非常大，初期常常面临想不清楚，想不全面的问题。这样的项目无论是产品、项目、还是客户本身都容易身心俱疲。

回到今天的主题，如何通过项目集管理实现收益最大化和如何敏捷的快速迭代，一方面主动的”要“需求，另一方面，快速迭代，让客户看到需求的反馈可能是怎样的，引导客户把真实的需求说出来。这类项目在阶段划分上要把刚才提到的点尽可能充分体现出来。比如需求分析和实现的交叉并行（注意要在需求判定为合理的情况下去推动交叉落地），在项目整体计划安排上，渐进明细，要争取客户干系人的支持，以积极响应客户为目的的渐进明细式项目管理。

如何调整落地呢，如果公司已经有成熟的项目管理体系、工具、标准，变革的开始是思维，之后寻找到切入点从最“痛”的地方入手思考，寻找到最容易看到效果和变化的方式切入能起到不错的效果。如果是本身项目管理还属于初级阶段，可以考虑的方案如下：

• 一套全新项目文档模版 -> 从战略定位到收益到项目过程提前梳理

• 以周为单位的快速迭代 -> 以快速交付为核心的项目计划制定执行

• 更明确和数字化的目标 -> 清晰明确的展示出现在项目的所处状态

预祝大家在项目管理的变革中有新的收获，也欢迎私信沟通交流；欢迎扫码关注，以后会分享更多关于项目、产品的思考和体会。

1. https://en.wikipedia.org/wiki/Volatility,_uncertainty,_complexity_and_ambiguity↩

2. https://agilemanifesto.org/↩