最近朋友咨詢我一個問題，說他們公司可能有很多小專案在并行（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，思維導圖 基本能解決極大部分問題~~
一些新鮮，灼熱的見解，沒有太整理，希望能對別人有幫助，對自己也是留個記錄~~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/212714.html
標籤：其他
上一篇：mybatis時間查詢小技巧