控制項目進度和質量首先在整體上要有一個合理清晰的流程，並且在整個管理過程中，嚴格按照流程走。流程的每一步如果都控制好了，那么整個項目管理就不會出大問題。
下圖是我們所有項目應該嚴格遵守的流程。
流程-需求
需求是整個流程的入口。通常需求從客戶那里來，而客戶通常不是那么專業，客戶發過來的需求可能很零散，甚至可能不合理，這時，項目經理需要對需求進行整理，並且多次不斷跟客戶溝通，保證正確理解了需求。
一個項目的需求入口必須只能是一個人——項目經理。相信很多項目都遇到過這種情況，客戶好像跟有的開發人員很熟悉，有時候客戶會把需求告訴開發人員，開發人員就自己做了，結果項目經理不知道。這就會出很大的問題。所以，不管來自內部還是外部的需求，所有的需求都只能經過項目經理。
流程-原型
原型用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了。於是這個需求管理系統就再沒有人相信和使用了。所以這一點非常重要。
需求變更時，要按照本文開始的流程圖一步一步走，因為是新的需求從流程入口進來了。
項目管理中經常還會遇到其他棘手的問題，擾亂項目計划，讓項目管理失去了對進度和質量的控制。歡迎大家提出討論。