为什么都敏捷开发了项目还会延期？！| 技术头条

作者 | 王晔倞

责编 | 郭 芮

上个月，我曾写过一篇《在传统企业做互联网架构》的文章，与大家探讨在传统企业里，如果搞互联网架构会遭遇哪些问题，并结合自己的经历聊一下心得体会。

说来也怪，在互联网盛行的这十几年里，我见过很多认真学习互联网思维的传统企业，虽然从技术架构、组织结构、到工作模式，都学得有模有样，绘声绘色，但基本都停留在 “四不像” 的阶段。

这种半吊子工程，不仅增加了内部矛盾，还降低了工作效率。

当然，导致这种现象的原因有很多，什么犹豫不决啊，什么错失时机啊，或者什么运营与营销手段过时等等。在外人看来，似乎都很有道理，但却没有命中核心。

在我看来，这和绝大多数的传统企业高管年龄偏大，且整体管理水平陈旧有关。

简单来说，很多传统企业老板平均年龄在40岁以上，高管起码在35岁以上，这些人在传统营销领域经验丰富，但随之而来的问题是对互联网不精通。他们大部分是业务好手，但整体现代化管理理念、管理技能与企业发展要求，还存在一定距离。

不仅如此，他们基本没有技术背景，对互联网架构的理解只局限于 “别出事”，对项目管理模式的理解只局限于 “快上线”。

记得在某次敏捷话题的分享中，在提问环节时，有位老板模样的大叔向我发问：“你们都鼓吹敏捷能提升研发效率，但为什么我们用了敏捷之后，项目周期该延误的还是照旧，成本也得不到有效的控制，真不明白为什么你们还整天瞎嚷嚷这个好，那个好，吹牛很好玩是吗？”

我脾气本来就爆，听完这番话的第一反应就想给他怼回去，或者干脆回他一句 “你不懂技术，没必要跟你解释。” 但我还是很礼貌的说了一番大道理，最终指着大屏幕违心地说了一句 “这是我的个人微信，今后可以多多交流。”

对方愣了几秒，面带微笑的点了点头，坐下了。但从他的表情上可以看出，对于这样的回答，他并不买账，估计心里早就用那三个字骂了千百遍了。

不过这也正常，在我的经验值里，如果自认为对研发与测试有着不少功底的话，那对项目管理模式就完全是门外汉了。有人说，门外汉还能站到台上去分享？这还多亏的这张伶俐嘴，和实践中积累了充分的案例，至少能在面对技术理科男的时候显得更加游刃有余，但在面对这种有备而来，并略带调侃的提问，的确显得有些措手不及。

进入现在的公司以来，我逐渐养成了 “遭遇挫折或不满事件，必复盘” 的习惯，通过翻阅大量资料及与其他公司的交流，对这个问题进行了梳理和规整。

如果再遇到类似提问，我想我会这样回答：

敏捷，解决的不是速度的问题，而是灵活性的问题。

就好比在短跑比赛中，速度最快的人种基本是黑种人，为什么呢？因为目标是明确的，拼的是身体素质，黑种人相比白种人、黄种人，天生就具有这方面的优势，当然也最有可能成为冠军。

短跑比赛，相当于一个需求明确且不会发生变更的业务项目，而黑种人，相当于某个采用瀑布式开发模式的技术团队，中途没有障碍，大家都把眼睛瞪大，撒开腿跑，一口气跑到终点，成本与效率一定是最低的。

当今的互联网业务，更像是一场羽毛球比赛。

就算面对同一个对手，每一场比赛的节奏，每一次出球的线路，都是完全不同的。在应对策略上，经验越丰富的球员越是能够增大预判的准确性，合理分配自己的体能和发力点，该快的时候快，该慢的时候慢，使自己的优势发挥至最大，最终赢得比赛。

很显然，敏捷模式不是万能的。

如果你的产品需求相对稳定，目标明确且很少走回头路，产品与技术的KPI各自为战，重视过程和强调文档，那就用瀑布式吧。

如果你的产品需求不明确，产品与技术的目标同为 “客户最终受益” 为宗旨，试探性需求偏多，接受不断尝试，不断试错的价值观，那就用敏捷式吧。

有人说，你这样讲还是太理论化，在现实的敏捷实施中，还是有人困扰于 “版本快结束的时候，需求要进行大范围调整” ，你质问他为什么？他会理直气壮地告诉你，“敏捷不就支持不确定性变更吗？”

对，敏捷的确支持，增加一个迭代周期来解决就行了，但时间与成本肯定会提升。

再说了，从敏捷的视角来看，目标变了等同于重新设定了新版本，重新再来自然需要更多时间。在这种场景下，非要给 “敏捷并未解决项目延误的问题” 的罪名，好像并不合适。

另外，虽然敏捷具有 “保持灵活性以便满足用户需求” 的功效，但用户往往对这种灵活性期望过高了，从而导致团队在持续交付价值的时候举步维艰。

在很长一个阶段里，我很反对敏捷，因为我觉得这为 “反复无常是正常的” 找到了一种借口。

你看，敏捷允许用户甚至能够在大型项目的后期调整优先级，但很多产品并不理解 “交付能力是有上限的” 这个道理。他们并不能真正理解速度和时间的度量标准，但却总是期望可以随时添加新的需求而且能及时得到交付。

我想，这也正是 “你们不是用敏捷了吗？那怎么项目还延期呢？” 这句话的由来吧。

作者：王晔倞，18年IT从业经验，现任职好买财富平台架构部技术总监，负责好买中间件及平台化的研发及运营，团队管理和实施重大技术决策。曾任大智慧测试总监，在2年内带领团队自研了“大智慧云测试平台”，通过平台化将金融数据服务业务从瀑布式逐渐转型为DevOps。

声明：本文为作者投稿，版权归作者个人所有。