工作跟进 - 反馈的填写方式 ¶
作者：KK
发表日期：2016.8.11
更新日期：2017.7.24
每天要反馈工作内容和工时 ¶
我要求团队基层员工每天都反馈工作内容和工时，示例大致如下：
修改全部前端页面的数据获取和存储机制为sessionStorage 3.5h 添加完成全部页面导航返回上一页功能，详情回退到列表页面做了cookie前端缓存方便读取不用再请求 2h 完善发现的一些细节问题修改 0.5h 评估对象增加日期筛选，评估次数过滤 0.5h 调整上传button文案，增加提交报告问卷的验证逻辑 问卷提交验证重新修改了一下提交test，目前和线上代码不一致 0.5h
本文对事不对人，只是拿这种情况来说，其实这位员工平时反馈写得还是挺好的，但偶尔也会有我觉得不大满意的地方
为什么要每天工作反馈呢，原因在《当管理者的感受 - 工作跟进 - 跟进频率》一文中已经提到过，其中一个就是我也要了解团队成员的工作情况，以便及时发现问题跟进或纠正
如果不要求反馈工时，员工的反馈内容就会偏模糊 ¶
当反馈的内容变得模糊的时候，你就很难把握大家目前工作的大致情况，不容易发现一些细节问题及时跟进处理
如果所反馈的内容使我无法理解或者模糊的话，其实这个反馈也失去了一部分意义
比如有人可能会反馈道“今天解决了遍历数据的问题”，所谓解决遍历数据的问题，那是什么数据呢？一天下来写的程序处理的数据那么多，我也想知道员工到底在哪方面有缺点，遇到怎样的数据需要专门去解决，我能不能给到他一些指点？他是不是缺少某方面的知识呢？
所以如果遇到这类反馈内容，我是希望他能更具体地描述“解决{XXX功能在处理YYY的时候}遍历数据的问题”那我才知道为什么那么多数据遍历不提偏偏要特意反馈这个数据的遍历问题
不然这一小块的反馈内容写跟没写是差不多的
经沟通后他表示认可我的意思，以后会注意不写太模糊的反馈描述了
如果你也头痛成员们的反馈太模糊，不仿试试学我一样让他们把工时也反馈出来吧，这样他们就会进一步细化描述了
示例 ¶
要求反馈工时之前，某员工的每天反馈内容大概是这样的： ¶
第一天：
后台修改，官网新闻修改
第二天：
app.js文档、后台修改，门户修改
要求反馈工时之后，反馈内容填写变成了这样： ¶
1、查报告单没有数据的显示优化（0.5h）
2、实现手机号绑定页面（0.5h）
3、实现评估归档功能（2h）
4、常见问题列表和详情页面（0.5h）
5、反馈页面（0.5h）
6、优化服务端返回错误的处理（2h）
你是担心大家的抗拒吗？ ¶
不用担心，其实我发现也挺多公司这么做，因为这招有效
如果不用反馈工时，本来有的人就在公司里混日子，要求反馈工时后，他其实是心虚，哪有什么底气来反抗这种制度
压力就是动力，在这种工时制监督下成员的工作产出会更好更高，通常相比那些不用反馈工时的公司的员工更勤奋能干
自己带的项目更能得到进度上的保障，因为大家都看着工时去做足事情来有个交待呢
如果工时不够，你有时候要管管 ¶
光要求反馈工时是不够的，如果一直不管，大家还以发现每天反馈的总工时4小时或6小时都无所谓，可一天上班时间起码有7.5小时啊，去除一些碎片时间好歹要产出7小时的工作量吧
所以开头要经常盯一下大家的工时是否达7小时以上，不达就问责一下他是不是混日子了什么的吧
甚至有些事情用的工时太长就更要问一下，有必的话直接拿这个作为理由扣绩效，他下次就不敢随便花很长工时做一件事了来混日子了
等大家习惯这样的工作监督制度后就会慢慢自觉起来，你可以不用频繁地去算他们的工时了