工作日志在研发管理中应用

改善研发管理,从TOPO开始TOPO 工作日志在研发管理中的应用

杭州云图科技有限公司| https://www.wendangku.net/doc/706158735.html,

工作日志在研发管理中应用

一：引子

下列哪些是让研发工程师填写工作日志的恰当理由？（多选）

A: 通过工作日志，可以让员工养成良好的工作习惯。

B: 通过工作日志，主管可以了解到员工的工作进度。

C: 通过工作日志，可以促进主管与员工的双向沟通。

D: 通过工作日志，有助于更好的开展量化的绩效管理。

如果你是一名研发管理者，为了让您得到准确答案，我在CSDN和JAVAEYE论坛上搜索“工作日志”找到的几个帖子，你不妨读读，听听研发基层员工对工作日志的看法：

作为一个工作3年的老员工，我与部门老大干上了，难道就这样走人？

请问程序员需要写工作日志和计划吗

哪位所在的公司要求写工作日志？要求精确到小时的？

请推荐好的工作日志管理软件

我每天都要写这样的工作日志，给一些鸟人看，大伙发表一下。

每天写工作日志、周报你怎么看？

工作进度反馈，有一种更优雅的方式吗？

如果你是一名研发工程师，那么下面的这个讨论你也可以读读，听听研发管理者们对推行工作日志的看法：

关于让研发工程师写工作日志的思考

在你仔细研读了上面这些讨论内容后再结合你们团队的实际情况，然后再做选择。想知道答案吗？本文可以让你全面了解在研发团队中推行工作日志的目的，以及如何设计一个让一线开发人员不再反感和抱怨的日志系统，并且让研发管理者又能够达到推行工作日志改善研发管理的目的。

二：导读

第一部分: 理论篇

很多研发团队都在推行工作日志，然而不少研发团队在误用工作日志，诸如希望想达到了解进度，促进沟通或叠加一些所谓的绩效管理等功能都让工作日志的开展和推行承载了太多不必要的内容。其实，本文所要表达的关于工作日志最有价值之处在于：工作日志是目前最有效的回答“研发人力投入到哪些地方去了？” 这个问题的手段。

此部分相关内容：

工作日志之误用篇

工作日志之目的篇

第二部分：功能篇

然而，要达到工作日志解决“人力投入到哪里去了？”这个核心问题，需要对工作日志系统的功能做良好的设计，因此本文接着为读者介绍了工作日志的一些极其有用的功能，包括如何正确的设计工作日志的填写表单，如何方便容易的分享工作日志，以及为了最大程度上减少开发人员工作日志填写的录入负担，系统应该提供的一些便捷的日志拷贝功能等。

此部分相关内容：

工作日志之设计篇

工作日志之分享篇

第三部分：管理篇

在介绍完基本的工作日志功能后，我们接着向读者介绍了如何使用工作日志的统计的功能来达到了解人力投入到哪些地方过去了的问题。如果不对工作日志进行多功能，多维度的统计，那么工作日志的作用就会失去大半。

此部分相关内容：

工作日志之个人统计篇

工作日志之部门经理篇

工作日志之项目经理篇

结合工作日志的目的，从提高研发协作效率的角度出发，杭州云图科技设计和整合了所有工作需要的工作日志的相关功能到Topo系统中，希望能够借助于此功能，在帮助研发团队的改善协作效率的基础上，提升公司管理组织的管理效率。

三：正文

工作日志之误用篇

目前，国内不少稍上规模的研发团队都要求员工写工作日志，而且推行工作日志的管理初衷也是五花八门。然而，笔者以为，下面的这几个让员工写工作日志的出发点都不大妥当。让研发工程师写工作日志，还是最好不要给出下面的4个理由。

一：通过工作日志，可以让员工养成良好的工作习惯。

为了支撑这个理由，有些研发主管可能会让他的员工去学习一下“戴明环”

（PDCA），也许还会推荐他们去阅读时间管理大师阿代尔的杰作《时间管

理》，甚至还能给员工引入“时间管理”的培训课程！

然而，这一条理由仅对有上进心或自我约束能力强或“比较听话”的员工有

效，你却不能指望你的团队里大都是这类员工。因此在面对每天都要填写工

作日志这件事情上，很难说这个理由能让他们欣然接受。毕竟，如果仅仅是

为了让员工养成良好的工作习惯，真的没必要用工作日志来达到这个目的，

因为这个做法的投入产出比实在不高。

二：通过工作日志，主管可以了解到员工的工作进度。

这的确是部分研发经理们期望推行工作日志达到的目的，可是，如果一个经

理离开工作日志就不知道某个员工的工作进度，那么经理们可以自问一下：

我真的不能只关注员工们的工作结果而需要去关心他们的工作过程吗？如果

回答是要关心过程，那么再问自己一个问题：下发的任务是否过大或持续时

间过长？如果还有别的原因要了解过程，为何不直接与他们坐到一起而要自

己独自呆在自己的办公室里看工作日志呢？

如果第一条理由是主管推荐员工去提高，那么员工可以很容易针对这个提出

反对理由，推荐自己的主管去学习一下SCRUM开发模式，了解一下何为“以

结果为导向”，并研究一下如何建设“自组织的研发团队”。

三：通过工作日志，可以促进主管与员工的双向沟通。

是的，不少公司就是这么干的，特别是一些大公司更是如此，

多么官僚的做法！为达到此目的，他们甚至还设计了一套极其

复杂的日志记录格式。要求员工填写在工作中遇到的困难，

需要哪些帮助？主管们看到员工在工作日志中的求助，就会尽

量去协调解决日志中提到的问题。笔者在以前的大公司工作时，

倒是经常看到员工填写了大量需要主管协助的事情，但是主管

们一点反应都没有！遇到工作中的困难，为何员工不是主动去

找办法克服，而是让他们将困难写到工作日志中，然后让他们

等待你去协助解决。

沟通首选面对面直接沟通，其次是MSN，QQ，内部电话等实时沟通，最次才是EMAIL，日报，周报等间接沟通手段。因为填写工作日志需要团队所有成员较大的时间成本付出这个因素存在，可以说采用工作日志来促进工作的双向沟通是最没效率的做法。通过工作日志来促进双向沟通与通过召开会议来了解项目进度是研发管理者最容易犯的两个错误做法。

四：通过工作日志，有助于更好的开展量化的绩效管理。

的确有些团队在借助于工作日志搞绩效管理，但是这是不恰当

的。怎么可以针对一个人某天做了某件事情来做绩效量化呢？

绩效考核怎么是针对过程而不是针对目标所达到的结果来进行

的呢？而且作为主管，每天都将时间耗费到对这些琐碎的事情

的评价上而不是把精力放到其他更加重要的地方，这是多么糟

糕的一种情况！

上面四条理由，都不是很恰当，那么为何我们还要求我们的员

工写工作日志呢？请接着阅读“工作日志之目的篇”。

工作日志之目的篇

很多底层的研发工程师痛骂CMMI,经常有人把它痛批得一无是

处，其中大量的文档，频繁的过程汇报是主要原因。那么为何

还是有那么多企业的中高层管理者对 CMMI奉为“圣经”呢？

管理者要求研发工程师写工作日志究竟可以达到何种管理目的

呢？在回答这个问题之前，我们先来看看研发工作者在实际的

工作中遇到的困难：

研发经理们的困惑：

下面的情形大多数研发部门经理都遇到过：“作为部门经理，

我的下属被投入到很多项目中去了，有些人还同时进入了几个项目，这种情况非常普遍。我们的开发人员既在一个项目中开发新特性，又同时需要维护好几个其他项目，我无法了解到他们的工作状况，这让我无法合理调配人力，我也不知道我投入到各个项目中的人力何时能够得到释放。”

项目经理们的困惑：

下面的情形大多数研发项目经理都遇到过：“作为项目经理，

安排进我项目的人中总会有不少人同时在其它项目中，我发现

他们有时在我的项目中工作，不知何时又跑到其他项目中工作

去了。表面上看部门经理分配了不少开发人员给我，其实真正

在我这里干活的人没多少。我理解公司研发人力紧张，人员在

项目间共享严重也是迫不得已，但是我想知道，名义上属于我

项目的开发人员究竟在我的项目中投入了多少工作量。”

开发人员的困惑：

下面的情形大多数研发工程师都经历过：“作为开发人员，以前我开发的特性要维

护，还要在新的项目中开发新特性。我的工作总是需要在几个项目之间切换，每个

项目经理都给我8小时的活，他们难道不知道我同时在几个项目中吗？每个项目经

理都觉得我没干多少活，但是加起来肯定超过8小时吧，不然我为何老是在加班？

我的付出为何就没人看到呢？”

研发部门经理，项目经理，研发工程师他们其实遇到了同一个问题：究竟项目人力

都投入到哪里去了？部门经理说，我想知道我的人在各个项目中的人力投入情况。

项目经理说，我想知道在我的项目中究竟有多少准确的人力投入。开发人员说，我

想让你们知道我在所有项目中的人力投入。

在当前国内企业的研发管理中，研发人力紧张是主管们经常

面临的挑战。上至老板，下至基层项目经理，他们时常面临

的问题就是：研发人力都投入到哪里去了？至此，你可能已

经明白了我们即将得出的结论：工作日志是目前最有效的回

答这个问题的手段。为何这样说呢？这就需要了解一下工作

日志应该如何设计才能够达到这个目的，请继续阅读“工作

日志之设计篇”

工作日志之设计篇

前面我们说过，工作日志的主要目的是解答“研发人力都投入到哪里去了？”这个问题，并且也谈到工作日志不是用来了解员工工作进展的。要具体说明这一点，这就需要涉及到工作日志系统应该如何来设计这个核心问题。

一提到工作日志的设计，也许你脑海里立即会想到以前你使用过的一些工作日志系统，它们的设计大概就是让开发人员每天写一些工作内容，然后主管可以按照时间逐天查看。我要说的这种设计根本就没有做个细致全面的考虑，本章的内容将为你展现一个全新的工作日志系统，相信到目前为止你还没有见过如此强大易用的日志系统。本章不仅让你看到一个完整的工作日志的设计，并且会通过仔细分析，阐明这样设计的理由。

输入表单设计

如果仅仅是为了达到这个“工时统计”这个目的，让研发工程师填写的工作日的工作内容大抵就应该设计成下面的这个样子：

必填项：

项目：(工作属于哪个项目)

?工时：(大概花了几个小时)

?标题：（一句话概括一下工作）

选填项：

?工作对象：（可以不填，即该条日志内容与哪个工作对象相关，例如解决了一些Bug，就关联一下这些Bug；

在开发某个任务，就关联这个任务；在写测试用例，就关联这个测试用例）。

?工作描述：（可以不填写）

是的，就3个必填字段，2个选填字段，字段越少越好，没有其它需要填写的内容了。毕竟工作日志是开发人员每天都要填写的东西，不要强制要求他们填写一些几乎没啥用处的内容。大致的输入表单如下图所示：

应该允许每天填写多条记录，如下图所示：

三种工作视图

为了方便填写和查看工作日志，最好提供工作日志的月视图，周视图和日视图。下面是工作日志的周视图，一般来说周视图是最方便的查询方式，既能够看到一周的整体工作情况，而且信息也因为空间较富裕较之月视图能够显示更多的条目：

月视图如下图所示：

显然无论是日视图/月视图/还是周视图,都应该提供方便的前后导航查看方式，例如在周视图下，应该能够方便的查看“上一周”和“下一周”的控制按钮；在月视图下提供“上一月”和“下一月”的控制，在日视图下提供“前一天”和“后一天”的控制。

日历导航

提供前后导航显然还不足以方便的查看任意一天（或年或月）的工作日志，我们最好再提供一个日历来完成这种时间段的任意切换，如下图所示：

这样点击日历中的任何一天就可以完成时间段的切换。至此，工作日志的个人填写和查看功能就基本完备了。

日志条目拖动拷贝

然而研发的很多开发任务都会持续几天甚至几周时间，有时某个开发人员的工作可能仅仅是持续开发某个模块，这时该员工填写的工作日志可能每天几乎都是雷同的，让开发人员每天手工输入相同的工作内容显然也是他们反感填写工作日志的一个重要原因，那么提供工作日志的条目拷贝就非常有用了。如下图示所示，最好能够通过简单的拖动就可以任意复制工作日志条目：

上面的“拖动拷贝”的操作方法大致是：要填写星期五的工作，发现与周四的工作一样的，这时只需要鼠标按住星期四的“工作条目”，将其拖动到“星期五”即可完成工作日志的填写。“科技是为懒人提供服务的”，这类人性化的设计大概最能体现这个了。

活动工时录入

填写工作日志需要细化到天和小时，但是没有必要精确到分钟，而且，通常情况下开发人员填写的小时也不一定要求非常准确，只要有个大概即可。某人某天的工时只是最基础的数据，每天记录的工时的准确性较之工时统计来

说并没那么重要，只需要尽量准确而已。这些基础的工时数据的合理偏差并不大对整体的人力统计构成影响，稍后介绍的“工作日志统计篇”可以帮助我们更好的理解这一点。

“拖动拷贝”是填写重复的工作日志活动的一种快捷方式。然而，对于只需要通过工作日志来收集工时信息这个目的来说，直接提供工时录入功能就更加方便了，下面来具体介绍一下这个功能：

每个人每天所做的工作在集成研发管理系统中会有两种数据体现：一种是活动记录，即某事某刻某人做了什么的系统自动记录；内容如下图所示：

另外一种是待处理事项。比如某个开发人员某几天一直在写文档，显然该员工可能在系统中并没有任何自动的活动记录，这时的工作主要体现在对待处理工作方面。如下图所示：

因此，一个员工填写工作日志时，如果系统可以自动从“活动记录和待处理工作”中提取整理出工作对象，然后开发人员仅仅需要简单录入一下工时即可，这样就可以最大程度给工作日志填写提供便利，如下图所示：

如果员工对“待处理工作”中的某项工作当天并没有耗费任何时间，那么只需要将该工作项的工时留空即可，录入当天涉及到的工作项工时后，系统即可自动为其创建相应的日志条目。这样就完成了工作日志的填写。

前面提到过，“工作日志不是用来检查进度的”，要了解工作进展情况，不应该通过员工填写工作日志进行，因为这样太耗费研发人员的时间，而且也让他们觉得这类工作繁琐而无趣，并且与开发工作相比毫无工作价值，从而挫伤他们的工作积极性，影响到他们的工作成就感。那么我们来看看不用工作日志，主管又如何来了解员工的工作进展情况?

如下图所示，系统自动记录了每个员工的所有工作活动，这些活动包括“开发，测试，评审，文档，版本”等等。一个主管可以看到月视图中看到该员工的主要活动，并且还可以按照活动记录的内容过滤来查看：

除此之外，查看员工的工作活动记录也可以按照该员工所在的项目来过滤，如下图所示：

有时，查看一个员工的工作状况，还需要与工作计划对比查看，因此，将工作计划同时显示在工作日历中，对了解每个人的工作状况也非常有益，同样，这种工作计划也同样支持按照不同的工作类型过滤，如下图所示：

这一章内容较多，但核心都是围绕着如何尽最大可能的减少研发人员工作日志录入的耗时，并介绍了一些不应该依赖工作日志来了解进度的功能。工作日志不是个人日记，填写好总归是要给他人看的，请继续阅读“工作日志之分享篇”。

工作日志之分享篇

前面我们详细描述了工作日志的填写，除了工时需要员工填写外，其余工作记录等反应员工当前工作状况的信息都由系统自动记录了。其实这些信息对自己主管来说显然希望能够了解到，另外这类信息对于需要与自己协同工作

的同一项目组的工作联系密切的同事来说也同样有用，这里就引申出一个工作日志分享的功能，下面我们来介绍

一下如何分享自己的工作信息：

1.分享工作日志设置

除了自己可以查看自己的工作日志外，每个员工还可以将工作日志分享给与自己工作密切相关的同事和自己的主管。如下图所示为“李斌”将工作日志分享给项目经理“赵忠诚”和部门经理“刘春燕”，同时他还将工作日志分享给了同事“李丹”

这样“赵忠诚”，“刘春燕”和“李丹”就可以查看“李斌”的工作日志了，如下图所示是部门经理“刘春燕”的工作日志查看情况：

2.分享给同事和主管的区别

那么分享给主管和分享给同事有何区别呢？这里的主要区别是：日志分享给主管后，那么主管的主管可以自动继承到下属的下属的工作日志查看权限，而如果分享给同事，那么该同事的主管并不会因为这个分享而查看到该工作日志。例如上图中软件部经理“刘春燕”将工作日志分享给自己的主管研究部经理“刘宛莹”。我们来看看部门经理“刘宛莹”的工作日志查看结果：

上图中我们可以看到，部门经理“刘宛莹”不仅可以看到了其下属(软件经理刘春燕)的工作日志，还可以看到其下属的下属（软件开发人员李斌）的工作日志。这种层级分享还可以一直递归下去，从而让上层管理者在必要时可以通过工作日志了解到所有管理范围内的成员（下属及下属的下属等）的工作情况。

3：部门经理可以随时了解到部门内任何一个员工的工作状况

大多数情况下，一个研发管理者只需要关注自己的直接下属的工作细节即可，因此这种看似“越级”的查看功能好像显得没有必要。然而，如果一个研究部经理要全面掌握下面3个子部门（软件部，硬件部，测试部）的人力状况情况，那么从工时统计方面就需要这种数据的层级统计支持了，因此这种设计为公司上层管理者全面掌握其管辖范围内的所有人力状况提供了可能。

如果工作日志提供了“分享功能”后就停止不前了，那么离工作日志要解决的核心问题“研发人力都投入到哪里去了”还差老大一截，然而很多工作日志系统就只做到了这个程度，研发人员在填写工作日志上的付出就这样白白浪费了，实在是太可惜了！为何这样说，请继续阅读“工作日志之个人统计篇”。

工作日志之个人统计篇

前面的工作日志分享篇中我们详细介绍了如何将开发人员的工作信息分享给自己

的主管和团队中的其他人。一般来说，研发工作者了解他们的工作状况时，通常

并不会过多的去关注每一个研发工作的细节，而往往更加需要关注的是一些整体

的工作信息。从本章开始，我们来介绍工作日志的工时统计功能，显然工时的统

计信息对每个研发工作人员来说都是比较重要的。

下面我们通过工作日志的统计功能，来向研发工作者呈现最关心的信息：我最近

的工作精力投入到哪里了？对每个研发工作者（下面是李新的个人工作视图中所

看到的）而言，他都可以通过下面的5个统计视图来直观的了解到自己的工作状

况。

1.我每周工作日志填写次数统计：

显然只有10月17日这一周我（李斌）填写了5天的工作日志，其余周都没有正常填写工作日志。如果工作日志填写都不正常，就会直接导致工时统计不准确，显然这个统计有利于帮助自己关注自己填写的工作日志异常情况。

2.我每周累计工作时间统计：

对于一般公司来说，每天至少工作8小时，每周40小时的工作时间还是应该保证的，显然从上图中我（李斌）的工作时间很不正常。请假了？还是工作日志忘记填写了？总之肯定不正常了。

3.我在各项目中的工时投入周变化趋势图：

这个图中可以看到我在所有参与项目中的工作投入的周变化趋势情况，从这个图中可以清楚的看到自己每周在每个项目中的工作投入变化趋势。

4.我在各项目中的工时投入月变化趋势图：

这个图中可以看到我在所有参与项目中的工作投入的月变化趋势情况，从这个图中可以清楚的看到自己每月在每个项目中的工作投入变化趋势。

5.最近一个月我在各项目中的工作投入情况：

有了上面5个统计视图的支持，我想任何一个研发工作人员都可以清晰的知道自己的工作投入了。通过这些视图，任何一个主管都可以清晰的分析出某个员工的最近工作投入情况，这也是填写工时的最大意义。如果不通过工作日志的工时，还的确很难找到其它更有效的手段了。

6：还想统计更多？

看到这个功能时，有一些研发主管可能有进一步获取其他统计信息的冲动，例如开发某个模块用了多少时间，开发某个特性用了多少时间？笔者认为统计的内容过细，一方面准确度会下降，另一方面其真实的作用也有限。因此，在做更多的细节统计前还是应该对此经过周密考虑，毕竟任何用于统计的元数据最终都是需要开发人员填写的，太多的填写内容会加重他们的工作日志录入的负担。

在解决了“我最近工作都投入到哪里去？”这个问题后，我们接着来解决部门经理的问题：“我的开发人员都投到哪些项目中去了”，请继续阅读“工作日志之部门经理篇”

工作日志之部门经理篇

我们前面提到过，大多数研发部门经理都遇到过这种困惑：“作为部

门经理，我的下属被投入到很多项目中去了，有些人还同时进入了几

个项目，这种情况非常普遍。我们的开发人员既在一个项目中开发新

特性，又同时需要维护好几个其他项目，我无法了解到他们的工作状

况，这让我无法合理调配人力，我也不知道我投入到各个项目中的人

力何时能够得到释放。”

有这种困惑的原因在于国内大多数企业研发团队大都采用矩阵式组织

架构，采用“资源线”和“产品线”并行的方式开展研发管理活动。

而一般的研发管理系统又因为设计上的难度而没法很好的支持矩阵式管理，它们大多更偏向于项目管理，因此导致部门经理在这方面得不到很好的信息支撑。下面的这些统计视图可以很好的回答部门经理的这些问题.

1.部门内所有成员每人每周工作日志填写情况：

上图给我们展现了部门经理看到的所有下属的工作日志填写情况，正常情况下每个下属应该保证每周填写5次工作日志，也就是应该是一条平行线。如果不是，一定是该员工出异常了。上面这个统计结果只是一个示例数据，如果一个部门的工作日志填写成这样，这个部门经理的管理措施就很不到位了。

2.部门内所有成员每人每周工时累计情况：

显然，如果不考虑加班和请假等异常情况，每个人的工作都按照每天8小时的话，所有人都应该是一条40小时的工作直线,否则工作时间就出了状况。显然上图中示例的情况表明每个人的工作都不正常。

这个统计对部门经理而言太有用了，他可以直接让部门经理非常容易知道“人都投入到哪些项目中去了”，而且还可以直观的知道这种投入的变化趋势！

3.最近一个月部门的每个成员在各项目中的工时分布情况：

这个对部门经理了解人力投入近况非常有帮助。支持我们解决了部门经理的人力投入疑问，下面我们接着来解决项目经理的问题：“究竟有多少人力投入到我的项目中了？”，请继续阅读“工作日志之项目经理篇

工作日志之项目经理篇

前面我们提到过，大多数研发项目经理都

遇到过这种困惑：“作为项目经理，安排

进我项目的人中总会有不少人同时在其它

项目中，我发现他们有时在我的项目中工

作，不知何时又跑到其他项目中工作去了。

表面上看部门经理分配了不少开发人员给

我，其实真正在我这里干活的人没多少。

我理解公司研发人力紧张，人员项目共享

严重也是迫不得已，但是我想知道，名义

上属于我项目的开发人员究竟在我的项目

中投入了多少工作量。”