——“你無法在不改變他們狀態的情況下觀察一個開發者”
故事是這樣的，數年以前我在一個頗具規模的專案裡幹活。一開始十分順利，不懂技術的老闆和一些使用者給我們指個大方向，等我們做出來他們就來測試功能。該重構就重構，該整個拋棄就拋棄。不用事事找老闆授權，只要功能按時完成，大家都 happy。
接著遇到一個難搞定的使用者，他要用軟體來替代專業使用者多年的經驗和直覺，他提的需求不能再模糊了，必須在下一個版本就實現。我們說什麼都沒用。幹了幾個月什麼也沒做出來。老闆沒辦法，找來了一個看簡歷是頂級的專案經理。工作流程立馬變了，我們開始使用 Jira，每個功能都被細分到不超過一天的工作量，每兩個星期開一次持續一天的會分配下一階段任務。
奇怪的是，進度反而更慢了。計算好的專案交付時間還在往後拖。然後專案經理就開始做一件最常見的事：招人。我們對招什麼樣的人沒有發言權，新來的人明顯有文化差異。當我們認為需要重構，或者拋棄功能時，他們就反對，說我們不幹正事，專案經理支援他們。我們變得士氣不振，吵了幾次以後，選擇很簡單：要麼閉嘴幹活，要麼走人。我們最好的程式設計師走了。我學會了誇大工作量，讓做什麼就做什麼，把想象力和創造力留給業餘專案。
新來的同事沒有幾個享受軟體開發，以前辦公室裡聊程式語言，現在聊汽車。而他們看起來很喜歡這種管理方式。有個人這麼對我說：“你從待辦事項找到下一項，搞定它，劃勾，然後就再不用理了”。他們不用負責，不用作任何艱難的決定，不需要有大局觀。專案進度越來越慢，bug 越來越多，隊伍越來越大，卻沒見改善。公司花的錢越來越多，收益越來越少。
到底哪裡出了問題？
在商業領域，細分式的軟體專案管理很吸引人。每個機構都渴望事情盡在掌控之中：給開發者那麼多薪水獲得了什麼回報，系統交付的時間多長，這樣才能做出準確的成本效益分析，預測生意。這完全誤解了軟體開發的本質。軟體開發本身是一個創造性和實驗性並存的過程。它本來就需要試錯。無數研究表明有效的創造性工作需要交給專家自主完成。作為開發者我們需要嘗試的自由，多試幾次才能找到一個有效的。我們也說不清為什麼要這樣，很多都是直覺，而且其中有一部分是錯的。
如果你問我開發一個功能需要多久，我只能老實說我真的不知道。我有一個大概的想法，但是沒法確定。一旦你問一個開發者告訴你接下來的 8 天他每天都要做什麼，你就把大部分創造力和意外之喜謀殺了。當然，對於那些喜歡工資多過程式設計藝術的人，微觀管理會很有吸引力。你按時提交自己的任務，經理怎麼說你就怎麼做。如果使用者不滿意，系統 bug 一堆，也不關你的事，你的工作已經完成了。
細分式的管理直接導致人才流失。那些真正厲害的程式設計師會直接走人，他們不愁找不到工作。那些不喜歡做決定，喜歡找藉口的人會留下來。你會發現你的隊伍變得越來越會抱怨，但對你的每項指令都順從的執行，對需求沒任何意見，好好填寫 Jira 表格，然後生產出質量極差的軟體。
到底應該如何管理開發者？
簡單：給他們自主權。設定一個大目標，讓開發者來實現就行了。他們有時會失敗，你對此需要留有餘地。不要因為失敗就增加干預。建設一個人人都有貢獻、值得信賴的團隊，而不是僱一屋子的被動消極的程式猿。
本文轉載自：伯樂線上