專案總監的方法論總結——點評

專案總監的方法論總結——點評

在MSN專案管理群裡，一位很資深的IT工作人員推薦她的部落格，我粗看了一下確實不錯，準備每篇閱讀一下，當然也希望透過點評一下來提高一下自己

原文地址：http://blog.違規廣告/user2/50754/archives/2009/37097.html
公司最近一下籤了好幾個軟體專案的單子，銷售額得上千萬了吧？本是好事，可是公司以前從沒有同時做這麼多專案，這種資訊化專案，週期較長，客戶都是大型國有企業，不好伺候。作為專案總監，管理著所有的專案和產品線，每天堆積到我這裡的問題層出不窮，搞得焦頭爛額。驀然回顧，才發覺自己和以前做CMMI顧問（做了4年半啊）時宣講的那些好的做法相距甚遠，自我反省並用通俗的語言提煉了一下，以期提高工作效率。
--上千萬的單子
--首先需要需要對單子進行分類，大單還是小單；單子複雜難易程度如何？是新技術新業務還是基於已有的專案；單子的優先順序如何
--上千萬的單子如果單純安裝人月/人收入去評估，需要多少研發人員，是否能夠交叉平行，研發人員是否能夠相互滲透到不同專案中。
--給每個專案制定相關人力、時間、成本計劃。

1.做事首先要建立一個明確的指導思想；原則不確定，無法談下面的。唉，這個“生產管理的專案”為什麼一開始不說好可以不以現有的產品為基礎呢，白白各個部門扯皮了那麼久！
--同意，但這個指導思想是建立在之前的分析基礎上的，基於產品看似很簡單，但也會面臨很多問題，以部分為基礎能否相容？是否面臨整合問題？

2.做事要有計劃；計劃，計劃，專案組自成立以來，似乎天天做計劃，可是到現在團隊沒有團隊的計劃，個人沒有個人的計劃。
--作為專案經理要有專案計劃，作為研發人員也要有周計劃，但是作為專案總監需要對每個專案的進展、問題、過程、風險有所評估，專案總監只需要看到專案經理的計劃即可。

3.為要做的事配備合適的資源；是“合適”的而不是“足夠”的。為什麼專案經理都認為公司一定要給你配備最強的人呢，給你配最強的了，別的專案咋辦呢？
--這個非常贊同。但前提是專案總監得了解自己的專案經理，他的業務水平、技術水平、管理水平、性格等等，把人放到合適的位置上，發揮和挖掘他的潛力。

4.給參與做事的人分配責任和許可權；本公司的組織結構很特別，專案經理和產品經理都集中在一個部門－專案管理部，然後是軟體設計部，開發部和測試部，最後還有個實施部，1個專案從頭到尾，至少要經過銷售、諮詢、專案管理、軟體設計部、開發部、測試部和實施部7個部門，責任和許可權難免有定義不清楚的地方。
--總的感覺，分工過於細緻了，不清楚公司規模公司狀況，無法下定論；部門越多，相關利害關係就越大，對於小公司建議以專案組方式存在，但必要的監管部門是必要的。

5.培訓人員；說來慚愧，我這個專案總監就沒對專案經理做必要的培訓，尤其是新來的專案經理，注意事項等等，專案經理管理著不是他下屬的專案成員，經常整的雞飛狗跳，我倒成了大保姆了，老要給人做思想工作。
--培訓人員，個人認為應該上升到公司制度層面和績效考核層面，但很遺憾，沒有公司願意去投入或是不能持續下去；這一點外企做的很出色，讓你能夠感受到自身能夠提高，而不是單純的coding和工作。

6.對產出物進行配置管理，簡單得說，就是儲存工作成果並版本控制，保證需要時能找到、找對成果物。
--配置管理是CMM2的基本要求，也是公司應該加以重視的一塊。配置管理在專案中通常只是給別人看的，實際上沒多少人去重視。
--配置管理對於大型系統的研發管理和多版本的研發管理是很有益的！
--配置管理對於形成公司級的組織研發能力和知識庫是很有幫助的！

7.識別誰是共利益者並拉其“下水”，一起做事。注意，首先就是“識別”，而不是恨不得把每個人都拖下水。有個諮詢專案，10幾萬的小單，兩個人做足矣，一遇到困難，就拖著別人一起幹，最後拖下水的共有7人之多，整成了個爛攤子。
--區分相關利益者，關鍵的和非關鍵的，核心的和非核心的，參與的和公司領導。

8.確定了以上的原則和方法，要有人度量過程，即使是1個人的工作，也要做度量。只有度量了，才好監控。現在誰都愛說事情難做，憑什麼呢？舉例說，本人8個月內跟績效考核相關的工作，僅方案就寫了5稿，跟老闆彙報了3次，跟CTO討論了3次，跟HR總監討論了4次，跟人事專員討論了1次，跟各部門經理討論了6次，跟專案經理/產品經理討論了3次，每次討論平均2小時/次,中間附帶還做了2次培訓....而且至今還沒成果，有了這些資料，我說難做。大概不會有人反對。喜歡記錄資料，這是至今為止我仍然還保持的以往的好習慣。
--度量是軟體過程管理中一個比較高階的階段了，這個的確很難做，但是又不能不去做的事情
--我的看法是從簡單入手，從程式碼的稽核、質量著手對開發人員進行度量；從程式碼的測試bug數量、重要程度對測試人員進行度量；從專案的實施過程和計劃相比對pm進行度量。
--首先度量，有了資料基礎，才能做其他事情。

9.要找人來客觀評價所做的效果；目前好像只有靠客戶來檢驗成果，公司的QA形同虛設。
--多數情況下，QA也是不被重視的，測試作為QA中的重要環節，應該獨立出來，但也會根據公司規模而定。

10.要讓你的上級及時瞭解進展和存在的問題；這個“上級”如果在比較複雜的管理模式下，應該在一開始確定清楚，現在存在兩種現象，或者只跟部門領導報告，專案經理不清楚，或者只跟專案領導彙報，部門領導不清楚。在壓力巨大，貌似人人都完不成任務的情況下，只有求助以前的經驗，去探討一些“方法論”，“磨刀不誤砍柴工”嘛。
--專案總監需要根據專案經理的彙報並瞭解情況下向上級彙報進展和問題的，只有當壓力和問題存在的情況下，才需要求助於上級尋找相應的人力資源、技術資源和其他幫助。