“1人100個(gè)月完成的項(xiàng)目，不是100個(gè)人1個(gè)月就可以完成。”
項(xiàng)目管理是讓項(xiàng)目活動(dòng)中相互競爭的各類制約因素：質(zhì)量、進(jìn)度、資源、風(fēng)險(xiǎn)等取得平衡的藝術(shù)，同時(shí)也是平衡項(xiàng)目干系人的各種需要、關(guān)注和期望，帶領(lǐng)不同的人朝著相同目標(biāo)邁進(jìn)的領(lǐng)導(dǎo)藝術(shù)。
成功的項(xiàng)目管理可以簡單理解為：按時(shí)、在預(yù)算內(nèi)+滿足產(chǎn)品需求+滿足質(zhì)量需求 地完成項(xiàng)目。
以下是我對項(xiàng)目管理的一點(diǎn)體會(huì)記錄。
需求等級(jí)
視覺 A：圖片沒有分享功能嗎？
技術(shù) K：圖片有鏈接轉(zhuǎn)發(fā)分享、微博或郵件形式分享等多種分享，全部開發(fā)的話需要推延時(shí)間表。
策劃 D：圖片只做預(yù)覽、下載已經(jīng)足夠了，暫時(shí)不做分享。
交互 E：如果我們的用戶是基于郵箱用戶，圖片的郵件分享還是建議做。
… …
如果在前期產(chǎn)品需求文檔中沒有明確定義每個(gè)需求的優(yōu)先等級(jí)，或者說項(xiàng)目成員對需求的優(yōu)先等級(jí)沒有明確的意識(shí)，可能類似的爭論會(huì)時(shí)常發(fā)生在項(xiàng)目成員之間，每個(gè)人會(huì)基于自己對產(chǎn)品目標(biāo)的理解來考慮這個(gè)需求是否要做，什么時(shí)候做，做到什么程度而產(chǎn)生分歧，因而增加項(xiàng)目推進(jìn)的阻力。
所以在前期產(chǎn)品需求文檔中，必須明確定義出每個(gè)需求的優(yōu)先等級(jí)，需求的粒度可細(xì)化到每個(gè)大功能下的子功能需求，如：圖片分享功能的轉(zhuǎn)發(fā)鏈接分享、郵件形式分享這樣的子功能需求。等級(jí)的劃分依賴于前期的用戶需求調(diào)研、產(chǎn)品的預(yù)定目標(biāo)、開發(fā)成本、運(yùn)營計(jì)劃等；
一般的需求等級(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)品沒有明顯的好處，用戶不在意
… …
每個(gè)需求的優(yōu)先等級(jí)確定之后，產(chǎn)品經(jīng)理根據(jù)產(chǎn)品預(yù)定目標(biāo)、開發(fā)成本、運(yùn)營計(jì)劃等來定義一個(gè)等級(jí)分界線，高于或等于這個(gè)等級(jí)分界線的需求在本期開發(fā)，部分根據(jù)成本、運(yùn)營計(jì)劃等因素調(diào)整到下期開發(fā)，而低于這個(gè)等級(jí)分界線的需求則只會(huì)在下期開發(fā)，這樣讓全體項(xiàng)目成員對本期要做的需求達(dá)成共識(shí)。
需求等級(jí)的實(shí)際應(yīng)用：
WBS各工作包Triage的參考基準(zhǔn)之一；Triage即確定需求任務(wù)是否要做，是否要現(xiàn)在做的一個(gè)共同決策過程；在Triage的過程中，任務(wù)owner對自己的任務(wù)以及其他人的任務(wù)有更全局的認(rèn)識(shí)。
Bug的Triage的參考標(biāo)準(zhǔn)參考基準(zhǔn)之一（也是zero bug *注1 和code freeze *注2 時(shí)間節(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)先級(jí)或特別嚴(yán)重的bug
*注2 Code Freeze：除高優(yōu)先級(jí)或特別嚴(yán)重的bug外，代碼凍結(jié)不再接受提交
WBS
技術(shù) K：相片上傳的界面還沒有搭建好嗎？這部分我們需要先做起來。
前端 J：視覺設(shè)計(jì)師沒有完成呢！
視覺 A：我在做相片的展示頁面，還沒有做到相片上傳。
… …
項(xiàng)目各成員對自己需要負(fù)責(zé)的任務(wù)粒度細(xì)分不到位，每個(gè)任務(wù)的交付時(shí)間點(diǎn)不夠明確，對任務(wù)之間的依賴關(guān)系也不夠清晰，造成項(xiàng)目推進(jìn)中的協(xié)作成本提高，項(xiàng)目時(shí)間預(yù)估準(zhǔn)確率不高，項(xiàng)目控制的風(fēng)險(xiǎn)增加；
因此在產(chǎn)品需求文檔確認(rèn)之后，必須做工作分解 WBS（Work Breakdown Structure），即把需求分解成較小的、易于管理的工作包。一般的工作包是最小的“可交付成果”。工作包必須詳細(xì)到可以對該工作包進(jìn)行估算（成本和工時(shí)）、安排進(jìn)度、分配負(fù)責(zé)人員或組織。
項(xiàng)目經(jīng)理、項(xiàng)目成員和所有參與項(xiàng)目的職能主管都應(yīng)該參與WBS工作，根據(jù)項(xiàng)目規(guī)模情況，可以由項(xiàng)目經(jīng)理或各模塊主策劃來組織。組織方負(fù)責(zé)召集有關(guān)人員，集體討論所有項(xiàng)目工作，確定項(xiàng)目工作分解的方式后，各職能方提交各自的WBS，匯總后畫出WBS的層次結(jié)構(gòu)圖。結(jié)構(gòu)圖中應(yīng)包括每個(gè)工作包名稱（內(nèi)容定義）、指派人員名稱、所需工時(shí)、可能的依賴關(guān)系等；
WBS的工作包，最終以任務(wù)形式錄入到QA中進(jìn)行跟蹤管理。
WBS的好處：
為資源、成本、進(jìn)度、質(zhì)量等控制奠定共同基礎(chǔ)，確定項(xiàng)目進(jìn)度和控制的基準(zhǔn)；
為各獨(dú)立工作包分派人員，規(guī)定這些人員的相應(yīng)職責(zé)，便于項(xiàng)目職責(zé)的落實(shí)和明確劃分；
針對各獨(dú)立工作包，進(jìn)行時(shí)間、資源需要量的估算，提高時(shí)間、資源估算的準(zhǔn)確度，并確定工作順序，提高協(xié)作效率，利于更準(zhǔn)確的制定項(xiàng)目進(jìn)度計(jì)劃表；
QA可視化項(xiàng)目管理
技術(shù) K：我完成到圖片分享功能，圖片下載的bug已經(jīng)就提交上來了，但是我現(xiàn)在沒有時(shí)間改bug。
測試 F：我已經(jīng)提了一輪的bug了，但是我不知道bug什么修好，然后我可以去復(fù)查。
交互 E：圖片分享功能開發(fā)完成了？可以測試了嗎？
產(chǎn)品經(jīng)理 ：現(xiàn)在大概還有多少P0的bug？zero bug時(shí)間節(jié)點(diǎn)是否需要后延？
… …
如果沒有QA，項(xiàng)目的狀況不是對每個(gè)項(xiàng)目成員透明化，就會(huì)出現(xiàn)以上的各種情況；
QA作為協(xié)同式任務(wù)管理工具，通過對每個(gè)任務(wù)的記錄和跟蹤，讓項(xiàng)目成員對整個(gè)項(xiàng)目的情況有直觀的了解，項(xiàng)目經(jīng)理可隨時(shí)監(jiān)控項(xiàng)目推進(jìn)中的風(fēng)險(xiǎn)是否在可控范圍，并提前快速作出調(diào)整。
不管是前期開發(fā)的工作包還是后期的測試bug，均以任務(wù)的形式錄入在QA里，然后對這個(gè)任務(wù)的一些基本屬性做設(shè)置，如：屬于哪個(gè)milestone、哪個(gè)模塊等，然后由各個(gè)階段的Triage的負(fù)責(zé)人按照需求等級(jí)標(biāo)準(zhǔn)來對任務(wù)作分類定級(jí)，并確定是否做，是否現(xiàn)在做；所有的任務(wù)都必須經(jīng)過Triage并approve通過，才能開始工作。Triage的決策需要多個(gè)層面的知識(shí)（結(jié)合產(chǎn)品、技術(shù)、進(jìn)度等多方因素），特別是在大項(xiàng)目中，Triage往往是一項(xiàng)群體工作，以功能小組（feature team）或產(chǎn)品決策組的方式來進(jìn)行。在項(xiàng)目的不同階段，可以由不同的角色來主導(dǎo)Triage流程。
在任務(wù)approve后，各職能方leader將任務(wù)指派給相應(yīng)具體執(zhí)行的人員。執(zhí)行人員，也就是任務(wù)的owner，必須設(shè)置任務(wù)的Status date，如：Status任務(wù)狀態(tài)是Working（進(jìn)行中）；Status date即完成日期點(diǎn)，Status date應(yīng)真實(shí)反映實(shí)際工作計(jì)劃，并應(yīng)契合項(xiàng)目時(shí)間表。
在執(zhí)行人員完成任務(wù)時(shí)，QA會(huì)通知各職能方leader去關(guān)閉這個(gè)任務(wù)，關(guān)閉的意義在于通知任務(wù)的相關(guān)跟蹤者，可以著手下一部分的工作，如某功能代碼任務(wù)關(guān)閉，即相關(guān)測試人員就知道可以開始這個(gè)功能點(diǎn)的測試工作；
通過任務(wù)在QA系統(tǒng)里的記錄和跟蹤，以及任務(wù)狀態(tài)的實(shí)時(shí)更新，最終會(huì)匯總生成各種可視化的圖表，項(xiàng)目進(jìn)展直觀，且可度量，能夠很好的把握整個(gè)項(xiàng)目推進(jìn)的節(jié)奏，對項(xiàng)目中各項(xiàng)問題和風(fēng)險(xiǎn)定位更容易，并可在周會(huì)上對項(xiàng)目的所有成員公開進(jìn)度信息，便于協(xié)調(diào)一致；
其中最重要的圖表：glide path任務(wù)走勢圖：
“實(shí)際任務(wù)走勢”與“計(jì)劃任務(wù)走勢”的對比，可以衡量出計(jì)劃與實(shí)際的偏差。
每日構(gòu)建
技術(shù) K：我們只在每個(gè)小milestone才會(huì)打build。
交互 E：希望可以每日bulid，我可以每天拿到最新的版本進(jìn)行測試。
測試 Q：我建議測試前期可以每個(gè)milestoen打版本，但是中期開始，每日build。
… …
每日構(gòu)建（daily build）是指每天對整個(gè)項(xiàng)目做一次完整的自動(dòng)構(gòu)建，生成可執(zhí)行文件的過程，對Web類產(chǎn)品，每日構(gòu)建通常要伴隨自動(dòng)部署的過程，將這些可執(zhí)行文件部署至測試環(huán)境，并按照一定的規(guī)則對這個(gè)安裝包或測試環(huán)境做版本編號(hào)，是一種Public build的管理方式。
每日構(gòu)建是編譯管理的一種方式，項(xiàng)目初期，可根據(jù)根據(jù)需要按照一定的頻率打，如：每周、每個(gè)milestone，隨著項(xiàng)目的進(jìn)行頻率逐漸增加build的頻率，如：每天build。
每日構(gòu)建的好處：
每日構(gòu)建讓從產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、策劃、交互、視覺等所有的項(xiàng)目人員從第一個(gè)小功能模塊完成開始，能夠隨時(shí)測試最新的版本提交bug，并能及時(shí)了解技術(shù)開發(fā)的進(jìn)度；
每日構(gòu)建讓測試人員從第一個(gè)小功能模塊完成開始，能夠每天測試最新的版本，提交新bug和復(fù)查部分bug，而不需要等著某個(gè)小milestone或者所有的功能代碼都實(shí)現(xiàn)了，再開始測試，大大增加了測試和開發(fā)的重疊時(shí)間，測試更充分，測試和開發(fā)的迭代效率更高，產(chǎn)品質(zhì)量控制得更好；而且bug提交到qa上，也會(huì)一并附上build版本號(hào)，方便技術(shù)還原現(xiàn)場，更快地解決bug；
每日構(gòu)建使得技術(shù)必須對每天自己輸出的代碼負(fù)責(zé)，一旦每日build失敗，必須檢查原因，并糾正不可再犯，以避免再次build失敗，這樣能非常有效地提高所提交代碼的質(zhì)量，減少bug的產(chǎn)生，加快開發(fā)效率；
雖然搭建并維護(hù)daily build，需要比較大的工作量，但絕對物有所值。
.