锁定老帖子 主题:工作进度反馈,有一种更优雅的方式吗?
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2010-08-27
最后修改:2010-08-27
它的表现形式是日报、周报,工具可能是在线填报、excel表格、甘特图进度更新、每日邮件、纸质表格等等。 本来,这个目标的动机无可厚非,但进度跟踪只是让项目进度可控的一种手段,而绝非目标。但给员工的感觉是,领导在监视他,甚至是季度发奖金的依据。所以,出于一种本能的自我保护,员工会虚报或谎报。 以我几年的经历,以及对其它公司的了解,我基本上没有发现有一个团队时积极主动地配合。 对于管理者,填日报或周报的动机,一般有以下几种: 1、了解项目进度,以便及时调整 2、根据工作日志,了解员工的工作负载及效率,以便改进绩效 3、观察团队各成员,看有没有偷懒的,做绩效考核时的依据 4、根据日志记录的工时,决定本月的薪水 5、根据日志记录的工时,以便部门向总公司要人月开支 以上几种我都经历过,虽然1和2是比较积极的,但员工的配合意愿还是很弱。 我觉得,最核心的原因是,管理者和下属之间,并没有真正建立信任。 对于1,难道只有工作日志这种手段吗?软件开发,不像建筑业,每天的工作进度,是可以用眼睛来观察的,并且进度几乎是线性递增。软件开发,特别是设计和核心模块的开发,一周的工作,很可能是前四天只完成功能进度的40%,后一天完成60%。如果项目经理不懂这些规律,他看到那40%,肯定是心急如焚。 怎么解决经理的焦虑呢?也许最好的办法是,每日及时沟通和下属主动反馈。但前提是,彼此间的信任。否则,下属感觉经理在催工,或者下属也没有反馈的勇气,因为自己四天才完成40%。 对于2,即使员工每天坦诚反馈,但对于项目经理,查看这么多人的日志,工作量很大,加上自己一忙,就忘了,反正也没人监督。但几周后,员工发现他写的日志只是一个摆设,于是也没有记录的热情了,一两句话了事。 对于3、4、5,就不用说了,员工会徘徊在职业道德的边缘。 对于工作进度反馈,在敏捷过程Scrum里,有每日15分钟的站立晨会,这是不用填工作日志的,呵呵。它的目标是团队间工作进度的沟通和协调。当然,它有敏捷宣言做前提。我觉得,如果生搬硬套也不太靠谱,理由有两点: 团队中可能存在一些技术新手,他们每天完成Scrum Master的期望进度不太现实,所以压力会非常大,导致工作时焦虑,而不是Scrum Master期望的强烈目标感。 有些工作是无法每天汇报进度的,特别是偏研发、技术攻关型任务,同样也会让某些成员焦虑、浮躁。 大家知道,软件开发最好的状态是relaxed、relaxed、relaxed。 还有一种方法,就是IBM Rational里面的ClearCase和ClearQuest集成,开发人员每天的工作成果,就是commit自己的代码,也就是ClearCase的提交操作(类似于CVS/SVN),而提交时,正好用到ClearQuest这个任务日志记录工具,也就是说,提交时,一定要选择当初项目经理给安排的一个任务。这也就避开了任务日志要在任务执行后记录的烦恼。总之,下班后最后一件事情,是commit自己的成果物(代码或文档),而不是打开公司的任务系统记录工作日志。 但IBM这套工具,特别是ClearCase太昂贵,另外学习和部署成本太高,对于小团队太重了点。 对于我们小团队,在经历了各种进度反馈方法后,比如Jira工作日志、每日邮件通知、甘特图更新,我还是回到探寻问题的本源:不就是想了解项目进度和团队状态吗?而了解项目进度和团队状态,不就是为了项目进度可控和提升团队绩效吗?如果团队齐心协力、自动自发做事情,那还需要狠抓进度跟踪吗? 所以,我采取走动式沟通。当然这只是一种辅助,因为当团队超过六人,加上自己也承担具体开发任务,很容易拖延。 最重要的方法是,培养团队凝聚力+强化目标感,而在团队凝聚力(责任感+主动性)培养中,最重要是形成一种开放、信任、分享的氛围。 这东西有点虚,但效果实实在在。因为,你会发现,员工在一个任务阶段后,会主动口头给你反馈。不过,我们目前还是没有达到理想的状态。 但我这种方式,并不适合大公司,特别是大型团队,因为它们更倾向于制度化管理。它们的日常管理工作,不应该依赖于管理者的个人英雄主义。 如果有一个项目立项,临时组建一个团队,要培养彼此间的高度信任,何其难。因为信任的建立,是一条漫漫长路。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2010-08-27
引用 对于我们小团队,在经历了各种进度反馈方法后,比如Jira工作日志、每日邮件通知、甘特图更新,我还是回到探寻问题的本源:不就是想了解项目进度和团队状态吗?而了解项目进度和团队状态,不就是为了项目进度可控和提升团队绩效吗?如果团队齐心协力、自动自发做事情,那还需要狠抓进度跟踪吗?
9个人以下的话,直接沟通是比较高效的,而且可以增进团结之间彼此的信任. |
|
返回顶楼 | |
发表时间:2010-08-27
最后修改:2010-08-27
我竟然忘了我探索过的进度反馈方法:
第一阶段:Jira工作任务日志 每周一在Jira里创建团队成员的工作任务,然后团队成员下班前在任务下填写:已完成+待完成+体会,再加上耗时+进度。我自己也填写。推广到整个公司。 我每周汇总一次任务日志,然后发现问题并且改进。 但执行了大概九个月后,放弃了,因为打开Jira比较慢,下班时大家心情比较急切,填写意愿不大。 第二阶段:邮件反馈 下班前,项目组成员给我发邮件,标题:任务名称,内容:已完成进度+待完成+体会,几句话即可。 然后,我每天在Project文件的甘特图里更新进度。 执行到项目结束,效果还行。 但后来总结项目成败因素时,我觉得任务进度反馈,对项目影响微乎其微,特别是我们这个灵活的小团队。 于是,下一个项目,我是每周一上午挨个沟通,然后在他们那儿更新甘特图进度。 第三阶段:走动式沟通 也就是文中记录的,不重复了。 |
|
返回顶楼 | |
发表时间:2010-08-27
最后修改:2010-08-27
根本的原因还是在于管理方式。是管理者让大家作事情,而不是团队成员自发作事情。其实你的这些困惑,敏捷开发的相关理论和实践都可以解决你的问题。但感觉你对敏捷没有太深入了解,或者是你太自信了。
|
|
返回顶楼 | |
发表时间:2010-08-27
最后修改:2010-08-27
我们一般是在每天scrum meeting前更新一下rally,项目组也习惯这种方式了,而且每个user story的owner也可以自己调整task的预估时间。
|
|
返回顶楼 | |
发表时间:2010-08-27
wwccss 写道 根本的原因还是在于管理方式。是管理者让大家作事情,而不是团队成员自发作事情。其实你的这些困惑,敏捷开发的相关理论和实践都可以解决你的问题。但感觉你对敏捷没有太深入了解,或者是你太自信了。
推动者,团队的自发性. |
|
返回顶楼 | |
发表时间:2010-08-27
最后修改:2010-08-27
wwccss 写道 根本的原因还是在于管理方式。是管理者让大家作事情,而不是团队成员自发作事情。其实你的这些困惑,敏捷开发的相关理论和实践都可以解决你的问题。但感觉你对敏捷没有太深入了解,或者是你太自信了。
做项目,肯定是要将目标和计划明确化,然后将目标分解成任务,将任务分配给人。这在任何项目管理都是必须的。 将任务分下去后,开始执行时,我始终觉得引力比推力更强大,也就是让员工感觉任务很有价值,实现它有成就感,他愿意主动去完成任务,达成目标。 可以这么说吧,只要我将任务安排下去,过几天后,任务就自动完成了,不需要我监督,虽然有时候可能和需求有点出入。这就是为什么我废除日报周报还可以掌握进度,当然有时候进度会延期,但这和监督与否几乎没有关系。 何谓敏捷?按时、按质、按量达成指定的目标。敏捷无定论,那个每日晨会我觉得很可笑,因为这不是管理里面最基本的沟通方法吗?还搞得这么神圣?认真研究这套书《职业经理十项训练》,你会发现所谓的敏捷方法,只是它的一个小子集(附件是电子版)。 |
|
返回顶楼 | |
发表时间:2010-08-27
最后修改:2010-08-27
工作日志这个东西,如果需要手动去填写,那么很容易就沦为走形式,因为它实际上是给所有人增加了额外的负担,而人是懒惰的、容易犯错的、不喜欢重复劳动的动物。
因此,工作日志必须是可以从某个地方导出、生成的,这样既不增加工作量,也避免了人工填写导致的信息流失和失真。 我们现在就采用JIRA“微博”来生成工作日志 工作日志如此,文档亦如此。 |
|
返回顶楼 | |
发表时间:2010-08-28
所谓管理,没有什么特效的办法,不然大家也不会如此头疼了。其实我的看法是得因人而异,因势而已。
比如刚进入团队的新人,你再信任他,也必须每天至少两次严格监督,不然非得乱套不可;对于老手,比较有经验的,这个时间则可以几天甚至每周。再比如时间紧的项目不允许你有任何偏差,必须紧跟;时间平缓的项目则不用跟那么紧,你有犯小错误的机会。 很多中层经理都犯想当然的毛病,自己当初是个很强的开发人员,就认为其他人也该这样,任务安排缺乏规划,简单粗暴分配,而且缺乏检查,出了问题又马上乱成一团。 我现在基本每天看一下fisheye的统计,每天代码量的增长曲线是否正常,不正常无论新手老手马上就可以发现问题;正常的话重点检查新手的功能和代码,直到他的代码和对业务的理解能赢得你的信任为止。 想靠团队自发的努力,实在是不靠谱的,不是团队不努力,而是即使努力,做的事情就是对的吗?经理不只是象征性的填写甘特图就得了。 其实主动回馈的确很重要,回馈不是回馈成绩,而是回馈问题;我现在的做法是每天写工作日志,mail发,对每个人都是个监督。 其实最后你会发现,失败的项目或者失败的管理,总结的时候你会发现遇到了各种问题,哪个都可能导致了失败;其实成功的项目或者管理呢,这些问题基本也都遇到了,困难一样存在,但是都没有成为阻碍。所以我经常说的就是撞一百次南墙也不知道路该怎么走,项目管理这个领域,成功经验和套路,比失败经验有意义一万倍。 |
|
返回顶楼 | |
发表时间:2010-08-28
最后修改:2010-08-28
我之前的公司一直至力于效率软件的开发和研究提高效率的方法,我们公司也自己实践,然后总结于软件中,效果很好 FLEX实现的 大家上班就打开。
说一下我们一天的工作流程,每周一早上大家都开个小会 确定下这周的目标 和下面几周的打算,然后就打开页面,展开工作日志的界面,好点时间想想先干什么,然后建好今天的任务列表,如果是项目经理的角色就会分配一些任务给别人,别人完成的时候自己会收到通知。这个工作日志有相关的报表,每周,每天,每月都有统计,包括创建任务和完成任务的比例等等。还有一个便签就像冰箱上的贴的一张纸,大家都可以在上面写东西,有问题就可以写上面,还可以把问题转成任务分配下去,也是大家讨论的地方,每个项目都有自己的便签板,上面写贴满了项目相关便签,很随意但很有用。还有一些相关工具帮助我们管理项目进度,工作分解(有时会给能力高的人分配一个比较粗粒度的任务,他自己会分解。或是项目经理自己做分析分解),里程碑(给各个版本建好目标,根据项目的时间和任务完成度,给出一个比例)等等。 我们的平时的工作完全依靠自己的工作日志 很好用可以很清晰的知道自己要干什么有多少任务,那是紧急的重要的,那些是不紧急的,所以我们的工作进度反馈和工作日志很好的结合起来了。 |
|
返回顶楼 | |