專案管理之我見 (轉)

專案管理之我見 (轉)[@more@]

之我見:namespace prefix = o ns = "urn:schemas--com::office" />

徐巖柏

 

一個好的管理者不是那種需要個人成功

或以人為本的人，而是那種喜歡權力的人

—大衛·麥克萊蘭(David McClelland)

 

  我非常欣賞這段名言，猛然看來這可能與我們的思想格格不入，中國幾千年的文化都是人與人之間和和美美，你好我好大家都好。可是這種境界可能很難長久。“不想做將軍計程車兵”是成不了一個好的管理者的。

  本人有幸得老師指點，在學生時代就開始商業的編碼，從學徒到技術狂熱追尋者，從員到一名專案管理者，每一步都給了自己很多的教訓。現在從一個新的起點，我開始冷靜下來，分析專案管理中的方法，這只是筆者自己的拙見。

  專案管理者上有懂事層、經理層，監工層，下只有被稱之為‘上帝’的編碼兄弟，如果把編碼人比喻稱普通工人農民，那專案經理就應該是基層三級幹部，嘿嘿。做基層幹部是及其不容易的，需要很好的和管理技能。那麼究竟如何做一個好的專案經理呢？過程如何？

  一個專案要從下面幾個方面來考慮：專案成本、技術範圍、時間控制、結果效益。這些也不是孤立的，它們是環環相扣的。

  專案成本決定專案的生命，一個50萬的專案和一個500萬的專案其生命週期是大大不一樣的；技術範圍可以決定開發的人力成本，對專案的質量控制有重大的影響；時間控制則可以在市場上佔據先機和優勢，同時對專案的人員配備產生影響；結果效益不言而喻，決定企業的生死。

  做一個專案往往經過如下的過程：

l  需求分析

這個過程就是知道要做什麼的過程，能把生活中的業務用文字描述出來，並進一步細化。這個過程是個艱難與抽象的過程，可能需要反覆多次。這就要求一個專案經理有敏銳的觀察力和良好的文字功底。如果你想向這方面發展，你要先培養自己這方面的能力，如果你連筆都懶的動的人，我想你可能不適合做專案經理。有時領導和上司的一句話、客戶的一個埋怨都是一個關鍵的材料。編寫出詳細技術需求，這包括所有面向、面向機器和其它軟體的介面，這要是一旦做錯，將最終會給系統帶來極大損害，並且以後再對它進行修改也極為困難。那麼如何才算一個較好的《需求分析報告》呢？筆者認為有這麼幾點：1需求要完整，能把客戶的要求都包含在內，同時使得開發者能從中找到設計和實現這些功能的資訊。2需求要正確，那種憑空猜測的功能是不可靠的，而且需求不能有二義性。3需求要可行，這可能是不少專案經理的誤區，專案一開始就設想要如何如何的功能強大， 沒有詳細考慮使用的環境和限制範圍，使得在實施時因技術可行性原因而修改需求，這就要求和小組的部分人員對需求的技術進行可行性分析。

l  專案計劃（設計）

計劃決定著誰去做、花多長時間去做、消耗多少費用的問題。作為專案經理，你在這時可能還是孤家寡人，你要制定良好的設計報告，這是向老闆要兵要馬的依據。一個良好的設計報告可能是這個專案中最重要的部分，甚至導致專案的生死。當然這也是最難做的，由於專案管理是一個創造性的過程，專案早期的不確定性很大，所以專案設計又不可能在專案一開始就全部一次完成，必須逐步展開和不斷修正，這又取決於能適當地對設計的情況作出反饋和控制，以及不間斷地交流資訊。

l  專案的實現（編碼）

這一部分就是專案怎麼做的問題了，雖然這些是每個程式設計師的工作，可是作為專案經理，這時更要有良好的組織才能。有了兵馬，如何行軍打勝仗？應該從下面幾個方面來考慮：1 團隊建設。怎麼使得這個團隊有生命力，發揮每個人的能力，這可以說是專案經理的社交技術，專案中有性格各異，興趣不一的兄弟，如何協調。比如外向型的人，說話直來直去，可能會使你難看，下不來臺，可是這種兄弟往往能指出你的不足和缺點，使你更好的改進你的工作方法，即使吵了架，喝上兩杯也就什麼都忘了；一個內向型的兄弟就應該冷處理，不要當面說其不是，要單獨細聊，還要及時關心他的生活。瞭解每位兄弟的興趣和長處，眾人拾材火焰高嗎！ 2專案的分解。怎麼把一個大的專案分解,需要專案經理有豐富的經驗，如果你不懂技術，那你應該去做投資、做懂事、總經理和人力資源經理。作為專案經理你應該能知道你分解的每一部分有多大的工作量和技術難度，它交給哪一個開發者最為合適，這樣你才能確切的安排時間進度；另一方面就是這些分解部分的重要級別，一級重要的部分、可能會給其它部分帶來重要影響的部分(一些共用模組)，要優先安排進行。其它的不重要的部分接下來進行，一旦發生不可控因數，可以把最不重要部分先去掉，同樣使專案順利交付。專案經理可以不是本開發團隊中技術最好的，但他(她)一定要是對需求最清楚的。還有就是有個攻關人，當專案進展中出現了技術難關，影響了專案的進行，或者專案的中間有人員流動，就需要攻關人來解決難題，其它的兄弟則繼續按計劃進行，來保證專案的按時交付。3 時間控制。有了兵馬，有了對兄弟的瞭解，有了專案的分解細化，剩下的應該就是監督和交流了，每個人只是埋頭苦幹自己的部分，你是沒辦法瞭解進度的，交流不會影響進度，一個良好的時間控制，能使得每個人工作起來很輕鬆，不要把所有的時間都用在編碼上，IT業是個知識爆炸的行業，每個人都要不斷學習新知識，這就需要有一定的時間來創新。要是Micorsoft的員工都只是寫程式，那就不會有如今優秀的軟體(思想)出現。只有個人和專案都能到達目標時，人的成就感才會更強烈，才不會有我出賣腦力就是混飯吃的感覺。專案經理的另一個誤區就是認為他的兵可以在此專案中學到更多的知識，不用再另外安排時間，“你做這個部分可以學到×××技術或你看這一塊也很有難度不是,可以學到很多”等等，可是你也冒了最大的風險，你不能知道他需要多久才能學會，你不知道在使用這個他不熟悉的×××技術時會有多少,沒有辦法，你的專案就成了他學習新知識的試驗地。從編碼人員來說，他也擔心出現問題，當修改BUG成了工作一部分時，他就會灰心喪氣，後果也是很糟糕的，怎麼辦？那就給你的兵一個學習、創新的機會。當每個人知識都在增長時，專案還不更好控制嗎？4質量控制。說白了也就是編碼質量控制，這同樣也要求專案經理懂技術，在個性化的演算法中要有統一，介面如何、命名如何、註釋如何、資料和演算法如何以及最終的如何都要有事先的規劃，包括使用的設計開發工具等都要做好要求。

l  專案的測試

當編碼完成時，作為專案經理的你不要認為可以鬆口氣了，你要對可能出現的任何結果負責，BUG出現了，你要分析可能原因，召開專案交流會，不要把責任一下子推到你的兵頭上，要協助解決，使得能將錯誤排除。還有就是測試報告不要要求太高，例如每一個普通運算元據介面，你都要進行壓力和效能測試是很荒唐的，你是在測，不是你的專案。作為專案經理你要清晰認識到：bug是不可避免的！

l  專案的維護與升級

這是最後一個問題了，你要利用這一段時間對專案進行總結，召開工作彙報會，給老闆和懂事彙報工作，召開專案組會議給你的兵以最恰當的感謝和肯定，沒有他們你是不能完成任務的，這樣也能為今後專案的再次合作打下良好的基礎，然後你的兵有些可能升了職或調到另外的一個專案組了。