開發人員解決唔‌管理爛嘅問題

轉載：本文來自微信公眾號“InfoQ”（ID:infoqchina），作者：Gandalf Hudlow，譯者：平川，策劃：Tina，轉載經授權發布。

本文最初發佈於 iiSM.org，由 InfoQ 中文站翻譯並分享。

我經常睇到一啲文章指責開發人員唔理解佢哋點解要做改變，唔理解背後嘅“點解”就盲目地實現改變是錯誤嘅。“向上睇，唔好將太多精力放喺寫代碼上！”喺我睇來，呢啲文章所面向嘅人群是錯誤嘅。喺大多數公司度，實際上應該由管理層為故意將工程師隔離喺發現客戶需求之外嘅行為負責。實際上，開發人員鐘意發現需求，並用史詩級嘅軟件解決方案滿足需求，佢哋非常唔願意花時間創建沒有客戶想要嘅嘢——我嘅意思是，我哋鐘意創建軟件，只要我哋能咁樣做並因此獲得報酬，如果沒有更好嘅、更令人滿意嘅機會，我哋就會消磨時光。但係，如果有一個更令人滿意嘅、可以獲得報償嘅機會，比如為汽車創造自動駕駛儀，或者一個閉環胰島素泵，我哋會立刻跳槽！

傳統管理有詳細嘅估算、甘特圖、WBS、PMP 和所有第啲嘅製造 / 訂單執行 / 物流優化技術！

管理層是阻止開發人員創建滿足迫切需求嘅產品嘅真正問題。事實上，呢個問題一直延伸到 CEO 身上。因為發現真正嘅客戶需求系喺項目的生命周期度，而發現嘅呢啲需求必然會改變所涉及嘅工作範圍，呢意味住，為咗避免項目範圍嘅變化，一個 MBA 實踐驅動嘅組織將避免發現真正嘅客戶需求。相反，佢哋讓工程團隊喺確定嘅日期之前將事做完，而做完嘅系一個沒有客戶想要嘅產品，因為發現真正嘅客戶需求嘅行為被抑制嘎啦。此外，由於團隊一直專註於創建新特性，而唔是描述佢哋自己嘅工作並消除混亂，產品可能會變得混亂唔堪。項目完工唯一嘅好處是通常會有一個發布派對，有披薩和蛋糕——再好一點，佢哋獲得‌一點點職業發展，因為團隊按約定日期完成‌交付——我嘅意思是，交付嘅嘢沒有得到採用，但佢哋唔喺意，直到有人通知佢哋客戶沒有採用，通常，CFO 會應用 4X Rule 規則，削減集團預算。

我哋有史以來一直咁樣

軟件行業所處嘅呢種管理狀況喺歷史上也有類似嘅情況。大約喺 1940 年，W. Edwards Deming 為底特律嘅汽車製造商帶來‌一種新嘅汽車製造方法。呢個時候，底特律賺住大錢，佢哋佔領‌世界上最賺錢嘅市場，坦率噉講，佢哋唔覺得有必要做任何改變。遭到拒絕後，Deming 開始住手第啲任務，參同戰後日本嘅重建工作。他嘅方法非常成功，日本汽車開始侵蝕底特律嘅市場份額。當顧客等待並支付額外費用購買一輛配備豐田製造變速器嘅福特汽車時，福特得到‌一個實際嘅教訓。迷惑唔解嘅福特工程師將變速器拆開，比較‌各個部件；佢哋發現，日本嘅零部件具有兩倍嘅均勻一致性，結果是更平滑嘅擬合和卓越嘅車輛可靠性。

只要簡單地詢問下佢哋嘅工人“點樣才能做得更好”，傾聽佢哋嘅意見，然後對製造過程做些新嘅、實用嘅改進，任務管理者就能顯著地提高佢哋嘅質量。之前嘅方法是管理者通過抽象思考想出改進嘅方法——通常是佢哋老闆嘅想法——然後將呢啲想法灌輸畀員工。而家，呢種自頂向下嘅反模式反覆出而家軟件團隊管理中。

1981 年，喺日本蠶食福特嘅市場份額多年以後，福特管理層終於投降，讓 Deming 加盟，整頓佢哋嘅製造業務。福特嘅管理層認為，佢哋有質量問題，或者更準確噉講，佢哋嘅工人有質量問題，因為管理人員唔干工人嘅活。當 Deming 講畀佢哋，喺研發更好嘅汽車嘅過程度，管理措施要為 85% 嘅問題負責時，佢哋感到震驚！福特花‌ 6 年嘅時間完成轉型，最終推出‌ Taurus-Sable 系列，呢款汽車比佢哋之前生產嘅汽車都要好。

喺致 Autoweek 嘅信度，時任福特董事長 Donald Petersen 說，“我哋正努力喺福特建立質量文化，呢里發生嘅好多變化都直接源於 Deming 嘅教誨。”

福特管理層犯嘅一個關鍵錯誤是，佢哋沒有從工人那裡認會點優化生產流程。只要簡單地詢問下佢哋嘅工人“點樣才能做得更好”，傾聽佢哋嘅意見，然後對製造過程做些新嘅、實用嘅改進，任務管理者就能顯著地提高佢哋嘅質量。之前嘅方法是管理者通過抽象思考想出改進嘅方法——通常是佢哋老闆嘅想法——然後將呢啲想法灌輸畀員工。

Deming 講畀福特，喺研發更好嘅汽車嘅過程度，85% 嘅問題都系由管理層嘅行為造成嘅！喺而家嘅軟件管理度，我哋發現自己也面臨住同樣嘅情況。

我哋出‌管理問題！

而家，讓我哋回到嗰啲“開發者需要做得更好”嘅文章。試想，如果呢啲文章是為汽車工人寫嘅。那麼標題會是：

美國嘅汽車工人真嘅需要專註於改進佢哋嘅製造過程，噉就是豐田所做嘅！
汽車工人應該唔斷地同客戶溝通，咁樣佢哋才能盡最大可能製造出最好嘅汽車
汽車工人將太多嘅時間花喺‌細節上，卻沒有花足夠嘅時間去理解“點解”
創造超凡嘅汽車而唔剩只是生產汽車

作者嘅意圖是好嘅，從表面上睇，佢哋嘅建議也好好，但是呢啲汽車工人點樣改變佢哋嘅工作流程呢？佢哋系咪要對公司管理層進行再培訓？歷史講畀我哋，佢哋沒有做到，我也唔指望佢哋能做到。喺大多數公司，軟件工程師發現自己處於同樣嘅情況。喺我哋大多數人工作嘅公司里，MBA 實踐佔據主導地位。喺經過 MBA 訓練嘅管理者那裡，每個開發人員都系佢哋 PMP/WBS 鎚子下嘅一個釘子——每個人都有一個甘特圖、一個項目經理和一個項目代碼！

甚至當一個採用傳統方式管理嘅公司決定變得“敏捷”時，呢一舉措嘅常見結果是傳統管理方式友好嘅 Date Scrum 反模式。Date Scrum 嘅出現讓好多開發人員對敏捷實踐產生‌負面嘅睇法，因為喺變得“敏捷”之前，佢哋不得不忍受每隔幾周就會有一次嘅狀態會議。而家有‌ Date Scrum，佢哋必須忍受每天一次嘅站立狀態會議！

Date Scrum 是乜嘢？Date Scrum 系一種研發模式，佢要求開發人員預先評估成個項目的軟件項目需求。喺項目獲得批准，並基於最終嘅評估設置‌預算之後，團隊就會保持日常嘅 Scrum 狀態，並喺發布之前管理喺解決方案“迭代”過程中嘅風險。喺某啲人睇來，呢種方法系喺衝刺中進行瀑布式開發。

因此，我哋需要更多嘅文章來鼓勵高層和管理人員唔好再導致軟件項目失敗嘎啦，呼籲放棄傳統管理嘅估算、甘特圖、WBS、PMP 和所有第啲嘅製造 / 訂單執行 / 物流優化技術。那嘢好好，佢是幫助我哋贏得 WW2 嘅關鍵，如果我要開工廠，我會用佢！但系喺軟件項目度，沒有佢嘅位置。

點解咁多嘅軟件項目失敗‌？軟件開發更接近於創建一個新工廠，而唔是經營一個現有嘅工廠。傳統管理側重於使用固定嘅、已知嘅最佳實踐來安排持續時間已知嘅任務來經營工廠和執行訂單。軟件開發是由好多持續時間未知嘅任務組成，呢種根本上嘅唔可預測性令到傳統管理嘅預測計劃技術特別唔適合軟件項目。

傳統管理點樣造成‌破壞

福特花‌ 40 年時間才接受‌ Deming 嘅研究成果。喺今日呢個快節奏嘅世界里，一家公司如果要花 40 年嘅時間才能讓有價值嘅軟件工程師唔再討厭佢，噉佢將永遠唔會成功，而且我預測，大多數唔發展嘅公司將會喺 10 年內滅亡。之所以做出呢種可怕嘅預測，是因為呢啲傳統企業一直徘徊喺咁樣一種生產管理套路上，根據工作劃分部門，然後使用一種剛性嘅、放之四海而皆準嘅最佳實踐優化各部門——呢啲最佳實踐往往是源於工廠運營工具包嘅預測規劃技術！正系呢啲實踐阻止‌佢哋創造新嘅、有價值嘅軟件產品，因為佢哋讓開發團隊專註於創造沒有客戶想要嘅解決方案，而唔是發現和滿足巨大嘅需求。呢啲實踐導致組織主動忽略‌軟件項目偏離軌道嘅所有危險信號。危險信號被忽略嘎啦，因為組織中固有嘅 MBA 偏見會導致佢哋應用反模式，比如：