我第一次做專案經理，那是十多年前的事情了，當時給國家開發銀行做一個財務風險分析的系統，這個專案：
- 金額：200 萬
- 週期：起初定的 8 個月做完
- 人員：10 個人左右。除了我之外還有，需求分析師 2 人；測試 1 人；Java 5 人（那時候還沒有前後端分離這個詞，前後端一起搞）；BI 工程師 1 人。
專案啟動之後，我們專案組去國開行駐場，行裡給我們騰出來一間辦公室，辦公室不大，我們十來個人坐進去之後，滿滿當當的。
我們周圍的辦公室，也都被其他同行佔據了，比如神州數碼、用友、中軟……本來 IT 行業圈子就不大，這下大家離得就更近了。
離得近了，最方便的就是挖人。A 公司看 B 公司給國開行做了一個系統不錯，單子金額也挺可觀，A 公司動心了，也想搞一套系統賣給其他銀行。從零開始做一套系統，對 A 公司來說難度和成本都不小，現在爽了，有捷徑了：B 公司的人就在自己的眼皮底下，時間長了，物色一個合適的人直接挖過來……
有點跑題，繼續說我帶專案的事。
這是我第一次帶專案，第一次做專案經理。以前參加專案，我最多也就是專案的技術負責人，把技術相關的搞定就行了，主要負責搭建環境、資料庫表設計、選擇技術框架、制定規範、寫寫程式碼……
當了專案經理之後，我還是和以前一樣，絕大部分時間就是在小屋裡和大家一起悶頭寫程式碼、開發系統，除了每週和客戶開一次例會，基本上對屋子之外的事情不太關心。
幾方面原因：
-
認知不夠，我以為把專案按時完成，功能滿足需求，讓甲方正常驗收了，這個專案就算做好了。
-
我本來就是程式設計師出身，對技術之外的事情沒啥興趣——這個可能是技術轉管理的通病。
-
國開行裡領導太多，隨隨便便遇到個人就得稱呼“張處”、“李處”、“趙局”。我也奇了怪了，總行裡的領導這麼多嗎？本來乙方在甲方面前地位就有的低，再讓我巴結這些個處長們……程式設計師的清高讓我幹不出來這個。
就這樣，我們在小屋裡“閉門造車”了三四個月，專案時間差不多過了一半，我要把開發的系統給國開行甲方爸爸演示彙報一次。
在演示之前，我們自我感覺一切良好，進展順利，按我們的估計，至少可以提前一個月交付專案。
結果，彙報的時候翻車了，甲方爸爸一頓啪啪打臉：
-
系統介面和互動設計，和銀行裡主流系統的風格不一致；
-
賬號和許可權體系不能單獨存在，要用銀行裡已有的一套方案；
-
部分功能過於繁瑣，使用門檻高；
-
甲方對部分開源技術的穩定性存在懷疑；
-
……
總之，這些問題意味著：我們之前做的大部分工作，需要改動甚至推翻重來，整個專案的前景蒙上了一層陰影。
這次暴露出來的問題，我肯定要承擔主要責任。就在我被打擊的迷茫和萎靡的時候，我的領導，公司的技術總監也知道了這件事，叫我回公司一趟。
回去之前，我做好了最壞的打算：被批評一頓、被擼了專案經理。
幸運的是，最壞的事情沒有發生，領導找我長談了一番，時間久遠，談話內容已經記不清了，大概內容就是理解我第一次從技術轉管理會犯錯，教了我一些帶專案的方法，相信我接下來能把專案做完……
不過，談話中領導的一句話，我到現在還記得清清楚楚：
專案成功的定義是什麼？一個成功的專案，就是讓專案的所有涉眾都滿意。
意思就是，成功的專案，是讓專案中參與的各方人員都感到滿意。
這句話徹底顛覆我的認知！我之前單純的認為把專案按時做完上線，客戶驗收付了款，專案就算成功了。
“讓專案的所有涉眾都滿意”，那麼我們專案的涉眾都有誰？他們滿意的標準是什麼？
我回到專案組之後苦思了好幾天，同時找銀行客戶、同事交流，後來基本想明白了：
甲方爸爸：毫無疑問，這是最重要的一個涉眾。對甲方專案負責人來說，他們最關注的是這個專案能按時上線，而且能解決業務痛點；同時在專案過程中他們要能完全掌控專案進度。這個專案延期或者沒做好，他們也不好交代。
系統的使用者：對使用者來說，就是要讓他們用著滿意，符合他們之前的工作習慣。
公司老闆：對老闆來說，他沒有指望這個專案能掙多少錢，他的主要訴求有兩個：1、通過這個專案讓國開行認可我們公司，爭取以後拿到更多專案；2、把這個專案沉澱成標準化的產品，將來賣給其他銀行。
團隊同事：首先，同事們不喜歡長期駐場做專案，畢竟不是自己的地盤，最理想的是有一個標準化產品（和老闆的目標一樣），以後再有專案，把產品給客戶短期實施就能搞定。另外，團隊裡大部分都是程式設計師，他們也需要技術提高、個人成長。
公司銷售：銷售和老闆的想法大概差不多，只不過更看重國開行眼前這個客戶，希望專案一期做完至少能先簽下來專案二期。所以他希望我跟他一起，多和客戶吃吃飯、喝喝酒，拉近一下關係。
想明白這些之後，後面就該我做出改變了。
比如，為了給銀行科技處的處長彙報工作，我和銷售一起在處長辦公室門口站著等，經常一站就是兩、三個小時。和銷售一起陪銀行領導吃飯聊天，給領導們解決電腦上的各種么蛾子問題……這些更是家常便飯。
這些我曾經牴觸的、不屑於乾的事情幹多了之後，甲方對我們的臉色明顯變好了。
再比如，為了讓甲方掌控專案進度，我們一兩週就迭代一個版本，主動去找甲方溝通確認。
另外，我發現有些事情是有關聯的。我在甲方這邊花的精力多了之後，在技術方面花的精力自然就少了。這就倒逼著我要把一些技術工作交給同事。隨著我責任和權力的下放，對團隊裡優秀同事來說，他們的技術話語權變大了，空間變大了，對他們來說也是個成長的機會。
其他的不細說了，最終這個專案的結果並不是特別圓滿，有好有壞。
壞的是，由於之前挖坑太深，專案最終還是延期了，8 個月的專案幹了 10 個月，專案小虧，大家的獎金也受損失。
好的是，專案上線之後使用者使用反饋比較正面，甲方專案負責人也比較滿意，專案結束後，順利拿到了二期的單子。
還有一個好事，專案結束後沒多久，我們專案組原班人馬真的搞出來一個產品，這個產品為以後專案實施幫了大忙。
我第一次做專案經理的經歷基本就講完了，最後再次把這句話送給各位：
一個成功的專案，就是讓專案的所有涉眾都滿意。
真的，這句話可以說是那次專案中，我收穫最大的一句話。一直到現在，不管是做專案、產品，還是做其他事情，我時不時的就會想想這句話。
希望這句話也能幫到你們。
我承認，很多時候讓所有涉眾都滿意，是很難的。朝著這個目標努力，最終達到“讓大部分涉眾基本滿意”，也算不錯了。就像考試一樣，不期望你能考滿分，但是你要去奔著考滿分去複習準備。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會通過公眾號，
把自己的成長故事寫成文章，
把枯燥的技術文章寫成故事。
我建了一個讀者交流群，裡面大部分是程式設計師，一起聊技術、工作、八卦。歡迎加我微信，拉你入群
