“1人100個月完成的項(xiàng)目，不是100個人1個月就可以完成。”

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

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

以下是我對項(xiàng)目管理的一點(diǎn)體會記錄。

需求等級

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

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

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

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

… …

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

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

一般的需求等級劃分：

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

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

P2 -Nice to have：做了則更好

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

… …

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

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

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

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

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

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

WBS

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

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

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

… …

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

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

標(biāo)簽： 項(xiàng)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。