1、淺析項目實施過程中“自頂向下”方法論的運用項目經驗總結-曾建蜀對于任何公司或組織來說，一個全新的項目在實施時通常會有以下幾個方面的制約因素：1、 工程實施文檔嚴重不全甚至沒有；2、 文檔質量不高，對工程施工人員幾乎無任何指導作用；3、由于開發團隊迫于公司考核壓力或客戶方的進度壓力，盲目采用快速跟進的方法，導致產品測試不充分，質量低劣；4、對于應用軟件依賴的第三方軟硬件產品不熟悉，且無法獲得第三方軟硬件廠商足夠的技術支持。針對這樣一些情景，我們無法通過歷史資料或組織內部培訓來提高項目實施能力，這個時候既需要一種勇往直前的勇氣，也需要有一種合理的方法。根據我近一年多來遇到的類似項目處理方式，本文提

2、出用“自頂向下”方法論來在進行工作方法的指引，并就該方法論的應用經驗進行總結和分析，以期幫助項目經理或項目實施工程師合理地選擇該方法、有效地利用該方法提高工作效率。本文將從方法論概念、與自底向上的區別、使用場景、方法論優缺點、采用該方法需要具備的能力、自頂向下方法論遵循的基本步驟和相關注意事項幾個方面進行分析和闡釋。本文視圖從理論上對“自頂向下”方法論的運用進行全面剖析，而對具體方法只進行簡單陳述，需要各項目經理和項目實施工程師仔細閱讀、用心揣摩。為便于理解，本文在文章的結尾以貴州移動的兩個案例來幫助大家理解。n 項目實施過程中“自頂向下”方法論概念在項目管理過程中，有很多管理領域都含有“自頂

3、向下”方法的應用，本文中的“自頂向下”方法論主要是指自有或第三方軟件安裝、調測過程中的方法論，與項目管理中的時間、成本、范圍管理等沒有必然的關聯。實施過程中的“自頂向下”方法論主要是在實施過程中將業務目標進行拆分，按正常工作的順序逐點逆序進行，滲透到軟件安裝、功能查找、功能該驗證、調試過程中。這里要強調的是在工作順序上把功能查找（功能使用）、功能驗證作為優先順序按逆序的方式提前到調試工作之前。這是本文“自頂向下”方法論的一個關鍵點。n 自頂向下與自底向上的區別與“自頂向下”相對的方法論主要是“自底向上”方法論。只要在應用軟件調試過程中遵循“先分析客戶需求，然后根據客戶需求去查找、驗證，調試和再

4、驗證”這個流程的，都是采用了“自頂向下”的方法，而“自底向上”遵從先調試后驗證的順序。“自頂向下”總體上是按細分的需求范圍縱向切塊來實施，對已完成的功能點能清晰的界定和判斷，“自底向上”總體上是按軟件組織架構橫向切塊來實施，對需求目標的界定和判斷不是很清晰。比如移動話務網管四期產品中的“主動監控”模塊，按自頂向下來實施的話，能很清晰地說明完成了什么廠家的什么指標處理（包括底層采集、中層算法調試、上層展現網元設置、歷史曲線查詢），而按自底向上方法處理，描述的則是廠家底層采集包安裝情況介紹、中層算法設置情況介紹。【說明：正確的理解這個例子需要假設你完全不清楚主動監控如何實施，不清楚主動監控有底層采

5、集、中層處理和上層展現這些環節】n 自頂向下方法的應用場景自頂向下方法論采用主要是在項目實施方法的探索階段，它不適用于項目的全過程，因為在探索出方法以后就會有更優化的辦法來取代。自頂向下使用的場景首先一定是要基于項目組織對工程實施順序、安裝部署細節、工程實施的詳細目標不清楚（甚至連業務范圍也不是很清楚）的情況下采用的，其目的是讓工作從“無從下手”的狀態轉變到可以正常開展的地步。一旦探索出方法以后，我們就可以考慮更優化的辦法，比如采用自底向上的方式來批量展開工作。從工作組織過程來講，自頂向下方法的運用往往是由于項目采用快速跟進的方式，忽略或不具備條件進行全方位的準備工作造成的。比如沒有進行充分的

6、需求調研、沒有合理的進行需求范圍的細分（細分到功能點）、沒有充分進行產品測試并編寫正確的施工文檔。n 自頂向下與自底向上優缺點比較特性自頂向下自底向上對歷史經驗依賴在項目實施組織沒有一套完整的實施辦法或歷史經驗可借鑒的情況下，它可以圍繞最終業務目標快速的展開相關工作在沒有完整的指導文檔或歷史經驗情況下，無從下手，工作無法展開單點問題對項目的影響把復雜的完整的實施過程進行了分解或縱向切片，將無法解決的問題暴露在單個點上，遵循由點到面的問題解決方法探索問題成片出現，單個問題可能影響到整體環節工作進度描述便于準確描述工作的進度不便于準確描述工作進度冗余工作工作效率相對偏低，增加了一個工作的冗余環節即

7、在調試完成之前已經有功能使用和功能驗證的過程，真正完成工作還有一個調試和再驗證的過程減少了冗余工作，避免了返工批量作業無法進行批量作業，在項目并行執行方面受到一定的限制可以進行批量作業，加快了進度n 采用自頂向下方法需要具備的能力和素質采用自頂向下方法需要施工人員具備一定的業務應用推廣能力和意識；需要具備項目管理對于WBS分解的基本能力和意識；需要具備軟件開發經驗和邏輯思維能力。根據前述對于應用場景的分析，由于這種方法的采用往往是因為在分析、測試、組織施工環節采用快速跟進方式從而造成階段性交付物質量不合格而導致的，因此需要在正式實施階段來對項目的需求目標進行工作細分，對交付物的特性進行細化的描

8、述。n 自頂向下方法運用的基本步驟該方法運用基本遵循以下幾個步驟：1、 閱讀合同技術建議書，了解項目背景及大致范圍；2、 收集需求說明書，了解細分的需求范圍；3、 對產品交付物（或產品功能）進行細分的描述和定義；4、 查找相關的產品（看看在哪個菜單下），進行產品功能驗證（輸入必要的參數和條件，看看是否得到相應的結果）；5、 對無法提供的產品功能進行嘗試性調試，或咨詢相關人員（如產品開發人員）后進行調試。6、 對第5步處理的過程記錄下來，看看其他功能是否適合類似的處理方式；7、 重復16步探尋更多新的方式或按第6步的方式進行實施并優化。n 自頂向下法使用的注意事項“自頂向下”方法論不僅適宜于一個

9、全新的項目，對一個已經有豐富的實施文檔指導項目的某些功能仍可使用，因為實施指導文檔對不同的環境不同的實施人員，其作用是有區別的，比如對于項目組織中一個剛加入的成員。由于采用該方法存在冗余工作，因此不可僵化運用，全程照搬。由于很多工作是漸進明細的，因此在完成工作方法的探索后，可以轉向其他更優化的方法，但是當遇到新的問題時，我們仍可在局部采用該方法對實施文檔進行補充和完善。n 實施案例09年，我在帶領貴州團隊進行項目實施時，有兩個項目即貴州移動綜合接入項目和貴州移動門戶項目都采用了這種“自頂向下”方法論來進行團隊工作指導，從而順利地推動了兩個項目的上線。案例一：貴州移動門戶項目實施背景：貴州移動門

10、戶項目從09年4月份開始啟動7月份達到上線使用條件。整個產品涉及需求調研、產品開發、項目實施、項目優化幾個過程。該項目采用IBM WebsPhere Portal框架進行開發，由于用戶要求6月30號上線，因此產品幾乎沒有設計環節就直接進行了開發；由于是我公司第一次涉足類似項目，因此在項目實施過程中幾乎沒有任何針對性的實施指導文檔也無法提供提供實施培訓，項目實施工作舉步維艱。本地項目經理和實施成員與北京研發之間產生了沖突，認為研發未提供安裝配置文檔，無法開展工作；北京研發認為由于時間緊、況且他們本身也是在摸索過程中，需要現場人員共同思考如何進行項目實施。鑒于此，臨時由我本人充當項目經理，按如下方

11、法進行項目工作開展：1、 閱讀了合同技術建議書和項目范圍說明書（excel版的項目范圍說明文檔）；2、 找客戶方項目經理劉陽交流他們心目中的門戶項目，并采用紙質描畫項目界面的方式對個人工作主頁、短信彩信發送、頁面內容裁剪、ESB數據流交互等功能進行了比較詳細的描述；3、 針對個人主頁、頁面內容裁剪、ESB和短信彩信發送功能，登錄到已經部署好的框架中去查看是否有該功能；4、 對于功能不具備的，立即電話咨詢項目經理（毛偉昌），了解原因并跟毛偉昌一起制定后續解決計劃；5、 對于已經具備的功能進行測試，記錄測試過程中發現的問題并咨詢研發人員；6、 根據研發人員的提示更改部署環節中的配置、或通過前臺設置

12、權限；7、 記錄和整理權限設置的具體步驟；記錄各配置文件分布的目錄；詢問相關模塊的開發人員關于配置文件分布目錄規則和配置文件的命名規則，抽象出其他類似功能的配置文件分布和命名規則。8、 對其他功能按照類似的操作步驟進行嘗試。并證明了前述過程的普遍適用性。9、 通知項目組另外2個成員按照相關方法進行嘗試。10、 三天后，2個項目成員均能按照相關方法完成相關的實施任務。目前該項目已經通過了上線使用演示和培訓，得到了網管中心副總和支撐室經理的認可，并在網管中心副總帶領下到貴陽市公司進行了一次推廣。該案例中體現“自上而下”思想的核心步驟為4、5、7。案例二：貴州移動綜合接入citrix虛擬發布實施背景

13、：由于09年3月份貴州移動網管中心將進行辦公地址搬遷，但搬遷的前提條件是需要綜合接入的citrix虛擬發布工程完成所有網管中心70余套軟件的集中部署和發布，而且citrix必須安裝在VMware虛擬主機上，不再實體主機上。這次項目的難點是：一、公司沒有人員實施過citrix應用集中發布；二、citrix產品從未在VMware虛擬機上進行過穩定性測試，而且由于與VMware的商業競爭關系，citrix不計劃提供任何VMware上的技術支持；三、項目施工時間短（40天）、虛擬發布設備不足；四、不同軟件部署在相同主機上可能存在應用沖突；聘請公司對該產品有一定了解并熟悉項目規劃的人員作為臨時項目經理進

14、行工作指導，該項目經理進行了大量的需求分析和風險分析，制定了如下的工作步驟：1）、針對每套應用制定了60余項調研任務；2）、調研完成后首先完VMware主機的安裝；3）、安裝CPS服務器；4）、安裝NBH客戶端；5）、安裝CPS；6）、在CPS上安裝應用，沖突應用的沖突監測；7）、CPS上的應用發布；8）、測試應用。計劃完成后抽調了本地40%的服務人員進行培訓和工程突擊，要求所有項目組員詳盡地完成調查表格中各要素的調研，并在調研評審結束后進行工程部署。但是在加班加點工作了20天后，沒有一份調研合格，沒有一套應用被成功發布，團隊成員與項目經理相互指責、并在公開場合爭吵。鑒于此，臨時由我本人充當項

15、目經理，按如下方法進行項目工作開展：1、 閱讀了技術方案建議書中關于citrix虛擬發布的原理，通過電話聯系citrix關于虛擬發布的基本過程；2、 重新組織項目成員到網管中心監控室、維護室、技術支援室和支撐室進行業務軟件的收集，將調研表格要素簡化到6項（軟件名稱、依賴的第三方軟件、使用該軟件的人員、該軟件在同一主機上最大可能并行開啟的個數、該軟件在不同主機上開啟的個數、通常判斷該軟件正常運行的方法）；3、 選取2個有一定項目管理意識的人員針對6要素調研表格進行3種分類：1）、不考慮沖突的；2）、同一主機內沖突的；3、不同主機間沖突的。4、 按第3步驟的分類進行縱向切塊，分成3個小組，參照第三

16、步中的類型各自選取一套或2套應用進行完整的發布過程嘗試；將原來8過程的部署順序按如下方式進行調整：、個成員完應用測試的最少量VMware主機安裝；、在兩臺虛擬服務器（P1、P2）上安裝相同應用；、在P2上安裝CPS軟件；、在P2上發布應用；、在任一NBH客戶端上啟動應用，按應用正常運行標準進行測試；、對于第步測試不成功的，到P1上進行測試，如果在P1測試成功，按后面的第5步處理即：咨詢，尋求問題解決辦法；對P1測試不成功的，找軟件提供商咨詢。5、 對于每一環節中出現的問題進行及時咨詢、研究或討論；將原來批量進行時批量暴露的問題縱向切為單點問題，逐個攻關；6、 將操作的過程進行及時記錄，并將暴露的問題及時完善到FAQ中，對由于操作過程考慮不周的地方，根據最新咨詢的結果和研究的結果進行操作步驟的完善；7、 根據第6步的操作，讓項目成員參照第3步的分類分組并行展開原有工作。14天后，整個項目工作全