問：老師，我們現在功能點、里程碑、優先級、功能點詳細描述、界面原型、數據庫結構、數據操作描述都做好了，那麼我們是否下一步就開始編碼了？
答：不。你們還需要工具。
你的軟件質量不行，銷售部一演示就報錯，實施部讓客戶用不起來，客服部整天接到客戶的電話，那麼公司的成本必須很高，當然老闆就很生氣。所以質量高了以後的運營成本就低了。
你的進度無法保證，老闆問你現在幹到了什麼階段，現在每個人正在做什麼，每個人的工作量多大，誰的工作質量不高，你是否能順暢的說出來？
所以，你需要一個需求與BUG管理工具。
BUG，是需要修復的任務。而沒有做完的功能，也是需要完成的任務。所以BUG和需求都是任務。而程序員要做的，就是完成這個任務。
誰做什麼功能？任務要求的時間是多長？他實際做了多長？他超出計劃時間或縮短了計劃時間，還剩多少任務，這些任務還需要多少天，餘下的任務該如何做，是改裁減還是乾脆不做？因爲一個系統的功能往往是關聯的，獨立互不干擾的功能不太多，那麼他超出計劃時間或縮短了計劃時間，其他業務小組該怎麼辦？如果在開發過程中需求有變動，程序員該怎麼辦？
很多很多的問題需要解決。所以我在講《業務開發小組》的時候就講到，不要讓業務組長開發程序。因爲有許多問題需要他來解決來協調來思考很細的細節。
有了需求與BUG管理工具，誰這個星期要幹什麼？他還有多少任務在身上？每個任務現在進展到什麼程度了？現在還有多少個BUG需要他解決？他寫出的功能的BUG比率是多少？他在一個月內完成的功能有多少？寫了多少行代碼？他有多少任務超期了？有多少任務中途變化需求了？
關於種種管理上要求量化的數據，我們都能很容易的統計到。對於我們控制質量、控制進度有非常好的幫助。
當然，有些團隊過去很不正規，現在應用了這種方法，每一個環節都是新的，所以感覺很陌生很茫然，還不如過去那樣省勁爽快。現在再讓學習一種新的工具，更是繁瑣。
所以，我們管理變革，一點點變革，覺得自己團隊什麼能首先做到，那麼就去做這一點。如果工具大家抵觸，我們可以先用EXCEL，也用WORD。直到大家都順暢了，都覺得用EXCEL和WORD麻煩了，再用工具。如果EXCEL和WORD就能適合本團隊，那麼幹嘛要換呢？我們是爲了拿工具達到我們的目標，用工具是我們的手段，不是必需。