市面上所有的研发管理软件，大多都有工时相关功能，但是却没有日报功能，好像也没什么问题，但是在使用过程中体验非常不好，为什么呢？
项目管理对于基层工作人员来说，主要解决这三个问题：开展我的工作、协作我们的工作和汇报我的工作，也就是说日常的汇报也是刚需。平台没有日报就会有下面的问题。
第一、如果离开平台，那么日报上罗列的事项和实际工作安排就没有紧密关联，“混子”对日报就有“操作空间”；管的人越多，越难记住每个人的具体工作。如果混子瞎编日报，也难以察觉，一看满满当当，以为产出还不错，干的事项不少嘛。日报是项目管理中的刚需呀，难以理解为什么市面上的研发管理平台都没有这功能。
第二、本来能不开会就别开会，很多时候是通过早会来确认工作进展，但这要花更多的时间，为什么要开早会就是因为日报上的内容和工作安排没有紧密关联或是根本没日报，只能当面说一说情况，有大家在场，混子没法再瞎编了。有了和工作安排完全关联的日报，这就可以不开没必要的早会了，有问题点对点找人就行了。可不可以用早会或是晚会来代替日报呢，这使不得呀，后续没法数字化，也不方便以后复盘及追溯。总结起来就是，和工作安排紧密关联的日报可以减少不必要的日例会。
第三、本来填写工时就是有点“反人类”的工作，再加上每个工作事项的工时，要一项一项的填，非常繁琐；有时候还要一项一项的找，让人烦躁得很。
第四、对PM也非常不友好，他要把大家提交上来的日报数据，再去汇总为项目日报等，如果再按时段统计大家的产出，这工作量就要命了。
归纳起来，项目管理中日报是少不了的，工时也要，且还想让工时填报不烦人。既要又要，有招么？
招数就是：采用日报与工时融合集中式填报的创新实现。写日报时集中式填报工时，一举两得，既能解决日报事项和工作安排关联的问题，又能让工时填报省时省力，最终可压缩混子的摸鱼空间，没法瞎编日报了，工时也不能浑水摸鱼了。
Codes 产品团队始终以用户为中心，从用户的使用场景来思考问题，而不是做什么都先去JIRA等同类工具找参考“依据”（这是“小屁孩”的玩法），这样是永远没法创新的，始终会被所参考的“依据”僵化思维。解决用户痛点，如何让用户爽，就如何实现，这也是我们创新的源动力，换句话说就是，不固守陈规，拥抱零基思维。
一、招数有了，有些需求细节要补充一下
填写日报时，要自动列出当日事项；工时主要用来计算进度和产出，那除了当日进行中的事项要填日报和工时以外，名下待处理事项且没有预估工作量的也需估一个时间，如BUG修改，用例执行和开会等，作为其他事项填报进来。
通过日报中今日事项、待处理事项以及其他事项，计算进度时工时的范围就比较全了；
不只是任务，日报中还要有明日计划，同时日报还能发到第三方平台，如邮件、企微、钉钉和飞书等。为了便于统计产出，既要有原始的明细数据又要有汇总类的数据，他们可以相互佐证，且可导出。
二、功能实现之日报填报及集中式工时填写
日报由今日事项、待处理事项、其他事项、以及明日计划组成。日报提交后可以按配置发往第三方平台。
1. 日报今日事项
今日事项，顾名思义就是当日处理过或办理过的事项或当日计划的事项。
日报填写：
自动列出当日处理过的事项前一天提交日报时，明日计划中的事项当天在我的事项中设置为今日事项中的事项如都没有，那只能通过右上的“补选当日事项”，来手动选择今日事项。然后如下图所示，填写工作说明，及工时信息；如有风险还可关联引起风险的事项，可以是潜在风险也可以是已发生的风险，工作台上的风险拓扑图就来自于这里的数据。
如在日报中填写了明日计划，在第二天，我的事项以及全局事项的列表中能看到今日计划这一列为选中状态，且在我的事项和全局事项的今日事项列的TAB中也集中显示出来，方便查阅所有人当日的工作安排。
2. 日报待处理事项
待处理事项，主要是缺陷及没有预估工作量的子需求（有些需求很简单，不用拆分为任务，直接把需求当任务的需求）以及用例，只是对于用例不需要填写预估剩余工时，通过用例执行成本自动计算，在日报中列出来是为了方便查看工时组成成分。
待处理事项的预估剩余工时填了之后，整体的进度才能算得准确，要不然只能开会时PM一个个问还要多久完成。
3. 日报其他事项
其他事项，指临时开会或不在计划内或是突发性的工作等。在日报中记录下来，包括工时信息。
管理本身也有成本，如开会等，或是计划外的其他事情，只要花了工时都记录起来，让一切成本都有据可查。
4. 日报发往第三方平台
5. 日报中从我的事项下勾选了明日计划后，次日在我的事项下相应TAB中今日事项显示为“是”，也可在我的事项下今日事项中查看我的今日事项。如前一天忘了写明日计划，也可当天早上在我的事项下相应TAB中主动勾选今日事项。
6. 管理员可以从全局事项下，查看当日所有人的今日事项，如有优先级高的事项或快到期的事项没排在今日事项中可以及时进行干预。全局事项下，其他列表中，如作为当日事项会显示为今日事项为“是”。
可查询今日到期以及本周到期的事项，然后查看是否作为今日事项以便进行干预，还可进行多种分组显示，如按人员、按项目、按迭代、按状态等。
三、功能实现之日报审批：按产出算工时，不是按打卡时间算工时。
Codes不提倡无意义的卷加班，为了加班而加班对公司和员工是双输，是管理无能的体现，管理层看不到数据，只能通过加班来缓解他的焦虑；
所以Codes的工时中增加工时审批这一流程，写日报时员工可以填一个工时，但是PM或是部门负责人可以按产出来修改员工日报中的工时，这就是工时审批的目的，如果某个任务张三填了8小时的工时，但是审批时被认定为产出只有6小时，就可更改为6小时。
当然也可以关掉审批流程，缺省是打开的，且审批人可以设置为项目PM或部门负责人。
对于填报人来说，一天只填一份日报，但是可能是跨多个项目，如设置为PM审批工时，那审批时不同的项目是不同的PM来审批。
点击状态可查看审批情况，如需要多个PM审批，只要有一位PM还没审批，就是审批中状态。
在日报列表（填报列表中），或是审批详情中，都可点击详情查看日报明细，以查看提交的原始日报内容。
四、功能实现之人员产出及工时统计
可按部门、按项目、按迭代、按人员汇总 ，还可层层下钻到人，比如从项目可下钻到迭代，从迭代可以下钻到人。
五、功能实现之日报查看
分为项目日报和个人日报
先是按项目按天汇总，然后详情中按人分组
1. 项目日报明细,按人分组
2. 个人日报六、功能实现之工时明细及进度既有原始的明细数据又有汇总类的数据，从项目到阶段、到迭代、到部门、到人都有。
七、功能实现之工时趋势
标准的燃尽图中是两条线 ：一条是理想线，一条是实际线。但现实中，经常计划制订后，时不时会加“东西”进来，那燃尽图的标准线就不一定准（且Codes中测试也纳入到迭代中，缺陷的工时没法提前预估），不如我们三条线：预估、实际和剩余（剩余用来反映进度），当然这是仁者见仁，智者见智。
有项目的工时趋势，有阶段的工时趋势，还有迭代的工时趋势，后续还支持个人的工时趋势。
八、功能实现之工作产出汇总
KPI只有在产出精准的基础上才能更好评判，产出也是KPI的大头。Codes 按项目按人分组、实现的需求、完成的任务、解决的缺陷、编写的用例、执行的用例（按执行成本算，不是按用例个数），其他事项以及上述各组数据对应的工时，一网打尽。如下图所示，当然也可导出为excel。
九、功能实现之风险拓扑图
根据日报中的风险，以拓扑图直观的方式显示风险。
十、总结
上述的实现没有技术门槛，抄也没地方抄，只有想没想到用户的痛点，这是考验产品经理的认知，也就是产品力。创新不是为了玩新奇，是为了解决问题。下一次我们来聊聊Codes独有的流程驱动的缺陷管理，也是很酷的功能，欲知后事如何且看下回分解。
本文由 @兔仔7904 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自 Pixabay，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
