國(guó)內(nèi)IT企業(yè)的底子到底有多薄弱？

原創(chuàng) 贊收藏 評(píng)論

舉報(bào) 2025-09-04

掃描,分享朋友圈

敏捷、DevOps、CMMI、IPD……近年來(lái)，研發(fā)管理領(lǐng)域的各類框架與工具不斷迭代，管理者們急于借新方法打破效率瓶頸。

可現(xiàn)實(shí)往往是：學(xué)完敏捷就拉著團(tuán)隊(duì)開(kāi)每日站會(huì)，引入DevOps就搭了CI/CD流水線方法，流程改了多次，團(tuán)隊(duì)的研發(fā)效率卻始終難有質(zhì)的提升，投入與產(chǎn)出的落差，成了許多企業(yè)的老大難。

不久前，阿道接觸到一位剛開(kāi)始用禪道的朋友，我們也就這一問(wèn)題交流了許多。這位朋友的經(jīng)歷恰好也為這個(gè)行業(yè)難題提供了獨(dú)特的視角。

很有意思的是，他大學(xué)是學(xué)通信工程的，在校期間更多的是系統(tǒng)學(xué)習(xí)傳統(tǒng)軟件工程體系——從需求文檔規(guī)范到瀑布式開(kāi)發(fā)流程，每一步都強(qiáng)調(diào)嚴(yán)謹(jǐn)與標(biāo)準(zhǔn)化；而畢業(yè)后，他又先后進(jìn)入互聯(lián)網(wǎng)與金融領(lǐng)域，不同行業(yè)對(duì)響應(yīng)、迭代的不同要求，又讓他不得不主動(dòng)接納敏捷、精益等更多樣化的管理思路。

兩種截然不同的知識(shí)與實(shí)踐背景，讓他對(duì)研發(fā)管理有了更辯證的思考：為什么有些團(tuán)隊(duì)用上了最前沿的管理方法，卻還是走不出方案有效，落地卻滿是紕漏的怪圈？

我們一致認(rèn)為，流程優(yōu)化的落地效果，始終依賴團(tuán)隊(duì)底層的工程實(shí)踐能力。研發(fā)管理如果脫離扎實(shí)的工程實(shí)踐談流程創(chuàng)新，終究是空中樓閣。

一、為什么方案有效，落地卻滿是紕漏？

因?yàn)樵诼涞氐倪^(guò)程中，很多原本設(shè)想很好的實(shí)踐慢慢就走了樣。比如在研發(fā)流程中，需求評(píng)審與代碼評(píng)審這兩個(gè)關(guān)鍵環(huán)節(jié)就很容易淪為走過(guò)場(chǎng)。

需求評(píng)審最大的作用，是讓所有人同時(shí)意識(shí)到：需求根本沒(méi)想清楚。評(píng)審的過(guò)程中，是能夠讓產(chǎn)品、研發(fā)、測(cè)試等所有角色在同一時(shí)間、同一語(yǔ)境下，共同意識(shí)到“這個(gè)需求到底有沒(méi)有用，還有沒(méi)有更好的方案”。

在這個(gè)過(guò)程中，我們才能夠及時(shí)發(fā)現(xiàn)那些隱藏在表面需求之下的邏輯漏洞、邊界模糊等問(wèn)題。比如某功能模塊的用戶場(chǎng)景是否覆蓋全面？不同系統(tǒng)間的交互邏輯是否存在漏洞？異常情況的處理方案是否明確？

但若是跳過(guò)這一步或者只是走個(gè)過(guò)程，就容易出現(xiàn)“產(chǎn)品經(jīng)理總是改需求怎么辦”。這種頻繁的需求變更不僅會(huì)打亂研發(fā)節(jié)奏，還會(huì)極大消耗團(tuán)隊(duì)精力，讓團(tuán)隊(duì)陷入“做了又改，改了又做”的惡性循環(huán)。

再看代碼評(píng)審，拋開(kāi)實(shí)現(xiàn)落地不談，團(tuán)隊(duì)成員幾乎都會(huì)承認(rèn)代碼評(píng)審對(duì)代碼質(zhì)量的重要性，但又都對(duì)這一環(huán)節(jié)抱有抵觸情緒。

這種抵觸背后，藏著一種類似“囚徒困境”的心理博弈：從個(gè)人角度看，研發(fā)人員會(huì)覺(jué)得代碼評(píng)審占用開(kāi)發(fā)時(shí)間，若暴露代碼漏洞或邏輯問(wèn)題，還可能影響個(gè)人評(píng)價(jià)，于是傾向于簡(jiǎn)化評(píng)審流程，甚至回避復(fù)雜模塊的檢查；但從團(tuán)隊(duì)視角出發(fā)，嚴(yán)格的代碼評(píng)審能直接降低線上故障風(fēng)險(xiǎn)，減少后期維護(hù)成本，是保障研發(fā)質(zhì)量的關(guān)鍵環(huán)節(jié)。

當(dāng)團(tuán)隊(duì)中每個(gè)人都抱著少花點(diǎn)時(shí)間在評(píng)審上，靠別人多把關(guān)的想法時(shí)，最終整個(gè)團(tuán)隊(duì)都要為低質(zhì)量代碼買單。

二、為什么關(guān)鍵環(huán)節(jié)難以落地？

為什么新的管理方法難以奏效？本質(zhì)上，是團(tuán)隊(duì)的基本功沒(méi)練扎實(shí)。

像IT研發(fā)管理中的很多理念，我們?cè)谥圃鞓I(yè)、建筑行業(yè)中都能找到源頭。比如建筑業(yè)講究萬(wàn)丈高樓平地起，依賴的是扎實(shí)的地基與標(biāo)準(zhǔn)化的施工，再比如制造業(yè)強(qiáng)調(diào)精益生產(chǎn)，就是靠每個(gè)環(huán)節(jié)的質(zhì)量、成本管控來(lái)實(shí)現(xiàn)效率的提升。

因此在研發(fā)管理中，不論是傳統(tǒng)的瀑布式開(kāi)發(fā)還是敏捷迭代，80%的核心實(shí)踐是相通的——需求管理、質(zhì)量控制、配置管理、迭代規(guī)劃……這些基礎(chǔ)的能力如果沒(méi)法落地，再先進(jìn)的管理框架也只是花架子。

為什么很多大型軟硬件結(jié)合的企業(yè)不用走敏捷，也照樣穩(wěn)扎穩(wěn)打？關(guān)鍵就是他們的底層工程實(shí)踐能力足夠扎實(shí)：需求評(píng)審有嚴(yán)格的準(zhǔn)入準(zhǔn)出標(biāo)準(zhǔn)，代碼質(zhì)量有明確的管控流程，測(cè)試環(huán)節(jié)有完善的自動(dòng)化體系……當(dāng)基礎(chǔ)能力達(dá)標(biāo)后，更好的管理方法才是助益。

禪道創(chuàng)始人春哥一直認(rèn)為，很多團(tuán)隊(duì)的流程規(guī)范大多停留在“倡導(dǎo)”層面，缺乏一套讓其必須被執(zhí)行的剛性約束機(jī)制。當(dāng)流程可以被輕易繞過(guò)，且繞過(guò)之后沒(méi)有直接的負(fù)反饋時(shí)，“走捷徑”就成了人的本能。

因此在禪道中，我們也很注重在工具中落地團(tuán)隊(duì)基礎(chǔ)工程能力的建設(shè)。

拿禪道DevOps平臺(tái)中的代碼掃描功能來(lái)說(shuō)，這就是保證工程實(shí)踐的一道閘門：提前定義代碼規(guī)范、自動(dòng)化完成代碼規(guī)范檢查、識(shí)別潛在漏洞、預(yù)警各類質(zhì)量隱患……讓問(wèn)題都能在代碼提交階段被及時(shí)發(fā)現(xiàn)。

（掃描規(guī)則）

（掃描問(wèn)題）

（掃描概況）

而且這種自動(dòng)化的掃描也不需要依賴研發(fā)人員擠出時(shí)間來(lái)做評(píng)審，更能減少因?yàn)閭€(gè)人經(jīng)驗(yàn)不足、精力有限導(dǎo)致的疏漏。當(dāng)代碼掃描成為研發(fā)流程的固定環(huán)節(jié)時(shí)，研發(fā)團(tuán)隊(duì)也會(huì)逐步實(shí)現(xiàn)代碼規(guī)范，在標(biāo)準(zhǔn)化流程的推動(dòng)下，慢慢地從被動(dòng)接受檢查轉(zhuǎn)為主動(dòng)追求質(zhì)量。

許多團(tuán)隊(duì)在管理方法中打轉(zhuǎn)卻難見(jiàn)成效，原因可能就在于把流程優(yōu)化停留在了理念層面，沒(méi)能將關(guān)鍵的工程實(shí)踐轉(zhuǎn)化為可落地、可衡量的行動(dòng)標(biāo)準(zhǔn)。

而禪道所做的，正是用工具內(nèi)置這種可衡量的標(biāo)準(zhǔn)。禪道中內(nèi)置的更多類似代碼掃描的剛性功能，讓原本依賴個(gè)人經(jīng)驗(yàn)的質(zhì)量管控，變成了團(tuán)隊(duì)共同遵循的硬約束。

對(duì)想要破局的研發(fā)團(tuán)隊(duì)來(lái)說(shuō)，不妨先從兩個(gè)小步驟做起：