最近朋友諮詢我一個問題，說他們公司可能有很多小項目在並行（20個左右），那麼產生了下面幾個問題
- “救火型”工作模式，一會兒A客戶抱怨了，做A項目。一會兒B客戶來了，趕緊做一下B項目，典型的被外部客戶鞭策着走，也就是被客戶控制了項目的節奏。
- 資源調配不過來，開發人員是有限的，做A項目，必然B項目要放下，那麼到底做A還是做B呢？
- 到底要不要加資源，加班來處理項目，那麼什麼時候加資源，怎麼加資源，加多少資源呢？
基於上面的描述我給出了，現在最重要的兩個圖（可視化其實是項目中應該經常考慮的方法，問題暴露了自然能有解決方案，就怕是自己陷入問題之中，而從來不知道問題在哪）
1. 關於資源的問題，第一反應在我腦海中的就是甘特圖（我這個是excel做的，敏捷的思想讓我放棄了MS project這樣的重量工具），
這個圖裏有有這麼幾個要素我覺得很重要
-- 每個格子裏需要的資源數
-- 虛線表示的項目milestone （如6月的那條豎線）
-- 最下面，資源超載的，顏色警示
-- 這個資源列表每月review的時候，都生成一個，然後每次在右邊寫上變動的change log
2. 關於項目是否出現交付的時間問題，那麼作爲敏捷工作者，release burndown chart第一時間跳出在了我的腦海，每個項目做一個release burndown chart。
每月update一次，這樣很容易發現失控的項目了，如下圖：就是看actual burn down那條線，是否大大偏離target burn down那條斜線，圖一中黃色的4~7月之間項目是有個停滯開發期的，
還好7月份採取了重要措施，讓項目回到了正軌，按時發佈
3.上面圖表用excel來做還算簡單，輕量級，也不需要頻繁更新，每月一次的項目組大會之前，項目經理更新一下。
（可以分兩次會議，一個是項目預備會議，項目組大會上一次展示更新的項目圖，並記錄問題。第二次會議，基於項目圖上的問題，進行逐個討論）
問題當天討論不出結果的時候，過一兩天隨着時間的推移，人一般會有更好的解決方案的。可能是人變聰明瞭，也可能是在放鬆的情況下，大腦更活躍。
沒有結果的時候，千萬不要坐在一起，浪費時間。
4.最後這些圖建議都貼牆上，走過路過不會錯過。這樣大家都知道公司項目的運行情況，以及是否有問題需要幫助.
在問題本來就多，複雜度很高的是否，千萬不要再引入複雜流程和複雜工具，來加大項目的複雜度。
excel，ppt ，Visio，思維導圖 基本能解決極大部分問題~~
一些新鮮，灼熱的見解，沒有太整理，希望能對別人有幫助，對自己也是留個記錄~~