李遲按：
我看了很多關於專案管理的文章，但發現文章說的和我實際上做的，出入很大。後來和同樣做專案經理的同事討論，發現一個祕密：我們只是臨時工，臨時兼職專案經理。對於專案經理的權力，權利，均是官方套話。

這篇文章主要是從前面文章發的牢騷出發，提煉一些的事，當做是經驗。

專案責任感
對於專案上的事，事無大小，首先問到的是專案經理。作為一個對整個專案負責的專案經理，有很多事是必須做的。但我做的不好。在這個專案中，很多事我都要親自做。我要統籌整體專案。專案成員搞不定的，我要搞。
以前我是專案成員角色時，安排給我的東西，我都會主動去做，涉及不同部門的，我會先問清楚對方介面人，然後自己溝通，無須專案經理親自出馬，只有搞不定的，我才會和領導提出。但這個專案，我發現專案成員的主動性不夠，應該是我沒有再三強調造成的。
另外，我還要關心技術方面的東西。因為專案成員除了流程上的事問我，還有他們不懂的事也問我，當然，為了面子，我會自己去查，然後回覆。實際上，一開始遇到這樣的事，我會告訴他們如何做，比如需求方面和誰確認，專案流程方面在哪裡看文件，某個模組和誰確認。但我發現有的人完全不理會，類似的問題還會繼續問。幾個回合下來，我發現了有的人的依賴性太強，沒有主動性。為了時間，於是我決定親自指導，親自做時效做要求。不過以後還是不要這樣做。累了自己，害了別人。
但我太關心技術方面的了，而忽視PM最基本的事：專案的管理。比如專案進度管理，監管專案的部門最關心的是進度，但我的管理能力不行，可能是我的權威還不夠，人家不聽。
在這個專案中，有太多的“猴子”我推不開，我以為能推開了，還最後還回到我的身上來。可以大言不慚地說這是我的責任心造成的。我負責的專案，我想把它搞好。

需求
這個專案，需求有很多是不明確的，說得難聽一些，有些功能，需求提出的人也不知道是怎樣了。我們公司的專門管理需求的人，但我覺得他的工作更多是收集需求，然後下發。做專案，會有需求分析這一階段，但現實上做得不好。首先，需求分析的人是開發人員，要知道，開發人員往往限於知識面及見識，不會分析得很好，並不是所有的人都瞭解某個需求在客戶那邊是怎樣用的，只是從自己使用的角度出發。其次，初期的需求可能是不明確的，後期會改，但其時已經在開發階段，負責人沒有專心重新考慮改動的需求，或許說沒有時間考慮。這樣說，對開發人員的能力有更高的要求了。但往往是一廂情願。最後的結果的，做出來的東西不是領導想要的。如果公司有專門的人做需求分析，即從客戶提出的需求做了分析後轉換成研發方面的需求，我相信會比較好。
另外一點，我作為專案經理，對於需求說NO的機會很少，基本上是需求方提出來，就要做。後期修改需求時，我即使說NO，最後還是要做。可能是公司制度有關吧。

開發
我做得不好的地方是，有的人初期沒有寫概要設計——即使我作了要求，但還是沒寫，我就允許後期補充。後來延期申請時，因為涉及到技術原因，大領導要看概要設計，但我沒能給出來，於是找了藉口推了。類似的事，很有很多。這個教訓很窩囊，不應該出現這種事的。如果再有機會，一定不會這樣。
現在想想原因，一是這個專案啟動的時機不好，人員都還沒完全到位就開預備會，在預備會上講了些專案開發的要求、注意事項，但未到位的人並不知道。二來在4、5月份啟動，恰好是公司職員開始旅遊的時期。比如在5月份，就有包括我在內的很多人去旅遊(如果不去，等做了專案就別想去了)，而6月份正式啟動專案，但6月上旬也有人去旅遊。這樣就失去了寶貴的前期時間，這段時間，就是做需求分析和寫概要設計的時間。這種事無法說什麼的，最好不要再出現。
後來測試人員陪產假，只提前一天告訴我，打得我措手不及，換了人員測試，又要重新熟悉裝置的使用。也耗了一定的時間。這種事如果能提前知會一下，做好準備就好一些。

人員
我太過相信專案成員了，以為所有的人都對專案流程熟悉，都有能力做。但中期我發現個別人不行，我無權力對某個人的能力做評價，但的確不是這個專案的這個模組最佳人選。我向上峰反映過，但我知道結果。我曾一度想過換人，但已然到中期，換人肯定不好，這也使得我被迫親自指導。這個血的教訓，使得專案監管部門考慮後續專案引入人員評價表，當然，是以我是做小白鼠為代價的。但如果下次還是不幸被做臨時專案經理，我會親自考核每個人。如果還有出現這種事(包括前文說的)，我一定要反抗。
另外，還有一個比較鬱悶的地方。在做專案計劃時，每個模組都安排了人，看似很好，但實際上，很多問題不是計劃表上所能知道的。在做專案時，會安排所謂的方案整合人。我便是從方案整合人做臨時PM的。他的角色是救火隊長。沒有安排到的模組，他來做；測出來的bug，他先分析；去外場測試，他要去。在這次專案中，我就是PM和整合人的合體。

流程
公司很多人對專案流程是有意見的，但又沒有提出更好的反對觀點，於是只能服從。
專案的監理，更多的是催文件，催週報。當專案出現問題時，永遠是相同的格式：對專案交付有影響嗎？如有影響，評估延期多少天？
對於風險管理，我認為有些扯了。風險管理是必要的，但實際上無法做得好。已知和有消除措施的風險都不是風險。
在專案驗收時發生的事，讓我最終認識到流程的權威性，流程就是流程，就要遵守。——哪怕再耗時。

最後說點委屈的話。作為菜鳥級別的人，肯定是要人指點的。我發現在專案中，監管的人都在高高在上，只是對你做要求，不理會原因。動不動就說你對流程沒意見就要努力執行到位。我曾一度放棄，他們愛說什麼說什麼，我只做我的事。而部門主管也沒有指點。因為公司的制度，做專案的人是歸專案經理和專案監管部門的，主管不過問。但在專案中，別的部門老大出面干預了，我們老大沒有。作為新手，的確需要有人指導迷津。

再簡練地寫一下：

1、前期需求階段。該階段儘量多花時間，同時進行預研工作。因為有的需求可能要做實驗才知道。在此階段，對於需求，儘量保持各方理解都一樣，在需求文件中，儘可能詳細做備註。因為確定的東西越多越利於開發。

2、驗收指標。建議寫清驗收方案，驗收對比，驗收指標是多少。如果自己不清楚，第一件事問人。在前期一定要明確好，同時要有關領導認可。如果領導沒空稽核，在郵件中加上：無回覆表示同意。方便日後扯皮。

3、設計文件。先進行設計，再編碼。一來是流程規定，萬一領導要找概要設計也好交差；二來如果沒有一個指導性的東西，自己想到哪就寫哪，這樣是耗時耗人的。在動手之前，要先想一遍涉及的模組。如果後期修改了機制，還要及時更新文件。如果個別人不寫，要麼強迫寫，要麼寧可延長專案時間。——匆忙的東西，總要延期的。

4、專案成員。一定要先對成員有認識、瞭解。萬一對SVN都不懂的人進來，玩笑就開大了。當然，如果熟知的同事，無所謂。如果實在搞不定，換人。在面子和專案結果中，我後悔當初選面子。

5、流程。公司的流程是權威，無法挑戰。我嘗試過很多次，在專案交付後的收尾階段終於放棄不掙扎。愛稽核多少天就稽核多少了。但是，如果是個人良心出發，還是建議從利於專案進行的角度對待問題。

李遲 2015.9.3晚