關於修車師傅的補充

關於修車師傅的補充

昨天令狐看了《修車師傅=軟體專案管理者》後私下裡跟我討論了一下。

令狐說得不錯：管理是分幾個層次的，每個層次都需要有管理。比如，高層領導對全公司進行管理，部門經理對部門的所有項目以及部門發展要有管理，專案經理對項目進行管理，至於最下面的小兵兵，也要對自己的任務有一個有效管理。

我非常同意他的看法，但對於我們來說，高層的管理咱沒接觸過，不敢妄加評論，只能就接近具體開發工作的軟體專案管理隨便說說。

令狐說：這是一個典型的管理不足的例子，那個修車師傅應該做的是，告訴徒弟們如何修車（基礎知識培訓），另外，還必須告訴他們如何合理安排自己的工作（管理知識培訓），師傅自己還要適當介入，為徒弟們做一些高層面的安排（專案管理），這樣，這個團隊才能有效運作徒弟要學，師傅也要學，師傅的專業技能應該是沒問題了，那麼他就應該學習如何合理使用手中的資源，包括靜態資源和人力資源。

這也正是我要表達的：技術專家未必是管理專家，雖然說可以通過學習逐步掌握，但這樣未必好。揚長避短才是更好的用人之道。如果一個公司裡，只有向管理髮展這條唯一的升遷之道，就必然迫使技術人員棄已之長，用已之短。就像讓Anders去當BORLAND的CEO一樣。

另一方面做技術管理的也必須瞭解技術，並參與其中，雖然他不必是高手，但不能脫離技術。其實在MS裡也是這樣的，很多專案經理甚至進階的產品主管都有在做編碼工作，不過國內的很多軟體專案經理好像一升做管理就覺得高人一等，不屑於再去做編碼這樣的工作，看來他們比MS的主品主管還牛啊。

令狐也說了：按敏捷的要求，管理者本身也是參與開發的，只是他的任務更加重而已，他起到的更多是一個協調團隊的作用，而不是一個指手畫腳的作用，作為一個團隊的管理者，應該是開例會的時候調動大家發言，並且控制發言主題不會偏離既定主題太遠的那個人，而不是一個在例會上長篇大論，讓其它與會者只能接受的那個人。

這點我很贊同，有一種說法便是：如果會上始終只有一個人在發言，那不叫開會，那是上課。

當然上課也是必要的，那就是成員間的相互培訓。令狐提到一個不影響工作的培訓方法就是建立公司內部的知識庫，這是一個好方法，不過我想面對面的培訓同樣不可或缺，但只能以自願為原則在工作之餘進行，這樣的話就必須保證XP要求的每周四十小時工作，不能加班。這就比較難了。

本文大量引用了令狐的意見，特此鳴謝。^_^