IPD咨询的研发绩效考核管理体系建设

背景

技术管理者(技术总监/经理/CTO)都会面临公司战略执行，公司业绩的压力，以及业务对技术团队支撑能力的期望和诉求。如何打造一支快速响应，高效能，能打硬仗的技术团队？是技术管理者的挑战和必须完成的任务。

痛点

1）技术选型混乱，大量基础技术组件代码重复构建，使用方式不一样；一些坑大家都需要重复踩一遍，关键是踩完了还不能复用经验可能还会在其他项目重复发生。

2）项目最终被业务追着跑，产品设计没有路线图, 整体业务架构没有规划，最终演变成大量业务基础服务重复建设，业务边界不清晰，业务服务职责不清晰。

3）线上事故不断，同一个问题可能重复发生或者一个事故发生后只有用户人为反馈后才能感知。解决和排查问题原因，需要很久分析才能解决。

4）线上服务器管理混乱: 公共服务重复建设，服务器权限不清晰, 发版断服，服务不能动态扩容等。运维忙于处理线上故障和版本发布。

5）研发流程，故障处理流程等标准化制度缺失或不明确; 人员的效能，团队的效能和组织效能无法量化，只能靠直觉和经验。

目标

打造一支快速响应，高效能，能打硬仗的技术团队。

1）技术人员效能提升50%, 整体人员成本降低50%。

2）业务迭代周期提升30%, 实现秒级发布秒级回滚。

3）故障响应速度提升90%，线上稳定性提升90%。

研发体系构建

1）业务一体化构建

业务的一体化（或者称为业务中台），本质是基于功能抽象复用、架构合理性和业务统一管理的视角，通过适度的业务逻辑抽象、弹性的复用功能设计，将产品方案进行抽象、复用和下沉，打造企业级一站式功能服务平台。而这个过程非常考验产品的统筹规划设计能力，架构师的业务理解和服务拆分能力。

个人比较推荐采用ddd的战略设计能力，产品与架构师和业务一起参与事件风暴，并梳理业务的核心流程，明确业务领域中的核心领域，支撑领域，通用领域，以及各个领域的上下文边界，并据此进行合理的业务微服务拆分，并反复验证业务领域模型和细节设计（也可同时采用传统的经验设计进行验证）后实施。同时个人也推荐在落地业务中台的时候，可以考虑把业务中台做“薄”一些，业务的前台做“厚”一些，这样可以保持前台业务的最大灵活性，帮助新业务快速度过探索期。

假如在业务架构顶层设计时候领域拆分不合理，会在未来造成很多的业务架构技术负债而且项目迭代的效能会大大降低。而这些负债越到后面的业务发展，改动越难，影响越大。合理的领域服务拆分，服务调用链路应该是理想的树状或者可预期的规律调用链路。而在实操过程中，我们可以通过观察pinpoint或者skywalking追寻调用链路是否是网状无规律的循环调用结构？此时我们要确认服务拆分是否合理，是否需要重新梳理业务进行优化。

虽然实际上每家公司的业务形态都不一样，若假设业务架构拆分合理（至少满足1-3年左右的业务架构演变），规划好产品技术路线图，项目迭代效能应该可以提升20%~30%。

业务领域图例:

2）技术一体化构建

技术的一体化（不仅仅只称为技术中台），主要解决的是“业务开发人员”使用技术的统一标准化，比如是技术编程语言统一（如java,.net,python），技术选型统一(如分布式的技术选型统一,框架统一)，技术使用标准统一（如日志规范），项目脚手架统一（如项目结构，项目文档统一）等。

我们在实践过程中通常会构建bsf（base service framework）基础服务框架，business framework 基础业务框架及bsf-demo基础业务脚手架去解决业务开发人员的技术问题。

【bsf基础服务框架】解决框架使用，技术选型，性能优化，日志规范及中间件监控等标准。让业务开发人员无需关注底层框架实现，只需按照标准技术规范，专注本身领域的业务开发实践，专注本身领域的业务价值实现。（bsf框架层优先兼容新旧技术选型,推进技术演变,业务开发无需改动代码;同时为运维一体化，监控一体化，管理一体化提供框架级支撑）

【business 业务基础框架】 解决业务之间公共通用使用的类库，比如业务的通信协议，业务的状态码标准（错误状态码）等等，同时也解决一些新旧架构兼容等业务兼容问题。

【demo标准脚手架】 解决业务框架标准化项目结构（或ddd项目标准结构）及文档，让开发人员1分钟生成项目3分钟进入项目开发。

基础框架集成顺序:

标准脚手架结构图:

通过技术一体化的实践，我们比较完美的做到剥离业务开发的（与业务无关的）技术，让业务专注业务的实践，同时底层技术演进和实践，业务开发人员无需关注和配合。那么业务线高级开发人员的比例可以减少50%+，研发效能提升10%+。（当然架构师依旧会深入在某个业务线领域协助业务优化自身的业务架构（如分库分表），让业务性能和稳定性得到进一步的提升。）

3）监控一体化构建

监控一体化的目的在于自动化的产出项目质量报告，并进行实时的预警机制，让业务开发人员只关注业务实践，无需关注线上性能问题（因为一旦有问题，我们就会自动监测）。

监控中心概要图

我们构建一个监控体系用于基础采集指标的收集，其中包含开源的一些采集系统，自建的一些采集指标（插件行使）补充，或第三方商业的工具（如听云等），同时也会动态多维度的项目性能质量分析报告及动态评分和评级，同时根据策略实时进行性能及异常预警到特定人员。

一方面将我们对常见的性能及稳定性问题的分析经验沉淀，形成自动化的监控和报警系统，彻底解放运维人力监控、人力分析预警；另一方面我们自动化的形成质量报告，实时分析出项目的质量情况和相应的解决方案建议（经验沉淀），推进项目质量改进和分析。

最终实现秒级性能及异常报警，实时质量分析报告，1分钟内精准定位问题，解放重复的性能分析和排查，研发效能可提升5%+。

4）运维一体化构建

运维一体化的本质在于彻底解放运维日常的工作,让运维更加关注服务器性能的提升,成本的降低。

在我们实践的认知中，我们认为运维和架构是一体的（至少也是难以分离），假如项目架构和技术层面没有做到统一（各自采用不同的技术选型和项目结构），那么在运维层面也难以做到统一，整体运维的工作量随着项目的数量，不断增加，甚至大部分场景都要单独维护，那么重复性和不必要的工作重复做。

运维自动化概要图

运维的工作是技术中较为繁杂的（包含环境管理，权限管理，网络安全建设，资产管理等等），我们期望在基础设施服务一体化,云原生容器化，运维一站式,CICD一体化,发布自动化这几块就做到运维的一体化。

【基础设施服务一体化】架构和运维推进并在设计初级做到技术选型的统一和项目结构的统一，技术内部团队中只允许使用一套基础设施服务和一套基础技术选型标准，比如分布式相关的基础服务，监控体系，研发管理体系和发布体系。

【云原生容器化】容器化可以有效的节省服务器成本,快速扩缩容和服务持续可用，在技术体系统一的情况下，实践虚机到容器化迁移非常迅速，实际可节省服务器成本约30%左右；同时我们也推进所有的基础设施服务全部用云原生方式替代，进一步降低成本和快速部署能力。

【CICD一体化】在技术一体化的基础上，采用一套部署脚本和机制，满足一键发布服务，一键回滚服务，所有服务版本化，所有服务秒级发布。开发人员无需关注线上部署脚本情况,无需关注服务启动切换，无需关注线上服务运行环境（虚机还是容器）。

【运维一站式】所有运维的定时/监控等脚本分发执行,所有服务器，资产及成本等关键性的运维工作进行统一的管控及自动化平台。

【发布自动化】在技术一体化的基础上，通过可视化流程形式构建整套发布流程和回滚流程，构建审批流程，将版本发布工作交还给项目团队，彻底解放运维的日常项目迭代发版的协同工作。

按照两家公司的不同技术团队（150-200人左右）同等规模下实践对比，运维一体化实践较好的公司运维仅需1-2人，而另外一家公司运维约7人左右，而对整个技术团队的效能提升应该在5%~10%左右。

5）管理一体化构建

管理一体化的目标在于建立数字化，标准化的管理方式，将经验和理念沉淀到系统中，通过数据去指导及验证管理决策，提升整体研发人员能效；同时我们期望将“人治”逐步变成"系统化",让管理者精力更加聚焦业务价值实现。

管理模式演变概要图

在管理实践中，我们将“经验直觉”人治管理方式逐步演变成规范化标准化的人治管理方式（管理成本也逐渐增加），也期望逐步向“数据化”“自动化”的系统管理转变（更加精准，更加实时且直观的暴露问题），通过数据指标进行分析和对比，快速的决策和改进。

从项目初期，我们就推进各个环节的标准化(管理规范一体化)，并制定关键核心规范并落地到各个项目中，但是效果不一定很理想。因为管理者在做业务价值和技术负债的取舍矛盾中，往往选择优先满足业务价值，本质是因为我们没有直观的量化的指标去衡量投入产出比,项目质量的变化,有效业务价值，这个也是最初数字化管理的需求痛点。

管理要“以人为本”，管人要以“人性”为前提，但管理者要有财务思维。研发效能平台将组织架构，组织文化，项目管理工具（禅道/tapd），项目质量（监控一体化）,标准规范（管理规范标准化），缺陷故障（线上bug/故障rca复盘），资源成本（服务器，资产，人员成本），周报管理，激励+成长+360考核等等已知研发体系信息进行分析。

以“员工”为维度产出员工/管理者的职级，任务数，bug数，任务完成度，有效产出量，代码质量，工作时长，有效工作时长，线上故障数，工作饱和度，分享能力，学习能力，成长度，产品价值，技术价值，业务价值等等；

以“项目”为维度产出项目/迭代的人员数，工时数，产品价值(达成率)，技术价值(达成率)，业务价值(达成率)，人员投入成本，服务器投入成本；

以“组织”为维度产出团队/组织的人员数，工时数，产品价值(达成率)，技术价值(达成率)，业务价值(达成率)，人员投入成本，服务器投入成本，任务数，bug数，任务完成度，有效产出量，代码质量，工作时长，有效工作时长，线上故障数，工作饱和度，分享能力，学习能力，成长度等等。

管理者最重要的事：制定目标，带领团队，拿出结果。我们期望通过将管理方法论沉淀为数据化，自动化的系统平台化管理，让管理者更加聚焦业务本身，通过一体化的量化数据增强管理和精准决策（验证管理成果），同时通过系统化降低管理(人员/职能)成本，（百人以上研发团队规模下）整体研发效能提升10%~20%。

术：在于通过招，用，养，留，去五个维度打造人员管理体系。

通常团队小的时候，人员的管理可以由核心管理者亲自安排，所以总体可控。而组织规模稍微大一些，权责必然会下放，组织也拆分成多个业务线或者团队。为了保证组织规模成长过程中，人员基本管理方式一致，我们需要打造标准的人员管理体系辅助各级管理者，确保合适人员可以识别，引入，培养，不合适的人员可以淘汰；这个过程中技术管理者要和 hrbp，共同协作打造整个人员管理体系。

打造招聘体系（招）

招聘体系是人事构建管理过程中非常专业的内容，而技术管理者可能关注工程师文化所带来的不同特点，可以从招聘渠道，人员组织规划和预算，面试流程标准化，试用期考核制度等维度协助完善体系构建。

• 招聘渠道:可以从专业招聘渠道补充和人才引进激励制度建设来完善。

专业招聘渠道补充: 技术工程师常见的招聘渠道有 boss，猎聘，拉钩等,招聘渠道选择的过程中，垂直行业的招聘渠道特性会更明显。高端或者一些合适的岗位，可以通过猎头推荐，也可以通过熟人推荐，在实操过程中成功率和匹配率上会更高一些。

人才引进激励制度的建设: 需要公司内部建立完善内推渠道，相应的岗位激励政策，显式的成功案例，打动人心的招聘文案宣传几个方向努力才能略显成效。当然曾经也见过一些公司的激励政策很好，但是内部宣传和成功案例，对内部员工的吸引和感知不够。也见过一些公司将内部人员推荐面试人数指标纳入技术部门各组绩效考核中，具体效果不得而知，也可以作为参考。

• 招聘计划: 可以从人员组织规划和预算来确定年度招聘计划和财务预算。

人员组织规划：技术管理者需要明确和对齐更高管理层年度的业务方向和期望，盘点自身组织最终需要达成技术目标，产品目标，业务目标，从而根据目标盘点现有技术人员，确定组织岗位规划和相应的招聘计划，协同相关的 hr 达成招聘目标。

预算: 技术管理者要有一定的财务成本思维，做好人员的组织规划后，确定相应研发组织的年度预算和部门预算，同时也要协同 hrbp 了解组织的投出产出比情况；如果中途有人员变动和额外新增人员，可以申请额外预算。

• 面试流程标准化:可以从梳理岗位模型，标准化面试，岗位胜任力模型 ，面试反馈，入职流程，试用期考核制度等多个维度推进优化。

岗位模型: 技术管理者需要协助招聘 hr，明确目标招聘岗位的人员画像，包括相应的年龄要求，能力模型（技术能力要求），级别，岗位职责，薪酬范围之外，也要特别关注技术岗位的能力，所需要的行业业务经验和业务知识的掌握程度。

标准化面试: 通过一定的标准化面试过程+标准化面试题库+经验交流，可以解决部分面试官的面试风格不一致导致面试结果不同的问题。但探其本质是应聘者能力是多维的，答案是多解的，需要规范性面试和面试官主观判断给予相对准确岗位匹配度评价。所以技术标准题库往往用于验证通用性的基础能力掌握是否全面，经验交流用于突显实战解决能力和全方位问题解决思路评估。

岗位胜任力模型：通过标准化多维度较为精准的判定该应聘者是否符合当前岗位，一般会考虑从价值观，年龄，稳定性，能力模型，薪酬等岗位匹配度模型建立岗位胜任力模型，这个对于招聘复盘，转正考核都会有参考意义，这个需要招聘 hr 统筹体系化梳理，建立标准。比如一些技术工作，若非管理岗，会对年龄会有所要求和限制；若非相同工种，技术能力要求和评估都有所不同，这些都是需要在建立模型时需要考虑的。

面试反馈：建立统一的面试反馈，让面试参与者（特别是通过者）填写反馈，关注面试过程和面试感受，同时也是反向筛选面试官，改善面试质量的方法。因为技术面试是专业性较强的面试过程，比如有些时候面试官的状态不佳和经验不足，在沟通过程的措辞和回答都要谨慎，否则容易引起应聘者反感，导致人才流失。

入职流程：根据不同岗位职级，建立快速的入职流程审批和背调过程，是技术管理者和相关 hr 特别需要关注的。毕竟求职是一种双向选择，很多优秀的候选人的错失，是因为漫长等待 offer 流程过程中，有了其他的机会；特别是技术工作者，求职的行业范围和机会也特别多。

• 试用期考核制度：可以从新人入职文档标准化，导师制度，试用期考核标准等方向建立入职后考核转正体系。

新人入职文档标准化: 除基础人事制度外，标准化运维环境，软件基础架构，项目流程规范，相关服务环境等软件环境，梳理必备基础信息文档和开发文档，最终整理新人入职文档，可以快速帮助新人上手，进入业务开发支撑状态；有效避免大部分重复性的一对一非业务基础信息指导，减轻技术管理者的工作量。

导师制度：为入职新人指定转正期间工作导师，协助入职工作环境熟悉，初期业务熟悉计划及答疑，中后期转正考核目标制定与达成及期间团队协作困难解决等；很多优秀技术人才在试用期后的离开，有些是因为新环境的不适应，关注度不够，目标不清晰导致，值得管理者反思。

试用期考核标准：帮助入职新人经历初期熟悉和适应后，一般在 2 周左右协助新人指定试用期工作和考核目标，导师需要协助指导期间遇到的难点和风险感知，帮助新人达成目标并对之进行考核评估，最终考核评估结果将直接关系试用期转正。

打造组织体系（用）

20~30 人左右的团队，其实不必关注太多团队组织问题，一个 leader 带着几个干活的（可能是全栈），直接非常高效率的拿出结果。而当团队成员达到 50 人左右的时候，技术管理者应该要关注和思考组织构建的问题了，我们可以从矩阵组织架构建设，人员梯队建设两个维度建立组织体系。

• 矩阵组织架构建设：从职能型组织，产品型组织，创新性组织三个维度构建混合型组织架构

矩阵型组织架构图

职能型组织：按照前端，后端，测试，产品，架构，技术委员会等职能维度拆分组织，在 30 人以下的团队中，人员的效能和复用性比较好，也非常适用。但是对于人员和产品的专业性深度及成长都会受限，适合业务探索初期。

产品型组织：按照业务领域维度拆分多个业务项目团队，在团队人员超过 30 人以上，就可以考虑专业化分工，业务边界明确，更聚焦本身业务价值和产品深度打磨，也更有利于绩效考核管理。

创新型组织：在业务成熟后期，尝试聚焦新业务创新，在探索初期召集 10 人左右小团队进行快速业务验证，快速迭代，快速体现价值，进行额外绩效激励。

在技术组织实际发展过程中，团队会根据本身的业务特性，团队规模大小，不断演进改变组织架构模式，以应对不同形态的挑战。一般情况下在超过 100 人左右时，组织会呈现职能型，产品型，创新型等多组织共存的混合架构模式。

• 人员梯队建设：从人员类型及梯队，职责及职级划分，AB 角色建设几个维度考量

人员类型及梯队: 组织内技术管理者要识别庸人，人手，人才，奋斗者不同人员类型，要区分普通员工，核心骨干，管理干部，储备人才几种人员类别，从而打造技术人员结构化梯队；一般来说技术负责人，产品负责人，架构师及高级开发往往时团队内最核心，最骨干的人，同样最终所有的激励制度会集中优先考虑，贡献最大，能力最大，承担核心岗位的头部员工。技术管理者要定期对骨干成员要一对一形式沟通激励，并形成机制规范。

职责及职级划分: 所有的员工都将归属到组织，归属到相应的岗位，明确相应的职责，权利和能力的边界，这是管理者用人的基本。所以一般技术成员都会有明确的归属产品线，明确的技术职级/管理职级，明确的岗位类型和岗位职责，这也是我们常说的“一个萝卜一个坑”；然而公司规模较小或创新组织时，人员复用性较强，跨边界和职责的工作会较多，职责和职级界限会相对模糊（比如说全栈工程师），这需要技术管理者权衡和区别。

AB 角色建设: 作为管理者最担心的是人员离职或者其他变动，直接影响组织目标达成。特别是行业业务场景特殊，专业性较强的技术工程师市场流动性不强，合适的人员需要长期培养。在公司达到一定规模或有足够预算时，应考虑全部核心岗位搭建明确 AB 角色制度，互相培养储备人才；在实际场景中 AB 角色的实施，确实会大量减少人员流动带来的业务风险；但是一些行业变动，管理能力问题，重大业务问题等导致的大范围的人员流动，还是需要技术管理者更智慧的管理思考。

打造成长体系（养）

30 人以下的团队，成员的专业能力的成长才是最有价值的，所以一般考虑从实战项目中提升能力。100 人以上的团队，应该考虑体系化的建设，建立学习成长氛围，培养出最符合公司价值观的“腰部”和“头部”力量。我们可以从技术能力模型构建，对内分享体系构建，对外交流体系构建，人员成长预算几个维度打造成长体系。

• 技术能力模型构建：梳理明确的技术职级评级和能力要求。

技术组织一般会分 P 偏技术路线，和 M 偏管理路线两个维度构建整体的能力模型，再从专业能力，管理能力，业务能力等维度梳理公司级职级要求，从而打造专业技术能力模型。对招聘而言应用能力模型，对标技术人员应聘者能力评级；对员工个人成长而言，打造能力模型，帮助个人明确个人能力成长路径和目标，激励前行。对技术管理者而言，通过日常沟通接触，对标能力模型，准确了解并给予管理成员明确的技术能力评估。一般来说，百人左右的技术组织就可以协同 hrbp 制定明确的能力职级划分，小规模的技术团队更多凭借管理者的从业经验主观判断，反而不太必要。

• 对内技术分享体系构建（走进来）：考虑内部建立分享激励制度，建立虚拟技术组织等形式。

核心目标是引导团队学习文化和氛围的建立，逐步形成学习型技术组织。可以从内部技术分享维度，建立技术内部分享制度和相关的激励制度，比如有些公司会有量化技术分享指标落到各个技术团队 kpi 考核或转正考核期，也有公司会将分享次数均摊到个人分享考评或绩效考核中，用于年终晋升参考指标或现场的现金激励，都是不错的方式；

在公司内部建立专业性的虚拟技术（偏职能更细化）组织，比如 VR 兴趣组，React 兴趣组，机器学习组等，用于交流专业深度的技术难题和新技术的发展方向，偶尔可以一起参加外部峰会，也是不错的选择。

• 对外技术交流体系构建（走出去）：考虑创建外部开源社区，参与开源社区和论坛交流，引入外部培训交流资源等方式。

创建外部开源社区：可以由公司技术管理者牵头，通过创办一些黑客马拉松项目，小型的开源项目，公司级技术博客等方式，让一些核心开发/有特长的开发人员，将日常项目中踩过的坑，优秀的解决方案，有价值的技术亮点，有意思的管理感悟沉淀到开放技术博客或者开源的项目框架中并分享给社区，一方面可以让技术人员学会总结并沉淀自身的能力，另一方面可以提升公司级别的技术影响力和技术交流平台。

参与开源社区和论坛交流：开源社区论坛和一些技术峰会代表了行业内顶尖的技术高手的最新思维，最佳实践，最新方向，对于个人技术视野和思路都会有较大提升。技术管理者应当关注同行业类似技术方案或解决方案，利用新技术新方案驱动业务提升，让自身技术解决方案处于业内领先水平。同时争取带领相关技术人员，主动参与和分享自身业务技术优秀的成功案例，寻找技术同路人一起交流完善。

引入外部交流和培训：目前技术行业会有很多的咨询和技术培训公司，无论从项目管理还是新技术解决方案，都有一些最佳的实践经验，新的技术方法论，成熟的解决方案。技术管理者可以复盘最新的一些技术难点或者关注最新的业内解决方案，邀请一些厂商、咨询服务商或者高端技术人才进行一些技术交流或购买一些相关的服务降低公司技术开发的成本。

人员成长预算：技术管理者需要协同 hrbp 一起努力制定整体的成长体系方案，并为之提供一些技术交流经费和相关的激励费用。比如培训的门票，机构培训费用，书籍费用，参与费用，茶谈交流报销等。

激励体系（留）

激励体系的构建是人事非常专业和有深度的一块内容，每家公司自身的业务特性和行业特性，激励的方式，强度，员工主体都有所不同；无论公司规模大小，员工都需要激励，而激励体系由于技术工种的工程师文化特性，不应该着重负向激励（惩罚机制），应该更加着重于物质和精神正向激励（奖赏）两大块，从薪酬体系构建，团队激励体系构建，个人激励体系构建，团建活动制度建设几个维度打造激励体系。

• 薪酬体系构建

一般公司的薪酬体系只有基本薪资，为了让员工的发展和公司的发展能够关联一起，现在很多公司会将基本薪酬拆分为月薪+绩效+期权+年终+福利几种方式，薪酬包也由月薪制转年薪，实践过程中这种方式在确实能够有效的激励员工。一般来说会将月薪的 20%左右浮动会额外作为绩效（绩效考核）和期权（公司股票价值）的激励，年终会根据公司整体发展情况和相应部门发展情况做一定的比例浮动（部门年终奖金池）；但是对于技术人员来说，适当的控制或降低绩效考核的绩效薪资比例，更有利于人员招聘（有些技术人员不太愿意接受难以预知的绩效薪资，即便人事承诺大部分情况下可以全额拿到）。推行薪酬体系变革，尽量不改变现有人员薪资体系，通过额外加薪和新进人员薪资调整逐步覆盖全员。

• 部门激励体系构建

公司上一定规模会拆分多个部门，为了凝聚部门最大团队战斗力，会通过一定的金钱，荣誉等方式给予部门进行激励和预算，而部门激励一定要优先考虑物质激励为主。部门激励的形式有很多，但都只是呈现方式，团队性的活动必须要有经费。技术管理者要协同 hrbp 等角色，建立季度，月度等团队预算标准，部门激励考核机制，相关的团建方案。

• 个人激励体系构建

对于管理者而言，管理要以人为本，要懂人性，要了解不同员工真实的需求，这才是个人激励的关键。有时不必特别关注马斯洛需求层次，技术人员是比较特殊的群体，薪资起点比较高，工作内容具有一定的创造性，所以精神维度的激励可能会比纯物质上的激励更适合。优秀的工程师的激励应该来源于内在成就感，所以理想情况下安排一些具备一定挑战性的工作，有效完成并得到认可，季度/月度的优秀荣誉奖项及部分物质鼓励，优秀解决方案的技术分享等等方式都是技术管理者和 hrbp 可以考虑的。

• 团建活动制度建设

团建活动是一个非常有效的构建团队凝聚力活动，吃喝玩乐只是一种形式。很多公司可能会找一些专业公司做团建活动，中间会穿插很多的团建小活动，这种形式对于销售类职业也许非常棒，但是对于技术类职业效果不是最佳。技术类职业人员大多因为工种原因，缺少频繁的口语沟通交流，性格大多内向，沉稳，专注，而且平常不定时加班较多，睡眠不足，体能上大多偏弱；所以休闲，游玩，泡澡，慢运动类的活动更为适合，或者吃饭喝酒吹牛逼也更为接地气。

激励来源于对需求的满足

绩效体系（去）

30 人以内的技术团队，谈论绩效的意义其实不是很大，管理者可以直接根据平常表现给出准确的评价。50 人以上的团队，基本要开始考虑进行绩效考核，进行统筹性的人员优化机制建设；本质上是通过体系性的建设对人员优胜劣汰，让优秀拔尖头部人员晋升，让垫底无能力的人员淘汰；通过贡献模型构建，晋升体系构建，能效模型构建，绩效考核体系构建，人员淘汰机制构建等维度构建绩效体系。

• 贡献模型构建

贡献模型（考察工作过程）指个人或者团队为组织所做的整体工作过程贡献衡量维度指标模型，核心考核的是工作的可量化过程（工作量，质量，结果），是人力资源和技术管理者评估员工产出的重要参考指标。对于技术人员来说，参与的项目数量，参与的项目迭代数量，提交的任务数，出现的 bug 数，重大的故障数量，分享次数，代码质量情况，价值达成情况（技术价值，业务价值，产品价值），360 度评价结果，上级评价结果等等都可以作为贡献模型的一些指标来源，最终量化的评价个人能力得分；对于技术管理人员来说，直接下属的综合平均得分是其综合能力得分。

• 晋升体系构建

一般来说公司每年会有指定的晋升时间窗口，技术人员根据自身意愿或上级主管提名申请晋升或加薪机会。技术管理者需要协同 hrbp，构建晋升制度化和流程化，根据晋升人员的能力模型，贡献模型，能效模型, 绩效考核结果（包含价值观考核）给予自动化的评估和参考，再根据晋升人员的面谈结果，意愿及个人未来成长规划，最终评估晋升结果。特殊场景下晋升申请，需要额外特殊流程审批和考核机制（比如考虑人员流失，破格提拔）。

• 能效模型构建

能效指标即投入产出比，这个指标也是衡量组织健康工作状态的一个重要参考指标。对于公司来说，定期评估组织/团队的能效情况，是 hrbp 的日常工作，便于及时识别组织问题。而对于技术工作团队来说，工作内容的创造性和复杂度（不像传统行业可量化结果），是导致组织能效评估难以量化实施的本质因素。基于资源的评估模型，可以作为其中一种可行评估的参考方式，通过梳理组织/个人的贡献模型评定其产出价值，再通过组织/个人的资产和成本评定其投入价值，最终量化投入产出比；能效模型构建是比较大的课题，具体实操效果依然需要探索验证。

• 绩效考核体系构建

绩效考核（考察工作结果）指个人或者团队制定和实现目标的最终结果完成度的指标量化模型。贡献模型考核的是目标达成过程细节为主，可以作为问题追溯和参考指标；绩效考核考的是目标实现结果为主，可以作为重要的激励指标。技术管理者不光为结果激励，同样给予过程优秀成长者奖励。绩效考核应包含价值观考核和目标达成结果考核两块，包含个人自评考核和直属主管考核两方面；自评和主管考核结果指标相差较大者，hrbp 和直属主管应及时约谈，帮助考核人认识目标预期期望和差异；考核指标结果直接影响绩效激励，但不影响年终激励。

• 人员淘汰机制构建

人员淘汰机制是不断优化团队能力的一种方式，让不合适的人离开或降级团队是对团队和公司最大的负责，但如何定义“不合适”需要技术管理者协同 hrbp 建立标准的制度和规则去识别。一般来说会根据公司的基本制度规定，绩效考核，主管淘汰权利三块去定义人员淘汰或降级，比如违法基本保密协议等严重违规，在公司层面直接淘汰；绩效考核超过连续两次不合格的员工，直接主管和 hrbp 会约谈帮助，视情况再做决定；其他严重影响团队的行为，主管举证后可以决定淘汰；年终整体绩效过低的员工按照适当比例（按照公司发展情况），考虑予以一定帮助或者劝退处理。

小结

一家优秀公司的成功往往包含优秀人才加组织的成功，管理之术致力于打造整个人才体系，激励优秀的人最终带领组织走向成功。然而对人的管理是复杂的，因为每个人的诉求和期望都是不一样的，管理者需要对人性有透彻的理解。而技术管理者尤其要理解管理之术终究是手段，是有了解工程师文化，真正的走进技术人员的内心才能有效激励，吾等共勉。