【文章內(nèi)容簡介】 前者還在各個公司里頻繁跳槽，跳來跳去都不滿意。有些扯開了，回到我們的話題。 日本的軟件規(guī)范與 CMM有驚人的相似，其中至少有 35%以上 都是幾乎一模一樣的。最近經(jīng)濟不景氣，東京倒閉了 160 家軟件公司，這個數(shù)字是今年 6 月份的，還在不斷增加。這些公司紛紛搶灘上海，招收技術人員。如果去這樣的公司應聘就要 考慮清楚了，進去可以學到他們的規(guī)范和質量控制，可是要想從程序員成為系統(tǒng)分析員或 PM，比登天還難。往往一個程序員進去干了好幾年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。拒傳華為正在嘗試 CMM4（華為印度研究所已經(jīng)通過 CMM4），對在華為工作的程序員們來說可謂福禍難料。當然，已經(jīng)作到 PM 或 QA 或者熱愛 CODING 的朋友例外。 需求分析 本身也存在著時間分配的問題。第一遍需求分析花的時間會最長，分析員們在客戶的各個部門之間幾乎把腿都跑斷，把口水說干，就是為了確立一個初期的需求模型。所有的文檔將會提交給 PM 進行復審并簽字，不合格的打回重做。反饋表隨之將提交給客戶，第二遍第三遍等等等等接踵而來，與客戶反復討論和磋商，反復提交文檔和表格，目的只有一個，明確需求。當 PM 最終合并了所有文檔并確立需求之后，最終生成的需求文檔將提交給客戶的各部門負責人簽字。這些文檔將作為合同的附件添加，以便在將來項目變更或者碰到重大問題時和客戶扯皮的重要依據(jù)。 需要說明 的是，客戶并非都是蠻不講理，但是說實話，頗有無奈，國內(nèi)目前的項目大多數(shù)客戶為了不讓自己的錢白花，經(jīng)常變著法子提需求。在啟動階段明確需求并簽字，無論最終情況如何，一份詳盡的書面文檔可以解決很多口頭承諾或概念模糊的文檔帶來的許多問題。 詳盡的需求分析有一個額外的好處就是對一些雙方都很陌生或者從來無人嘗試的領域將是一個決定是否進行項目的判斷標準。有時候，這種大項目在簽單時雙方都沒有絕對把握保證可以出成果，一旦在需求分析階段發(fā)現(xiàn)難以逾越的技術難關，就會放棄項目。典型的例子就是 NMD 洲際導彈防御系統(tǒng)。上世紀八十年代初 美國搞星球大戰(zhàn)計劃，拖跨了蘇聯(lián)。大家對那段歷史有些含糊，很多人認為蘇聯(lián)人上了美國的當。其實并不完全如此，蘇聯(lián)人的情報機構無孔不入，并非那么容易上當受騙。實際上當時美國國防部已經(jīng)開始著手 NMD 系統(tǒng)軟件的需求分析，前后耗資數(shù)億美圓，耗時兩年，僅僅是做需求分析，終于發(fā)現(xiàn)存在著在當時技術上無法達到的高度，隨后項目被放棄。 項目啟動要確定項目計劃，與客戶一起實施第一次項目審核，確認并對一些產(chǎn)品和服務向下包廠商下訂單。這個時候的 PM 會忽然發(fā)現(xiàn)有開不完的會，一天開三到四個會議是很正常的事情。這些會議有與客戶 的會議，與下包廠商的，有團隊的，有公司高層的。團隊的會議主要是建立正式的團隊，提供團隊成員的角色和職責，提供績效管理方法，向成員提供項目范圍和目標。與客戶的一個主要會議將是項目啟動會議。在這個會議上 PM 會與客戶確立正式的交流渠道，項目綜合描述，讓項目參與人員相互了解，建立以 PM 為核心的管理制度。還有一些零零碎碎的東西甚至包括辦公場地的大小，電話多少部，所有人的聯(lián)系方式等等都要在會議上確立，并做會議記錄。這都是些非?，嵥榈氖虑?，聽起來婆婆 ***，卻是非常必要，缺一不可。大概就是所謂三軍未動，糧草先行吧。 這 時候，作為公司高層，應該向全公司發(fā)表申明，正式給 PM 發(fā)布項目經(jīng)理任命書和項目授權書。這個動作雖然在別人看來有些形式主義，但是對提高 PM 本人的士氣和責任感是有很大助力的。 三 .計劃階段 （ WBS） 啟動階段結束后，項目進入計劃階段，也就正式進入實施。這里概念可能有些不太對頭，其實是翻譯的緣故，反正大家明白意思就行，不用拘泥于字面。 WBS 是一組要提交的項目元素，用來組織定義項目的總體范圍，具體包括從工作內(nèi)容，資源，成本角度考慮項目范圍；建立一套系統(tǒng)所需要的分層工作結構；把項目分解成易于 管理的幾個細目，這概念有些模糊，其實跟資源管理器里分目錄是一回事情。可以說， WBS 是計劃階段的核心。 WBS 會詳細的分到遞交件，包括給自己人用的項目使用的過程文件，給客戶用的模塊和說明文檔，完成每個細目的標準以及如何把這些細目的責任分配到具體的個人。 WBS 有縮進式和樹狀式，我這里也沒辦法畫圖，大家參考一些項目管理的書籍，里面有詳細介紹。我整個文章只挑我覺得需要注意的地方，如非必要，對技術細節(jié)或者工具使用不做詳細介紹。WBS 的細目并不需要分解到同一水平，最下面的細目叫做工作包，分包的依據(jù)是個人的責任和可信度，也 就是說到每個人頭上的任務是否能落實，是否有把握完成；還有就是準備對項目進行控制的程度，程度越深， WBS 樹也就越深。由于 WBS 是實用性的東西，根據(jù)個人理解也不一樣，所以一個項目可能會有幾個正確的 WBS，看 PM 的需要和最適合當前團隊狀態(tài)的進行選擇。 WBS 的定義還是很麻煩的。 PM 要召開團隊進行討論，向成員提供與項目相關的所有詳細資料，并把 WBS 樹分解到二層三層。然后要花上一段時間讓成員進行頭腦風暴式（ BRAINING STORM）思考，制訂工作產(chǎn)出和相應人員的職責，記錄每一個工作包的完成標準。在頭腦風暴式思 考時，會有很激烈的爭論， PM 要協(xié)調關系，調節(jié)氣氛，從自己能考慮到的各個角度旁推側敲，提示成員的思維角度和方向并加以總結。盡管很麻煩，制訂 WBS 仍然是非常值得的。如同需求分析一樣， WBS 準備的越充分，編碼的進度越快。 既然是商業(yè)行為，那么項目的風險必然存在，相信閱讀這個帖子的朋友不少人都經(jīng)歷過或大或小的風險。有些風險很容易解決，有些風險則大大損害利益。不論什么樣的風險，能避免盡量避免，所以有必要對風險進行管理。由于風險的不可預知性，風險管理難度很大，概念也很難講清楚，只能從一些可行的角度去分析，進行管理。 首先要識別風險。這是個難度很高的活。 PM 要先召開風險識別會議，這個會議面向公司，高層，跨部門的有經(jīng)驗的人都將參加。然后審核由項目小組生成的風險清單并與重要成員進行風險溝通，檢查一些重要的風險源如 WBS，成本（時間）預估，人員計劃，采購管理等等。最后就要用到 PM 本身在以前類似項目中得到的經(jīng)驗教訓。 識別之后要進行分析。我們可以進行粗略的量化分析（精確分析是不可能的事情）。有經(jīng)驗的人可以一起參加討論，把提交出來的風險進行分類。首先按發(fā)生的可能性分，一般分成高，中，低三個級別，雖然很勉強，但是好歹也有 個量化