李遲按：
今年2月份我對自己參與的專案進行了個人總結，但這個專案陸續地進行，直到現在的8月份、9月份。出於習慣，繼續寫總結。
這是一篇牢騷文章，作為步入中年的人，似乎不應該如此。但我覺得自己還年經，有些事，憑已之意氣，說上兩句也無妨。另外監管專案的部門說不開專門的會議評價各項事，心有不爽，只好在這裡發發牢騷了。以下是站在既是開發角色又是專案經理角色的角度行文的。

前文
今年4月23號，A、B階段的專案經理髮電子郵件，說要啟動C階段，開發人員3人，測試人員2人。4月26號還是27號還是28號，部門主管突然告訴我要做C階段的專案經理。4月29號中午，上屆專案經理髮電子郵件，安排我為專案經理，同時追加1個開發人員，並要求4月30號召開專案預備會，但因為有人員未到位，不啟動。6月人員正式到位，所以專案計劃表從6月1號正式開始，8月14號完成軟體開發提交測試。8月18號正式發電子郵件交付給其它部門（按公司制度，“其它部門”是專案的客戶）使用。截至8月底9月初，即本文寫草稿及發表為止，仍在做收尾工作。只計實質的工作，我投入的時間大約有4個多月。翻開我的工作日記，在去年的這個時期，我就開始了這個專案，歷時一年。鑑於公司制度，沒有離職情況下，只要沾過邊的事，就要負責到底，我相信以後這個專案一直會follow著我。

正文
去年的這個時候，公司著手這個專案，當然，前期工作，是不算到專案裡面，但往往會有先行者——比如我，去做公司所謂的“預研”。從做小弟到做專案經理，聽上去似乎不錯，前途無量。然而實際上卻不如此，在這個公司，你懂得越多，你的活就越多。我所做之工作，相比以往的角色，只是多“管理”：開會，寫報告，寫申請。而寫程式碼，去外場測試，找bug，一樣倒沒落下。
公司組織架構中，有“專案經理”這一崗位，而我，title是工程師。雖然公司開發氣氛很濃重，但無可避免地有著制度條例。我想不明白，為什麼公司現在已經有了專案經理，怎麼還讓我去做呢？實際上，我這個專案經理是兼職的，無實權的。所以凡有我無權或無力做決斷之事，我都會第一時間請示上峰。
不過，可能由於人微言輕之故，即使是流程制度上規定的需要稽核的事，有的領導也沒有迴應。我的觀點是，人在其位，要謀其政，該你乾的事，你應該要幹。但有的領導偏偏很忙，我只好向上峰反應，叫領導去催領導了。而對於一些驗收方案的事，應該是領導自己寫的，但依然忙沒給我，於是我就自己安排人寫人，叫領導回覆行還是不行。後來我聽人說，因為公司以前專門招聘來的“專案經理”都不懂搞專案，所以從現成的開發人員中選專案經理出來，美其名曰人才培養。
有人說，為什麼你不反抗呢？如何反抗？我本著做事的原則，不想扯皮太多。每個召開專案例會時，我都有或多或少的意見，但得到的回覆都很冠冕堂皇，沒什麼實際用。我特別反感的話是：既然你對流程沒有意見，就應該想辦法把事情做好。而當我就某些事說出意見後，回覆說，流程只是規定你如何做事，但沒有把每個細節都考慮。另外，前文說的請示領導，也是必要的。像有些驗收項和標準，我認為是可以的，但有的領導不認可，最終只能如領導所願。有次開會，大領導罕見地參加了，問我們這幫兼職的PM是不是頭上有天花板——即在工作時，是否有些事壓著你。我們都很快速地承認有。其實，大領導知道，我們也知道，但並不是每個事情都可以反抗的。
有道是“匹夫無罪，懷璧其罪”，人沒有罪，有罪的是璧玉。流程本身沒錯，但錯的往往是人。有的人在執行時有疏忽，或不到位，以結果導向來看，就是有問題，而執行，又在於專案經理。作為菜鳥級別的新手PM，有些事的確沒意識到，你不能要求一個搞了3年核心驅動的人，會很好地完成稽核UIl介面細節的東西及管理。但我會努力去做，但有的事，實不是吾之力可及也。當然，在這裡我是為我開脫，但面對領導的批判，我依然有責任把責任攬到自己身上。
但自己想想，老是做好人不行啊，後來我學會了和某些部門打官腔了，並決心如此下去。這也多虧了這些經歷。

下面按時間順序說說專案實施過程的事。

其實初期的需求是不明確的，參與那麼多專案，沒見過有幾個是很明確的，也沒見過幾個後期不需要修改的。這或許是無法改變的現狀。而我，只是想讓一些很明顯的需求項描述清楚。我們公司有專門寫需求文件的人，由於本人對文字的理解異於其它人，所以對於一些細節的描述，我是很在意的。因為對於程式來說，是要確切的知道的。比如，需求上說要支援可播放的視訊格式，是支援AVI，還是MP4還是MKV？只支援單一一種即可，還是所有的格式都支援？類似這樣不明確的，加上有部分描述還有錯誤。我多次和該負責人就文字的準確性和多加備註方面展開爭論，當然，結果我lose——即使我在會議上向領導明確提出。需求是有部分未考慮周到的，這也是無法避免的事，但有些需求項，是完全可以寫得清楚明白的。比如，中期專案加入了IE 64位的支援，但偏偏在後面用括號寫上幾個IE版本號，由於領導口頭告訴我的是支援64位，我就沒留意IE的版本，到後面專案準備收工時，發現程式在有的IE版本上有問題。於是回查，於是發現了需求裡要對很多個版本的IE都支援。找到原因，也好辦，改。但時間，起碼用掉了3天。後來我發電子郵件，把專案經理(即我)、模組實施人員、測試人員和管需求的，都批評了一次，當然，不出意料，管理需求人員進行回覆，並說特別加入了IE的需求，你們要引起重視，對需求細節不明確的可在研發需求分析或概設時及時向人家提出，消除誤解。我完全可以繼續爭吵下去。但於事無補，因為時間已經耗掉了。對此，我在專案例會上把意見說出來，就不知道管理專案的部門(公司有專門管理專案的部門，由他們制定流程、管理專案進度，專案經理要向他們彙報，我上面所說的領導，很多時候是指他們，但他們沒有人是做過開發的)如何處理了。

概要設計一直是公司的心病。當年，公司召開員工吐槽大會，有人專門就概要設計存在必要性提出意見，引發大領導的不滿意。後來不久，那位兄弟去別處高就了，在遠方的他不知還要不要寫概要設計。但概要設計是必須的流程文件，一定要寫的。這個專案中，開發上位機的哥們一直沒寫。這也是我的疏忽，我在開始已經強調要先寫概要設計或編碼，但可能是選擇性忽視的原因，沒有寫。我催促了幾次，後來就放棄了——因為專案準備進行了中期，已經不是概要設計階段了。於是我計劃到專案準備完成時再叫他補充。在我的堅持每隔一天催一次的努力下，在交付前終於完成了。
在專案初期安排人員時，已經確定了哪些人負責哪些模組了，概要設計也相應完成。但後續有不同的需求加入來，已有概要設計已不能表述；新加需求又雜又亂，無法統一寫一份。我就此事問專案管理的領導。他們要我給出具體的例子，我給了當前的，但他們沒給明確的意見，叫我自己把握度。我一聽就想不寫了。但基於責任心，我還是安排人做了補充——我不希望我經手的專案，有的功能沒有在文件中體現。至於其它人，不是我的事，我不操心。

我負責著一個模組，本來作為專案經理，應該做整合的人，不做具體的模組開發。但人手不夠，我不搞就沒人了。但我高估了自己的能力，一來部門還有事務要做(本來做專案不應該有部門事務干擾的)，分散了時間；二來我還要兼顧專案管理的各種雜事，同時分散了時間。到後面發現搞不定了，只好分派給別人了。我也專心做了打雜的角色了：整合。沒有人負責的模組出問題，我來搞，測試的bug，首先我來分析；別人的bug一時解不完，我來，解不了的，我來。後面有人週末有事無法加班，我要去。專案搞不完，首先是專案經理的事。即使心裡再不爽，也要做。

理論上，每個模組都自測沒問題後整合就輕鬆很多，但事實上我不親自自測，我不敢提交給測試人員測試。在自測時就發現很多很基本的問題。當然，搞開發肯定會有問題，但很基本的問題就不應該存在。最可能的原因是大家都沒有進行自測。

以前還不是專案經理時，我要和測試人員一起到外場測試。因為之前有反映，測試人員不懂用。有開發人員去，也好解決一些異常情況。而我是專案經理，依然要去。一句話，人手不夠的情況下，你不去就沒人去了。風吹日晒的過程，不說也罷。

做專案肯定有延期，雖然公司領導不願看到，也想辦法不使之發生。但實際上不發生是不可能的。流程上說有延期要寫申請，要提前三天。我好像一共申請了三次。前兩次按足官方話來說，看電子郵件，不會看出再有問題引起延期，但還是有了第三次。主要還是技術方面的原因。至於因為需求或欠考慮的原因，各位領導依然要我給出真實理由，還問我有沒有預判。最後一次要我給真實原因，我就列出了後期發現的所有bug，根據事實描述各個bug的情況。

關於驗收，其實要做的事情很多。首先，專案交付是要通過測試的，實驗室測試和外場測試通過後才能算通過，另外各類文件也是多個部門稽核，走流程恐怕也要一兩天才完成。但這終歸是專案組的事。其次，臨時組成的專案組的客戶是公司其它部門，我們做完東西是給他們賣的，他們也要驗收。包括需求點，文件，bug，易用性，擴充套件性，等等。比如，這個文件這個地方描述有歧義；這個UI介面的顏色不太明顯；這兩個框的距離大了，不對齊；這兩個框的距離小了，資訊太長顯示不下，等等。
本來在我這個專案完成之前，另一個專案先完成，進行了驗收，期間就扯皮了很久很久。我以為經此一役，各方都會理解，達成共識。但沒想到，這個專案依然如此，似乎這個永恆之事。也正因為之前的爭吵，後面到我和客戶部門爭吵時，首戰告捷，這還得多謝該專案。
為了更好地賣出產品，他們站在客戶的使用角度提的各種意見，是無可厚非的。只是，我不太習慣這個驗收一次又驗收一次的制度，也受不了其它部門作為客戶的態度。我覺得，大家都是同事，我們做完東西，你們又不會給錢。更何況，做專案最多可報銷加班餐和加班交通費，吃專案飯也有人均的限額。就連週末加班調休也要稽核幾天，你加班了5個週末，又不一定會批5天休息，而且又沒有獎金。何必如此受氣。

下面說說我作為專案經理的其它事。

對於開發人員，這次我沒有過多考慮。但現在後悔了。我太相信領導安排的人了。前文提到了，所有人員是領導安排好的。我想，這些人員應該都是有能力做專案的。但事與願違，有人連基本的SVN都不會用。而且，該人連專案基本流程也不懂，做事條理性也不夠，我幾乎差點手把手教了。對於加班很晚而第二天10點才開上班的事，我也無法干預。後來我向有關專案管理部門反應問題。得到答覆是，你做為專案經理，你應該自己管好自己的隊員。就是我，關於專案成員的所有事，都是我本職要做的。後來我為自己想到一個理由，就是我作為專案經理的威信還不夠，因為我只是一個coder；因為我只是一個與其它基層員工平等的員工；因為我和有的成員不在同一部門。我說的話，人家不一定聽。想到這，除了得到教訓外，我也心安理得了。

對於流程制度，我有很多想說的。但多次和別人交鋒發現，無論怎樣，我還是too young。

對於專案來說，交付之後即表示研發的結束，但專案還不能結項。而關於結項，我也有些不爽，可能是跟制度有關吧。以前是說驗收，在驗收過程出現問題要解決。解決之後才能申請結項。我就此事向有關領導諮詢過，他們說沒有原則性問題，可以在交付後就申請，但不一定會稽核通過。當然，經過考慮，我肯定是聽從他們的意見。我不知道公司的專案制度為何如此設計。本著快速開發之原則，理應不存在專案驗收了，客戶部門也再次驗收，專案交付後，還要受客戶部門的牽制。我覺得，公司組織架構決定了存在這樣的問題，產品涉及不同部門，在專案開發時客戶部門並沒有大量參與，都是基礎部門做開發，但他們在後期做支援卻是以專案交付的結果為基礎。客戶部門不一定會百分百理解和掌握專案涉及的方方面面。按專案制度來說，要在他們使用得沒任何問題後才能結項。但即使如此，後期有不同需求而原專案成果不滿足時，又會涉及到基礎部門。而公司制度又規定，基礎部門必須為客戶部門做支撐。這樣對於我們來說，前期做專案，後期做維護，始終沒有脫離過。

其實這種制度是不利於個別人員的發展的。就這個專案的我來說，專案未立項時，我已經在摸板子了，對於外設，系統構建及程式燒寫，已經在研究了。完成這些後，我就開發做業務程式的整合(主要是哪個模組沒安排到人的，都指派給我)，兼職陪測試人員去外場測試。而完成了A、B階段後，我變成專案經理，但又兼職著開發人員。這種哪裡需要人就到哪裡去的做法，在公司領導來看似乎是好的，因為鍛鍊員工的能力。但試想一下，在一個有專職專案經理的公司裡，讓一個沒有經驗的人負責專案，風險誰擔？最後還不是歸於專案經理頭上？

無論怎樣，一個專案如果有問題發生，那麼首當其衝的就是專案經理，無論是怎樣的問題，專案經理都難辭其咎。在這個以結果為導向的公司裡尤為明顯。面對領導，即使把實情說出來，領導也未必會理解。所以就選擇在這裡發發牢騷。牢騷發完，該幹活幹活去了。

後有人記錄了此事，單表專案經理之心酸和無奈：

嵌入式軟體工程師

以前呢
我的崗位是嵌入式軟體工程師
負責核心驅動移植 根檔案系統構建
解決“底層問題”

後來啊
我還是嵌入式軟體工程師
同時 兼任“方案負責人”
負責核心驅動 根檔案系統 “底層問題”
還有方案整合 “裝置問題”跟外場測試

而現在
同時 兼任“專案經理”
我依然是嵌入式軟體工程師
負責核心驅動 根檔案系統 “底層問題”
還有方案整合 “裝置問題”跟外場測試
以及開會 報告和扯皮
整天進度控制 風險管理

將來嗎？
我仍舊是嵌入式軟體工程師
已知要光榮掉天坑一
其它的
就是重複昨天的軌跡

(注：天坑一併不是一個坑，而是代表著研發新CPU的眾多坑)

(全文完)

李遲 2015.9.3晚