好早就想開博，可懶啊，拖啦一年後，終於邁出了第一步，鼓勵下自己吧！
新來的總監老M，已經接觸幾天了，做事有一套的，技術出身有說服力，給咱一羣菜鳥不少指導，堅信團隊確實需要經理-導師的角色。
老M組織全員溝通，來推行計劃甘特圖和設計等約束和工具，方便團隊溝通統一語言，我有些小小的困惑，然後再老M溝通了一番。
問題一：甘特圖做計劃是否影響團隊的自發性，可能會3天的事情估個5天完成，給自己留有buffer呢？
- 如果是有deadline的項目來講，那咱得倒推法評估，另外過長的計劃需要適當調整和壓縮時間。
- 甘特圖WBS到細粒度，子任務粒度不能超過3天，這樣大家沒有太多的buffer空間。
- 從管理角度來看，需要跟蹤和反饋，及時調整計劃。
問題二：公司原來是推敏捷的，不強調細緻的計劃，另外有一套JIRA系統是管理項目任務的，和甘特圖就衝突了。
- 敏捷適合互聯網公司的快速迭代，咱做企業級產品允許有規矩按計劃幹活。
- 在不成熟的團隊裏面，應該更重視計劃，否則很多事情都漂起來，無法落實和跟蹤。
- 過程和約束（准入準出條件），有助於團隊培養好的工作習慣。
結論：接下來咱們暫時只局部優化（整體流程不大動），強調計劃（小組和項目）和文檔（產品、設計、測試文檔）。
- 甘特圖只用於小組長做計劃，提高團隊自我管理能力。
- 小組長再將WBS任務錄入到JIRA，因爲JIRA是管理和協作系統，咱還是不能摒棄的。
- 項目人員規劃並部署看板，將任務貼到看板。
- 小組長組織每日站會，每個人發言我昨天做了什麼，今天要做什麼，我有什麼困難和阻礙等。
問題三：數據採集和度量的疑問，以前做過敏捷也做過甘特圖，兩種模式的碰撞已經方向越來越模糊，度量的目標到底是什麼？
- 度量的目的是：通過數據表現來察覺本質的原因並分析分類，爲下個迭代改善提供參考。
- 團隊裏面先做基礎數據的採集，在適當時做數據分析與度量，並且老M會教授我們一些方法。
- 度量可以有計劃（甘特圖計劃與實際的對比）和目標度量（在製品數量度量）。
結論：將問題分類整理,錄入到JIRA系統，爲數據分析做採集工作。
延遲開始------>原因是以下1.2.3.4......
設計延遲------>原因是以下1.2.3.4......
開發延遲------>原因是以下1.2.3.4......
測試延遲------>原因是以下1.2.3.4......
交付延遲------>原因是以下1.2.3.4......
- 設備、資源不到位
- 開發技能不足
- 設計技能不足
- 測試技能不足
- 手上任務未完成而不能及時開始下一個任務
- 任務安排衝突
- 外部依賴
- 其它待補充
結論：接下來工作的兩重要點
- 計劃與跟蹤
- 總結與反饋