進度安排與跟進經驗和提議

1.       進度安排

以本次XX平台項目為例，3月6日從校方傳回深圳後，已經整理好了客戶的需求清單，但需要細化，并且産品人員還要按照産品更新的計劃加入一些額外需求進來，如加強使用者體驗與UI效果改進等。項目的開始階段是艱難的，進度安排遇到的主要問題如下：

l  需求仍未得到校方的簽字确認，而産品人員加入産品更新的需求進一步擴散了項目範圍

l  立項難，通常需求要非常明确、計劃安排也精确的情況下才立項（由于績效等各類因素的影響），這段期間通常較長（該期間進展緩慢），對于項目周期本身隻有1～2個月的項目來說會拖延時間，開銷較大

l  由于急于給使用者計劃和報告進度把時間定為4月中旬（客戶當時提到4月初），當時未考慮産品更新方面需求的情況下做出的，存在無法兌現承諾的風險。

經過分析與溝通，發現部分需求分三部分：

l  是比較明确了可以簡單溝通後立即進入開發，如某些顯示、BUG等修改方比較固定

l  而另一些需求可能存在較為複雜的設計，如學期的支援，這一塊涉及到非常多的相關聯資料，需求與産品一起設計出方案與校方溝通确認後才能明确，這部分僅給出大概的工作量估算；

l  還有一些的産品更新自發提出的需求，由于已承諾了傳遞日期這部分按照優先級不保證全部完成；

精确的安排所有工作，工作量大，且在日後很大機率出現偏差及修改，分析以上情況後，按照明确的需求快速地制訂本周和下周的工作計劃，而較遠日期隻在較高層次（或較粗子產品）做大概的估算，即采用“滾動式”日程安排。“一波還未平息，一波又來侵襲”，在整理産品提出的需求過程中，發現同一個需求點的幾個子需求分散到不同的需求項中，這時日程活動需要将相關的需求點進行整理，容易漏掉某些需求點，測試用例也将很分散。立即與産品溝通，需求的整理做好“高内聚”工作，把相關的功能盡可能的歸到一起，友善與日程活動一緻，如一個選課相關的方式變化、查詢選項增加、UI修改三項工作關聯度高應歸為一個需求或一個需求下的幾個子需求。另外我也提議立項可以依據情況盡早進行（立項後将被關注接收更多監控），而立項可以不要求給出精确的每個階段時間範圍，簡化後續變更過程，鼓勵主動承認延期責任者。

2.       進度跟進

好的日程安排如果沒有跟進執行，也是“空中樓閣”，是以必須實際落地做實。目前情況是：

l  有人員将要離職，意味着工作狀态可能存在不能完全投入風險，另外還存在很多交接工作和其它潛在的影響

l  有2位新進入員工，他們需要融入到團隊中，熟悉業務、開發架構等，有一段“震蕩期”

l  每個員工的工作積極性、責任心、技術水準存在較大差異

l  工作過程中涉及到的互動多，如一個需求開發可能需要WEB前端、UI、UED的配合

征對以上情況，首先采用了證明較有效的方式是每日5分鐘左右非正式的讨論晨會，簡單地報告和讨論進展與遇到的問題，既能加強成員的參入度，對進度不正常的組員無形中施加了潛在的緊迫感（如某個員工報告工作未完成而其他成員進度正常時），對正常的進行表揚等。

另外更重要的是單獨的跟進工作，通常會采用樂觀與悲觀兩種政策(McGregor的Y理論和X理論)，如果該組員積極、責任感強、善于溝通與回報則會采用樂觀的态度充分的發揮該組員的成就感，較少的幹涉，甚至接給他一些較多協調處理的任務，更多的讓他發揮，對其進度也認為是樂觀的，進而可從中節省時間處理薄弱環節；而對于新進入員工作、态度消極、有問題少回報、有關鍵性技術問題等情況下則将重點跟蹤，包含詳細代碼走查、實作思路指導、更詳細的日程計劃、更頻繁的檢查等。

3.       進度安排CMMI流程、文檔提議

有關CMMI流程和文檔，可能了解不夠的原因，僅以清單方式提出困惑和我個人認為較好的一個參考提議

困惑	參考提議
部分文檔實際作用小（僅個人認為），編寫維護工作量大；部分文檔存在事後“趕出來”或者大量拷貝其它文檔，基本隻起應付檢查作用，對于過程型文檔幾乎無實際意義，有些内容不具備後續實際參考作用	盡可能減少不必要的文檔，過程性文檔（如工作量估算、日程安排、工作周報、會議紀要）等應在項目過程使用階段檢查；驗收時重點關注項目結束後仍需使用的文檔；注重内容本身抽查，而非形式（如需求編号、文檔編号、作者與審批者等）檢查，不應過度注重“招式”
文檔結構目錄太深，找文檔時目錄層次太多，不易查找，如日程表經常會檢視更新，在第四層檔案夾中	路徑偏平化，第一級目錄檔案目錄要增多，應基本包要在第二級時出現所有常用文檔，尤其是高頻率使用的文檔甚至可直接放在一級目錄
部分文檔模闆設計不合理 l  需求文檔中不應過度注重資料字段清單 l  項目周報不應重複錄入日期資訊，如檔案按日期項目命名則不用再錄入日期和項目名稱 l  很多文檔都要重複項目階段時間範圍	盡可能精簡實用