測不許的程序員（Heisenberg Developers）

摘譯自 http://mikehadlow.blogspot.co.uk/2014/06/heisenberg-developers.html

 

——「你沒法在不改變他們狀態的狀況下觀察一個開發者」

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

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

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

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

咱們對招什麼樣的人沒有發言權，新來的人明顯有文化差別。當咱們認爲須要重構，或者拋棄功能時，他們就反對，說咱們不幹正事，項目經理支持他們。

咱們變得士氣不振，吵了幾回之後，選擇很簡單：要麼閉嘴幹活，要麼走人。咱們最好的程序員走了。我學會了誇大工做量，讓作什麼就作什麼，把想象力和創造力留給業餘項目。

新來的同事沒有幾個享受軟件開發，之前辦公室裏聊編程語言，如今聊汽車。而他們看起來很喜歡這種管理方式。有我的這麼對我說：「你從待辦事項找到下一項，搞定它，劃勾，而後就再不用理了」。他們不用負責，不用做任何艱難的決定，不須要有大局觀。

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

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

這徹底誤解了軟件開發的本質。軟件開發自己是一個創造性和實驗性並存的過程。它原本就須要試錯。無數研究代表有效的創造性工做須要交給專家自主完成。做爲開發者咱們須要嘗試的自由，多試幾回才能找到一個有效的。咱們也說不清爲何要這樣，不少都是直覺，並且其中有一部分是錯的。

若是你問我開發一個功能須要多久，我只能老實說我真的不知道。我有一個大概的想法，可是無法肯定。

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

固然，對於那些喜歡工資多過編程藝術的人，微觀管理會頗有吸引力。你按時提交本身的任務，經理怎麼說你就怎麼作。若是用戶不滿意，系統bug一堆，也不關你的事，你的工做已經完成了。

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

到底應該如何管理開發者？
簡單：給他們自主權。設定一個大目標，讓開發者來實現就好了。他們有時會失敗，你對此須要留有餘地。不要由於失敗就增長干預。建設一我的人都有貢獻、值得信賴的團隊，而不是僱一屋子的被動消極的程序猿。