一點兒故事，說出來大家開開心或引以為鑑

因為“好奇害死貓”，什麼都想有所瞭解，所以至今身無長技，各方面都仍是個新 兵。偏又話嘮，喜歡與人聊天。近期收到ITPUB編輯小韓的邀請，說是可否聊一聊技術人生 ，這倒是不敢，要麼就說說我自己的一點兒故事和事故吧，我覺得倒是可以說出來大家開開心或引以為鑑。

我 先 是 做 了 軟體產品（包含硬體）的實施部署，後又接觸測試、使用者培訓，被技術團隊推到前面成了“專案經理”。

幫助籌建過一個業務條線的PMO，遭遇過自己的專案失控，經歷了老大年齡又回到起點老老實實從HelloWorld，逐字逐句敲進去從頭學JAVA，基於對自己產品相關業務、功能的瞭解和不再犯怵程式碼，漸漸敢於在售前工作中答應、拒絕和引入變革。

第一次當專案經理是在北京一個銀行的專案，雖然之前已經參與了幾個現場開發（主要是旁觀），也在投產後的客戶現場做過技術支援，但在取得了當時信產部“專案經理”證照後，被公司領導詢問是否能當新專案的專案經理、覺得需要什麼條件的時候，仍頗為意外和興奮。

因為是公司已有產品、新客戶，銷售打算做成標杆專案，公司領導很支援，技術團隊的人員個個能力很強。（後來瞭解，他們中至少兩三個人自己帶專案都沒問題，為自己哭三秒鐘）

技術團隊的老大隻叮囑了一句：“你去開會，我們寫程式碼，不要亂答應需求、不要亂激發需求，萬一答應了，我們做你的後盾！”。 有了底氣，交流、傾聽客戶需求時靜定了許多，傾聽、反饋、探討、質疑、建議進退自如了不少。

◆   客戶對於我們是新的，我們於客戶也一樣

真的體會到了“麻桿兒打狼，兩頭兒怕”。我們不知客戶是否會在尚未了解已有行業內實踐和系統的情況下，天馬行空大拆大改；客戶擔心我們固守已有產品、程式碼，不肯做他們的個性化業務需求。

一些技術選擇，與其說是因為技術決策所致，倒不如說是雙方在過程中相互觀察、體會對方意圖、意願的影響佔多。

雖然中間有跌宕起伏，但專案還是如期上線了，並且經受了年終業務的考驗，沒有發生一筆金額錯誤。

在專案過程中，親身感受到了甲方的訴求、疑慮、堅持、思考、積極行動，乙方的需求困惑、技術決策猶豫、團隊技術帶頭人在團隊中的能量和作用。

但，也造成了兩個錯覺：“自己可以獨當一面做一個專案經理了”，“技術團隊，應該都是相似的水平”。

◆   過於樂觀的判斷，為今後坎坷埋下伏筆

透過了PMP考試後不久，接到委託，幫助直接領導的業務條線成立一個PMO（專案管理辦公室）。

類比重大工程成立的PMO，我們顯然並不是一個決策機構，甚至實質無權直接下達停工令。而更多是檢查、度量進行中的專案，為領導及時定量了解專案進展、風險提供資訊，對專案進行風險提示，引入專案管理工具、對專案經理進行技能培訓，對各團隊的專案管理機制進行落地和持續改進。因為之前也參加過CMMI培訓，辦公室的工作人員也被我叫成“過程改進工程師”。

PMO確實做到了利用“掙值法”對專案進行持續度量，為專案經理提供了“風險識別”、“Project與進度網路圖”、“WBS分解方法”等具體培訓，幫助發現、糾正了一兩個專案範圍擴大、需求“半路”失控、專案交付物定義不明確問題。

◆   但，管理並不能代替經營

為了激發各團隊的自主經營意識、算賬能力、生存意志，公司向“多層級合夥制”調整。希望從“領導要你幹、你要聽話幹”，轉變為”我要幹“、“賦能讓你幹”。PMO這種傳統職能型組織的作用弱化、取消，也成為必然。

信心滿滿的以為了解了專案、瞭解了專案管理方法，只要堅決貫徹管理意志、使用專案管理方法，就能幫專案走上正軌。每一次貌似的邏輯自洽、自我感覺良好的盲目篤定，都終會被現實毒打。只是，來得如此之快，不知是不幸還是萬幸。

受到客戶信任，部門接到一個新行業、新客戶的新業務專案（對於我們已有積累而言是新），目標是重構現有業務系統，使之能夠恢復對業務需求的敏捷支援。

◆   接手新專案， “我”搭臺你唱戲，這步棋走錯了？

作為專案經理，根據以往的經驗，特意挑選了一個技術部門經理帶其固有下屬的成型技術團隊，業務需求分析、技術人員管理、技術決策，全部交給技術團隊。 而自己全力爭取公司在資金、人手上的資源支援，聯絡客戶、甄別協調各方訴求、解決團隊吃好、住好、心情好，與主要負責人和骨幹持續強調成功交付的意義和價值。

就像當時自己說的“我給你們搭臺，你們來唱戲”。

但隨著時間推移，發現專案在需求階段遲遲無法取得進展，客戶現有相關業務理解、原有系統業務功能、周邊關係、內部資料結構不能產出，也無法進一步決策新系統實現、替換方案。

才發現：想始終對專案有駕馭能力，不能退居為支援型的“專案助理”，至少應該親力親為需求分析。疑問是否高估了團隊能力、過於樂觀了專案工期、低估了專案複雜度。

得到的感受是：

你對需求的駕馭能力，取決於你對客戶業務的理解程度、換位思考和溝通，你對技術團隊的駕馭能力，取決於你自己把握產品、技術的程度等“非正式權力”。

對於人員伸縮變化可能很大的專案，只有有“一人成軍”的能力，才有可能在適當的時候透過增配人手，實現“千手千眼”。（此處說駕馭而不是控制，是因為我理解的駕馭是根本、重要方向不跑偏，而控制是錙銖必較、算計的博弈。）

◆   程式碼這東西， 會就是會，不會就是不會

半路卸任專案經理，自我認知遭到重挫。感恩公司，難得有一段時間允許我摒棄外務，類似寡婦撒豆、撿豆，“無求”、“息心”敲最簡單的HTML、JAVA的HelloWorld，替代思慮、平復心境。

過程中發現自己原來很笨，敲幾行最簡單的程式碼都錯誤百出，以為看會了、看懂了，合上教材或網頁，對於關鍵字、程式碼行結束符號、縮排格式、段落竟然記憶全無、理解全無、疑問百出。 

“紙上得來終覺淺，絕知此事要躬行“，才領會程式碼這東西，會就是會，不會就是不會，與你聰明、笨無關。

◆   程式碼不騙人， 若程式報錯，定是自己錯了

學習程式設計，只能從自己動手“編”下手、老老實實敲每一行程式碼、每一段程式碼，都跑通，再改一改、想一想、試一試、玩兒一玩兒，無法跳躍、無關“簡單”不簡單。

 “不糾結（於心）、不糾纏（於事），無心於事、無事於心”，成了這一段時間縈繞在心頭，避免無謂內耗、平靜心緒的口訣。

千手千眼

得到了一個進入某大型客戶專案的機會，向各方明確不再擔什麼“專案經理”的虛名，就是負責產品測試、使用者使用文件編寫、使用者培訓。

◆   “逆境不空過，順境不枉為，無忌守本心”

一切似乎輪迴到了原點。任務明確，輕車熟路，心情倒也純淨、平和，工作進展也順利起來。有節奏、有效率的完成本職後，正好可以自由地除錯、閱讀仍不大看得懂的這個B/S系統原始碼。權當調節心情、鍛鍊意志、磨鍊自己如笨拙鐵杵般的程式碼技術能力（也許還有心智，苦笑）。

與枯燥的學程式碼不同，有專案需求、真實問題的推動，每次看程式碼就有了明確的目的和可驗證的結果。以問題為線索，使我能夠漸漸進入各個具體功能的程式碼實現中去觀察和理解。對於各種物件、寫法也基本混了個彼此臉兒熟。一段時間以後，居然也可以用IDE對程式碼進行編譯、除錯、修修改改、照貓畫虎了。 

“逆境不空過，順境不枉為，無忌守本心”是這一段時間，雖未成型，但醞釀在心裡的一段話。

期間覺得，以前按照崗位定義要求每個人與崗位對齊是費力不討好的，只有當你自己不同程度具備多種能力後，才能根據合作同事的知識、技能情況，主動調整對接時描述問題、下達任務的方式，去有效解決問題。

說白了，就是對方不熟悉系統的情況時，就明確具體動作指令，只延展借用同事的手、眼代替、延展自己的手、眼；如果夥伴對系統有知識就可以簡練成術語交流；有自主工作能力就只描述清目標即可，既有效連線、延伸彼此能力，又相互體會到成就和尊重。也許就是相當於“千手千眼”了吧。

隨著幾年的專案接近尾聲，我的工作壓力也從上線推廣支援、售後支援多出些許餘暇。為了小團隊的生存，開始分出精力跑產品售前交流、投標的事。

◆   客戶需求的傾聽者，客戶期望的建立者

有了對客戶業務、產品功能和結構的更多理解、程式碼的一點點駕馭能力，在售前交流中感到能更快的與客戶有效進入業務情景討論，結合客戶業務講解及演示產品，更從容地傾聽客戶需求、理解客戶具體人員所處的需求情景。 甚至為了有效演示進行系統的快速修改、臨時創造對客戶有價值的功能，偶有左右逢源的感覺。

體會是：售前，不僅是產品的演示、講解者，更是客戶需求的傾聽者、客戶期望的建立者。

不能只追求自己講得多、講得全、講得有條理、講得爽，而是要講到客戶的關切上，聽懂客戶的訴求，問出客戶的情景，建立客戶對未來前景的希望和信心。售前不是靠提供虛幻的希望，給後續團隊、客戶挖坑，而是建立一個切實可達、可行的期望。

售前閒暇，把自己曾經的誤以為、彎路、感觸寫了個豆腐塊的《售前工作》分享在了公司群裡，倒也不怕更丟人。但願大家能從我的錯誤中看到“坑”，不必重蹈覆轍，在我的有限實踐中，略有啟發、甚至獲益，秀出各自的精彩。

經歷和水平太低，我的笑話和偏見先講這些，告一段落吧。