70 lines
8.9 KiB
Markdown
70 lines
8.9 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
大咖对话 李昊：创业公司如何做好技术团队绩效考核？
|
||
你好！
|
||
|
||
本周作客大咖对话的嘉宾是满帮集团高级技术总监兼联席委员会主席李昊，拥有超过10年的技术管理经验，目前在满帮管理超过500人的团队。对于高速发展的创业公司而言，如何保证项目的按时保质交付看起来是对研发管理者的一个基本要求，但这背后其实需要织架构、流程规范、绩效考核和团队文化等各方面技术管理，今天我们就和李昊聊了聊其中如何做好组织架构和绩效考核这两个方向的话题。
|
||
|
||
极客时间：您能简单介绍一下您和您目前负责的工作内容吗？
|
||
李昊：我工作后一直在外企从事研发和技术管理工作，在IBM做过存储、在Ericsson做过基站、在Myriad做过前后端。几年前开始创业，加入货车帮之前，在TestBird做分管技术产品运营的VP。2016年11月加入货车帮后，货车帮又和运满满在2017年底合并成立了满帮集团。目前我在货车帮这边管理整个技术体系以及平台产品运营、企业效能等部门。
|
||
|
||
目前的满帮集团是中国干线物流的独角兽公司，通过人、车、货等多个维度的业务拓展，建立起包括信息、交易、金融、能源等在内的多个事业群，在这个数万亿规模的赛道上独占鳌头。
|
||
|
||
极客时间：在公司高速发展的过程中，如何在保证项目按时保质交付的同时，构建技术团队完善的人员、组织架构和可持续的绩效考核机制呢？
|
||
|
||
李昊：项目按时保质交付看起来是对研发管理者的一个基本要求，但其实背后的组织架构、流程规范、绩效考核和团队文化等各方面技术管理的基础工作必须都做扎实，才能做到。这环环相扣的四个方面，每个都可以写一本很厚的书，但我们这里主要聊聊发展比较快的创业公司里面，怎么做组织架构和绩效考核。
|
||
|
||
先说团队和组织架构的搭建。无论是在TestBird还是在货车帮，我在这上面都花了很多时间，这几年下来面试的人肯定有3位数了，但时间花得是值得的，因为人和组织是任何事业的根基。而团队和组织架构搭建的要点，我觉得有这么几个：
|
||
|
||
首先，一定要按公司的客观发展阶段来搭建团队。早期创业公司是非常目标导向的，成本也非常紧张，这个时候人往往不是很多，组织架构的设置也不会很复杂。在技术团队，要多招通才，保证技术水平出色并且有共同价值观的人进来，这样沟通成本低，大家在条件受限时能高效地解决实际问题。成熟期之后的公司，更加的职能导向，需要在每个职能条线上都有更加专业的人加入，把产品、运营、设计、前端、后端、测试、运维、安全等专业条线搭建起来。这个阶段的难度在于如何看方向，定战略和要结果了。
|
||
|
||
其次，对于一线员工来说，他的直接主管实际上就代表着公司。很多员工觉得公司好或者不好，其实就是他的直接leader好或者不好。所以在团队不断壮大的过程中，基层的技术负责人和一线经理这一层的管理能力一定要跟上。有很多创业公司在高速发展的过程中，一些研发干得不错的员工被直接提成了管理者，但是又没有管理和领导能力的培训跟上，结果导致了很多问题。
|
||
|
||
在组织架构和文化价值观定下来之后，绩效考核相对来说是比较容易的。因为组织架构决定了谁来考核，价值观决定了绩效导向。但是在我们这个行业，真正做得好的公司其实不多，因为技术团队在软件领域要考核输出是很困难的，原因主要在于：
|
||
|
||
|
||
1.和生产制造或者销售等工作不同，软件开发等工作很多是“无形的”，一套软件系统在财务上是算作无形资产的；
|
||
2.对软件工作任务的拆解也是比较主观的，我们经常干的事情就是让技术负责人做一个评估就当成deadline；
|
||
3.设计和开发、部署工作并不是分阶段进行的而是并行的（特别是现在“敏捷”了之后）。
|
||
|
||
|
||
因为这些特点，之前技术团队的绩效考核往往呈现两方面的问题：
|
||
|
||
|
||
1.关注输出的总功而不是有用功；
|
||
2.关注个人的而不是团队的（这方面很需要向体育行业学习，从NBA到英超，现在逐渐都有一些对团队的统计，比如有些主力球星没有在场上的时候，整个团队的传球次数和进攻效率等等，来追求团队输出的最大化）。
|
||
|
||
|
||
举个例子，国内有的技术团队在绩效考核的时候计算代码行数。只要稍微理性一点我们都知道，同样的问题被10行代码解决了，要比1000行代码好得多。我们每天都说要还技术债，实际上代码本身是最大的技术债：一旦有代码被写出来，它的维护和变更都会产生巨大的代价。但同样的，另一个极端：用尽量少的代码解决问题，也不值得推荐，因为如果代码太追求技巧，其他人看不懂，可维护性会变差。
|
||
|
||
再比如，有些技术团队衡量绩效看迭代中的story points。但它更多的是说明团队的总功（velocity），而不是效能（productivity）。用它来作为绩效标准会有两个问题：
|
||
|
||
|
||
1.它是一个相对值，同一个团队处于不同的上下文时输出也不一样，跟踪比较的意义不大；
|
||
2.一旦被当成绩效，团队会把“完成”尽量多的story当成目标，可能造成有用功比例降低，甚至是影响团队之间的协作。
|
||
|
||
|
||
还有一些公司会统计人力资源利用率，如打卡、记录工时等等都算是这种思路的实现方式。一方面，这些被记录下来的时间里面肯定有不少水分。更重要的问题是，高资源利用率意味着团队其实没有时间来响应需求的变更和插入，以及现有系统的优化。数学里面的排队原理说明，一旦资源利用率达到100%，lead time就会趋于无穷大，也就是说，当你资源利用率非常高的时候，很可能你要完成一个事情的时间是趋于无穷大的（到处都在排期，到处都是死锁）。
|
||
|
||
所以，我经常看到国内的团队因为研发负责人没法找到科学的方法说明自己团队的绩效，就先把996搞起来，感觉是用挺悲壮的方式告诉老板“我们很拼吧”。其实996无非是人月神话的变种，我自己是不建议长期搞的。
|
||
|
||
那关于创业公司的绩效管理我自己的心得是：
|
||
|
||
首先，人少的时候不必追求方法论。十几二十个人的时候，老大自己拍板就行了。如果这个阶段你谁好谁坏都不知道，或者你拍下来的结果还沟通不下去，那这个老大就不要当了。
|
||
|
||
然后，在人慢慢多起来的时候，就要找对指标，业内有句话说的很好，“没有错误的KPI搞不垮的团队和公司”，在实践中，主要有以下几个要点，供大家参考：
|
||
|
||
|
||
任何面向不信任员工设计的指标最好都不要有，比如前面提到的把工作时长和绩效挂钩。大部分人到创业公司是想做事的，不要把大家逼成上班的心态。
|
||
先考察团队，再考察个人。我们会通过一些指标来衡量整个技术团队的能力，比如效率方面的上线次数，lead time，质量方面的MTTR，回滚次数等等，都有考察。个人绩效方面，我们是OKR结合KPI来做。OKR⾃底向上，体现个人成长的需求，主要影响职级，不直接影响绩效，是⽬标管理工具；KPI⾃顶向下，根据团队的性质不同，侧重点不同，决定了绩效考核结果，同时也直接影响职级和年终奖。
|
||
这些指标要尽量的标准化，可视化，公开化。比如我们的团队指标是有专门的Dashboard的，因为只有可度量的才是可优化的。再比如我们个人的OKR也是放Confluence上互相可见，一方面这样可以让员工了解其他同事的工作和目标，另一方面这样还增加了团队的横向一致性。
|
||
|
||
|
||
这里讲了很多，主要是希望能够为其他的技术管理者提供一些在创业公司里进行组织架构和绩效管理的经验，作为大家进行这部分工作时的一个参考。毕竟，在一个公司里面销售等团队的绩效是相对比较容易衡量的，而产品技术团队的成本很好计算，价值却很难衡量，所以常常被划成所谓的“成本中心”。越是这样，就越需要有一套合理的组织架构，再通过科学的考核机制，用简单易懂，对日常工作侵入和干扰少的方式，通过数据来衡量和验证自己的价值。
|
||
|
||
|
||
|
||
|