會寫代碼的專案經理

也許文章的標題起的帶有諷刺的味道，其實這也是本人的一個小小的疑問。

一個項目的領導者該不該對技術有一點深度的瞭解或者說專案經理應該是一個不錯的進階程式員。我的頭跟我說專案經理不需要寫代碼也不需要對技術有多瞭解，只要對項目的進度有個整體的把控就OK了。這種觀念一開始我不太贊同，專案經理對技術的實現沒有一定的瞭解，在安排進度的時候是不是會草率的了事。給程式員預留的時間也不能準確的控制好，是不是會導致項目的進度控制的不太合理；

在參與開發項目的時候尤其是有一定技術含量的時候，更要專案經理對技術的實現有自己獨特的見解，能協助程式員理清頭緒。但是話說回來，專案經理不可能幫每個程式員都去解決技術問題。在一些中小企業，專案經理顯的很“肥胖”，這種“肥胖”完全是脫俗的，對技術似乎已經到了一種爐火純青的高度，總覺得技術無非就是增、刪、改、查。這也是我的頭跟我說的，程式員就是做增、刪、改、查的。沒有多少技術含量，敲來敲去都是那些東西。做為程式員的我們不太喜歡聽這樣的話，技術的深奧是不能用這種片面的話來概括的。

我們搞技術的，在領導看來常常有一種毛病，什麼毛病呢？就是我們在解決技術問題的時候，喜歡較勁。領導會這麼想也有他的道理，領導希望能把項目趕緊做完。在進度上領導永遠最關心，不喜歡我們為了一個小小的技術問題，而耽誤大量的時間。哪怕換一種相當麻煩的實現手段也行，保證進度第一。如果沒個程式員都這樣想，我擔心恐怕項目的品質難以保證了。

由於專案經理的存在是隨著項目的存在而存在的，我所在的開發部。項目完工後，就交給維護部門進行後期維護。經常聽到維護人員的抱怨，代碼寫的亂、繁瑣，難以維護，添加一個功能只能進行額外的編寫代碼，更本沒辦法切入代碼中進行添加。這個時候專案經理已經不複存在了，哪怕知道這個項目是某個人帶的，也許這個人又帶了另一個項目。這樣的惡性迴圈，受罪的是維護人員。我們公司的業務量比較大，項目的開發週期很短，一般一個項目基本上都控制在一個月之內。為了突進度，將大量的技術不錯的程式員從維護部門掉出來，進行項目的開發。在這種節骨眼上，我看到的是專案經理已經不太在乎技術實現的方法了，只在乎技術實現就行了。基本上維護部門需要對我們開發的代碼進行一個40%的重寫，而不是重構。因為看不懂，或者說是很繁瑣更本沒辦法維護下去。如果改出了問題，線上上報錯，那麼維護人員的代價就大了，輕則警警示告，重則扣錢。

所以本人一直不贊同專案經理是一個不懂技術的人，可能就是會簡單的東西就帶項目。很多公司都有一種現象，不關你的技術水平怎麼樣，只要你熟悉業務就能帶項目，技術問題交給程式員，但是有沒有考慮到你手下的程式員是不是大部分都是不錯的。人多了不一定就能把事幹好，反而讓帶新人的老員工分神。一個專案經理一定要是一個不錯的架構者，雖不說你精通某種技術，但最起碼要求你對整個技術架構有個自己的認識。

也許園子裡的兄弟們不這麼認為，這隻是本人的一些想法，專案經理到底該不該熟悉技術。這樣的疑問我想在園子裡能找到答案。