測不準的程序員

——“你無法在不改變他們狀態的情況下觀察一個開發者”

故事是這樣的，數年以前我在一個頗具規模的項目里干活。一開始十分順利，不懂技術的老板和一些用戶給我們指個大方向，等我們做出來他們就來測試功能。該重構就重構，該整個拋棄就拋棄。不用事事找老板授權，只要功能按時完成，大家都happy。

接著遇到一個難搞定的用戶，他要用軟件來替代專業用戶多年的經驗和直覺，他提的需求不能再模糊了，必須在下一個版本就實現。我們說什么都沒用。干了幾個月什么也沒做出來。

老板沒辦法，找來了一個看簡歷是頂級的項目經理。工作流程立馬變了，我們開始使用Jira，每個功能都被細分到不超過一天的工作量，每兩個星期開一次持續一天的會分配下一階段任務。

奇怪的是，進度反而更慢了。計算好的項目交付時間還在往后拖。然后項目經理就開始做一件最常見的事：招人。

我們對招什么樣的人沒有發言權，新來的人明顯有文化差異。當我們認為需要重構，或者拋棄功能時，他們就反對，說我們不干正事，項目經理支持他們。

我們變得士氣不振，吵了幾次以后，選擇很簡單：要么閉嘴干活，要么走人。我們最好的程序員走了。我學會了夸大工作量，讓做什么就做什么，把想象力和創造力留給業余項目。

新來的同事沒有幾個享受軟件開發，以前辦公室里聊編程語言，現在聊汽車。而他們看起來很喜歡這種管理方式。有個人這么對我說：“你從待辦事項找到下一項，搞定它，劃勾，然后就再不用理了”。他們不用負責，不用作任何艱難的決定，不需要有大局觀。

項目進度越來越慢，bug越來越多，隊伍越來越大，卻沒見改善。公司花的錢越來越多，收益越來越少。

到底哪里出了問題？

在商業領域，細分式的軟件項目管理很吸引人。每個機構都渴望事情盡在掌控之中：給開發者那么多薪水獲得了什么回報，系統交付的時間多長，這樣才能做出準確的成本效益分析，預測生意。

這完全誤解了軟件開發的本質。軟件開發本身是一個創造性和實驗性并存的過程。它本來就需要試錯。無數研究表明有效的創造性工作需要交給專家自主完 成。作為開發者我們需要嘗試的自由，多試幾次才能找到一個有效的。我們也說不清為什么要這樣，很多都是直覺，而且其中有一部分是錯的。

如果你問我開發一個功能需要多久，我只能老實說我真的不知道。我有一個大概的想法，但是沒法確定。

一旦你問一個開發者告訴你接下來的8天他每天都要做什么，你就把大部分創造力和意外之喜謀殺了。

當然，對于那些喜歡工資多過編程藝術的人，微觀管理會很有吸引力。你按時提交自己的任務，經理怎么說你就怎么做。如果用戶不滿意，系統bug一堆，也不關你的事，你的工作已經完成了。

細分式的管理直接導致人才流失。那些真正厲害的程序員會直接走人，他們不愁找不到工作。那些不喜歡做決定，喜歡找借口的人會留下來。你會發現你的隊伍變得越來越會抱怨，但對你的每項指令都順從的執行，對需求沒任何意見，好好填寫Jira表格，然后生產出質量極差的軟件。

到底應該如何管理開發者？

簡單：給他們自主權。設定一個大目標，讓開發者來實現就行了。他們有時會失敗，你對此需要留有余地。不要因為失敗就增加干預。建設一個人人都有貢獻、值得信賴的團隊，而不是雇一屋子的被動消極的程序猿。閱讀原文 ?