协作 SaaS：从 Scrum 到混合，你真的认为仅仅是研发模式的变化吗？

HeyCSM

为什么说 Scrum、瀑布、混合、IPD 不仅是一套框架，更是一种理念的折射？

Scrum——作为敏捷开发领域的代表性框架，我相信我们现在做很多人在初次接触时可能只看到它的表面流程，就开始对于敏捷做理解的时候，都是一套框架以及框架背后的一些关键要素：比如说 Scrum 经典的
3355

用 4 个数字直接概括了 Scrum 的工件、角色、活动、价值观。

乍一看，这似乎只是研发团队高效交付的工具。

然而当我做了很多实践，并且了解到更多方法论之后，发现 Scrum 不仅仅是一套管理流程，更是一种基于敏捷文化的深层理念，它深刻影响着组织的运营方式、文化演变，甚至推动企业整体向更敏捷、更高层的方向发展。

作为在协作领域较为活跃的企业研发项目管理的主流模式，哪家协作软件没有个 Scrum 的解决方案，都不好意思说自己在这个领域里混。

而 Scrum 从小众框架变身为企业研发项目管理主流背后的原因值得我们去把玩一下。

从“老大哥”瀑布模型讲起

像项目管理的PMP起源于建筑业一样，瀑布模型（Waterfall model）其实也借鉴了制造业和建筑行业的管理逻辑。

The waterfall development model originated in the and industries,where the highly structured physical environments meant that design changes became prohibitively expensive much sooner in the development processWhen it was first adopted for software development, there were no recognized alternatives for knowledge-based creative work. –Wikipedia

当时瀑布模型面临的市场环境是什么样子呢？

在上个世纪的 60~70 年代，随着计算机技术的兴起，软件开发项目主要是是面向政府和军事领域的大型项目，这些性质的项目通常规模庞大需求明确，开发周期较长，而且因为项目本身存在的复杂性和长期性——严格的计划性和阶段性管理被视为是项目管理的成功的关键。

所以，瀑布模型其实是诞生于需求较为稳定，变化不大的环境下且更多运用于复杂项目。

在这个瀑布模型中借鉴了工程项目的管理思维，提出了将项目划分为一系列连续的阶段，类似于是建筑、制造等传统工程行业的流程，每个阶段有明确的输出，并且在进入下一个阶段前必须完成所有的前置工作，这种模式在当时的局面下为项目管理提供了可预测性和控制力，特别是在资源分配时间管理和质量控制方面。

但随着技术的爆发式增长以及市场需求的快速变化，我们很容易的就发现了瀑布模型在面对不管是来自 C 端还是 B 端日益增长的市场客户需求，对于需求变化的响应能力是比较差的，而且反馈迟缓，更别说客户参与的程度也有限，另外长周期还意味着风险的增加。

所以从市场这种无形大手的推动来看，瀑布模型被新的管理方法论所代替是一个必然的事情。

瀑布模型到敏捷的急转弯

以 Scrum 为例，我们经常能听到 Scrum 被形容为瀑布模型之后的急掉头。

传统的瀑布是开发遵循严格的线性流程，项目是从需求分析到设计开发测试再到最终交付，每个阶段都是按顺序进行的，虽然对大型稳定的项目有所帮助，但在应对快速变化的市场的时候还是显得捉襟见肘。

Scrum 呢更多是对这种僵化流程的一个否定，它通过迭代式的开发取代了线性的规划，是团队在每次短周期的 Sprint 中都能够交付可用的产品增量，确保能快速响应客户的需求。

在瀑布模型中的强调固定计划，而 Scrum 则把灵活应对作为核心价值，每次迭代都可以根据反馈调整方向，不管客户的需求怎么变化，它都有 100 种样子可以去迎合客户。

Scrum 是一种轻量级框架，旨在帮助团队通过迭代交付，快速响应客户需求，强调透明、检视与适应。–Scrum 指南（引用时有所改动）

而敏捷本身所倡导的宣言也好，价值观也好，Scrum 中的相关定义也好，使得 Scrum 不仅在技术层面改变开发流程，也使得在项目管理和组织协作上实现了一次急掉头。

换句话说，Scrum 不仅是一套开发流程，它更是一种以反馈为驱动、持续优化的理念。Scrum 通过透明（所有人都能了解项目状态）、检视（定期反思当前流程）、适应（根据反馈做出调整），确保团队能够在高速变化的市场中快速反应、灵活应对。

Scrum 作为这种思维的“急掉头”，正是为了解决应对市场的这一矛盾。

Scrum：从研发工具到组织文化

起初，Scrum 可能只是被视为一种研发工具，一种帮助软件团队提高效率的框架。然而，随着时间的推移，越来越多的企业发现，Scrum 背后的理念可以被应用到更广泛的领域——它不仅仅是一个研发框架，更是一种文化转型。

看敏捷带来的商业价值

Scrum 不仅仅是在帮助企业提高研发效率，它更深层次的价值在于推动企业快速交付商业价值。

在《2023 中国企业敏捷实践白皮书》中，63%的受访者认为交付的商业价值是衡量敏捷项目成功的首要因素。 ——《2023 中国企业敏捷实践白皮书》

在以客户为中心的商业环境中，Scrum 通过快速的产品迭代和持续的客户反馈，帮助企业将产品价值最大化。这种快速交付与反馈的能力，不仅帮助企业避免了传统项目管理中后期存在的“大爆炸”式失败风险，还大幅提升了产品的市场适应性。

看敏捷带来的协作团队

传统的瀑布式开发依赖于固定的计划和明确的分工，而 Scrum 强调团队成员的高效协作和持续沟通。这种模式不仅限于开发团队，它同样适用于市场、设计、运营等多个职能部门。

例如，Spotify 就通过 Scrum 的自组织团队模式，推动了创新和产品体验的持续改进。通过跨职能、自我管理的团队，Spotify 能够在高度动态的市场中保持快速的响应和调整能力。

Spotify 通过敏捷团队实现了高效的创新管理，使团队能够快速适应变化，并保持对市场需求的高度敏感性。 ——《敏捷组织形意神》

这种自组织和高度协作的模式，也逐渐成为各大企业推动敏捷转型的关键。例如在一些高科技公司，产品和设计团队通过 Scrum 和敏捷实践打破了部门之间的壁垒，快速反馈与决策成为了团队创新的源泉。

《敏捷组织形意神》指出，真正的敏捷组织不只是技术和流程的调整，它是整个组织的文化重塑。通过 Scrum，企业可以创建自组织团队，提升灵活性、协作和创新力。——《敏捷组织形意神》

企业在推动 Scrum 的过程中，往往需要打破传统的层级结构，转向更加扁平化、以团队为核心的运作方式。

每个团队成员不仅仅是任务的执行者，他们通过自我管理，在项目的每个阶段都参与决策。

这种转变，正是 Scrum 及其其他敏捷方法论带给组织的深远影响，而这种影响不仅仅是对内的对外上，也为企业带来了在复杂环境中的竞争力，在企业面对不确定时能够更从容地进行调整，推动创新，使组织能够快速适应技术变革和市场变化。

所以每一套方法论框架背后的理念更值得我们思考。

国内混合研发模式的崛起

没有完美的框架这句话，我觉得也特别适合放在我们企业管理领域，因为每一家公司的商业站位都不尽相同，企业每一套方法论引入背后所体现出来的内容裁剪、演化才是我们更应该关注的点。

我之前是一个不折不扣方法论的纯原教旨主义者，很强调它的原始性，但是后来在长期的实践中，已经在慢慢地改掉了这个臭毛病。

举个例子，之前敏捷爆火的一个热点的关键词叫中华田园式敏捷，刚开始的我觉得一定是错的，后来慢慢发现是有其一定的合理性的。

虽然 Scrum 在全球已经有了大量的应用实践，但在中国的市场落地的过程中的好像完全依赖敏捷原主张，面临着一些挑战，跟国内的一些管理文化、商业环境、客户画像都有无法调合的冲突，那我再强硬推行敏捷的原教旨不就一定会面临着水土不服的局面吗。

尤其是党政国央、金融、制造等行业对于一些需要长期规划、固定目标和严格合规要求的大型项目，单纯的 Scrum 框架可能无法提供足够的结构和控制。

因此，许多国内企业选择了一种混合研发模式，将敏捷与传统的瀑布式开发结合，形成了一种适应中国市场体质和企业需求的管理方式。

瀑布与敏捷的融合： 在大型项目中，企业通常会在项目初期使用瀑布模式进行整体规划，明确需求、设计和关键里程碑。在项目的后期开发和交付阶段，则引入 Scrum 的迭代开发模式，确保在具体的执行过程中能够灵活应对变化。
混合模式的优势： 这种模式结合了瀑布的稳定性与敏捷的灵活性，帮助企业既能应对大型项目的复杂性，又能在开发过程中保持足够的适应性。例如，某些国企和金融行业的企业在核心系统开发中需要长时间的严格规划和合规性审查，但在具体功能实现的开发中，又需要通过 Scrum 的迭代开发来提高交付效率。
中国特色的敏捷实践： 中国市场的特性要求企业在管理方式上具有更高的适应性。国有企业、大型制造业和金融机构，通常有非常复杂的层级和合规流程，单纯的敏捷在这些环境中难以发挥最大效果。通过混合模式，企业可以在保持计划性的同时，灵活应对变化，实现从项目规划到产品交付的高效管理。

根据《2023 中国企业敏捷实践白皮书》，越来越多的中国企业选择采用混合模式，以适应不同项目的需求。特别是在制造业和金融行业中，混合模式逐渐成为主流。 ——《2023 中国企业敏捷实践白皮书》

例如，一些大型国企在早期会使用瀑布模式规划产品的整体架构，而在产品开发的后期，则通过 Scrum 快速交付功能模块。这种“混合研发模式”让企业既能保持整体控制，又能享受 Scrum 带来的快速交付和反馈的好处。

~~嘿嘿，真香。~~

历史总是惊人的相似

首先，瀑布模型在当时的时代局限下，尤其是技术和管理背景下，确保了复杂项目的可控性。

接下来Scrum的引入可以被看作是对传统管理模式的一次“否定之否定”。瀑布模型以计划性和控制为核心，适合低变化的环境，但在面对快速变化的市场时暴露出明显不足。敏捷的出现，尤其是 Scrum 的实施，是对瀑布模型的反思与调整。

尽管 Scrum 的敏捷特性在快速变化的环境中展现出来了巨大的优势，但是部分项目性质中要求的规划、里程碑、监管要求使得管理的关注点重新回到了瀑布模型的规划性和可控性这个特性上，混合模型通过整合 Scrum 和瀑布的优点，平衡了管理的计划性和灵活性，所以不难看到有很多企业客户关注此模型，协作产品也花大力气推出相应的解决方案（例如PingCode 混合模型重磅上线，解决“瀑布+敏捷”管理难题
 ）。

这种发展过程符合“螺旋上升”的历史规律。瀑布模式作为一次发展阶段，为传统项目管理提供了结构性框架。但随着市场变化的加剧，敏捷理念迅速崛起，Scrum 在否定瀑布模式僵化一面的同时，也保留了它的一些有价值的结构元素，如计划与流程的框架。通过这种“否定中的否定”，Scrum 带来了项目管理方法的螺旋式上升，帮助组织进入更高层次的灵活管理。再然后混合模式应运而生。企业在前期规划中采用瀑布模型的长周期计划性，在后期开发中引入 Scrum 的短周期迭代和灵活调整。混合模式在某种程度上既是对瀑布模型的否定，也是对其合理部分的继承，并通过结合 Scrum 的动态性，平衡了计划性和灵活性，推动了项目管理的螺旋上升。

这里再提一下我最近比较关注的 IPD，之前也写过相关文章：协作 SaaS：他们在说的 IPD 究竟是什么东西
 ，如果说混合是在开发过程中做了融合与升华的话，那 IPD 相当于是更高纬度的一个全局整合，它从顶层视角不仅关注了产品的开发阶段，还把整个产品生命周期纳入了管理的范畴，而且我觉得 IPD 里边有一个比较巧妙的点是——它先是从管理思维上继承了传统的瀑布式流程，又在开发过程中融入了敏捷管理中的动态调整与创新，将项目管理提升到了战略层次。

再来做一个总结：

从瀑布模型到 Scrum，再到混合模式与 IPD，我们看到项目管理的方法论在批判和吸收中不断螺旋上升，适应时代的变化。而每一种模式的出现，都是对上一种模式局限性的反思，同时也是对前一阶段经验的继承与提升。

这一过程与历史的演进惊人相似，呈现出否定之否定的辩证发展。

从 Scrum 开始的进化趋势更值得关注

在未来，随着技术的发展和市场的进一步复杂化，管理方法肯定会继续沿着这条螺旋上升的前进路径。

这种螺旋式的演进不仅仅是项目管理方法的提升，更是企业组织文化与管理思维的一次次进化。

正如历史的发展一样，项目管理的发展同样展现出螺旋上升的永恒规律（挺美妙的不是吗？一法通万法通）。

何其有幸我们这些协作 SaaS 的客户成功经理是离专业方法论、商业环境进化最近的地方，不主动都可以被“螺旋上升”。

而我们 CSM 在发展过程也要做的就是不断让进步发生。

你好，客户成功经理