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