大家好:
我是烤鸭。看完春晚小品的心情(除了神马组合),就跟下面这哥们一样,尬的抠脚。再加上初一跟家人出去一趟,消费是真的复苏了,哪哪都排队。本来还想去洗温泉,给商家打电话一直占线…就能想象有多少人了。最近这几天就好好在家休息休息,再抽空写篇文章复盘下,对技术类管理和绩效的一些想法。
我眼中的管理
“管理”,每个人都有自己的一套见解和理论,没有一成不变的。我觉得是跟行业还有职业有很大关系的,国企、私企,大公司、小公司的管理模式肯定也不一样,适合当下的才是最好的。就像《亮剑》里的李云龙,你说他不懂管理,可是能打胜仗,那个年代需要这样的人。你说懂的话,连上级命令都不听,放在任何时候任何组织肯定都待不下去。
虽然我几年前就带领项目,不过那时候没有什么行政职级,小公司人也少,来活就干。结果是把项目做好就行,领导很好相处、组内的人能力也行,所以不需要考虑太多技术以外的东西。
转折点
转折点是在上家公司做项目,项目做到关键点的时候,技术经理因为个人原因走了,我就临危受命带领十几个人把项目做完。那个时候是真的累,做风口行业又得赶时间。不过直到后来团队解散的时候,CEO跟我聊,作为一个研发你肯定是没问题,不过作为团队leader,还需要锻炼。那个时候很累,心里也不服,实际情况是:团队一直换帅,大家心里早就没了热情,能力也参差不齐。不过静下心的时候思考下,当时是不是有另一种方式,能让自己和团队轻松点,于是报名PMP学习了项目管理。
直到21年四季度的时候,领导说有个机会可以带个团队,那时候我刚考完PMP不久,也想着能学以致用,但是项目管理也团队管理也不一样,而且我学的那版PMP更倾向于大型项目,并不太适合现在互联网的节奏。于是又开始从零开始学习团队管理,符合当前公司氛围的管理模式。我特别佩服情商高的人,能快速的切换身份,知道什么场合做什么事情、说什么话,更是能在不经意间把锅甩给你。
带小团队
搁在以前我肯定会说,一个6个人的团队还讲什么管理,有一个不敲代码的leader,反正我觉得是挺扯的。所以刚接手团队,干的不比大家少,也会试着从技术上"说服"组员。毕竟"talk is cheap,show me the code"。
所以我干的多,我希望你们干的跟我一样多,那时候半夜、周末拉着大家解决问题,再找个机会请大家吃个饭拉进下关系。平时运营、测试反馈问题,第一时间回复并查看问题,基本上能自己查的时候就自己查,团队信任是一方面,另一方面就是有时候确实不太好意思,记得有次晚上12点多运营反馈问题,群里也没人搭理,正好没睡,就给他查了。
渐渐地,又有上家公司的感觉,身心俱疲。后来还是领导多次找我谈心,组长一定不是技术最好的,从技术转向管理是需要一定时间的,团队的信任也是培养出来的。后来尝试把事情分出去,这样自己有时间和精力处理一些组外的事情。
管事or管人
来事情就分活,大家把活干完,这样就是管理么。团队既没有成长,又不稳定,也就是现在不太好跳,搁三年前哪还有人了。按照马斯洛的需求理论,生理需要—>安全需要—>社会需要 —> 尊重需要 —> 自我实现。得问问大家的职业规划,比如 有的人想养老,有的人想学习做管理,有的人想专心搞技术,在能力范围内尽量满足每个人的诉求。
问题显现
有句话是这样说的,没有开除过人的管理者,不是成熟管理者。当然我离管理者还差得远,只是遇到了绩效分配,就感觉很头疼。团队每个人都很积极,各自负责的工作也没出过什么问题。于是我提出了轮流背绩效C的想法,如果团队一直是积极的状态,这种没问题。但是反向思考一下,如果明知道今年无论做得多少,都会背C,会不会多少打消一些人的积极性。在保证团队相对公平的情况下,没有肯定个人的价值。所以我就在想能不能有一套量化体系来决定大家的绩效,这样就都不用纠结了,一切以数据为准。
技术的绩效
KPI or OKR
KPI更强调和结果和战略,OKR更强调过程和个人。所以技术类以okr作为绩效工具比较合适。
维度
之前有人提过,以代码行数来看一个人的产出,但凡干过开发的都知道,这个太扯了。如果一行都没有,那确实有问题,但是不能说行数越多,就是干得越多。
这里我想提出几个可以参考的维度:
-
负责的项目迭代、维护。
-
项目分级制度,第一、第二责任人制度
-
版本迭代研发
-
-
制度规范
- 研发制度遵守情况(不限于开发、上线、中间件等)
- 跨部门问题解决
-
工具生产/解决方案。
- 中间件研发
- 创新项目研发
-
事务工作及横向事宜
- 事务工作推进
- 团队分享
-
方法论沉淀
- 形成合适场景下的理论体系
实用性待验证
我们现在采用的敏捷开发,每半个月发一次版本。每半个月给大家做一次评分,就不用季度或者半年末头疼了。
前2项是有很多小项目的,比如能效、质量、规范等等。按照100分的话,理论上做完前2个就应该至少80分了。
后面3项应该是加分项,具体的小类目需要根据实际情况自己设计。
有几个共识是:责任越多、分数越高,承担的风险越大、分数越高。
如果付出了很多,但是结果不尽人愿,这种需要看实际情况,毕竟OKR不是强调过程的。
其实还缺少了周边的反馈,问问产品、测试、运营等其他接触的人对你的看法。
任何的体系和工具都不是完美的,需要打磨成最适合当前环境的,如果后续有机会试用的话,再来完善这段。
总结
这是我个人从技术转管理的一篇心得,并不一定有实用价值,还需要在后续的工作中验证。
针对技术转管理,做个简单的总结:
- 摆正心态,不写代码不一定就是退步,团队的Leader一定不是技术最好的人。
- 尽快磨合和团队的信任感,一个人再牛也比不上一群人。
- 尊重和满足每个人的想法,to be a good listener,不要画饼。
- 使用OKR做绩效评价,使用量化指标来保证相对公平。
不管在哪个公司,哪个团队,互相都有正成长就对了。如果没有,run就完了。不好run的话,那就努力run呗。
参考文章
https://baijiahao.baidu.com/s?id=1681072629938095162
https://baijiahao.baidu.com/s?id=1736244982868887602
https://zhuanlan.zhihu.com/p/385139247