程式設計師不是資源

　　在我入行的時候，專案經理的Excel或Project裡面經常看到我的名字，作為一個資源存在，隨時供調配。這個起初還沒有什麼，但是某一天當我遇到一個爛掉渣的專案經理之後，就對這個越來越反感了。程式設計師的名字不應該僅僅是表格裡面的一個資源，而是企業價值的實現者，沒有企業員工你企業屁都不是。

　　通常一個公司在專案緊張的時候，程式設計師會面臨加班趕進度，甚至熬夜的場景；由於市場環境和企業生存壓力，可以理解，特別對於做專案的公司，客戶從需求提出到上線，給你2個月時間，任性的要命。但是這種狀況如果在一個公司是常態，程式設計師經常處於救火的狀態，從一個專案到另外一個專案，不停切換，那就是公司的問題了。

　　程式設計師的勞動是一種較高強度的腦力密集型勞動，很難說將一個程式設計師放在什麼地方，他就能產出多少的成果。一個好的程式設計師和一個差的程式設計師寫出的程式，其效能，可讀性，擴充套件性差幾條街可能還找不到。如何讓程式設計師自由發揮，產出超出預期的成果，是管理者的責任，也是一個好的技術管理者的衡量標準。在不停救火的狀態下，程式設計師只能把你的功能實現，要說其他，那就算了吧！爛專案就是這麼養成的，大家都是在自己的一定工作範圍內把功能實現，否則老闆會說你能力不行，還談什麼設計！還談什麼程式碼可讀可維護！

　　幾個具體細節建議： 

儘量給程式設計師提供一個寬敞的辦公環境

　　有條件的話，可以提供較寬敞的辦工桌和辦公環境，不說什麼人體工程學座椅，只要辦工桌夠大，辦公室開闊，有思考問題的地方就行；沒有條件也要創造條件。

傾聽程式設計師的聲音

　　專案到期完成不了，不是程式設計師的問題，是管理者的問題，如果能力不行，那麼早開始你為什麼看不出來，看出來了為什麼不替換掉，不能替換為什麼不重新調整工作計劃；對進度把我不住，為什麼不每天早會，每週週會進行進度調節；先聽聽程式設計師的說法，為什麼沒有完成，是幾個專案同時進行，還是需求理解不透，還是技術遇到難點，作為管理者有沒有及時發現問題，並幫助解決，見過爛的技術管理者，基本上只會責怪，只會催繳週報！ 

專案進度把控

　　雖然敏捷流行，但是一般公司也不會這個，但是你只要使用其中幾個關鍵點就行，對專案也能進行把控，象上面說的早會，每個人說清楚自己昨天完成的事情和今天要做的事情，以及困難，這樣專案進行中大家都能知道各自做的東西在整個專案中的作用；可以將每次迭代計劃分配到人的每個任務寫出來貼在牆上，精確到天，做完一個劃掉一個，專案每個成員都看的清清楚楚，有壓力的同時，動力自然也來了。

程式碼設計評審的重要性

　　相信現在阿里的程式碼也沒能做到百分之百的評審後上線，但是這個不是你不進行程式碼設計評審的藉口，特別是對於一個企業的核心繫統，不然日積月累其結果就是，這個系統就是職業陷阱，誰接手誰離職！一次內部評審也就花個20分鐘，說說思路就行，你說你沒時間，你有沒有想過你一天的工作效率多低，你一天真正集中寫程式碼的時間也就三四個小時而已，其他時間被各種雜事佔據，20分鐘你也拿不出來。

讓程式設計師承擔起責任

　　不要讓程式設計師只是作為一個功能的實現者，要讓他們自己有能力的時候承擔起一個系統來，人在被動接受任務的時候都會有種反抗心理，主動承擔任務的時候，就截然相反了，對於有能力的程式設計師為什麼不讓他自己說了算呢！

團建的重要性

　　早前我在的一家公司，我所在的部門有個傳統，每個季度都會有個大型的團建活動，把各個地方的員工一起聚在北京一起玩，讓大家互相認識互相瞭解，潛移默化的就是以後工作起來大家比較默契，效率自然就高了。作為技術管理者，搞好搞活團建活動是個硬指標。

　　請聽好了，程式設計師真的不是資源！