“1人100個月完成的項目,不是100個人1個月就可以完成。”
項目管理是讓項目活動中相互競爭的各類制約因素:質(zhì)量、進(jìn)度、資源、風(fēng)險等取得平衡的藝術(shù),同時也是平衡項目干系人的各種需要、關(guān)注和期望,帶領(lǐng)不同的人朝著相同目標(biāo)邁進(jìn)的領(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)品目標(biāo)的理解來考慮這個需求是否要做,什么時候做,做到什么程度而產(chǎn)生分歧,因而增加項目推進(jìn)的阻力。
所以在前期產(chǎn)品需求文檔中,必須明確定義出每個需求的優(yōu)先等級,需求的粒度可細(xì)化到每個大功能下的子功能需求,如:圖片分享功能的轉(zhuǎn)發(fā)鏈接分享、郵件形式分享這樣的子功能需求。等級的劃分依賴于前期的用戶需求調(diào)研、產(chǎn)品的預(yù)定目標(biāo)、開發(fā)成本、運營計劃等;
一般的需求等級劃分:
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ā)成本、運營計劃等來定義一個等級分界線,高于或等于這個等級分界線的需求在本期開發(fā),部分根據(jù)成本、運營計劃等因素調(diào)整到下期開發(fā),而低于這個等級分界線的需求則只會在下期開發(fā),這樣讓全體項目成員對本期要做的需求達(dá)成共識。
需求等級的實際應(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é)點計算的參考基準(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é)不再接受提交
出處:163 UED Team
責(zé)任編輯:bluehearts
上一頁 下一頁 關(guān)于項目管理的一點體會 [2]
◎進(jìn)入論壇網(wǎng)站綜合、網(wǎng)頁制作版塊參加討論
|