技术转管理是多数工程师对自己的职业规划路线，相信我们最可爱的嵌友也不例外，但是迈入管理层以后，是不是真如自己想象得那么一帆风顺呢？其实谈何容易。。。
看看下面我和小张的对话，希望能帮助到准备或者已经转管理的你！
半年前，我认识了小张。小张刚刚升了技术总监，手底下管着五十几号人。我这边正恭喜小张高升呢，小张却长叹一声：
“大师，还是写代码轻松啊，技术管理太难了。如今这些开发不比我们当年，活布置下去就没动静，到了交付日问他干完了吗，他就找一大堆理由，没一次按点交付的。平时混一天是一天，彼此还不服，总觉得老子天下第一，在座的都是垃圾。”
“那你可以考虑试试工时管理。”
“嗯？工时管理是什么？”
工时管理是什么？
工时管理源自于人力资源的时间管理，是一种历史悠久的传统管理手段，后来被研发管理借鉴出来，应用到各种开发实践中。
工时是员工记录自己花费在每个任务上的时间，在不同的管理系统里有着不同的称呼。例如JIRA中叫“Time Spent”，TAPD中称为“花费”，微软叫“问题解决时长”。无论叫什么，本质上都是人力资源成本的一个度量单位，是一个“具体的人和一段时间”的关联。
工时管理是围绕着工时建立起一整套管理方案，帮助团队从被动接受到主动承诺、主动管理、持续改进的这样一种方法。
欧美很多企业都要求研发团队记录工时，记录工时这个功能也在研发管理工具中成为必备功能。微软、Google、Facebook等都要求研发人员记录自己解决问题的时长，甚至对于很多创业公司、高度敏捷团队，大家可能连需求文档都不写，但却会认真记录解决问题时长。
“这么神奇？这是什么原理？”
原理是什么？
因为一个人一天的工作时间是有限的，这些有限的时间做出来的产出也是有限的。
工时管理的原理，就是要求员工记录每个问题自己投入的时间长度，然后通过人和事两个维度分析，来发现问题。
对人，可以评估员工表现，找到优秀员工，聚焦管理资源；对事，可以实现有效预估，和过程中的自主管理。
“听着挺有意思，那我要怎么做呢？”
“你呀，要先从让大家写日报开始……”
写日报咯！
小张听得两眼放光，回去就让团队每天提交日报。
小张手下有三个研发经理，老王资格最老，很是忧虑，“咱们团队都是敏捷型团队，写日报是不是太严格了？”。
这种态度小张早有预料，让老王现场说说，自己团队每个成员都在干啥。老王开始还能大概说说，问细了就完全不知。
“老王啊，你们天天跟团队在一起，都不知道他们每个人天天在干啥，你说，这团队还能好么？”
老王很感慨，其他两个研发经理也点头，于是第二天，研发团队正式开始提交日报。
小张要求每个开发人员在日报里要写清楚，自己每天干了啥，每件事情用了多少时间。
实施两周以后，小张又来找我。
“日报推下去了，大家最开始还挺新鲜，现在又回到老样子。而且团队内部逐渐有了抱怨，任务管理系统里要更新任务状态，还要天天写日报，同样的事儿两个地方做两次，太浪费时间“。
“如此这般、这般如此……”
日报变工时
小张与开发经理们碰头，这个日报怎么样？老王挠挠头，“你说有用是有用，每天看看每个人的总结挺好的，也能发现点儿问题，就是大家觉得太麻烦，两头记录。”
“怎么改合适？”
“反正开发人员每天都要关任务，干脆关任务的时候把工时记上得了，我看系统里的工时日报就可以了。”
“好呀！”小张顺水推舟，“但是，一个任务当天干不完，他的日报里不就少了这个事儿吗？”
“那就要求甭管干完没干完，每天至少记一下，这样天天都全了。”
“就这么干！”
第二天，团队宣布，不用写日报了，只要每天记录工时就行了，团队很高兴，当场鼓掌。
研发管理源数据主要可分为两类：资源数据和资源活动数据。数据分类清晰，可以促进全面地收集数据和合理地存储数据。便于后期数据的分析汇总。
一是资源数据，例如人、组织结构、知识信息等。此类数据变更频率比较小。资源数据最好能全面记录。但受限于法律规定或信息获取手段等，数据的完整性不一定能保证，这里就需要把握一个度，通过长期的坚持和积累，实现数据的不断丰富。
二是资源活动数据，比如开发过程数据、测试过程数据、投产过程数据，生产问题解决数据等，此类数据的记录往往是比较缺乏的。为了更好地保留研发管理活动所带来的资源活动数据，需要建立严格的管理流程和制度, 并配以相应的技术手段，实现活动过程的即时记录。
——摘自《研发精益数字化管理》
延期？逾期？
小张最讨厌的事儿就是项目延期。
有几次大的延期导致客户非常不满，小张覆盘发现，主要问题都在产品和开发这里，前面一拖，后面就只能跟着拖，越拖越远。小张尝试过要求开发经理保证交付不延期，效果很差。
两周后，小张又来找我。
“大师，您不是说工时管理能有效防止延期吗？快教教我，下面该咋干？”
“首先啊，你口中的延期，其实是逾期……”
延期，是指将约定的交付日期向后修改。
逾期，是指在约定的交付日期无法交付。
二者之间的关键区别是：延期是双方沟通后的共识，进度风险已经得到识别和控制，双方都已接受；而逾期则是单方面行为，并没有提前通知客户进度风险。
“可是这有什么关系呢？不都是没办法按期交付吗？”
“要治疗延期，要先治逾期，都不逾期了，延期就好控制了。”
“那怎么治逾期呢？”
“考核什么，得到什么，先学美国大使馆，发布一组逾期数据再说。”
逾期排名
小张回去就翻历史数据，把过去一个月各个团队的需求逾期情况统计了出来，找研发经理一起过。
大家一看，老王团队的逾期率最低，小赵团队的最高。
第二天，小张发布了各团队逾期排名，强调减少逾期是现在工作的重中之重，务必要在这个季度，把逾期率降低到10%以下！
小张点名表扬老王团队逾期率低，希望老王团队再接再厉，其他团队要向老王团队学习。
这下七嘴八舌说啥的都有，有不服的，有得意的，有懵的。
过了一周，老王主动找到小张。
“张总，我有个建议，可以减少逾期率，就是推广起来有点难度。”
“别有顾虑，有建议直接提”
“你看工时记录的这地方啊，还有个预估剩余时间，我琢磨着可以用起来……”
余量估算
小张给我打电话，了解了一下估算该怎么搞。
实现估算也很简单，每个开发人员在填写工时的时候，要对这个任务剩余的工作时长进行评估，填写到“预估剩余时间”里去。
如果剩余时间超过了到期日，就说明这个任务干不完，这时必须上报研发经理。
一周后。
“效果怎么样，小赵，你那边好像又延期了，什么情况，为啥没提前发现？”
小赵哭丧着脸：“估算是估算了，可大家都是按系统设定的剩余时间填了，压根没主动思考剩多少时间，等到干不完了的时候才上报。”
老王想了想：“我们是不是可以做个案例教育团队，强调认真估算的重要性。”
小张摇摇头：“要做，但只教育是不够的，现在是你们三个身上揹着逾期率，但是开发人员自己没有背，压力没有传递下去。”
老王眼睛亮了：“给开发人员做个逾期排行？”
“对，但是只限于团队内部使用，不对外公开比较。”
“我们试试！”
内部排行
各个团队统计了每个任务的逾期情况，拿着数据挨个找开发人员确认逾期原因。大家确认基础数据没问题以后，各团队发布了逾期排行。
小张把研发经理们叫一起，都拿出自己部门的排名过一过，看看谁靠谱、谁不着调。和大家的主观印象基本一致，靠谱的就是大家常说好的，不着调的基本也是大家觉得有问题的。
咬不准的主观印象，一个逾期排名就说明白了。
两周后，逾期率降低到10%以下。
小张：“效果不错。”
小赵困惑：“张哥，这不就是把逾期变成延期了吗？他们来找我说干不完，我也只能延期呀。”
老王皱眉：“我觉得大家预估得更谨慎了，能不能干完也都更上心了，就是产品那边觉得咱们估算时间有点保守。”
“是啊，逾期问题解决了，生产效率问题还在，得找大师聊聊去。”
过去，我们的大部分研发管理是依据经验管理，现在的市场竞争环境与过去相比发生了很多变化，因此研发的管理也需要随之变化，而仅仅依据经验作出的判断往往会有很高的风险。没有数据的企业就像没有昨天、没有历史一样，曾经犯过的错误还会犯，曾经缴纳的“学费”还要继续去缴；没有数据支撑，管理者就无法做到精准定位问题，无法进行精细化管理。
数字化管理可以量化管理研发团队和研发个人的工作过程、工作成果；可以精准分析效率、质量、成本、收益等内容，发现研发行为与工作成果之间的关系以及其中存在的问题，然后根据分析结果来制定改进管理方案，促进优化资源配置、改善工作的方法工具、改善管理流程、提高研发效能。
——摘自《研发精益数字化管理》
预估太保守？
小张call过来：
“大师，我们逾期率几乎没了，但是大家的预估越来越保守，这个怎么破？”
“预估，看的是准不准。不管保守还是乐观，总归是不准。”
“那怎么才能准呢？”
“分两步走，第一步，要度量准不准；第二步，要给团队赋能，教他们怎么评估。”
“怎么度量准不准呢？”
“看任务第一次预估的时间和实际交付的时间，他们的差就是准不准的‘度’。”
“明白了，那怎么才能评估得更准呢？”
“这个嘛，就得细说说了……
精确预估
小张回去就折腾起预估差异率，数据出来几位研发经理一看，差异率都在30%以上。
老王：“预估是老大难问题，不好估啊！”
小张：“把数据拿出来，看看能有什么发现。”
他拿出一张图，这个图将所有任务的实际投入汇总，以人时为横轴，任务个数为纵轴，展示了所有任务的成本分布。
小赵一看就说：“1人天以下占50%，1-2人天占30%，2人天以上占20%，这三个台阶多明显！”
老王：“我们可以把第一个阶段的任务叫‘简单’，第二个叫‘一般’，第三个叫‘复杂’，这样就能给任务分级了。”
“但是怎么能识别出来一个任务是哪个级别呢？”
小张：“把大家组织起来自己看这些任务，让团队自己总结总结经验。”
于是，小张组织研发团队各自面对自己的历史数据，对每个级别的任务特点进行总结，总结的结果收集起来，作为每个团队的任务分级指南。
实施两周，效果明显，差异率下降到20%左右。老王主动要求团队每个月总结一次这个预估手册，持续提升预估准确性。
过了一个月，我见到小张，小张已经不愁眉苦脸的了。
“现在干活没啥大问题了，但是这都年中了，得刺激刺激大家。”
测量要有明确的目标，通过目标来引导方向，围绕目标制订测量计划。测量要结合数据分析，通过分析可以使研发管理的人、事、物之间建立关联，如果没有后续的跟踪分析，测量得到的数据就会失去价值和意义。
1、分类分析法
分类分析法是根据数据对象的特点对其进行分类，再进一步分析，从而进一步挖掘事物的本质的方法，如图2-20所示。
当数据分析的对象数据规模很大时，我们可以按照其特点和属性归类，使类内的对象差异小，具有共性；类间的对象差异大，具有个性，那么我们就可以对数据对象的几个类别进行分析。这样，分析工作的难度和强度都会大大降低。这就是分类分析的价值所在，用类别代替个体，使复杂的事情简单化。
——摘自《研发精益数字化管理》
绩效评价
工时管理能够用来对每个人进行绩效评价。
关注两个指标，一个叫投入产出比，一个是饱和度。
投入产出比 = 任务规模 / （能力 * 工时）
饱和度 = 工时 / 应出勤时间
这两个指标互为矛盾指标，简单说，如果干不出活，还想投入产出比高，就只能少记工时，但是这样的话，饱和度就低。
具体计算时，参数可以这样设置：
任务规模可以根据之前的“简单、一般和复杂”分别对应1、2、5。
能力可以按照职级分别指定，与各个职级平均薪资成比例，比如T3=3，T4=5，T5=7，T6=9。
应出勤时间就是按照考勤系统的数据统计出来工作时间即可。
这两个指标，加上之前的逾期率和预估准确率，分别配上权重，就可以得到绩效评分了。
绩效排行
小张回去就拿数据统计了一圈，做了团队排名和个人排名，找大家一起参详结果。
小赵一看：“我怎么又排最后？我太难了！”
老王嘿嘿一笑：“这排名有意思，你看丁丁，是我们的好员工，投入产出比这么高。你再看亮亮，干得好像挺多，都是简单的事儿，级别这么高还拈轻怕重，投入产出比这么低。”
小赵也来了精神：“我的团队这饱和度成问题啊，怎么这么低？回去得好好教育教育他们，都以为少写点儿时间就万事大吉了？”
老王建议：“现在还是初期，我建议把饱和度的重要性稍微调高点，鼓励大家多记录，等大家饱和度都上来以后，再往下降降。”
工时绩效试运行了一段时间、给予团队足够适应期之后，下半年，小张团队发布了绩效排名。
针对前三名员工，小张做了个流动奖章，并且每个月奖励1000元。
第一名的团队有流动红旗，奖励活动经费3000元。
部门士气为之一振，打了鸡血一样的抢红旗、抢奖章。
对吊车尾深恶痛绝的小赵，硬是给弟兄们扇风鼓劲儿，把红旗抢到了手。
结语
小张虽然也很高兴，但是隐隐还是有担忧。
“大师，大家光顾着抢红旗，工作真做明白了吗？”
工时管理能帮助团队降低进度风险，提升投入产出比，这是工时管理擅长解决的问题。
但是到底组织是不是真的能够从中受益，光靠一个工时管理是搞不定的。
意犹未尽的工程师
不妨认真阅读一下《研发精益数字化管理》
此书同样适用于嵌入式项目
后期我们会邀请作者来分享一下个人从事项目管理的经验，敬请期待！
继续看，有福利！
小编申请了数量有限的书送给大家
助力嵌友在管理岗位
一帆风顺！
规则如下：留言讲述一下自己在项目中遇到的管理方面的问题（可以是自己的，也可以是别人给你造成的），小编会从中挑选幸运的朋友，将书快递给您！（截止日期：2020年6月12日中午12:00）
到时候请留意手机互动留言哦~
