國內IT企業的底子到底有多薄弱？

本篇目錄

一、爲什麽方案有效，落地卻滿是纰漏？
二、爲什麽關鍵環節難以落地？

敏捷、DevOps、CMMI、IPD……近年來，研發管理領域的各類框架與工具不斷叠代，管理者們急于借新方法打破效率瓶頸。

可現實往往是：學完敏捷就拉著團隊開每日站會，引入DevOps就搭了CI/CD流水線方法，流程改了多次，團隊的研發效率卻始終難有質的提升，投入與産出的落差，成了許多企業的老大難。

不久前，阿道接觸到一位剛開始用禅道的朋友，我們也就這一問題交流了許多。這位朋友的經曆恰好也爲這個行業難題提供了獨特的視角。

很有意思的是，他大學是學通信工程的，在校期間更多的是系統學習傳統軟件工程體系——從需求文檔規範到瀑布式開發流程，每一步都強調嚴謹與標准化；而畢業後，他又先後進入互聯網與金融領域，不同行業對響應、叠代的不同要求，又讓他不得不主動接納敏捷、精益等更多樣化的管理思路。

兩種截然不同的知識與實踐背景，讓他對研發管理有了更辯證的思考：爲什麽有些團隊用上了最前沿的管理方法，卻還是走不出方案有效，落地卻滿是纰漏的怪圈？

我們一致認爲，流程優化的落地效果，始終依賴團隊底層的工程實踐能力。研發管理如果脫離紮實的工程實踐談流程創新，終究是空中樓閣。

一、爲什麽方案有效，落地卻滿是纰漏？

因爲在落地的過程中，很多原本設想很好的實踐慢慢就走了樣。比如在研發流程中，需求評審與代碼評審這兩個關鍵環節就很容易淪爲走過場。

需求評審最大的作用，是讓所有人同時意識到：需求根本沒想清楚。评审的过程中，是能够让産品、研发、测试等所有角色在同一时间、同一语境下，共同意识到“这个需求到底有没有用，还有没有更好的方案”。

在這個過程中，我們才能夠及時發現那些隱藏在表面需求之下的邏輯漏洞、邊界模糊等問題。比如某功能模塊的用戶場景是否覆蓋全面？不同系統間的交互邏輯是否存在漏洞？異常情況的處理方案是否明確？

但若是跳过这一步或者只是走个过程，就容易出现“産品经理总是改需求怎么办”。这种频繁的需求变更不仅会打乱研发节奏，还会极大消耗团队精力，让团队陷入“做了又改，改了又做”的惡性循環。

再看代碼評審，抛開實現落地不談，團隊成員幾乎都會承認代碼評審對代碼質量的重要性，但又都對這一環節抱有抵觸情緒。

這種抵觸背後，藏著一種類似“囚徒困境”的心理博弈：從個人角度看，研發人員會覺得代碼評審占用開發時間，若暴露代碼漏洞或邏輯問題，還可能影響個人評價，于是傾向于簡化評審流程，甚至回避複雜模塊的檢查；但從團隊視角出發，嚴格的代碼評審能直接降低線上故障風險，減少後期維護成本，是保障研發質量的關鍵環節。

當團隊中每個人都抱著少花點時間在評審上，靠別人多把關的想法時，最終整個團隊都要爲低質量代碼買單。

二、爲什麽關鍵環節難以落地？

爲什麽新的管理方法難以奏效？本質上，是團隊的基本功沒練紮實。

像IT研發管理中的很多理念，我們在制造業、建築行業中都能找到源頭。比如建築業講究萬丈高樓平地起，依賴的是紮實的地基與標准化的施工，再比如制造業強調精益生産，就是靠每個環節的質量、成本管控來實現效率的提升。

因此在研發管理中，不論是傳統的瀑布式開發還是敏捷叠代，80%的核心實踐是相通的——需求管理、質量控制、配置管理、叠代規劃……這些基礎的能力如果沒法落地，再先進的管理框架也只是花架子。

爲什麽很多大型軟硬件結合的企業不用走敏捷，也照樣穩紮穩打？關鍵就是他們的底層工程實踐能力足夠紮實：需求評審有嚴格的准入准出標准，代碼質量有明確的管控流程，測試環節有完善的自動化體系……當基礎能力達標後，更好的管理方法才是助益。

禅道創始人春哥一直認爲，很多團隊的流程規範大多停留在“倡導”層面，缺乏一套讓其必須被執行的剛性約束機制。當流程可以被輕易繞過，且繞過之後沒有直接的負反饋時，“走捷徑”就成了人的本能。

因此在禅道中，我們也很注重在工具中落地團隊基礎工程能力的建設。

拿禅道DevOps平台中的代碼掃描功能來說，這就是保證工程實踐的一道閘門：提前定義代碼規範、自動化完成代碼規範檢查、識別潛在漏洞、預警各類質量隱患……讓問題都能在代碼提交階段被及時發現。

禅道項目管理软件-DevOps平台-扫描规则

（掃描規則）

（掃描問題）

（掃描概況）

而且這種自動化的掃描也不需要依賴研發人員擠出時間來做評審，更能減少因爲個人經驗不足、精力有限導致的疏漏。當代碼掃描成爲研發流程的固定環節時，研發團隊也會逐步實現代碼規範，在標准化流程的推動下，慢慢地從被動接受檢查轉爲主動追求質量。

許多團隊在管理方法中打轉卻難見成效，原因可能就在于把流程優化停留在了理念層面，沒能將關鍵的工程實踐轉化爲可落地、可衡量的行動標准。

而禅道所做的，正是用工具內置這種可衡量的標准。禅道中內置的更多類似代碼掃描的剛性功能，讓原本依賴個人經驗的質量管控，變成了團隊共同遵循的硬約束。

對想要破局的研發團隊來說，不妨先從兩個小步驟做起：