第二部分做最細緻的專案跟蹤
專案計畫告訴了我們要如何去完成專案，但是專案計畫的執行並非總能夠沿著預定的軌道前進。可以肯定地說，如果沒有健全的反饋機制，計畫的執行定然會偏離預定的軌道，而唯一能夠確避免的措施就——追求專案計畫執行中最細緻的專案跟蹤，在計畫的執行稍有偏離的時候就糾正其方向，這在控制理論中，就是基於反饋的控制。
巨集觀上來說，重型專案管理方法往往傾向於花更多的時間來作乙個細緻的專案計畫，以確保後期計畫執行的可控。但是，細緻的計畫並不能替代細緻的跟蹤。
1.1. 細化任務
現代控制理論告訴我們，控制的精確程度是建立在被控制量量化的粒度之上。量化得越細，就能夠控制得越精確。因為在很少偏移量的時候這種趨勢就得以糾正。
但是量化並非沒有代價，過細的量化會增加成本，所以這之間存在乙個權衡。
敏捷的專案管理要能做到隨機應變，應付各種可能出現的情況，也是建立在對任務的細分，並對任務的狀態採取高頻度的探測並及時調整的基礎上。那麼任務究竟要細分到什麼程度呢？這並沒有確定的度量。
不同規模的專案可能都存在不同，但是我的經驗告訴你，如果可以的話，讓你的任務的工作量盡可能控制在一天以內。
1.2. 控制任務的粒度
專案計畫的失控往往都是由於專案任務劃分不夠清晰，粒度過大引起的，我想這是我和很多軟體從業者的深刻體會。
當然，乙個常見的反駁意見是「不是我們不想細化任務，而是專案剛開始，很多東西都很模糊，無法把任務劃分得很細」。其實這句話中存在兩點誤解，我想從正面來說明：
第一， 任務劃分與產品的解析度是無關的。
這裡，我杜撰了乙個詞語「產品的解析度」，用來表達對產品的了解程度。的確，我們對乙個產品了解得越多、越細，就越可以把如何完成這個產品的工作任務劃分得更加精細。但是反過來，即使乙個產品初期對我們來說是模糊的，難道我們的任務就不可以劃分得很細嗎？
其實照樣可以。產品從模糊到清晰的過程也是問題分解的過程，每個大問題都可以分解為許多子問題，而對於每乙個子問題，其實完全可以對應到相應的子任務。即使我們以「盲人摸象 」為比喻，要搞清楚大象是什麼，也總可以分解為按照頭部，身體，四肢，尾巴幾個部分分別摸來細分任務。
第二， 任務劃分包含解決問題的思路
所謂任務，都是為了解決某個具體問題，而如何解決這個問題，從邏輯上我們首先需要把問題分解。問題分解的過程就可以對應到任務劃分的過程。比如：
如何完成專案目標這個大問題就可以分解為 「如何完成需求定義？」，「如何完成系統設計？」，「如何實現？
」，「如何保證質量？」等子問題，而這些子問題又可以進一步細分。那麼問題被分解清楚了，任務也就清楚了。
說到任務的粒度，現實中常看到過於粗陋的做法，比如專案任務分配表一般基於功能模組，最多也就劃分到子功能。但是如果單單把這個子功能的實現指派給開發人員，你期望能夠在任務指派的第二天了解到什麼進度呢？
任務的粒度要逐步細化，這是建立細緻跟蹤的必要條件。建議把任務的粒度控制在一天以內。
1.3. 誰來劃分任務？
任務的細分並不容易，因為這種細分反應了對求解問題的逐步邏輯分解。所以，劃分任務的人必須是對任務真正了解的人，強調這一點非常重要。
我們常見的錯誤就是認為專案經理既然是乙個專案組的頭，工作任務理應由他來進行分配和監控。但是，實際上，我們看到了這種方式帶來問題：「專案經理並不了解專案工作的細節！
」，「如果專案經理並不了解工作的細節，那麼專案任務又如何能夠細分呢？」。
問題來了，「那麼你告訴我誰應該劃分任務？」，我的答案是：設計師、開發人員等等所有做具體活的主角們。
沒有人比設計師更清楚這個系統具體包括哪些功能模組，每個模組又分成了哪些類和類方法，每個方法的難易程度以及需要消耗的工作時間。沒有人比開發人員更清楚還有多少方法目前沒有完全實現，還有多少bug等待自己去fix，以及完成這些任務所需要的時間。ok，既然他們最清楚，就理應由他們劃分工作任務。
因為只有符合實際的任務被劃分出來了，我們的跟蹤和控制才能施加在點子上。
問題又來了，「要是他們故意簡化任務呢？」。首先，要批評這種懷疑。
團隊的成員應該相互信任而不是相互堤防，這樣團隊才能齊心協力走向成功。其次，我告訴你這也是有方法做到的。我們的產品最終要以能夠符合需求定義為完成準則，如果以需求定義的清單去檢查這些任務的完成，自然就知道每個任務是否在為完成需求定義的產品真正做貢獻。
案例： 在milkyway專案中，專案經理cobo決定讓設計師和開發人員共同來完成各自的任務列表清單。首先是設計師根據需求定義清單列出了自己的設計任務清單，並把該清單給需求人員審核，以便及時發現是否漏掉了某些工作。
同樣，開發人員在明確自己的工作範圍並理解設計後，也開出了乙份任務列表清單，同樣該任務列表也必須通過設計師過目，以便及時發現實現能否覆蓋設計。經過上述確認後，cobo感覺任務列表還是非常明細、豐富而且真實的，即使存在微小的誤差，也很容易調整過來。
1.4. 決定任務的優先順序
在討論這個問題前，我給乙個實際的案例：
案例： 測試部昨天給jack提交了20個bug，jack初初看了一下，這些bug可以分為三類：
第一類是中斷性錯誤，即測試人員在測試中被各種原因所中斷，比如丟擲異常、無響應，無故退出等等，導致無法繼續測試下去。
第二類是介面錯誤，由於無法正確獲得使用者的資訊，很多模組都無法正常顯示表單建立人。
第三類是程式內部的驗證邏輯錯誤，比如儲存時那些非必錄項被報告必須錄入。
除了修復bug，jack今天還打算向負責控制項開發的daniel寫封電子郵件以明確乙個自己的乙個新需求。因為jack發現自己的使用者管理介面左邊的那顆使用者樹可能需要乙個通過鍵盤可以快速定位的功能。
當然，上週專案例會上專案經理對單元測試進行走查提出的幾個**問題也需要盡快修改，專案經理已經安排了明天進行複查。
平常jack還是工作蠻高效的，可是現在事情一多，jack就不知道自己該優先處理那些任務了。
其實專案中的任務總會多於你的精力和資源。那麼怎樣完成任務才能把你帶向成功呢？的答案就是總是把你手上的任務細分，並排定任務的優先順序。
什麼決定任務的優先順序？
在你的手上，可能有很多任務，究竟什麼任務是應該優先處理的呢？這是乙個普遍的問題。這個問題沒有標準答案，但是存在一些判斷的原則，只要你掌握這些原則，並且真實地用到你的專案中去，你就會成為乙個高效能人人士。
傳統專案管理中經常應用「重要且緊急，重要但不緊急，不重要但緊急，不重要也不緊急」「四象限原則」來指導個人對事情的處理優先判斷準則，但是這比較空洞，具體到軟體專案任務，可以參照如下一些判斷準則：
原則1：如果這個任務完成起來非常輕鬆，所消耗的資源和時間都很少，那麼它的優先順序要比那些複雜難辦的任務要高。
這個原則其實體現了一種「心理戰術」，任務不管大小，完成了總會有或多或少的成就感。這就跟考試答題一樣，先易後難往往可以在心理上幫助自己逐步取得勝利的信心。
原則2：如果這個任務的完成可以使一批任務告一段落，從而取得階段性的成果，那麼它的優先順序要比其他的高。
無論是你自己還是你的領導，都渴望聽到成功的訊息。優先完成乙個任務如果可以把一批任務的狀態改為「ok」，這將能鼓舞士氣。對於軟體專案，士氣無疑是許多事情成功的必要條件。
原則3：如果這個任務是否能夠完成，將直接或者間接影響團隊中其他人的任務完成，那麼這個任務的優先順序要高。
軟體專案的成功必定是整個團隊共同努力的成功。優先完成被依賴項，可以讓整個團隊並行工作，從而在整體上取得更好的進度。
原則4：如果你的上司更在意你這個任務的完成，那麼這個任務的優先順序要高。
幫助專案成功也要幫助自己成功。而幫助自己成功了，你的信心、能力也將必然有助於專案的成功。
1.5. 對每個任務進行預期和反查
任務在分配的同時，或者稍後一段時間，應該給出這個任務完成時間的預期。對於專案成員來說，儘管一開始，要準確預期任務的完成時間非常困難，但是從實踐中我們看到，只要整個團隊的每個成員都堅持這樣做，日久形成了習慣，那麼整個專案的任務看起來將比不這樣做明朗許多。
軟體開發的最大特點就是非常依賴於成員的工作狀態和成員之間的溝通和協調。對任務保持預期的習慣，有利於使整個專案的工作量和工作進度在整個團隊保持透明，這是充分調動每個人的積極性，保證整個團隊力往一處使的關鍵。
誰給任務做預期？
我一直相信，最了解任務的往往是親歷親為的設計人員和開發人員，那麼任務完成的預期也理應由他們自己給出。我堅信在團隊內豎立誠信跟做買賣一樣重要，儘管「大膽去相信你的下屬吧」，讓他們自己決定自己的任務什麼時候完成。決定好後，你就只管根據他計畫的時間來跟蹤即可。
其實你沒有理由相信你的下屬會故意拖延任務的完成時間。因為聰明的下屬往往總想超乎你的預期去完成任務，以取你的欣賞。只有傻瓜才會故意把自己的任務完成時間做不符合邏輯的拖延。
讓專案成員自己給出任務預期，體現了領導者的充分信任。這種信任其實會成為一種無形的壓力。「領導都讓我自己預期任務什麼時候完成了，如果我到時候沒有完成，如何解釋得過去？」。
每日review
通過任務預期，管理者和下屬之間其實達成了某種時間契約。作為下屬，唯一的想法就是按時或者提前完成自己預期的任務。對於管理者，也要重視這個契約，需要積極、按時、細緻地去review任務的完成狀況。
敏捷的專案管理由於把任務的粒度細分到天，那麼每天都理應對預計完成的任務進行review。review的好處是可以以天為單元控制專案進度的誤差，同時讓整個團隊保持知己知彼的良好溝通狀態。
是不是需要時才做review呢？我的建議是最好確定一固定時間來對專案狀態進行review。固定時間，有利於整個團隊形成良好的時間觀念，這一點非常重要。
什麼時候review
review在什麼時候開始呢？這裡面也有學問。我的乙個同事yew曾經建議安排在每天早上上班後半小時，並給出了下面的原因：
1. 促使專案成員不遲到
2. 讓專案成員在一天的開始即進入緊張的工作狀態
3. 強調每個人當前的任務，幫助專案成員明確當天工作目標
4. 給專案成員預留了晚上作為按時完成任務的buffer
每日晨會
乙個非常有效的review制度就是每日晨會。在每日晨會上，專案各成員可以匯報自己的專案進度，工作中所遇到的問題、需要協調的事項等，而專案經理可以檢查工作進展，布置新的工作任務和傳達上面新的指示和動態。作為乙個團隊，讓每個成員對專案達成一致的認識，尤其是風險認識是極其必要的。
晨會的技巧
我想不會有人懷疑晨會帶來的好處，但是會有很多人懷疑這樣做是否太浪費時間，得不償失。這裡就涉及到乙個晨會的技巧。
軟體專案管理在高校軟體開發中的應用
作者 林琳周躍飛 矽谷 2008年第18期 摘要 不少高校在做軟體研發時，尤其是自用軟體，重點更集中於科技創新，而對於在軟體專案小組中引入專案管理的認知度還未達成共識。以中國民航飛行學院廣漢分院飛行教學管理管理資源網的研發為例，簡要闡述專案管理在高校軟體開發中具體應用。關鍵詞 專案管理專案經理需求規...
軟體開發專案中的質量管理研究
作者 錢潔萍 科技創新導報 2012年第11期 摘要 隨著知識經濟時代的到來,整個社會的高效運作對計算機軟體產品的依賴程度越來越高,軟體質量以及軟體質量管理日益成為人們關注的焦點,對軟體的開發過程進行質量管理是解決軟體質量問題的重要方法。本文詳細介紹了軟體質量的概念 軟體質量工程體系的思想和內容 軟...
基於軟體開發過程的專案管理
摘要 本文分析了基於軟體開發過程中對專案管理過程的詳細描述。關鍵詞 軟體開發過程 專案管理 隨著資訊科技的快速發展，應用軟體的功能越來越龐大，為了便於管理，把專案管理的方法引入到軟體開發過程當中，對所有的軟體活動進行有效的管理。本文按照傳統的瀑布模型從專案管理九大知識領域的角度，進行軟體管理專案的工...