基本上，產(chǎn)品開發(fā)過程中的一些重大的關(guān)鍵問題，都是需要產(chǎn)品經(jīng)理來拍板;至于拍板之前的種種溝通、權(quán)衡等，就要靠產(chǎn)品經(jīng)理本身的“素質(zhì)”了，正文開始：

“1人100個月完成的項目，不是100個人1個月就可以完成?！?/p>

項目管理是讓項目活動中相互競爭的各類制約因素：質(zhì)量、進度、資源、風(fēng)險等取得平衡的藝術(shù)，同時也是平衡項目干系人的各種需要、關(guān)注和期望，帶領(lǐng)不同的人朝著相同目標邁進的領(lǐng)導(dǎo)藝術(shù)。

成功的項目管理可以簡單理解為：按時、在預(yù)算內(nèi)+滿足產(chǎn)品需求+滿足質(zhì)量需求 地完成項目。

以下是我對項目管理的一點體會記錄。

　　需求等級

視覺 A：圖片沒有分享功能嗎?

技術(shù) K：圖片有鏈接轉(zhuǎn)發(fā)分享、微博或郵件形式分享等多種分享，全部開發(fā)的話需要推延時間表。

策劃 D：圖片只做預(yù)覽、下載已經(jīng)足夠了，暫時不做分享。

交互 E：如果我們的用戶是基于郵箱用戶，圖片的郵件分享還是建議做。

如果在前期產(chǎn)品需求文檔中沒有明確定義每個需求的優(yōu)先等級，或者說項目成員對需求的優(yōu)先等級沒有明確的意識，可能類似的爭論會時常發(fā)生在項目成員之間，每個人會基于自己對產(chǎn)品目標的理解來考慮這個需求是否要做，什么時候做，做到什么程度而產(chǎn)生分歧，因而增加項目推進的阻力。

所以在前期產(chǎn)品需求文檔中，必須明確定義出每個需求的優(yōu)先等級，需求的粒度可細化到每個大功能下的子功能需求，如：圖片分享功能的轉(zhuǎn)發(fā)鏈接分享、郵件形式分享這樣的子功能需求。等級的劃分依賴于前期的用戶需求調(diào)研、產(chǎn)品的預(yù)定目標、開發(fā)成本、運營計劃等;

　　一般的需求等級劃分：

P0 -Must have： 如果缺失，產(chǎn)品不能發(fā)布

P1 -Should have： 如果缺失，產(chǎn)品能發(fā)布，但不能達到預(yù)定目標(功能/性能)

P2 -Nice to have： 做了則更好

P3 -Neutral： 對產(chǎn)品沒有明顯的好處，用戶不在意

每個需求的優(yōu)先等級確定之后，產(chǎn)品經(jīng)理根據(jù)產(chǎn)品預(yù)定目標、開發(fā)成本、運營計劃等來定義一個等級分界線，高于或等于這個等級分界線的需求在本期開發(fā)，部分根據(jù)成本、運營計劃等因素調(diào)整到下期開發(fā)，而低于這個等級分界線的需求則只會在下期開發(fā)，這樣讓全體項目成員對本期要做的需求達成共識。

　　需求等級的實際應(yīng)用：

WBS各工作包Triage的參考基準之一;Triage即確定需求任務(wù)是否要做，是否要現(xiàn)在做的一個共同決策過程;在Triage的過程中，任務(wù)owner對自己的任務(wù)以及其他人的任務(wù)有更全局的認識。

Bug的Triage的參考標準參考基準之一(也是zero bug *注1 和code freeze *注2 時間節(jié)點計算的參考基準之一);Triage即確定測試中的Bug是否要修，是否要現(xiàn)在修;如：在功能開發(fā)期間，P0、P1、P2及以上的Bug都要修;當進入接口凍結(jié)期后，只有P0、P1normal及以上的Bug才允許修，以保證優(yōu)先的Bug問題更快地被解決。

*注1 Zero Bug：當前不存在active bug，或不存在高優(yōu)先級或特別嚴重的bug

*注2 Code Freeze：除高優(yōu)先級或特別嚴重的bug外，代碼凍結(jié)不再接受提交

　　WBS

技術(shù) K：相片上傳的界面還沒有搭建好嗎?這部分我們需要先做起來。

前端 J：視覺設(shè)計師沒有完成呢!

視覺 A：我在做相片的展示頁面，還沒有做到相片上傳。

項目各成員對自己需要負責(zé)的任務(wù)粒度細分不到位，每個任務(wù)的交付時間點不夠明確，對任務(wù)之間的依賴關(guān)系也不夠清晰，造成項目推進中的協(xié)作成本提高，項目時間預(yù)估準確率不高，項目控制的風(fēng)險增加;

因此在產(chǎn)品需求文檔確認之后，必須做工作分解 WBS(Work Breakdown Structure)，即把需求分解成較小的、易于管理的工作包。一般的工作包是最小的“可交付成果”。工作包必須詳細到可以對該工作包進行估算(成本和工時)、安排進度、分配負責(zé)人員或組織。

項目經(jīng)理、項目成員和所有參與項目的職能主管都應(yīng)該參與WBS工作，根據(jù)項目規(guī)模情況，可以由項目經(jīng)理或各模塊主策劃來組織。組織方負責(zé)召集有關(guān)人員，集體討論所有項目工作，確定項目工作分解的方式后，各職能方提交各自的WBS，匯總后畫出WBS的層次結(jié)構(gòu)圖。結(jié)構(gòu)圖中應(yīng)包括每個工作包名稱(內(nèi)容定義)、指派人員名稱、所需工時、可能的依賴關(guān)系等;

　WBS的工作包，最終以任務(wù)形式錄入到QA中進行跟蹤管理。

　　WBS的好處：

為資源、成本、進度、質(zhì)量等控制奠定共同基礎(chǔ)，確定項目進度和控制的基準;

為各獨立工作包分派人員，規(guī)定這些人員的相應(yīng)職責(zé)，便于項目職責(zé)的落實和明確劃分;

針對各獨立工作包，進行時間、資源需要量的估算，提高時間、資源估算的準確度，并確定工作順序，提高協(xié)作效率，利于更準確的制定項目進度計劃表;

——————————————————————————————————————————–

　　QA可視化項目管理

技術(shù) K：我完成到圖片分享功能，圖片下載的bug已經(jīng)就提交上來了，但是我現(xiàn)在沒有時間改bug。

測試 F：我已經(jīng)提了一輪的bug了，但是我不知道bug什么修好，然后我可以去復(fù)查。

交互 E：圖片分享功能開發(fā)完成了?可以測試了嗎?

產(chǎn)品經(jīng)理 ：現(xiàn)在大概還有多少P0的bug?zero bug時間節(jié)點是否需要后延?

如果沒有QA，項目的狀況不是對每個項目成員透明化，就會出現(xiàn)以上的各種情況;

QA作為協(xié)同式任務(wù)管理工具，通過對每個任務(wù)的記錄和跟蹤，讓項目成員對整個項目的情況有直觀的了解，項目經(jīng)理可隨時監(jiān)控項目推進中的風(fēng)險是否在可控范圍，并提前快速作出調(diào)整。

不管是前期開發(fā)的工作包還是后期的測試bug，均以任務(wù)的形式錄入在QA里，然后對這個任務(wù)的一些基本屬性做設(shè)置，如：屬于哪個milestone、哪個模塊等，然后由各個階段的Triage的負責(zé)人按照需求等級標準來對任務(wù)作分類定級，并確定是否做，是否現(xiàn)在做;所有的任務(wù)都必須經(jīng)過Triage并approve通過，才能開始工作。Triage的決策需要多個層面的知識(結(jié)合產(chǎn)品、技術(shù)、進度等多方因素)，特別是在大項目中，Triage往往是一項群體工作，以功能小組(feature team)或產(chǎn)品決策組的方式來進行。在項目的不同階段，可以由不同的角色來主導(dǎo)Triage流程。

在任務(wù)approve后，各職能方leader將任務(wù)指派給相應(yīng)具體執(zhí)行的人員。執(zhí)行人員，也就是任務(wù)的owner，必須設(shè)置任務(wù)的Status date，如：Status任務(wù)狀態(tài)是Working(進行中);Status date即完成日期點，Status date應(yīng)真實反映實際工作計劃，并應(yīng)契合項目時間表。

在執(zhí)行人員完成任務(wù)時，QA會通知各職能方leader去關(guān)閉這個任務(wù)，關(guān)閉的意義在于通知任務(wù)的相關(guān)跟蹤者，可以著手下一部分的工作，如某功能代碼任務(wù)關(guān)閉，即相關(guān)測試人員就知道可以開始這個功能點的測試工作;

通過任務(wù)在QA系統(tǒng)里的記錄和跟蹤，以及任務(wù)狀態(tài)的實時更新，最終會匯總生成各種可視化的圖表，項目進展直觀，且可度量，能夠很好的把握整個項目推進的節(jié)奏，對項目中各項問題和風(fēng)險定位更容易，并可在周會上對項目的所有成員公開進度信息，便于協(xié)調(diào)一致;

　　其中最重要的圖表：glide path任務(wù)走勢圖：