聊聊 IT 行业的项目管理模式

引

最近在梳理一个持久性项目的大的开发计划编排、进度追踪等一系列的 PM 工作。大团队中的其他小伙伴们也都有各自非常优秀的最佳实践。新龙提到，每日来个复盘，一定是永久的性的话题，将自己最深处的灵魂个挖掘出来鞭挞，一定非常的酸爽。我想来，不鞭挞自己，可以把我过去的两种主要的项目管理模式给拉出来复盘一下，做一些自己的总结，也是不错的。于是，有了下面的话。

在这篇文章里，你能看到：

1. 比较传统的软件厂商的瀑布流式的开发模式

2. 现在互联网大厂喜欢搞得敏捷迭代模式

传统的瀑布

传统的瀑布式开发，是目前最常见的、最典型的 IT 研发方法，其特点在于需要严格地遵循预先计划的需求收集、需求分析、设计、Coding、再到测试的步骤顺序来进行。每次需求结果的验收，是一次瀑布迭代的收尾。

对于这类的玩法，个人的经验在于，其苛刻的需求处理顺序，导致所有的需求处理的自由度低；因此在项目的过程中，往往会发现在很早时承诺的工期由于各种需求的变更而无法达成，从而造成很高的代价。而对于这类开发，如果需求不明确，那么进行开发几乎是不可能的。更有甚者提出，软件开发失败的原因有 70%是由于瀑布式开发造成的。这个数字正确几何我们并不可考，但其反应出来的问题是不可忽视的。

在笔者经历的一些公司中，大型通讯供应商企业偏好瀑布式开发。其主要原因，笔者猜测在于组织架构的设置导致需要有一定标准地、顺序的需求处理流程。如，产品部门进行需求的梳理，需求梳理清晰后，形成对应的 MRD/PRD 文档，交给下一个环节处理部门——研发部。研发部对接多个不同产品部门过来的产品需求，并对其进行排期，完成研发后，交由下一个部门——测试部。完成测试后，进行最终上线。从这个角度来看，其流程清晰明朗，基本像传统工业流水线一样，环环相扣。

当然，正如上面描述的那样，虽然能够比较好地衔接，但对于需求不清晰，未来不确定的产品，这类瀑布式开发简直是一场噩梦。产品不大清楚应该做成什么样，希望研发能先有一个 MVP（最小产品）来验证市场；但研发不清楚产品到底要啥，无法便无法完成交付。于是出现彼此不断扯皮的情况。

敏捷迭代

“上帝说要有光，于是，就有了光。”上帝说，这样不行，要有敏捷迭代，于是就有了敏捷迭代。

敏捷迭代的出现解决了以上瀑布式开发中暴露的一些问题，从而在海外和互联网企业中大放异彩。为何它会如此受欢迎？我们知道，如果是传统的软件公司，例如大型通信公司，其产品形态往往会有硬件存在，因此需求清晰明白，才能生成一个完整的产品给到终端消费者。

然而，对于互联网企业的产品而言，我们往往是在创造一些从未有过的、新的、以颠覆者姿态出现的产品。因此，其产品形态、操作流程等细节， 在一开始根本就无法完全确定下来。于是敏捷迭代在一开始就提出，以最终用户需求为目标，先产生出一个能满足客户最小需求的 MVP 原型产品出来，然后再在迭代的过程中不断提供给我们的客户进行试用，找出产品的优化和改进点，再不断进行迭代更新的这样一个过程。

我们可以看到，敏捷迭代的特点是螺旋式的。对于最终的需求长相，相信所有人都并不清楚。因此，对于陌生领域的探索，我们先拟定一个 MVP，然后再根据终端用户使用该 MVP 所产生的数据，或者根据对 MVP 的探讨建议和意见，不断生成需要改进的意见和建议，从而成就一款举世无双的创新产品。

再从组织关系上来看，对于敏捷迭代式的企业，产品团队、研发团队、测试团队必须紧密地坐在一起，为着同一个目标去努力。每日站会，dashboard，其实都只是一种展现形式，其核心灵魂在于三个不同职能的团队的合作方式不再是顺序的，而是螺旋的、你中有我我中有你的形式，这样的方式，能够将需求任务拆解到最小颗粒度，让产品、不同研发角色和测试能够并行进行，从而提升研发的效率。

那敏捷有不好的吗？当然有，当你的组织架构设定无法让这个团队坐在一起时，一定会出现水土不服的情况。

结

哪种是最好的项目管理模式？

正如上面提到的，这其实和一个企业的产品形态、组织架构设置、企业文化等诸多因素都息息相关，你无法说哪个哪个是最好的。我认为，最合适的才是最好的。

这里提到了组织架构设置，突然觉得组织行为学是一个比较好的 topic。下次找时间来聊一点组织行为学的内容，我看可行。

于辛丑年冬月初五