為管理者，還是為了團隊；為了管理報表，還是為了協作需求，這些是在項目管理工具選擇或開發時需要面對和思考的一個問題。
傳統項目管理工具在團隊內部臭名昭著
項目管理工具當初都是為了項目團隊開發的，協助項目團隊管理項目：目標和進度，主要服務主體是項目團隊，但是當管理者知道了有這么一個工具，于是就提出了很多管理性需求，這樣就慢慢讓傳統的項目管理工具越來越龐大，越來越復雜，使用越來越困難，困難的讓團隊失去了項目管理工具的主動權。你會經常看到厚厚的幫助項目管理工具幫助文檔，一系列的項目管理工具培訓，這些都讓傳統項目管理工具在團隊內部臭名昭著。
兩張皮和成本浪費
現在，再來具體看看傳統項目管理工具：基本上都是從管理的角度出發，也就是有管理需求，就添加一個操作要求；有報表需求就添加一個字段；有管理期望，添加一個新的功能。圍繞管理，讓團隊配合，無形之中，團隊就增加了很多為了滿足管理需求的工作，如：填寫工作日志，估算進度，精確填寫工時，填寫風險，上傳里程碑報告等等。
這樣就容易造成如下兩個問題：
1. 兩張皮，實際狀況和管理看到的報表不匹配
a) 更新不夠及時，實際情況無法及時反饋到系統中
b) 應付性操作，僅僅為了在“數據”上滿足管理需求
2. 成本浪費，團隊投入了大量的工作在滿足管理需求上，而不是業務目標上
a) 由于不能直接給團隊帶來直接收益，團隊被動執行，耗精氣神
b) 管理需求就像多變的天氣，變來變去，系統為了滿足，就不斷打補丁，推出新的操作要求
值得高興的是，伴隨著敏捷方法的出現，現在的很多工具已經意識到了這一點，再次回到項目管理工具的原點，回歸當初的驅動力，從團隊自身出發，打造團隊自己的工作平臺。同時，這些工具也能兼顧管理需求。這樣就讓項目管理工具或團隊協作平臺真正發揮作用，有效提升組織的協作效能。
這類的工具有兩個基本要求：
1. 團隊協作
首先，是要透明，有透明才有真正的協作。每位成員每天的工作對相關干系人都可視化；遇到的問題、實際進度要及時團隊共享共擔；相關完成標準可視化、易理解、易執行。
其次，給團隊協作提供相關團隊決策支持。
最后，就是要簡單、方便。從團隊自身的角度設計具體操作，減少團隊的學習和使用成本；要不負面影響團隊的正常工作，能正面提升團隊的工作效率。
leangoo看板
2. 滿足管理需求
管理需求確實要滿足，但是前提是不能通過改變或增加團隊的工作來滿足的，可以在不改變團隊自身的工作，利用信息化工具自動收集，并進行大數據分析，從而獲得。這里舉兩個例子：
1) 風險管理，風險管理不是靠在系統中識別和記錄幾條風險就能解決的，真正的風險已經隱藏在日常工作日志中，如：
? 某個Task已經在Doing狀態停留了很長時間（進度風險）
? 某些Backlog的優先級已經被調整了好幾次（需求風險）
? 每次沖刺評審都沒有用戶參與，也沒有用戶反饋（商業風險）
? 每次沖刺，記錄速率，并重新估算剩余的Backlog（成本風險）
這些實實在在的風險完全可以通過系統日志自動分析得出（建立風險管控模型）,無需項目經理或SM再搞個風險管理文檔進行控管。
2) 進度管理，進度不是靠項目經理匯報出來的，真正的進度已經隱藏在日常工作日志中了，如：
? Backlog、Task的燃盡速度，關注的是剩余工作的進度，而不是完成的進度。因為整個項目的進度取決于還有多少沒有完成，而不是已經完成了多少。(剩余工作進度)
? 基于里程碑的計劃管理粒度已經不能滿足當前的管理需求，進度需要每天真實更新，每日站會能滿足這個需求，團隊協作看板讓每個任務的移動直接關聯進度（每日進度更新）
? 進度不再是需要重新計算，不再是需要被動匯報，不再是復雜看不懂的圖表。而是及時、實時和一線保持一致的可視化的簡單視圖，對管理者開發和推送，也會有能力請管理者走下來，實時了解和指導（進度走動管理）。
“舍得舍得”
這里管理需求的滿足談的比較多，這也是筆者近15年的項目管理工具實踐經驗，如果不能滿足管理需求，相關的項目管理工具或團隊協作工具很難得到管理層的支持，也就很難申請到相關資源(如：費用等)。所以項目管理工具必須要滿足管理需求，但是方法不能簡單粗暴，直接強壓，而是應該長效考慮，從團隊的角度深入思考。這個和“舍得舍得，有舍才有得”的道理是一樣的，只有當我們真正為團隊服務時，相關的管理需求也就自然滿足了，也只有團隊真正使用了項目管理工具，管理需求才能得到真正的滿足，否則得到的僅僅是兩張皮的假象、勞民傷財的結果。所以選擇或開發項目管理工具要“勿忘初心”——不要忘記服務團隊！
?
?
作者：Scott ，王慶付
Scrum中文網資深敏捷顧問和教練，CSM,PMP,CMMI,Prince2,TOGAF,TTT
來源：http://home.leangoo.com/9342.html
原創文章，轉載請注明
)
)
)
)
