版權聲明：如有轉載請求，請注明出處：http://blog.csdn.net/yzhz  楊爭  

        web項目指基于web的開發項目，由于web開發的一些特點，使得web開發的項目管理與以往的軟件開發項目管理有很大的不同，具體表現在
1、web項目周期短。
        一般的web項目的周期為1～3月，而一般的軟件開發的周期都在半年以上，象vista微軟花費了五年的時間才開發出來。
2、web項目要求上線快。
        互聯網公司推出的產品，講究快字當頭，誰先推出產品占領市場，誰就取得先機，所以web的項目往往要求上線快，對于比較大的項目通常我們會先把產品先launch上線，然后第二期第三期再來完善。
      “快”應該是web開發和通常的軟件開發的最大區別，web產品的維護是在服務器端，這就使得這種快成為可能，我們可以很容易地隨時升級產品，而通常的軟件由于是部署在用戶的機器上，升級的頻率和幅度沒辦法與web產品比擬。
        也正由于這個“快”，使得web項目的需求變更成為了web項目管理中最需解決的問題。
 
        web項目經理手冊分為若干主題，每個專題從項目管理的某個方面介紹項目經理在這方面要做的事情，專題會陸續推出。
       本手冊為本人在項目管理中的經驗總結，所以手冊的內容也會不斷完善中。

       本手冊的原則：
1、指導性強。
2、實用性強。
        我一直崇尚這么一句話：把問題復雜化是為了幫助我們更好地理解這個問題，而把問題簡單化是為了讓我們更好地執行。所以本手冊把簡單可行作為標準。一個再好的流程如果不簡單可行，最終也沒法在實際工作中推廣起來。當然簡單的含義不是要少做事情，而是所做的事情讓執行的人覺得就該怎么做，不這么做，質量就沒法保證，并且執行起來很自然。

對閱讀者的要求：
1、本手冊來源與本人平時項目管理的經驗，不同公司有不同的特點，項目本身也有差別，本手冊雖然闡述的是具有普遍性的問題，但是遇到一些具體特殊問題，大家還是要以實際情況為準，本手冊可以起到參考作用。

web項目經理手冊-版本控制流程

        大家在項目過程中是否會經常發生以下問題：
1、測試人員在測試階段更新測試環境時，發現編譯不通過，或者應用出現異常，無法進行測試。后來發現的根源是測試和開發共用一個分支。
2、有一天某個人群發了一條郵件通知，“我們的項目代碼已經發到主干，這段時間大家不要修改主干信息”，這樣影響其他項目的正常發布。
3、項目進行了比較長的時間，等最后發布，需要與主干進行合并的時候，出現大量的沖突，幾乎沒法處理。而且沖突處理完后我們還需要重新再做測試，以保證我們的沖突處理沒有問題，這樣又會需要花費大量的時間。

 版本控制流程目標：
1、保證各個環境(開發、測試、主干)的獨立，避免相互影響。
2、減少最終發布時合并主干出現沖突的概率。
3、降低沖突處理的難度。

原則：
多個版本（開發版本，測試版本，發布版本）；多次合并。

流程：
1、項目開發編碼前從當前主干建立一條開發分支，供項目開發人員使用；
2、開發結束，提交測試的時候，從當前主干建立一條測試分支，將開發分支合并到測試分支上，供測試人員進行測試。這樣開發人員對開發分支的修改不會影響測試環境；
3、bug fix的時候我們定時將開發分支的修改合并到測試環境中。
3、回歸測試的時候，從當前主干建議一條發布分支，將測試分支合并到該發布分支上，在發布分支上進行回歸測試。
4、發布前，將發布分支合并到當前主干。

好處：
1、多個版本相互獨立，互不影響
2、通過多次與主干的合并，這樣發布時候和主干做最后一次合并的沖突會大大減少，并且在與主干多次合并過程中的沖突解決都在測試階段中得到了測試。

建議：
如果項目的周期比較長，和主干進行合并的次數也應該加大，以降低處理沖突的難度。

 

web項目經理手冊-開發時間估算

 

        項目經理制定項目時間表的時候，需要估算每個任務所需的時間，其中開發任務中模塊的分配和時間估算是其中最主要的部分。本篇專門就這部分作一個闡述。

一、在分配模塊和估算開發時間時，我們需要把握的原則和目標：
1、保證項目整體的進度。
2、有助于確保開發編碼的質量。
3、有助于提高開發編碼的速度。

二、每個公司都擁有自己的技術框架，開發人員主要的工作通常投入在具體的商業邏輯上。
通常每個模塊所需的開發時間取決于以下三個因素：
1、該模塊的商業邏輯的復雜程度。
2、開發人員的技術水平和對項目所在應用的熟悉程度（包括對框架和應用的熟悉程度）。
3、該模塊技術實現上是否有技術難點。這里我把技術難點定義為：在現有系統中還未實現的有一定技術難點的問題。對于這樣的難題，開發者沒有相關的代碼可以參考，需要投入一些時間研究解決。

三、模塊分配和開發時間估算的步驟：
1、作為項目經理劃分好模塊后，我會自己先估算一下每個模塊所需要的開發時間。

2、召集所有開發人員，討論模塊分配和開發時間估算。
      項目經理將劃分好的模塊，讓開發人員從中挑選他們感興趣的模塊。這樣做可以提高開發人員的主動性和參與性。
      項目經理在分配模塊的時候還需從以下幾方面考慮，以確保開發的速度和質量。
 (1)相同類似的模塊由同一人負責開發，比如文章的增刪改由同一開發者負責。這樣做的好處就是開發者對相關邏輯會更加熟悉，同時接口的定義也會比較明確，溝通的成本比較低。
 (2)技術難度比較大的模塊由技術水平比較高的人負責。
 (3)業務邏輯比較復雜的由對這塊邏輯比較了解的人負責。

 3、模塊分配完后，開發人員評估自己負責開發的模塊所需要的時間。在此過程中我們會比較詳細的討論每個模塊的技術實現，以便使時間的估算更加準確。
 
 4、項目經理對開發人員估算的時間進行確認。
        在確認過程中作為項目經理我會參考以上提到的三個因素，同時將自己估算的時間和開發人員估算的時間進行比較。這其中的差異當然會存在的。對于那些差異比較大的，我會和技術人員探討其中的緣由。
        對于時間周期比較長的任務，我通常會再細分一下，爭取每個任務的最長時間不超過3天。時間周期越長的任務，不確定性越高，風險也越高，越有可能成為項目的瓶頸。
 
 
建議：
1、項目總結的時候，對項目中的一些數據做好統計比如單位UC所花的開發時間、測試時間等，這些數據統計可以作為以后開發的參考。
2、對技術難點，在項目開始前做好技術準備，提前安排人員研究。這樣會節省以后項目時間，降低技術風險。

 

web項目經理手冊-Code Review

 

     Code Review是保證項目中代碼質量非常重要的一個環節，其主要工作是：
1、發現代碼中的bug；
2、從代碼的易維護性、可擴展性角度考察代碼的質量，提出修改建議。

1、代碼中的bug主要會出現在下列兩個地方：
(1) 與商業邏輯無關的bug。
        比如，系統中打開的流／文件／連接等沒有及時關閉；或是存在thread safe問題，或是存在性能低下問題等，這類問題對有經驗的開發人員是比較容易發現的。

2、與商業邏輯相關的bug。
        這類bug是非常隱蔽的，如果有對產品不熟悉的人參與該產品的項目開發，容易出現這類的bug。為了避免這類bug的出現，我們除了在Use Case和Test Case中詳細描述以正確指導開發人員并在測試時能及時發現它之外，Code Review也是不可缺少的保證環節。
        我們希望代碼的審核者對產品非常熟悉。

3、什么樣的人承擔代碼審核者Code Reviewer？
(1)、比較熟悉相關商業邏輯。
(2)、有豐富的編程經驗。
兩者缺一不可。

4、代碼Code Review的步驟，這些是我在平時工作中的經驗總結，目前也是按照這個步驟在做。
(1)、代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UC依次講解自己負責的代碼和相關邏輯，從Web層->DAO層；
(2)、代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發現隱藏的bug；對這些bug記錄在案。
(3)、代碼講解完畢后，代碼審核者給自己安排幾個小時再對代碼審核一遍。
        代碼需要一行一行靜下心看。同時代碼又要全面的看，以確保代碼整體上設計優良。

(4)、代碼審核者根據審核的結果編寫“代碼審核報告”，“審核報告”中記錄發現的問題及修改建議，然后把“審核報告”發送給相關人員。

(5)、代碼編寫者根據“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。

(6)、代碼編寫者 bug fix完畢之后給出反饋。

(7)、代碼審核者把Code Review中發現的有價值的問題更新到"代碼審核規范"的文檔中，對于特別值得提醒的問題可群發email給所有技術人員。

5、責任：
        代碼編寫者，代碼審核者共同對代碼的質量承擔責任。這樣才能保證Code Review不是走過場，其中代碼編寫者承擔主要責任，代碼審核者承擔次要責任。

6、Code Review必備的文檔：
      “代碼審核規范”文檔：記錄代碼應該遵循的標準。代碼審核者根據這些標準來Code Review代碼，同時在Code Review過程中不斷完善該文檔。

web項目經理手冊－需求變更管理

 

  需求變更管理是web項目管理中最重要的一個環節，需求變更管理的有效性直接影響項目的成功與否。

  對待變更的態度：
1、變更是不可避免的。
2、變更必須被管理。
3、積極發現引起變更的因素，促使變更盡可能早的出現，減低變更帶來的風險。

需求變更管理的目標：
1、相關的干系人必須清楚地了解發生的變更。
2、變更處于有效的管理中。
3、盡量降低變更帶來的風險。

  通過制定需求變更的流程，確保項目中的需求變更有效地進行，實現上述的目標。

  需求變更流程：
1、確定需求的基準線。
 通常我們會以User Case作為需求基準線，在User Case確認之后的任何需求改變，都需要走需求變更流程。沒有走需求變更流程的需求將不被認可。

2、首先項目經理接收到需求變更的要求。
  需求變更的提出者可以是項目中的任何人包括產品經理、客服、開發人員、測試人員等。
 
3、項目經理評估該需求變更。
  項目經理可以召集相關人員討論該需求變更的合理性、可行性，實施的代價以及對項目的影響。
 項目經理作為項目的負責人，對項目的成功負有主要的責任。所以需求變更的決策者應該由項目經理承擔。
 
4、需求變更確認后由專人將需求變更記錄下來(格式如下)，通知給項目中所有成員。其中以下人員對需求的變更是緊密相關的,他們必須知曉并認可此需求變更。包括（客戶方代表，需求分析師，測試人員，相關開發人員）。
需求變更表的格式：

序號

變更提出時間

變更描述

變更類型(是對原有需求的修改還是新增需求)

原因

變更提出者

開發人員

對進度的影響（工作量）

5、相關人員接收到確認的需求變更后，做以下事情。
需求分析人員修改需求說明書和User Case的相關內容。
測試人員修改測試用例的相關內容。
開發人員修改代碼中的相關部分。

6、需求凍結
 項目越到后期，需求變更對項目的影響就越大，所以在一定時候我們會進入需求凍結階段，不再接收需求的變更。

 

web項目經理手冊-項目經理的工作內容

 

一、項目經理的目標
1、滿足項目利害關系者的不同需求。
清晰明確地了解每一個項目利害關系者的需求和期望,投其所好。
項目利害關系者包括：項目團隊成員和項目團隊外成員(比如各部門的部門經理，客服等)。
2、保證開發項目按時保質的完成。

二、項目經理的職責
1、建立有效的流程保證項目的順利進行。
2、制定詳細周密的項目計劃。
3、跟蹤，推動項目按計劃進行。
4、積極解決項目過程中出現的問題和沖突。
5、調動開發團隊的積極性，創造力，推動團隊成員在項目過程中不斷成長。

三、項目經理的具體工作

1、項目前期階段
  . 技術可行性分析，對項目進行技術評估、成本評估以及風險評估。
 . 與需求方代表進行需求討論，明確項目的目標、價值；確定項目范圍、功能及優先級。
  . 組建項目團隊，特別要搞清楚項目的key person(對產品有決定權的人)。
  . 項目啟動會議。

    通常項目成員包括以下人員：項目經理、架構師、技術經理、產品經理、開發工程師、DBA、測試工程師、需求分析工程師、UI、文案、SQA、SCM。
   
階段輸出物：確認后的最終需求文檔
       
2、分析設計階段
. 制定項目進度計劃，工作任務分解(WBS)。
. 資源申請-項目涉及到的開發資源、測試資源、設計資源。
. 數據庫設計。
. 系統設計。
. 文檔(包括UC、Demo、TC等)評審會議

階段輸出物：
(1) User Case
(2) DEMO
(3) 系統設計文檔
(4) 數據庫設計文檔
(5) User Case等文檔評審
 
3、執行階段(開發、測試)
. 準備開發環境、測試環境。
. 跟蹤，推動項目按計劃進行。
. 通報項目的進展情況，通常以周報的形式。
. 對項目的階段成果進行評估，以確保該階段完成的質量，包括代碼審核、SQL審核等。
. 對需求變更進行控制管理。
. 對項目風險進行管理。
. 測試階段客戶驗收、收集反饋意見。

4、發布階段
. 制定項目發布計劃。
. 用戶培訓。
. 發布上線。

5、上線后監控
. 數據監控(日志、服務器狀態)。
. BUG FIX及改進。

5、結束階段
. 項目總結會。
. 產品交付。

 

web項目經理手冊-項目經理需要銘記在心的話

 

1、項目經理不是來管人的，而是來支持人的。
        解析：不光是項目經理，任何經理的職位都是如此。但現實中很多人并不是那么做，這也是為什么他們沒能把項目做成功的原因。作為項目經理首先要端正態度，認識到這份工作職責的本質。

2、好的開始是成功的一半。
        解析：一個好項目的失敗，往往是由于前期的準備不足、計劃不周密。所以在項目初期要舍得花時間做前期的需求收集、討論、技術準備等工作。盡管前期的工作看起來并沒有直接產生效益，但這塊工作做好了，后面的工作往往會事半功倍。否則前期準備不足，很可能導致項目出現各種各樣的問題（比如大量的需求變更等）。

3、什么樣的項目最可能成功？答案是：項目越小成功的可能性越大。
       解析：項目經理和相關人員要仔細評估項目中feature的成本/價值比，盡可能縮小產品的規模。
      有時候項目經理可能改變不了整個項目規模，但是項目經理可以采用各種手段來“縮小”項目，比如分期進行、迭代開發等。
 
4、任何對項目的改善無關的工作都是浪費時間。
       解析：在項目過程中項目經理不要做表面工作，或者對項目本身無意義的工作。比如無休止的會議；要求編寫詳細而最終沒有用處的文檔。
 
5、使用者的參與是項目成功的重要保證。
      解析：使用者可以是：產品經理、需求方代表、或者客戶。
      在項目的各個階段，項目經理要積極要求使用者參與到項目過程中。通過這種與使用者不斷的溝通、反饋，使得最終做出來的產品是客戶真正想要的。

6、不要認為把任務交給團隊成員，期間你可以不聞不問，到了完成的時間他自然會把任務交上來。這種想法是非常錯誤。
       解析：這樣做無疑會增加項目的風險，很容易出現該完成的任務沒有按時完成，有些延誤，這樣項目后續的工作都會收到牽制。
      正確的做法是：當把任務安排下去后，你要定期和成員溝通完成的情況，詢問是否需要支持，這樣我們才能保證任務能按時保質的完成。

7、溝通要訣：項目過程中與相關人員溝通時，不要總認為對方的出發點都是從項目利益考慮，他/她一定先考慮個人利益或部門利益，所以項目經理要做的是：如何把對方的個人利益(部門利益)引導到和項目利益一致。

8、“加班”是一個危險的信號，表明一定是某個地方出現了問題，要找出進度落后的原因。

9、項目開始前，項目經理一定要找出項目的決策者是誰，誰對項目的產品有最終的發言權。

10、我們交付的不是程序，而是產品和服務。 

 

web項目經理手冊-風險管理

 

         風險管理是web項目中項目經理最重要的工作之一。風險管理是一個持續的過程，貫穿于整個項目過程中，風險管理包括風險識別、風險估計、風險解決以及風險管理策略。
   
        在實際web項目中，項目風險主要表現為以下情況。了解這些有助于項目經理在項目初期就識別出這些風險，并采取措施避免或者減少它們的發生。

一、web項目風險列表：
1：需求變更風險：需求已經打上了基線，但此后仍然有變更發生，對項目造成影響。
       如何減少此類風險的發生？
(1) 前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。
(2) 需求文檔中要有demo。對于web項目，圖片比文字更能說明問題。
(3) 找出項目中需求的決策者(通常會是產品經理、相關職能主管、客服)，所有的需求要經過他們的認可。
(4) 客戶在項目過程中的全程參與有助于降低此類風險。需求討論、需求確認、User Case確認、測試階段的客戶驗收等環節，都要要求客戶參與。
(5) 發生需求變更時，嚴格按照需求變更流程執行。

2、技術風險：開發過程中遇到技術難題，導致開發時間延遲或者需求不得不發生變更。
     如何減少此類風險的發生？
     在項目開始前的技術評估階段，明確技術難點，提前安排人員進行攻克。如果在可預期的時間內無法解決，可以要求需求方變更需求。

3、質量風險：對于web項目而言，質量風險主要指開發代碼的質量。
       如何提高開發人員開發的質量？
(1)、制定項目計劃時，對開發時間的評估要盡可能的合適。合理的開發時間對開發質量的影響很大。開發時間評估可參考【web項目經理手冊-開發時間估算】。
(2)、有一套嚴格可行的代碼規范，編碼時嚴格遵守，code review時嚴格考核。
(3)、在編碼前，開發人員要對框架熟練掌握。
(4)、一份好的系統設計文檔對指導開發非常重要。

4、資源風險：項目所需人力資源無法按時到位，導致資源風險。
如何減少此類風險的發生？
這個就需要在項目計劃制定的時候提前申請確認資源，并在項目過程中不斷溝通協調。

二、項目風險管理的要點：
1、上述我們所說的風險管理都是指可以預期將要發生的風險，那些不可預期將要發生的風險不屬于風險管理的范疇。這也說明項目經理的經驗和知識對能否管理好風險至關重要。
2、詳細明確的項目計劃、以及項目執行過程中每個要點的質量保證是降低項目風險的必要條件。
3、風險報告是項目團隊以及領導了解項目風險的一個有效手段。
風險報告的格式通常是：

序號

風險簡介

對項目的影響

解決方案（對策）

web項目經理手冊-跨部門合作項目

 

       web項目中有很多項目涉及到跨部門、跨公司的合作。這類項目往往比其他項目更有挑戰。對于項目經理如何做好這些項目呢？
       首先讓我們看看這類項目都有哪些共同的特點。
1、合作雙方工作在不同地方，對項目溝通造成一定影響。
2、合作雙方隸屬于不同的公司或者部門，雙方的項目開發流程可能完全不同，在項目執行過程中需要考慮到這個因素。
2、合作項目需要雙方共同完成，如果一方的工作進度出現延誤，那么整個項目的進度都會收到影響。

      本人根據平時這類項目的實施經驗，總結一下這類項目要想成功，需要把握的原則。
1、合作雙方的領導層必須都非常重視這個項目。剃頭挑子一頭熱的項目成功的可能性不會高。
只有這樣，項目的優先級才有保證，這樣在以后項目過程中一些資源（包括人力、硬件、時間投入）更有保證，配合起來也會更加順暢。

2、合作雙方確定好各自的接口人。雙方的溝通都通過接口人進行，這樣可以降低成本，提高溝通的效率。
接口人可以分為兩類：一類是商業上的接口人，一類是技術上的接口人。

3、完備的文檔(接口文檔、數據庫文檔)必不可少。
web項目雙方的合作在技術方面通常采用API接口方式交互。所以項目前期詳細準確的接口說明文檔非常重要，雙方開發人員之后的開發都是嚴格按照接口進行。
同時接口的相對穩定也是非常重要的，所以需要前期設計的時候認真全面地考慮接口規范。
 
4、便利的溝通工具。
 對于跨地區的合作，便利的溝通工具是非常重要的。當然工具最好是免費，比如使用IM。從溝通方式的效果來看，我覺得面對面的溝通>電話溝通>EMAIL(or IM)。

5、接口變更的及時通知。
這一點很重要，接口變更應該有流程來保證，特別是對于這種成員分散在不同地方的團隊尤為重要。
 
6、前期技術方案的溝通。
前期技術方案的討論以及接口的定義，最好能當面溝通，這樣效果最好。所以前期最好去一趟對方公司商談這些要點。

7、各自開發環境的可訪問問題。解決雙方開發環境的相互調用問題。
合作雙方聯調的時候通常需要訪問對方的接口。由于雙方都在各自環境進行開發，所以需要解決這種問題。
最好的情況是：可以訪問對方的環境(外網)。
最大的風險是：沒有可以聯調的環境，等到發布到正式環境上再測試，這時候時間上就有點晚了，可能會遇到一些之前預想不到的問題。所以聯調的時間越提前,問題就能越快暴露出來，整個項目的風險就越小。
聯調環境的穩定也非常重要。有一次我們發現我們的功能有問題，代碼跟蹤調試，結果發現原來對方的環境有問題，浪費了我們很多時間。

8、由于項目的各個點是互相依賴的，所以在一些關鍵點上要能按時提交，否則會影響對方的進度。
在項目計劃中要詳細定義各個重要的里程碑，并嚴格控制執行。

9、項目進度報告。
定時相互通告項目進度，重點關注項目風險。

10、熟悉對方項目開發的流程。
不同公司項目的流程、角色分工不一定相同。只有熟悉了對方項目的流程，在與對方溝通時候才能做正確的事情。所謂知己知彼，才能百戰百勝。
千萬不要自己悶頭開發，完全不顧對方的做事方式，然后自己想當然他們應該和我們一樣。

 

 web項目經理手冊-你會溝通嗎？

 

序號	項目干系人	其對項目的主要期望	在本項目中的利益程度 (H, M, L)	對項目的影響程度 (H, M, L)	與其溝通的策略
1
2
3
4
5