为管理者，还是为了团队；为了管理报表，还是为了协作需求，这些是在项目管理工具选择或开发时需要面对和思考的一个问题。
传统项目管理工具在团队内部臭名昭著
项目管理工具当初都是为了项目团队开发的，协助项目团队管理项目：目标和进度，主要服务主体是项目团队，但是当管理者知道了有这么一个工具，于是就提出了很多管理性需求，这样就慢慢让传统的项目管理工具越来越庞大，越来越复杂，使用越来越困难，困难的让团队失去了项目管理工具的主动权。你会经常看到厚厚的帮助项目管理工具帮助文档，一系列的项目管理工具培训，这些都让传统项目管理工具在团队内部臭名昭著。
两张皮和成本浪费
现在，再来具体看看传统项目管理工具：基本上都是从管理的角度出发，也就是有管理需求，就添加一个操作要求；有报表需求就添加一个字段；有管理期望，添加一个新的功能。围绕管理，让团队配合，无形之中，团队就增加了很多为了满足管理需求的工作，如：填写工作日志，估算进度，精确填写工时，填写风险，上传里程碑报告等等。
这样就容易造成如下两个问题：
1. 两张皮，实际状况和管理看到的报表不匹配
a) 更新不够及时，实际情况无法及时反馈到系统中
b) 应付性操作，仅仅为了在“数据”上满足管理需求
2. 成本浪费，团队投入了大量的工作在满足管理需求上，而不是业务目标上
a) 由于不能直接给团队带来直接收益，团队被动执行，耗精气神
b) 管理需求就像多变的天气，变来变去，系统为了满足，就不断打补丁，推出新的操作要求
值得高兴的是，伴随着敏捷方法的出现，现在的很多工具已经意识到了这一点，再次回到项目管理工具的原点，回归当初的驱动力，从团队自身出发，打造团队自己的工作平台。同时，这些工具也能兼顾管理需求。这样就让项目管理工具或团队协作平台真正发挥作用，有效提升组织的协作效能。
这类的工具有两个基本要求：
1. 团队协作
首先，是要透明，有透明才有真正的协作。每位成员每天的工作对相关干系人都可视化；遇到的问题、实际进度要及时团队共享共担；相关完成标准可视化、易理解、易执行。
其次，给团队协作提供相关团队决策支持。
最后，就是要简单、方便。从团队自身的角度设计具体操作，减少团队的学习和使用成本；要不负面影响团队的正常工作，能正面提升团队的工作效率。
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
原创文章，转载请注明