项目管理工具到底应该为谁服务?
为管理者,还是为了团队;为了管理报表,还是为了协作需求,这些是在项目管理工具选择或开发时需要面对和思考的一个问题。
传统项目管理工具在团队内部臭名昭著
项目管理工具当初都是为了项目团队开发的,协助项目团队管理项目:目标和进度,主要服务主体是项目团队,但是当管理者知道了有这么一个工具,于是就提出了很多管理性需求,这样就慢慢让传统的项目管理工具越来越庞大,越来越复杂,使用越来越困难,困难的让团队失去了项目管理工具的主动权。你会经常看到厚厚的帮助项目管理工具帮助文档,一系列的项目管理工具培训,这些都让传统项目管理工具在团队内部臭名昭著。
两张皮和成本浪费
现在,再来具体看看传统项目管理工具:基本上都是从管理的角度出发,也就是有管理需求,就添加一个操作要求;有报表需求就添加一个字段;有管理期望,添加一个新的功能。围绕管理,让团队配合,无形之中,团队就增加了很多为了满足管理需求的工作,如:填写工作日志,估算进度,精确填写工时,填写风险,上传里程碑报告等等。
这样就容易造成如下两个问题:
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
来源:www.leangoo.com
原创文章,转载请注明