【正文】 BS 的定義還是很麻煩的。這里概念可能有些不太對頭，其實是翻譯的緣故，反正大家明白意思就行，不用拘泥于字面。與客戶的一個主要會議將是項目啟動會議。上世紀八十年代初 美國搞星球大戰(zhàn)計劃，拖跨了蘇聯。反饋表隨之將提交給客戶，第二遍第三遍等等等等接踵而來，與客戶反復討論和磋商，反復提交文檔和表格，目的只有一個，明確需求。這些公司紛紛搶灘上海，招收技術人員。在國內，只會照抄別人代碼，一點都不懂創(chuàng) 新，凡事依靠別人，快下班就盯著表看的程序員是不少，這種人一般很難有什么前途。實際項目操作的例子表明，分析設計的時間越長，需求設計做的越詳細，測試的時間就越短，返工率越低，風險也越小，成本越容易得到控制。 PM 此時除了要親身參與需求分析綜合整理文檔之外，還要處理好團隊成員與客戶的關系，確保關系不會惡化到無法收拾的地步。隨著需求分析的逐步深入，新的團隊成員不斷加入，啟動階段結束的時候正式的團隊將建立。啟動階段 PM 的主要任務是率領總體架構設計師和系統分析員收集盡可能詳細的數據，確立盡可能詳細的需求，進一步確立詳細的項目范圍，預估資源，確立其他方案并獲得進入下一階段的批準。一般來說 PM 已經被項目里大大小小的事 情搞的筋疲力盡，要 PM 去主動要求客戶配合是很吃力的事情。這里要注意的就是資源和高層的支持。但是這個標準對每個公司來說都有一個底線，一旦超過了這個底線，那項目就肯定是虧的。但是有一點可以肯定，這是 PM 成為 PM 的第一道關，也是最重要的一關。這種情況非常多，銷售的任務是拿下單子，我聽到的銷售們說的最多的就是 沒問題 或者 NO PROBLEM，但是當我聽到客戶的要求和銷售的回答時我總是心驚肉跳，很不自然。溝通，并不僅僅是大聲說話，而是在表達自己觀點的同時發(fā)現問題并綜合整理加以解決。這是個經典的戰(zhàn)例，誰能事先想到哥白尼會來幫助 IT的人賺錢？這個 PM靠的就是博學和由博學引申出的敏銳的感覺抓住了機會，讓客戶產生共鳴。討論問題的時候就是機會，如何投其所好，是一大關鍵。對 PM 來說，這是個非常危險的挑戰(zhàn)。揣摩客戶心理需要有多方面的知識，需要深度和廣度，然而，最重要的仍然是作人。很多公司為了保持公司形象，會統一叫員工打扮的好看一點，看起來象個白領的樣子。 PM 必須作到能與每一個層次的人交談，尤其是看起來比自己層次要低的群體，哪怕是公司里掃地的阿姨。對方這個人非常順利，金錢地位 美女樣樣不缺。對 PM 來說，并不要求在各個方面都很精通，那是不可能的事情，只要 PM 對一些流行的話題和天文地理歷史各方面的知識有個大概的了解，在需要的時候能盡快的掌握，才有機會創(chuàng)造機遇和把握機遇。當然，也有一些不夠踏實的朋友把溝通和吹牛當成了完全的一回事情，在和客戶交流的時候口若懸河的說一些不著邊際的話。在銷售和客戶做承諾之前， PM 要主動的跟銷售交流，提供粗略的總體設計框架和技術難關以及能考慮出的工作量，而不是等出了問題再被動和銷售在老板面前互相推委責任。 二 .啟動階段 項目三要素有多種版本，各不相同。在這個時候，很能體現 PM 與技術人員的區(qū)別。這時候對 PM 的作人再次提出挑戰(zhàn)。從風險控制的角度來說，問題發(fā)現的越早，風險越小，損失也就越小。 在收集完數據之后， PM 要和客戶開始明確項目的大小，成本，規(guī)格，期限等重要特征并將其寫入合 同文本，同時準備內部的包括預算，衡量標準等文檔，建立項目的評估標準。這種需求一般比 較含糊，無法體現客戶真正的需求。對有相同或類似模式的小項目來說采用快速開發(fā)或疊代開發(fā)是很合算的做法，時下流行的極限編程就是針對這方面建立的思維模式。基礎夯實了，金字塔就容易造了。這類程序員雖然在起步時會吃很多虧，而且是主動找虧吃，然而幾年之后與前一種程序員的社會地位會出現明顯的分化。拒傳華為正在嘗試 CMM4（華為印度研究所已經通過 CMM4），對在華為工作的程序員們來說可謂福禍難料。 需要說明 的是，客戶并非都是蠻不講理，但是說實話，頗有無奈，國內目前的項目大多數客戶為了不讓自己的錢白花，經常變著法子提需求。實際上當時美國國防部已經開始著手 NMD 系統軟件的需求分析，前后耗資數億美圓，耗時兩年，僅僅是做需求分析，終于發(fā)現存在著在當時技術上無法達到的高度，隨后項目被放棄。這都是些非?，嵥榈氖虑?，聽起來婆婆 ***，卻是非常必要，缺一不可。 WBS 會詳細的分到遞交件，包括給自己人用的項目使用的過程文件，給客戶用的模塊和說明文檔，完成每個細目的標準以及如何把這些細目的責任分配到具體的個人。在頭腦風暴式思 考時，會有很激烈的爭論， PM 要協調關系，調節(jié)氣氛，從自己能考慮到的各個角度旁推側敲，提示成員的思維角度和方向并加以總結。這是個難度很高的活。我們可以把這兩種類別的三個級別進行組合，碰到可能性也高，成本也高的風險就定位為不能接受。 預估其實并不是一次性工作，在整個項目過程中，預估始終需要。上回邵衛(wèi)老師講課，推薦的工具是 m$的 PROJECT，這個工具我還不會用，因為沒時間去摸索。團隊成員士氣的逐級衰落會給項目后期的開發(fā)帶來難以估計的影響，進度將會大大延緩。假設 結束時間為 1 月 12 日， 結束時間為 1 月 22 日， 結束時間為 1 月 15 日， 結束時間為 1 月 20 日，那 么， 2 階段中最晚的結束時間是 的1 月 22 日，所以在 3 階段中的 3 個子階段 ， ， 的最早開始時間都不能早于 1 月 22 日。測試前期也可以適當的壓一壓，那時候人剛完工，都比較懶散。我相信有這種天才程序員，因為我碰到過幾個。其實老板和 PM 根本不看重這個，他們關心的是使用什么樣的工具能盡快的達到目的。這個時候千萬不能手軟，并非要刻意賺取客戶的錢財，而是不能養(yǎng)成客戶經常變更的習慣，否則后患無窮，維護的成本會讓 PM 吃不消。而這個時候如果 PM 跟對方高層的人關系搞的定，可以透過對方高層把事情壓住。一個 QA 會管理多個項目，有時候甚至會親身參與。 PM 必須經常問自己，項目已經到了什么階段？完成了多少？花費了多少？完成時成本是多少？掙值法 的術語不少，象 BCWS， BCWP， ACWP，但是關系比較簡單，大家參閱一下相關資料，這里不再羸述。失敗沒什么，所有的 PM（注意是所有，不是幾乎所有）都失敗過，然而失敗會成為教訓和經驗，推動你繼續(xù)前行。項目結束請客戶出去泡溫泉時 PM 們千萬別忘記了辛苦為你工作的 程序員和工程師們，當然，如果他們不愿意看到你的臉那么你就折現發(fā)到他們的存折上去，正好讓他們回家好好休息