項目管理之如何控制項目進度和質量

　　控制項目進度和質量首先在總體上要有一個合理清晰的流程，而且在整個管理過程當中，嚴格按照流程走。流程的每一步若是都控制好了，那麼整個項目管理就不會出大問題。

　　下圖是咱們全部項目應該嚴格遵照的流程。

　  流程-需求

　　需求是整個流程的入口。一般需求從客戶那裏來，而客戶一般不是那麼專業，客戶發過來的需求可能很零散，甚至可能不合理，這時，項目經理須要對需求進行整理，而且屢次不斷跟客戶溝通，保證正確理解了需求。

　　一個項目的需求入口必須只能是一我的——項目經理。相信不少項目都遇到過這種狀況，客戶好像跟有的開發人員很熟悉，有時候客戶會把需求告訴開發人員，開發人員就本身作了，結果項目經理不知道。這就會出很大的問題。因此，無論來自內部仍是外部的需求，全部的需求都只能通過項目經理。

　　流程-原型

　　原型用axure畫，不論是web、desktop仍是APP，都用axure畫。目前爲止沒有比axure更強大的原型工具。

　　在咱們的經驗中，導出成網站的原型，能夠做爲需求管理很重要的一部分。因此，每一次需求的變動都應該首先體現到原型中，原型必定要一直維護下去。

　　畫原型的一個最最重要的經驗就是，要把全部的UI都體現出來。包括哪些呢？各類狀態下的界面，全部的錯誤或者提示，也就是說凡是最終用戶看得見的東西，所有要體如今原型中。

　　因爲原型自己仍是需求管理系統的一部分，因此，原型頁面上也能夠放一些業務邏輯說明，特別是頁面跳轉等。還有一些隱藏的業務邏輯也能夠在原型頁面上寫出來。

　　流程-UI設計

　　原型作好了以後，就可讓UI團隊開始基於原型作設計了。設計作好了就切圖。設計團隊的產出物爲設計源文件、效果圖和切圖。放到SVN裏面供開發人員使用。

　　流程-測試用例

　　原型作好了以後，測試團隊就能夠基於原型寫測試用例了。若是沒有測試團隊，這一步也可省去。

　　流程-任務系統

　　這一步是很是關鍵的，其中最重要的工做就是功能評估。功能評估建議用Xmind軟件來作，評估好了再錄入到咱們的任務系統。參考：

　　若是項目經理不是項目所需技術領域的專家，那麼在評估的時候，叫上技術團隊領頭人一塊兒。可是一個好的項目經理，即便是本身不熟悉的技術領域，本身也應該有一個比較準確的評估。

　　任務評估時間還應該包含開發人員自測的時間。

　　當任務都評估好了，就能夠錄入到咱們的任務系統了。錄入任務系統以後，就是作迭代計劃。

　　在咱們的任務系統中，開發計劃是經過迭代來作的。建議每一週提一個迭代，最多不超過2週一個迭代。開發人員只須要關心當前這一個迭代裏面的全部任務，至於具體先完成哪一個任務，如無特殊要求，都應該讓開發人員自行安排或者項目經理給一些建議。

　　每個迭代要求明確的開始和結束日期。一旦結束日期到，就應該把迭代裏面未完成的任務移到下一個迭代。也就是說，迭代日期到，迭代的進度就是100%。對於有些只完成了一部分的任務，在咱們的任務系統中，要麼你能夠拆分任務把已完成的部分拆分出來，要麼你也能夠把整個任務移到下一個迭代。

　　開發人員完成功能開發以後，首先要通過全面的自測。一個聰明的開發人員應該在自測的時候解決絕大多數BUG。通過自測的產出物應該是具備很高質量的，特別是高質量的UI和UX。自測經過才能提交給測試團隊，或者項目經理。作不到這一點的開發人員應該被淘汰。

　　自測完成以後，填寫工時記錄，將進度標記爲100%，將任務狀態標記爲完成（不是關閉）。

　　流程-測試

　　若是沒有測試團隊，測試就應該由項目經理負責。

　　測試中報的BUG要提交到任務系統。測試人員提交BUG的時候不須要評估時間，而且也不須要指派。項目經理把全部未指派的BUG列出來，而後進行時間評估，而後再指派給某個開發人員。

　　BUG也是屬於迭代的。若是不是那麼緊急的BUG，能夠暫時不安排到迭代裏面，能夠等到最後再去修復BUG。

　　流程-完成

　　測試團隊測試經過，項目經理能夠根據實際狀況看是否須要再檢查一遍。或者檢查的力度到什麼程度，這都由項目經理自行決定。檢查經過，任務狀態標記爲關閉，任務完成。

　　問題 – 團隊間等待

　　開發過程當中，可能各個技術團隊之間的銜接會出現等待。好比客戶端開發的開發人員，在作到某一個功能的時候，結果UI設計或者API尚未準備好，那麼就只能等起。

　　這種銜接等待是沒法避免的，咱們只能儘量下降等待的時間。咱們是這樣解決的：

　　在咱們的任務系統中，咱們會加一個任務標籤，叫「緊急任務」。注意這裏是標籤，不是優先級也不是任務類型。一旦出現這種等待，等待的人就給被等待的人建一個「緊急任務」。若是等待的人沒有新建任務的權限，那麼交給其團隊負責人建立。咱們也建議你把這類任務同時放到一個任務分組裏面，而且加個快速查詢。

　　等待的過程當中，開發人員能夠用假數據或者假UI來代替，等數據或UI準備好後再替換。

　　問題 – 需求變動

　　需求變動是任何開發團隊都沒法避免的問題。咱們要作的就是把需求變動對項目形成的影響儘量降到最低。

　　一般狀況下，只有最緊急的需求纔會放到當前的迭代，不然變動的需求都應該放到之後的迭代。若是放在當前的迭代，那麼就須要把當前迭代中的部分任務移到下一個迭代。而且跟客戶溝通好這個計劃的改變。

　　需求變動時，必定要將需求更新到需求管理系統（原型和任務系統），無論變動的需求形成的工做量有多大。這一點是不少項目忽略的。舉個例子，用戶完成註冊，原本系統送100金幣，某天客戶過來講改爲送200金幣，結果程序員就花了幾分鐘時間將100改爲200了事。過了幾個月，新同事加入項目，看需求系統裏仍是寫的100，就去問項目經理，項目經理就說何時改爲200了。因而這個需求管理系統就再沒有人相信和使用了。因此這一點很是重要。

　　需求變動時，要按照本文開始的流程圖一步一步走，由於是新的需求從流程入口進來了。

　　項目管理中常常還會遇到其餘棘手的問題，擾亂項目計劃，讓項目管理失去了對進度和質量的控制。

　　本文轉載自：http://www.spasvo.com/news/html/2016826135059.html