数字化项目如何兼顾敏捷与瀑布？混合式项目管理实践解析

在数字化项目里，最为常见的误区，并非是选错了方法，反而可是总想凭借一种方法去解决两类不同的问题，一类是什么呢，是寄希望于运用瀑布方式来守住种种预算、责任以及里程碑，另一类又是什么呢，是还想着借助敏捷手段去应对需求方面的变化以及业务方面的试错；到了如今，越来越多的组织转向了混合式状态，其缘由并非是方法自身显得很时髦，而是项目所处的大环境其内在本质规定了，管理者必须要同时去处理“确定性”这一状况与“不确定性”这一层面；PMI同样是非常明确且着重地强调了，项目所运用的方法正朝着更为灵活的fit-for-purpose这种方向演变发展，也就意味着要依据项目所处的环境状况来组合运用不同的实践方式。

一、为什么数字化项目很难只靠一种方法走到底

数字化项目跟传统工程项目之间最大的不同之处，并非在于运用了数量更多的技术，而是在于其在本质上同时涵盖了两类工作：

有一种工作，它追求的是确定性，像预算方面，采购环节，签订合同，涉及接口部分，关乎合规事宜，还有阶段审批以及上线窗口这些。

有着另一类工作，这类工作充满不确定性。比如像需求澄清、流程重构、用户体验进行验证、数据口径予以调整，还有技术方案开展试验。

前一类工作，需有着清晰的边界，以及可问责的机制，后一类工作，需具备快速的反馈，还有持续的修正。问题并非在于企业不晓得敏捷是好的，而是在于好多项目从一开始便并非单一的属性。PMI对于项目方法的描述，也并非是二元对立的，而是一个从predictive到agile的连续谱，每个项目都应当在这个谱系之上寻找到自身的位置。

这同样是为何，在数字化项目当中，“敏捷还是瀑布”二者选一这种情况，常常属于一个并不真的那么有实际意义的命题呐。实际上，真正达到成熟程度的管理，并非是要舍弃计划，而是在于清楚地晓得，哪些方面的内容必定得早早去做筹备计划，而哪些方面的内容则必定是要一边开展相关工作一边从中学习其经验状况啦。

英国政府官网有关敏捷规划的指南表明得十分明晰：于敏捷环境当中，规划并非已消失不见，而是理应在“恰当的层级、恰当的时间”予以开展，在远期保持高层次级别，于近期再实施细化。对于数字化项目来讲，这一点格外关键，因为诸多风险并非源自变化自身，而是源自组织将本应于迭代里辨明的问题，过早地包装成了确切答案。

依据组织实际情形来看，诸多本土企业在数字化项目方面频繁出现摇摆状况，恰恰是源于这个原因。一方面，企业高层期望项目能够进展迅速，最好是一边推进一边进行调整；另一方面，高层还对预算有着可控要求，责任要清晰明确，节点要能够进行汇报，风险要可以进行追溯。于是，团队表面声称在开展敏捷工作，可实际上依旧被责成在启动时期回答过多原本根本不可能一次性阐述清楚的问题。其结果便是：在前期时文档编写得非常厚重，而到了后期变化依旧数量众多，团队既未曾获取到瀑布模式所具备的确定性，也并未真正得到敏捷回馈所带来的效率。这样的矛盾，并非凭借一句“全面敏捷转型”便能够予以解决，而是得要在治理机制的层面，再次去划分“什么应当被锁定，什么应当被打开”。

近年PMI的研究也证实了这个趋向，项目团队着实正显著转向更为灵动的交付模式，混合式方法的应用持续攀升，并且预测式、混合式、敏捷式在项目表现方面并非单纯谁高谁低的差别，关键之处在于是不是适配项目环境。这对管理层而言是个相当重要的提示，即项目治理的成熟，并非体现在 “全公司一致采用一种方法 ”；而是彰显于能否依据多样项目谋划出不一样之控制力度 、协作节奏以及反馈机制。

二、混合式方法不是“折中”，而是“分层治理”

1. 混合式真正“混”的，不是流程，而是管理逻辑

有许多团队将混合式理解成这样，也就是“前面依照瀑布模式，后面依照敏捷模式”，又或者是“管理层看待瀑布模式，研发团队推行Scrum”。然而，如此这般的理解仅仅说对了其中的一半而已。混合式真正需要去解决的问题，并非是把两套术语简单地拼凑到一块儿，而是要把两种不一样的管理逻辑安置到各自最为有效的位置上去：只要是涉及到承诺、约束、资源配置以及问责的相关事项，就应当更加稳定 ；只要是涉及到探索、验证、反馈以及优化的相关事项，就应当更加灵活。PMI 针对 hybrid 的定义，从本质上来说，同样是这种抱持着“按项目环境组合实践”的思路，并非死板地将流程切割为两半。

2. 对管理层来说，要稳的是边界，不是每一个细节

针对 GOV.UK 的敏捷规划指南里那个很值得管理层去借鉴的观点来说，在敏捷这种模式当中，计划依旧是有着重要意义的，不过应当是在“合适的层级、合适的时间”去开展合适深度的规划工作；对于远期的工作要保持高层级的状态，对于近期的工作才进行进一步细化呢。这个原则要是放置在企业项目里面，其含义是非常明晰的：高层真正需要去管控住的，是目标、边界、里程碑、投入上限以及关键风险这些方面，而并非是想着在立项阶段就把所有业务细节一次性给冻结住呀。本应于迭代期间予以澄清的那些问题，却被提前“写死”，这般看似是进行控制，实则仅仅是将不确定性从后台转移到了后期变更当中，是这样的情况，你明白吗，标点符号。

3. 对交付团队来说，要活的是路径，不是责任

敏捷并非意味着团队能够毫无限制地去变更范围，更不是说对结果不用承担责任。真正成熟的混合式项目，是在责任清晰的这个前提之下，把实现路径交由团队去进行优化。Agile Alliance收录的Halliburton实践极具代表性，企业依旧保留阶段和关口框架，不过在执行区间引入基于Agile的开发机制，从而让团队能够在原本的治理约束之下获取更快的反馈以及迭代能力。这表明，治理的稳定跟执行的敏捷并非相互矛盾，而矛盾的常常是，组织将治理的稳定以及执行的敏捷这两者，设计在了同一个层面上。

4. 真正有效的混合式，是“上层定规则，下层做学习”

这句话乍一看好像挺简单，可实际上，这是好多企业特别难以达成的地方来着。为啥这么说？因为呢它要求管理层接纳一个实际情况，啥实际情况？就是并非所有问题在一开始就能回答得明明白白清清楚楚；与此同时，它还要求团队接纳另外一个实际状况，啥情况？就是并非所有的变化都能够毫无限制不受羁束。混合式项目管理它的本质，可不是给变化放行开方便之门，而是要给变化划定界限设置边界，给探索留出余地留出空间，给决策留存依据留存证据。唯有做到这一点，组织才不会处于那种在“敏捷与瀑布之间晃来摆去摇摆不定”的状态；而是在用两种不同的逻辑一块儿共同管理复杂性。

基于工具承载的角度而言，混合式方法并不适宜借助一套过于单一的工具习惯予以落地。就拿 ONES 项目管理工具来说，ONES Project 能够同时给予需求、任务、缺陷、迭代管理的支持，以及看板、燃尽图等敏捷常用能力的支撑，如果同时 ONES Plan 对项目里程碑、甘特图、多项目总览和资源管理予以支持，并且 ONES Wiki 支持文档关联任务、嵌入任务进度与知识沉淀。若将这些能力一并进行审视，会发现其更适宜去承载这样一种混合式场景，即治理层关注里程碑以及资源，交付层负责进行迭代与反馈，文档层致力于做决策留痕以及知识沉淀。在此当中，关键并非在于工具自身究竟有多齐全，而是在于它能不能让不同的管理层级各自去关注各自的重点，而并非是让所有人都盯着同一张明细表。

三、存在着这样一个针对本土企业而言更为适配的混合式落地框架，1. 治理层：要率先去界定“哪些东西是不能够轻易发生改变的”。

在项目启动阶段，我通常建议先把四类问题定义清楚：

必须得先将这些“不能轻易发生改变”的事项阐述明白，只有这样。于后续而言，其迭代才不会演变成毫无 boundaries 的随意尝试错误行为。在此处，所需要的是治理方面清晰明了，并非是文件数量繁多。

倘若再深入到工具层面，治理层最为需要的并非是“更多的表格”，而是那种能够稳定展现边界条件以及关键节点的载体。举例来说，ONES Plan 它具备支持项目里程碑、甘特图、多项目总览以及资源管理的功能，并且还能够与 ONES Project 里的项目、迭代、工时数据进行联动；像这类能力是比较适宜放置在治理层来运用的，原因在于管理层切实关注的一般并非是某张任务卡的流转细微之处，而是关键节点是否处于受控状态、跨项目资源是否存在冲突、整体节奏是否出现偏离。

2. 交付层：把“会变化的东西”放进迭代而不是放进争论

当进入交付阶段以后，关于需求优先级、方案细节、流程设计、用户界面、报表口径这般诸多方面的内容，应该尽可能借由待办列表、版本路线图、迭代评审以及用户反馈去逐步实现收敛，而并非在会议之上反复地进行抽象的争论。GOV.UK所采取的做法是会把愿景、目标、路线图同用户故事予以可视化处理，并且将近期的工作进行细化，远期的工作维持在高层级；位于其背后的管理逻辑十分值得借鉴：并非是不去做规划，而是不会把那些尚未经过验证的内容假装成已然确定的答案。

于此层面，ONES Project 的能耐在更为贴近团队日常运用情景的方向上展现，它能够支持构建需求池，能够助力展开规划迭代，能够实现任务管理，能够达成缺陷管理，并且借助看板、燃尽图以及多种报表来协助团队把控当下进度与质量情形。对于混合式项目来讲，这类能力的意义并非在于“愈发类似敏捷”，而是在于辅助团队将变化置于一个可视、可排序、可复盘的节奏当中，而非任由变化在微信群、会议纪要以及口头协调里失控地扩散。

3. 协同层次：构建“双节奏”体制，并非借助单一的会议去处理全部问题，而是采取多种方式协作。

不少项目之所以呈现出既迟缓又杂乱的状况，并非是由于会议数量少，而是在于同一组会议肩负起了两种全然不一样的任务。对于混合式项目而言，更为合理的应对方式，是起码留存两套节奏。

前者处理“项目是不是依旧位于正确轨道之上”之事，后者处置“团队在下一轮到底要完成交付什么”这个问题。两套节奏一旦被分离开来，许多组织内部所产生的消耗就会马上降低，原因在于高层不会再被各种细节所沉没，团队也无需在每一次评审的时候都再度去阐释项目所具备的意义。

要是企业已然在着手推进这种双节奏管理，那么在工具方面也最好防止“治理信息”以及“执行明细”相互分离。同样拿 ONES 来说，ONES Project 与 ONES Plan 之间的数据实现互通，Plan 能够查看 Project 里相关项目以及迭代的工作量、进度还有工时数据。这传达出一种情况，即管理层无需深入探究团队每一轮 Sprint 的那般细微微观的具体详情，照样能够得到充足的上卷信息，并且团队也无需为了向上进行汇报，而额外去维护一套偏离现场实际情况的“领导版台账”，这恰好是混合式方法能不能成功落地的一个时常被低估的条件。

4. 度量层：把“可控”与“有价值”分开看

，混合式项目极易出现的管理偏差，在于仅关注计划达成，却不重视价值验证，或者仅仅看重迭代速度，而忽视整体承诺；前者易于将项目打造成按时交付的低价值系统，后者则易于把团队塑造成忙碌却失控的交付机器。所以，PMO起码要构建两类指标：

一类是治理方面的指标，像预算出现偏差这一情况被包含其中，还有里程碑达成的比例，重大风险形成闭环的比率，以及关键依赖得以兑现的比率。

还存在着另一类，它是流动性与价值方面的指标，像需求吞吐这一情况，还有从需求起始直至上线所历经的周期，以及缺陷逃逸的比率，版本验收能够通过的概率，用户针对其采纳的相应状况。

便是由于这样的缘故，混合式项目没办法仅仅依靠一张甘特图，同样没办法仅仅依靠一张燃尽图。于此处，ONES 的一个值得可取之处在于，它并非单纯着重于某一种项目方法。ONES Project 一方面给出看板、燃尽图、多种报表等偏向敏捷的度量与协作能力，另一方面还给出瀑布、通用协同等项目模板；而 ONES Plan 则更偏向于里程碑、甘特图、资源视角。面向正在推行混合式管理的团队而言，如此这般“不同视角对应不同管理层级”的产品设计，相较于仅仅着重某一套方法论，更贴近组织实际情况。

5. PMO 的角色：从“文档监督者”转向“治理设计者”

这属于众多企业极具升级价值的一步，于混合式项目当中，PMO的价值并非单纯局限于检查模板是否完备，而是要去进行关口设计，明确边界定义，协调跨部门之间的依赖状况，统一指标的口径，促使风险实现朝前转移。并且要为管理层提供协助，用以区分哪些变化需要通过升级来进行决策，哪些变化应当留在团队内部予以解决。

要是把这个角色转变朝着更前的方向推进一步，PMO 还得肩负起“信息架构设计者”的职责，即什么内容得实现标准化，什么内容能够依据项目进行裁剪，什么信息用于向上汇报，什么信息服务于团队协作，哪些文档是为了合规留下痕迹，哪些文档是为了知识复用！

ONES Wiki能够支持文档关联任务，能够嵌入任务进度，能够进行模板化创建，还能够版本留存。对于PMO而言，这类能力的价值并非在于“多一个文档工具”，而是在于能够将项目制度与会议纪要、决策依据和任务执行之间的关系建立起来，从而避免在项目结束之后只剩下一堆彼此脱节的文件。

四、混合式实践中最常见的三个误区

误区一：前期把需求写死，后期再做“敏捷执行”

这是极为常见且特别隐蔽的问题，团队在前期耗费大量时间去做厚需求、长流程、全量确认，等进入开发阶段才切换到Sprint，表面看上去是“瀑布加敏捷”，实际上仅仅是将反馈延迟包装成了迭代，PMI关于hybrid life cycles的讨论也明确予以提醒：要是依旧在前期详尽收集需求，而用户验收又集中于生命周期末端，那么反馈延迟仍旧存在，项目很难切实获取敏捷所带来的学习优势。关键并非有无 Sprint，而是用户反馈是否足够早地介入到其进入决策之中。

误区二：学了敏捷动作，却没有改决策机制

不少组织会采用站会，还有回顾会，以及燃尽图、待办列表，看起来“颇具敏捷性”，然而预算依旧一年锁定一回且没法变动，优先级变换仍旧得层层层层向上请示，跨部门资源产生矛盾冲突时却不存在能一锤定音拍板做决定的人，范围出现改变时也欠缺极为清晰明确的规则情况。最终导致的后果也就是，团队所施行的动作越来越多，可是决策运行产生效率却并未往上升高。实际上真正致使项目进度被拖慢，通常不是团队不懂得进行迭代，而是组织没有针对决策所拥有的权限，以及边界条件和升级的路径重新去做设计规划。敏捷从来不是一系列简单的动作组成，而是一整套能够让反馈能够更快地进入到管理范畴中去的机制体制制度规章等等。

误区三：把 PMO 继续当成“模板警察”

要是 PMO 的首要工作依旧是去搜集周报、核查模板、催办审批，那 mix 式最终极有可能便是在旧有的治理体系外头套上一层新的术语概念。真正具备价值的 PMO，并非是将项目管控得更为死板僵化，而是要把组织的约束条件转化成团队能够加以执行的边界范围，把团队现场出现的变化情况转变成管理层能够用以决策的信息内容。也就是说，PMO 的成熟程度，并非取决于文档的数量多少，而是要看它有没有助力组织把“控制”从形式上的控制提升为能够实现决策的控制。对于这件事而言，工具固然重要，然而其前提一直是，工具得服务于治理设计，并非取而代之治理设计。

五、给中高层与 PMO 的一个判断标准

一个数字化项目是否适合混合式，我建议至少问三个问题。

第一，对于这个项目而言，是不是存在着一部分内容是“必须确定”的，同时又存在着另一部分内容是“必须探索”的呢。只要这两者同时存在，那么单纯采用敏捷方式或者单纯使用瀑布方式，通常情况下都并非是最为合适的解决办法。

首先，存在这样一个情况，那便是组织有没有意愿，将治理层以及交付层进行分开设计，并非运用同一把尺子，对所有工作展开统一考核，这是第二个要点。

第三，管理层可不可以接纳这样一种管理方面的现实情况呢，即并非所有问题都应当在启动的那个阶段就回答得以清楚明白，然而所有重大的承诺都必定得有清晰的边界限定，有确凿的证据支撑，还有明确的责任人归属。

PMI针对此的核心判断挺径直，真正起作用的办法，并非在于纯度，而是在于可不可以给项目环境增添价值。

倘若在这三个问题之中，存在两个及以上的答案为“是”，那么这个项目大概率就不应当再去争论“究竟是选择敏捷还是瀑布”，而是应当着手设计你的混合式治理框架。到达了这一步，工具的选择也应当依据这个逻辑来进行展开：治理层可不可以看到全局的节奏以及资源，交付层能不能管理迭代以及反馈，知识层是否能够沉淀决策以及经验。从 ONES 官方所公开出来的信息去看，Project、Plan、Wiki 这三种能力组合，的确是比较契合这种“上层看治理、下层看执行、过程留知识”的落地要求的；但是它最后是不是能够真正去发挥价值，依旧是取决于企业有没有先把治理边界给设计清晰以及有没有把协作机制给设计清楚句号。

结尾

数字化项目有着复杂性，这复杂性并非在于技术比以往更多，而是在于管理对象自身已然产生了变化，它一方面要求组织如同工程那般守住边界，另一方面又要求团队像产品一样持续进行学习。正因为是这样的情况，混合式方法论的价值从来都不是在于“折中”，而是在于“分层” 通过瀑布式治理来守住目标、责任、预算以及关键节点，借助敏捷方式交付来缩减反馈链路、提升需求质量、加速价值验证。

对于中高层以及 PMO 而言，这并非是关于方法的选择题目，而是涉及治理能力的题目。谁能够将稳定性以及适应性一同设计进到项目机制之中，那么谁便更具备可能性在不确定的环境里把数字化项目切实做成。倘若再配备如同 ONES 这样在同一时间支持敏捷协作、瀑布计划以及跨层级信息联动相应的工具底座，混合式方法便会更加容易从理念转变成为组织能够执行的管理实践。

相关标签： # 数字化项目 # 混合式管理 # 敏捷与瀑布 # 治理框架 # 项目管理