黑钢.384

  • 1603 主题
  • 1697 帖子
  • 5032 积分
  • 身份:版主
  • 论坛新秀 灌水之王 突出贡献 优秀版主
  • E币:2130

技术转管理,会遇到哪些问题?有什么“套路”可循?

2020-6-16 17:15:26 显示全部楼层
工程师从技术转管理,谈何容易!               

半年前,我认识了小张。小张刚刚升了技术总监,手底下管着五十几号人。我这边正恭喜小张高升呢,小张却长叹一声: “大师,还是写代码轻松啊,技术管理太难了。如今这些开发不比我们当年,活布置下去就没动静,到了交付日问他干完了吗,他就找一大堆理由,没一次按点交付的。平时混一天是一天,彼此还不服,总觉得老子天下第一,在座的都是垃圾。”
“那你可以考虑试试工时管理。”
“嗯?工时管理是什么?”
工时管理是什么?
工时管理源自于人力资源的时间管理,是一种历史悠久的传统管理手段,后来被研发管理借鉴出来,应用到各种开发实践中。
工时是员工记录自己花费在每个任务上的时间,在不同的管理系统里有着不同的称呼。例如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元。
部门士气为之一振,打了鸡血一样的抢红旗、抢奖章。
对吊车尾深恶痛绝的小赵,硬是给弟兄们扇风鼓劲儿,把红旗抢到了手。
结语
小张虽然也很高兴,但是隐隐还是有担忧。
“大师,大家光顾着抢红旗,工作真做明白了吗?”
工时管理能帮助团队降低进度风险,提升投入产出比,这是工时管理擅长解决的问题。
但是到底组织是不是真的能够从中受益,光靠一个工时管理是搞不定的。

文章来源于方云数字化研发管理 ,作者谭健

最新评论

楼层直达:
我要评论
0
16
广告
关闭 热点推荐上一条 /6 下一条
快速回复 返回列表