程序員不是資源

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

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

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

幾個具體細節建議：

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

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

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

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

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

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

請聽好了，程序員真的不是資源！