文档介绍：互联网技术团队的绩效管理-互联网大讲堂-20211222
2021年12月22日
15:06
主讲：
余波 >>> 博客地址
时间：
2021-12-22 15：00至17：00
地点：
互联网大讲堂
群号：
43046设计，再由工程经理兼做几乎是不可能胜任的，这个时候就必须依赖专职的架构人才，成立架构师团队，不然大家就成天火烧屁股了，架构师团队和工程团队的关注点是有很大不同的，前者我们称为创新线，更多关注创造力，后者称为工程线，关注工程吞吐。针对这两条线，我们设置不同的绩效管理方法，用不同的指标进展绩效跟踪。组织结构问题解决了，我们相当于把一台“拖拉机〞变成了“法拉利〞。
正当我们踌躇满志准备上路时，我们发现摆在面前的是一条泥泞的小路，请问法拉利能够跑过原来的拖拉机吗？，即使能够跑过，我想也不敢跑太快吧，一不小心底盘就报销了，舍不得啊，为了让法拉利们能够跑得快一点，我们需要一条高速公路，在高速公路上，我们设定规如此，要求速度到达多少才能够上去，像拖拉机这种压根就不让上了，从而保证车流吞吐，这条高速公路就是流程，当我们已经不是三五个人加几条枪的时候，流程对绩效的影响是巨大的〔因为流程，更多是为那85%效劳的〕。
流程：流程的设计，最怕生搬硬套，我有两个关键体会：
1、注意各协作团队的综合能力配比，关注瓶颈节点，比方收费站，就是高速公路的一个瓶颈节点，还有容易出车祸的路段也是瓶颈节点，直接影响车流吞吐〔排队啊〕，体到我们的工作现场也有类似的典型瓶颈，比方，当QC资源缺乏时，工程质量很大程度上要依赖开发团队自己，这个时候再强调什么理论上的职责分工就是不切实际的，这个时候要通过诸如代码走查制度、加强单元测试来弥补，这其实是一种典型的用开发换测试的做法。目的是打掉整个流程的瓶颈；
2、控制流程本身的本钱，够用就好，开发资源缺乏时，还一定要出详细的设计文档；QC资源缺乏时，还要求一定要有完整的测试用例，这些都是学院派干的事情，靠谱的流程都是经过裁剪的，以牺牲某种特性来换取更大的好处，所谓两权相害取其轻，否如此，我们付出的流程本钱根本上是打了水漂，更重要的是，流程本钱不光是指我们遵循这个流程所花费的时间，还有繁琐的流程所吃掉的工作热情。
文化：在我的理解中，所有的文化都是为了制造幸福感，当一个人幸福并快乐的时候，这本身就是一种强大的生产力，我依然记得在BenQ时，当时的副总张安佐有一句话“每天早上眼睛一睁开，就能够一跃而起的人是最幸福的〞，某种程度上，我们所有人都在追求能够让自己每天一跃而起的事情，比方对于一个母亲那可能是为家人准备一顿丰富的早餐，那么照顾好这个家就是她一跃而起的动力，而之于我们，如果一份工作能够让我们一跃而起，那我们怎么可能没有效率？，一跃而起是源于我们内心对于团队及团队所做的事情的深深的认同，这种认同是一种人性文化的深耕。以上
局部，是有关绩效来源的一些思考
互联网研发团队绩效方案设计：
先要介绍一下技术团队的生存背景，对于一家电子商务公司来说，其真正的产品是“交易效劳〞，交易效劳由两方面构成，一个是产品和技术提供的在线交易平台〔生产工具〕，另外一个是客服提供的过程效劳〔生产〕，而负责将“交易效劳〞卖出去的责任更多的落在营销〔市场、运营〕，持续、快速的交付对用户有价值的交易效劳，是电子商务公司的核心竞争力，对于技术团队来说，持续、快速的交付高质量的平台特性，是技术团队的生存根本，鉴于这样的特点，我们的工程特点是追求短平快，百分之七八十的工程的实施周期都在一周以内，工程规模很小，偶尔有大的工程，我们也是想尽方法把它分解成一二三期，从而降低工程的实施周期，这样做的好处是显而易见的。让一个特性最快与用户见面，是验证它是否有效的最好方法。结合大局部工程周期都在一周以内的特点，我们把工程绩效的度量周期定为一个月，每个月会进展一次绩效回忆，让各工程组总结调整，注意，我们只是把月度作为度量统计的单位，绩效考核的周期还是以季度为周期的，月度的度量，决定工程奖金的分配。而季度绩效考核，影响的是季度奖，为什么不选择月考呢？有两个原因：首先如果每个月考一遍，管理本钱太高了，其次，绩效考核的目的就是在对产能分布进展识别，我们还有20%的跨月工程的，用季度这样的宽度，可以更好的覆盖，让各个工程组之间的比对数据更具参考价值
在上述原如此的指导下，我们接下来谈谈具体绩效考核方案的设计，技术团队绩效考核方案的制定，整体遵守几个原如此：
１、使用工程绩效分，来衡量工程业绩
２、使用非工程绩效分〔事件绩效分〕，来衡量日常工作之外的创新、拓展奉献
３、对于同一类型岗位，使用统一考核模型〔权重和算法可调〕
４、对于差异性较大的小工种，使用个性考核方法
５、管理职能与执行职能考核别离