版權(quán)聲明：如有轉(zhuǎn)載請(qǐng)求，請(qǐng)注明出處：http://blog.csdn.net/yzhz  楊爭  

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

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

對(duì)閱讀者的要求：
1、本手冊(cè)來源與本人平時(shí)項(xiàng)目管理的經(jīng)驗(yàn)，不同公司有不同的特點(diǎn)，項(xiàng)目本身也有差別，本手冊(cè)雖然闡述的是具有普遍性的問題，但是遇到一些具體特殊問題，大家還是要以實(shí)際情況為準(zhǔn)，本手冊(cè)可以起到參考作用。

web項(xiàng)目經(jīng)理手冊(cè)-版本控制流程

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

 版本控制流程目標(biāo)：
1、保證各個(gè)環(huán)境(開發(fā)、測(cè)試、主干)的獨(dú)立，避免相互影響。
2、減少最終發(fā)布時(shí)合并主干出現(xiàn)沖突的概率。
3、降低沖突處理的難度。

原則：
多個(gè)版本（開發(fā)版本，測(cè)試版本，發(fā)布版本）；多次合并。

流程：
1、項(xiàng)目開發(fā)編碼前從當(dāng)前主干建立一條開發(fā)分支，供項(xiàng)目開發(fā)人員使用；
2、開發(fā)結(jié)束，提交測(cè)試的時(shí)候，從當(dāng)前主干建立一條測(cè)試分支，將開發(fā)分支合并到測(cè)試分支上，供測(cè)試人員進(jìn)行測(cè)試。這樣開發(fā)人員對(duì)開發(fā)分支的修改不會(huì)影響測(cè)試環(huán)境；
3、bug fix的時(shí)候我們定時(shí)將開發(fā)分支的修改合并到測(cè)試環(huán)境中。
3、回歸測(cè)試的時(shí)候，從當(dāng)前主干建議一條發(fā)布分支，將測(cè)試分支合并到該發(fā)布分支上，在發(fā)布分支上進(jìn)行回歸測(cè)試。
4、發(fā)布前，將發(fā)布分支合并到當(dāng)前主干。

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

建議：
如果項(xiàng)目的周期比較長，和主干進(jìn)行合并的次數(shù)也應(yīng)該加大，以降低處理沖突的難度。

web項(xiàng)目經(jīng)理手冊(cè)-開發(fā)時(shí)間估算

        項(xiàng)目經(jīng)理制定項(xiàng)目時(shí)間表的時(shí)候，需要估算每個(gè)任務(wù)所需的時(shí)間，其中開發(fā)任務(wù)中模塊的分配和時(shí)間估算是其中最主要的部分。本篇專門就這部分作一個(gè)闡述。

一、在分配模塊和估算開發(fā)時(shí)間時(shí)，我們需要把握的原則和目標(biāo)：
1、保證項(xiàng)目整體的進(jìn)度。
2、有助于確保開發(fā)編碼的質(zhì)量。
3、有助于提高開發(fā)編碼的速度。

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

三、模塊分配和開發(fā)時(shí)間估算的步驟：
1、作為項(xiàng)目經(jīng)理劃分好模塊后，我會(huì)自己先估算一下每個(gè)模塊所需要的開發(fā)時(shí)間。

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

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

web項(xiàng)目經(jīng)理手冊(cè)-Code Review

     Code Review是保證項(xiàng)目中代碼質(zhì)量非常重要的一個(gè)環(huán)節(jié)，其主要工作是：
1、發(fā)現(xiàn)代碼中的bug；
2、從代碼的易維護(hù)性、可擴(kuò)展性角度考察代碼的質(zhì)量，提出修改建議。

1、代碼中的bug主要會(huì)出現(xiàn)在下列兩個(gè)地方：
(1) 與商業(yè)邏輯無關(guān)的bug。
        比如，系統(tǒng)中打開的流／文件／連接等沒有及時(shí)關(guān)閉；或是存在thread safe問題，或是存在性能低下問題等，這類問題對(duì)有經(jīng)驗(yàn)的開發(fā)人員是比較容易發(fā)現(xiàn)的。

2、與商業(yè)邏輯相關(guān)的bug。
        這類bug是非常隱蔽的，如果有對(duì)產(chǎn)品不熟悉的人參與該產(chǎn)品的項(xiàng)目開發(fā)，容易出現(xiàn)這類的bug。為了避免這類bug的出現(xiàn)，我們除了在Use Case和Test Case中詳細(xì)描述以正確指導(dǎo)開發(fā)人員并在測(cè)試時(shí)能及時(shí)發(fā)現(xiàn)它之外，Code Review也是不可缺少的保證環(huán)節(jié)。
        我們希望代碼的審核者對(duì)產(chǎn)品非常熟悉。

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

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

(4)、代碼審核者根據(jù)審核的結(jié)果編寫“代碼審核報(bào)告”，“審核報(bào)告”中記錄發(fā)現(xiàn)的問題及修改建議，然后把“審核報(bào)告”發(fā)送給相關(guān)人員。

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

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

(7)、代碼審核者把Code Review中發(fā)現(xiàn)的有價(jià)值的問題更新到"代碼審核規(guī)范"的文檔中，對(duì)于特別值得提醒的問題可群發(fā)email給所有技術(shù)人員。

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

6、Code Review必備的文檔：
      “代碼審核規(guī)范”文檔：記錄代碼應(yīng)該遵循的標(biāo)準(zhǔn)。代碼審核者根據(jù)這些標(biāo)準(zhǔn)來Code Review代碼，同時(shí)在Code Review過程中不斷完善該文檔。

web項(xiàng)目經(jīng)理手冊(cè)－需求變更管理

  需求變更管理是web項(xiàng)目管理中最重要的一個(gè)環(huán)節(jié)，需求變更管理的有效性直接影響項(xiàng)目的成功與否。

  對(duì)待變更的態(tài)度：
1、變更是不可避免的。
2、變更必須被管理。
3、積極發(fā)現(xiàn)引起變更的因素，促使變更盡可能早的出現(xiàn)，減低變更帶來的風(fēng)險(xiǎn)。

需求變更管理的目標(biāo)：
1、相關(guān)的干系人必須清楚地了解發(fā)生的變更。
2、變更處于有效的管理中。
3、盡量降低變更帶來的風(fēng)險(xiǎn)。

  通過制定需求變更的流程，確保項(xiàng)目中的需求變更有效地進(jìn)行，實(shí)現(xiàn)上述的目標(biāo)。

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

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

序號(hào)

變更提出時(shí)間

變更描述

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

原因

變更提出者

開發(fā)人員

對(duì)進(jìn)度的影響（工作量）

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

6、需求凍結(jié)
 項(xiàng)目越到后期，需求變更對(duì)項(xiàng)目的影響就越大，所以在一定時(shí)候我們會(huì)進(jìn)入需求凍結(jié)階段，不再接收需求的變更。

web項(xiàng)目經(jīng)理手冊(cè)-項(xiàng)目經(jīng)理的工作內(nèi)容

一、項(xiàng)目經(jīng)理的目標(biāo)
1、滿足項(xiàng)目利害關(guān)系者的不同需求。
清晰明確地了解每一個(gè)項(xiàng)目利害關(guān)系者的需求和期望,投其所好。
項(xiàng)目利害關(guān)系者包括：項(xiàng)目團(tuán)隊(duì)成員和項(xiàng)目團(tuán)隊(duì)外成員(比如各部門的部門經(jīng)理，客服等)。
2、保證開發(fā)項(xiàng)目按時(shí)保質(zhì)的完成。

二、項(xiàng)目經(jīng)理的職責(zé)
1、建立有效的流程保證項(xiàng)目的順利進(jìn)行。
2、制定詳細(xì)周密的項(xiàng)目計(jì)劃。
3、跟蹤，推動(dòng)項(xiàng)目按計(jì)劃進(jìn)行。
4、積極解決項(xiàng)目過程中出現(xiàn)的問題和沖突。
5、調(diào)動(dòng)開發(fā)團(tuán)隊(duì)的積極性，創(chuàng)造力，推動(dòng)團(tuán)隊(duì)成員在項(xiàng)目過程中不斷成長。

三、項(xiàng)目經(jīng)理的具體工作

1、項(xiàng)目前期階段
  . 技術(shù)可行性分析，對(duì)項(xiàng)目進(jìn)行技術(shù)評(píng)估、成本評(píng)估以及風(fēng)險(xiǎn)評(píng)估。
 . 與需求方代表進(jìn)行需求討論，明確項(xiàng)目的目標(biāo)、價(jià)值；確定項(xiàng)目范圍、功能及優(yōu)先級(jí)。
  . 組建項(xiàng)目團(tuán)隊(duì)，特別要搞清楚項(xiàng)目的key person(對(duì)產(chǎn)品有決定權(quán)的人)。
  . 項(xiàng)目啟動(dòng)會(huì)議。

    通常項(xiàng)目成員包括以下人員：項(xiàng)目經(jīng)理、架構(gòu)師、技術(shù)經(jīng)理、產(chǎn)品經(jīng)理、開發(fā)工程師、DBA、測(cè)試工程師、需求分析工程師、UI、文案、SQA、SCM。
   
階段輸出物：確認(rèn)后的最終需求文檔
       
2、分析設(shè)計(jì)階段
. 制定項(xiàng)目進(jìn)度計(jì)劃，工作任務(wù)分解(WBS)。
. 資源申請(qǐng)-項(xiàng)目涉及到的開發(fā)資源、測(cè)試資源、設(shè)計(jì)資源。
. 數(shù)據(jù)庫設(shè)計(jì)。
. 系統(tǒng)設(shè)計(jì)。
. 文檔(包括UC、Demo、TC等)評(píng)審會(huì)議

階段輸出物：
(1) User Case
(2) DEMO
(3) 系統(tǒng)設(shè)計(jì)文檔
(4) 數(shù)據(jù)庫設(shè)計(jì)文檔
(5) User Case等文檔評(píng)審
 
3、執(zhí)行階段(開發(fā)、測(cè)試)
. 準(zhǔn)備開發(fā)環(huán)境、測(cè)試環(huán)境。
. 跟蹤，推動(dòng)項(xiàng)目按計(jì)劃進(jìn)行。
. 通報(bào)項(xiàng)目的進(jìn)展情況，通常以周報(bào)的形式。
. 對(duì)項(xiàng)目的階段成果進(jìn)行評(píng)估，以確保該階段完成的質(zhì)量，包括代碼審核、SQL審核等。
. 對(duì)需求變更進(jìn)行控制管理。
. 對(duì)項(xiàng)目風(fēng)險(xiǎn)進(jìn)行管理。
. 測(cè)試階段客戶驗(yàn)收、收集反饋意見。

4、發(fā)布階段
. 制定項(xiàng)目發(fā)布計(jì)劃。
. 用戶培訓(xùn)。
. 發(fā)布上線。

5、上線后監(jiān)控
. 數(shù)據(jù)監(jiān)控(日志、服務(wù)器狀態(tài))。
. BUG FIX及改進(jìn)。

5、結(jié)束階段
. 項(xiàng)目總結(jié)會(huì)。
. 產(chǎn)品交付。

web項(xiàng)目經(jīng)理手冊(cè)-項(xiàng)目經(jīng)理需要銘記在心的話

1、項(xiàng)目經(jīng)理不是來管人的，而是來支持人的。
        解析：不光是項(xiàng)目經(jīng)理，任何經(jīng)理的職位都是如此。但現(xiàn)實(shí)中很多人并不是那么做，這也是為什么他們沒能把項(xiàng)目做成功的原因。作為項(xiàng)目經(jīng)理首先要端正態(tài)度，認(rèn)識(shí)到這份工作職責(zé)的本質(zhì)。

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

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

6、不要認(rèn)為把任務(wù)交給團(tuán)隊(duì)成員，期間你可以不聞不問，到了完成的時(shí)間他自然會(huì)把任務(wù)交上來。這種想法是非常錯(cuò)誤。
       解析：這樣做無疑會(huì)增加項(xiàng)目的風(fēng)險(xiǎn)，很容易出現(xiàn)該完成的任務(wù)沒有按時(shí)完成，有些延誤，這樣項(xiàng)目后續(xù)的工作都會(huì)收到牽制。
      正確的做法是：當(dāng)把任務(wù)安排下去后，你要定期和成員溝通完成的情況，詢問是否需要支持，這樣我們才能保證任務(wù)能按時(shí)保質(zhì)的完成。

7、溝通要訣：項(xiàng)目過程中與相關(guān)人員溝通時(shí)，不要總認(rèn)為對(duì)方的出發(fā)點(diǎn)都是從項(xiàng)目利益考慮，他/她一定先考慮個(gè)人利益或部門利益，所以項(xiàng)目經(jīng)理要做的是：如何把對(duì)方的個(gè)人利益(部門利益)引導(dǎo)到和項(xiàng)目利益一致。

8、“加班”是一個(gè)危險(xiǎn)的信號(hào)，表明一定是某個(gè)地方出現(xiàn)了問題，要找出進(jìn)度落后的原因。

9、項(xiàng)目開始前，項(xiàng)目經(jīng)理一定要找出項(xiàng)目的決策者是誰，誰對(duì)項(xiàng)目的產(chǎn)品有最終的發(fā)言權(quán)。

10、我們交付的不是程序，而是產(chǎn)品和服務(wù)。 

web項(xiàng)目經(jīng)理手冊(cè)-風(fēng)險(xiǎn)管理

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

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

2、技術(shù)風(fēng)險(xiǎn)：開發(fā)過程中遇到技術(shù)難題，導(dǎo)致開發(fā)時(shí)間延遲或者需求不得不發(fā)生變更。
     如何減少此類風(fēng)險(xiǎn)的發(fā)生？
     在項(xiàng)目開始前的技術(shù)評(píng)估階段，明確技術(shù)難點(diǎn)，提前安排人員進(jìn)行攻克。如果在可預(yù)期的時(shí)間內(nèi)無法解決，可以要求需求方變更需求。

3、質(zhì)量風(fēng)險(xiǎn)：對(duì)于web項(xiàng)目而言，質(zhì)量風(fēng)險(xiǎn)主要指開發(fā)代碼的質(zhì)量。
       如何提高開發(fā)人員開發(fā)的質(zhì)量？
(1)、制定項(xiàng)目計(jì)劃時(shí)，對(duì)開發(fā)時(shí)間的評(píng)估要盡可能的合適。合理的開發(fā)時(shí)間對(duì)開發(fā)質(zhì)量的影響很大。開發(fā)時(shí)間評(píng)估可參考【web項(xiàng)目經(jīng)理手冊(cè)-開發(fā)時(shí)間估算】。
(2)、有一套嚴(yán)格可行的代碼規(guī)范，編碼時(shí)嚴(yán)格遵守，code review時(shí)嚴(yán)格考核。
(3)、在編碼前，開發(fā)人員要對(duì)框架熟練掌握。
(4)、一份好的系統(tǒng)設(shè)計(jì)文檔對(duì)指導(dǎo)開發(fā)非常重要。

4、資源風(fēng)險(xiǎn)：項(xiàng)目所需人力資源無法按時(shí)到位，導(dǎo)致資源風(fēng)險(xiǎn)。
如何減少此類風(fēng)險(xiǎn)的發(fā)生？
這個(gè)就需要在項(xiàng)目計(jì)劃制定的時(shí)候提前申請(qǐng)確認(rèn)資源，并在項(xiàng)目過程中不斷溝通協(xié)調(diào)。

二、項(xiàng)目風(fēng)險(xiǎn)管理的要點(diǎn)：
1、上述我們所說的風(fēng)險(xiǎn)管理都是指可以預(yù)期將要發(fā)生的風(fēng)險(xiǎn)，那些不可預(yù)期將要發(fā)生的風(fēng)險(xiǎn)不屬于風(fēng)險(xiǎn)管理的范疇。這也說明項(xiàng)目經(jīng)理的經(jīng)驗(yàn)和知識(shí)對(duì)能否管理好風(fēng)險(xiǎn)至關(guān)重要。
2、詳細(xì)明確的項(xiàng)目計(jì)劃、以及項(xiàng)目執(zhí)行過程中每個(gè)要點(diǎn)的質(zhì)量保證是降低項(xiàng)目風(fēng)險(xiǎn)的必要條件。
3、風(fēng)險(xiǎn)報(bào)告是項(xiàng)目團(tuán)隊(duì)以及領(lǐng)導(dǎo)了解項(xiàng)目風(fēng)險(xiǎn)的一個(gè)有效手段。
風(fēng)險(xiǎn)報(bào)告的格式通常是：

序號(hào)

風(fēng)險(xiǎn)簡介

對(duì)項(xiàng)目的影響

解決方案（對(duì)策）

web項(xiàng)目經(jīng)理手冊(cè)-跨部門合作項(xiàng)目

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

      本人根據(jù)平時(shí)這類項(xiàng)目的實(shí)施經(jīng)驗(yàn)，總結(jié)一下這類項(xiàng)目要想成功，需要把握的原則。
1、合作雙方的領(lǐng)導(dǎo)層必須都非常重視這個(gè)項(xiàng)目。剃頭挑子一頭熱的項(xiàng)目成功的可能性不會(huì)高。
只有這樣，項(xiàng)目的優(yōu)先級(jí)才有保證，這樣在以后項(xiàng)目過程中一些資源（包括人力、硬件、時(shí)間投入）更有保證，配合起來也會(huì)更加順暢。

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

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

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

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

8、由于項(xiàng)目的各個(gè)點(diǎn)是互相依賴的，所以在一些關(guān)鍵點(diǎn)上要能按時(shí)提交，否則會(huì)影響對(duì)方的進(jìn)度。
在項(xiàng)目計(jì)劃中要詳細(xì)定義各個(gè)重要的里程碑，并嚴(yán)格控制執(zhí)行。

9、項(xiàng)目進(jìn)度報(bào)告。
定時(shí)相互通告項(xiàng)目進(jìn)度，重點(diǎn)關(guān)注項(xiàng)目風(fēng)險(xiǎn)。

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

 web項(xiàng)目經(jīng)理手冊(cè)-你會(huì)溝通嗎？

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