大家好：

我是烤鸭。看完春晚小品的心情(除了神马组合)，就跟下面这哥们一样，尬的抠脚。再加上初一跟家人出去一趟，消费是真的复苏了，哪哪都排队。本来还想去洗温泉，给商家打电话一直占线…就能想象有多少人了。最近这几天就好好在家休息休息，再抽空写篇文章复盘下，对技术类管理和绩效的一些想法。

我眼中的管理

“管理”，每个人都有自己的一套见解和理论，没有一成不变的。我觉得是跟行业还有职业有很大关系的，国企、私企，大公司、小公司的管理模式肯定也不一样，适合当下的才是最好的。就像《亮剑》里的李云龙，你说他不懂管理，可是能打胜仗，那个年代需要这样的人。你说懂的话，连上级命令都不听，放在任何时候任何组织肯定都待不下去。

虽然我几年前就带领项目，不过那时候没有什么行政职级，小公司人也少，来活就干。结果是把项目做好就行，领导很好相处、组内的人能力也行，所以不需要考虑太多技术以外的东西。

转折点

转折点是在上家公司做项目，项目做到关键点的时候，技术经理因为个人原因走了，我就临危受命带领十几个人把项目做完。那个时候是真的累，做风口行业又得赶时间。不过直到后来团队解散的时候，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