开发人员每天提交一份日志到底合不合理？

我们公司开发的产品就是SAAS的互联网工作日志，并且也在要求伙伴们用我们自己开发的软件，每天写工作日志。通过...





我们公司开发的产品就是SAAS的互联网工作日志，并且也在要求伙伴们用我们自己开发的软件，每天写工作日志。通过写工作日志，已经实现了团队既定的目标：做一家4点半下班的公司，给大家最大的工作自由度，同时又不影响我们的工作产出和市场竞争力。

首先，说说我们为什么会开发工作日志这样的产品。原因其实很简单：我们团队转型互联网之前，是做企业外包服务的。团队人不多，10来个人，但有同事经常出差。以前我们沟通工作的方式是：开周会。但发现以周为单位的管控粒度，对于我们这样的初创企业跨度太大，因为开周会时确实能发现很多问题，但因为沟通或者响应不及时，这些问题已经木已成舟，纠错成本非常高。所以，公司后来增加了晨会，但晨会的问题是：浪费大家的时间！似乎每个人陈述自己的工作只需要2-3分钟，但10来个人加起来就是半小时之多，如果沟通中发现有问题，再掰扯半天，这时间成本就更高了！而且最重要的是：掰扯的问题并不是和所有人都有关系，但却需要所有人都参加这样的会议！再加上，个别同事如果有急事迟到几分钟等，沟通问题又需要他知晓，等他不等他，是个问题……纠结！所以，通过晨会沟通工作，貌似科学，但我们实践的反馈是：效率太低！

所以，我们开始通过工作日志的方式来沟通工作！但找了word、邮件、QQ空间等等很多工具，感觉写日志都不方便。所以我们一怒之下，自己做了一个，这是后话。作为团队创始人，我同意楼上说的：如果你自己不写，而且同事写了日志你也没有反馈，那么请你不要要求大家写工作日志！

因为写工作日志的目的是：让团队的工作信息快速分享、流动起来！

以前我自己也有个误区：认为工作日志是领导检查员工工作饱和度的手段，所以领导忙可以不写，但员工要写。但实际上：往往这样的公司实施工作日志制度一定用不起来，因为出发点就有问题！工作日志对自己的作用是：帮助自己回顾整理一天的工作；对于团队的作用是：让工作信息在团队中快速流动起来。以前，我也经常“怪罪”我们团队的个别伙伴做事情不够积极主动：分配的任务你不过问，从来不会主动反馈。但换位思考，管理者的这种想法其实有问题：因为我们曾经作为基层员工时，也搞不清楚究竟哪些任务对于领导来说是重要的，是值得专门花费时间去找他汇报，而且这种汇报可能还会打断他的工作！作为基层员工，我觉得实在是不好意思啊！但现在通过工作日志这种方式，员工只需要在工作日志的成果里面@一下自己的领导就可以了。通过工作日志这种方式的交流，我觉得最能够节省团队的沟通成本。

废话少说，上图：我自己写了5年的工作日志（以前是用word、邮件写，后来才用日事清写）


我公司同事写的日志（他是异地办公，在成都，我们团队在北京）

每天只需要把日志@给团队相关人员即可。

我们采用的是KPTP的模式来落实工作日志：K：keep，今天做了哪些工作；P：problem，遇到了哪些问题；T：try，计划如何尝试解决这些问题；P：plan，明天的计划是什么。

我们开晨会、写日志、找别人沟通，不都是为了了解这些信息吗？所以，写日志只是手段，能够找到一种适合团队的方式来做好团队效率管理，才是最根本的目的。

陈鸿彬 | 鸿观

每个开发项目落实到个人

每个人都要有独立做事的能力

    关注 购信订阅号