标签：组织 会些 技术 激励 构建 管理者 团队 心得

原文见这里：技术总监需要会些什么

背景

技术管理者(技术总监/经理/CTO)期望通过体系化的管理方式，能够在百人、千人以上的团队中有效的构建聚焦目标、自我成长、高效能的研发作战团队，快速拿出成果，支撑业务发展。

痛点

• 小团队人员快速扩张，团队文化稀释，人员效能下降，目标逐渐弱化。
• 各团队管理方式及标准不统一，人员管理及协同逐渐混乱。
• 组织扩大后，难以有效关注个人，无法准确评判个人的成长、贡献等。

目标

通过构建完整的研发管理体系，建立管理机制，让技术组织聚焦目标、高效运转，同时激励团队不断优化提升。

研发管理体系构建思考

通过道、法、术、器、势五个维度去思考整个管理体系的构建。

道： 在于文化、思维、准则、价值观、领导力的构建，是思维和意识，它需要我们落到实处。

通常团队小的时候，leader 可以深入到日常的管理事务中，管理者的智慧和想法可以体现在明处并落到做事上。

而当团队规模过百人的时候，组织架构一般已拆分层级，各项目和人员已经聚焦于各自产品线上，甚至人员都已经分布在各个角落，新人的面孔逐渐陌生，此时我们也许需要构建文化，思维，基本准则，团队的价值观和管理者的领导力。

关注团队文化

文化在于使命、愿景、价值观的思考，这个也是组织需要思考并明确的目标。

技术管理者需要深刻理解组织的使命和未来需要解决的一些社会问题；也需要了解客户的真正的痛点，努力达成美好又有价值的结果；更需要明确在组织达成客户目标过程中，需要遵守和秉承的基本准则、宗旨。

管理者最基本的工作就是要亲身践行这些内容，并有意识的传达给一起奋斗的员工，而不是挂在墙上或写在纸上；同时我们也会考虑将组织文化加入绩效考核和入职考试中，以强化团队文化。

建立工作准则

准则在于明确组织达成目标过程中最基本的工作原则。一些职能部门或者特定职业群体会有自身工作的特殊原则和特性，比如技术部的一些工程师文化和思维方式，我们会将这些做为基本的工作原则和独有的组织文化。

工程师文化可以包含有高效、守信、激情、创新、分享等工作原则，它来源于组织的文化，又包含技术的文化特性，技术管理者应该迎合这样的群体，建设这样的团队和氛围。

• 高效：更好更快速的拿出结果。
• 守信：愿意为承诺的结果负责。
• 激情：全身心的投入并感染别人。
• 创新：敢于颠覆现有的模式并拿出结果。
• 分享：将经验赋能给团队，与团队一起成长。

做事的工作思维

思维在于制定目标，完成目标过程中的思维方式。这个在建立和制定团队或者项目的工作目标及关键性事务决策时非常有用，比如用在制定 ocr、kpi、技术选型决策、人员安排等场景。

以下几种思维方式是我们可以参考的：用户第一、奋斗者优先、价值导向、财务思维。

• 用户第一：找到组织或者团队服务面向的客户对象，能够对他们的痛点和爽点感同身受，并通过技术或者产品手段赋能并服务好用户，最终体现产品或者解决方案的价值。
• 奋斗者优先：需要管理者识别并区分出团队成员中不同类型的人（庸人、人手、人才、奋斗者），要把机会和激励留给敢于承担、并和团队一起成长的人，这样的人成长会很快，潜力也往往很惊人。
• 价值导向：做事要明确目标和事情本身的技术价值，产品价值和最终用户可感知的业务价值，我们只做最有价值的工作目标，筛选掉没有价值的工作内容；这是技术管理决策需要考虑的关键维度。
• 财务思维：本质是成本思维；定目标、做事要明确目标和事情本身的资源（人员、时间等）投入产出比。我们允许战略性的投入，长远性的收益，但是做事时我们需要预估、明确和关注；这也是技术管理决策需要考虑的关键维度。

关键岗位的领导力

领导力是一种影响力，是成事的能力；管理者不仅仅局限于管理事务本身，更要关注人、关注团队，要以人为本；技术管理者需要掌握领导力，指引团队，去达成组织目标；可以从“找准目标”、“激励团队”、“影响他人”、“感同身受”这几个维度培养自身的领导力。

• 找准目标：需要技术管理者具备一定的专业能力，帮助团队梳理一个愿景，制定一系列目标；也可以通过一定的感召力，帮助团队成员发现自我成长的动力，制定个人发展的目标；而本质上是需要领导者能够帮助团队找到方向。
• 激励团队：管理者要激励团队、使众人行，而激励本身也是很大的话题；我们可以通过物质上的激励、荣誉上的激励、职位上的激励、成长上的激励等多种激励方式，让团队不断地小步成功→正向反馈→继续成功→正向反馈...如此循环，打造不断打胜仗的氛围和团队。
• 影响他人：领导者需要有一定的前瞻力，去指引团队（它并不一定要体现在专业知识方面）。此时需要管理者拥有一定的学习力，给予团队指导，输出自身的观点，影响他人，提升他人的认知。
• 感同身受：同理心不一定是领导者必备的素质，但这是管理者基本的能力素养。管理者要能够感知他人的情感、团队的氛围，做到有效沟通；能够为团队的成功而喝彩，为团队的失败、自身的决策及相关的结果负责。

小结

“有道无术术尚可求,有术无道止于术”，足以让人明白管理之“道”的重要性。管理是“以人为本”，核心在于目标和激励，本质还是管理者对“人性”的透彻理解，管理的“法”、“术”、“器”的细节和实施最终都源于对管理之“道”的理解和落地。所以有些技术管理者空有方法论，最终实施结果并不理想，这时需要反思落地的管理手段是否真正对齐初心。

法：在于流程化、标准化、制度化的构建，是通过管理制度（法治）方式管理组织。

一般来说小团队人员在 50 人左右的时候，建立基本的研发流程就足够满足日常研发管理。当团队规模超过百人、千人的时候，研发组织也许已经拆分成很多小团队，协作同时也会面临远程沟通的问题等，此时我们会考虑运用常见的流程、标准化的技术、规范化的制度去应对大型技术团队管理的挑战。

将研发协作流程化

研发管理中通常会涉及项目管理和人事管理，所以管理流程一般会围绕项目流程和人事流程去构建，而所有的流程化构建的目的是提升研发效率、降低协作成本，这也是判别一件事是否符合流程化的重要标准。

• 流程化的构建工具：考虑采用钉钉、飞书、OA 系统、TAPD 等等一些协同工具来定制流程解决。
• 项目流程构建：由研发 PMO 等类似角色牵头，在协助组长解决日常项目中遇到的沟通、协作等问题后进行复盘，统筹抽象分析，梳理构建标准化的流程建设。比如项目立项流程、项目迭代流程、项目发布流程、紧急事故处理流程、研发资产申请流程等类似流程都会在这个过程中沉淀下来。
• 人事流程构建：由研发 hrbp 牵头，在协助组长解决日常项目中遇到的人员效率、状态、成长、考核、晋升、淘汰这类问题过程中进行复盘，统筹归纳分析，梳理构建标准化的流程建设。比如试用期转正流程、请假流程、人员晋升流程、招聘流程、面试流程等等。

将研发规范制度化

研发管理会涉及项目管理和人事管理，同样管理制度也会围绕项目流程和人事流程去构建，同理所有规范制度化构建的目的是标准化操作，有法可依，减少或避免犯错。

• 制度化的查询工具：考虑采用wiki、confluence 等知识库相关的工具。
• 项目制度构建：由研发 PMO 等类似角色牵头，在协助组长解决和复盘日常项目问题的过程中，进行体系化解决方案的梳理，考虑从管理维度建立规范，制度等标准化的操作流程机制，避免重复犯错。比如数据库设计规范、分支管理规范、项目发布规范、线上故障处理规范、网络安全规范、项目流程规范、测试用例管理规范、项目性能标准规范等。
• 人事制度构建：由研发 hrbp 牵头，在协助组长解决人员相关问题的过程中，进行全局性体系化思考，协同 PMO 等类似角色共建研发相关人力制度。比如绩效考核评分规范、研发晋升制度、研发招聘制度、研发激励体系等。

将研发技术标准化

在构建整个研发体系的过程中，我们期望通过五个维度（技术一体化，业务一体化，监控一体化，运维一体化，管理一体化）进行体系化构建，其中技术一体化的核心是打造标准化的技术体系。

技术标准化（技术一体化）包含技术/框架选型标准化、技术使用标准化、技术协议/工具标准化、技术结构标准化等。其中开源的bsf框架（基础框架）解决选型和使用标准化的问题，business（业务框架）解决协议和工具标准化及技术选型兼容问题，demo 脚手架项目解决快速构建新项目和技术结构标准化问题。

基于技术标准化的原则，我们也会关注运维标准化、监控标准化、测试标准化等涉及整个 devops 相关的标准化技术建设。

• 运维标准化（devops）：通过构建 CICD 标准自动化流程, 通过 ops 自动化发布，让日常发布交还开发，彻底解放运维工作量；通过构建运维标准化体系实现自动化运维。
• 监控标准化：通过标准化的监控体系构建全维度性能监控和质量分析，通过 oms 自动化监控，让日常问题排查更智能，秒级报警、秒级服务自愈、秒级报告项目质量。
• 测试标准化：通过标准化的测试管理体系、主流程自动化测试体系、自动化全链路压测体系，解放测试部分工作量，保障线上性能和稳定性。

小结

管理之法本质是从流程化、标准化、制度化等维度建立整个“管理机制”，最终的核心目标是通过管理的法治建立标准化的操作规范，再通过标准化的规范提升人员的协作效率、监督机制、系统稳定性/安全性等；技术管理者在实施时勿忘初心，切忌为了管理而管理，一切尽可能从简化人力管理，提升效率为目标而设置管理机制。

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

通常团队小的时候，人员的管理可以由核心管理者亲自安排，所以总体可控。而组织规模稍微大一些，权责必然会下放，组织也拆分成多个业务线或者团队。

为了保证组织规模成长过程中，人员基本管理方式一致，我们需要打造标准的人员管理体系辅助各级管理者，确保合适人员可以识别、引入、培养，不合适的人员可以淘汰；这个过程中技术管理者要和 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 会约谈帮助，视情况再做决定；其他严重影响团队的行为，主管举证后可以决定淘汰；年终整体绩效过低的员工按照适当比例，考虑予以一定帮助或者劝退处理。

小结

一家优秀组织的成功往往包含优秀的人才的成功，管理之术致力于打造整个人才体系，激励优秀的人最终带领组织走向成功。

然而对人的管理是复杂的，因为每个人的诉求和期望都是不一样的，管理者需要对人性有透彻的理解。而技术管理者尤其要理解管理之术终究是手段，只有了解工程师文化，真正的走进技术人员的内心才能有效激励，吾等共勉。

器：在于通过系统化、工具化体系整体提升工程效能，精细化管理。

社会（农业、工业、现代化）发展至今，产能的提升本质上来源于工具的提升。无论团队大小，工具对于研发效能的提升是显而易见的，一些场景下也许可以带来 5 倍，10 倍的提升。

因此技术管理者必须关注技术行业内最新及最佳的一些实践，并评估尝试这些实践所沉淀的一些平台或者工具赋能整个技术团队。

我们在实践从五个维度（技术一体化，业务一体化，监控一体化，运维一体化，管理一体化）构建研发体系，不断在其中引入一些第三方的工具/平台/开源/理念，和自研一些工具或者框架来提升整体研发体验和效率。

• 云平台

云平台的好处是按需使用，简单方便。对于创业型的小公司，可以快速开发上线验证商业模式，减少 IT 运维的很大工作量。

当然云平台从原则上来说规模化会带来成本的降低，实际情况并非如此，上一定规模以后可以适当考虑场景和成本，自建服务器或搭建混合云方式。国内考虑腾讯云、阿里云；国外考虑 aws 和 google 云。与第三方云厂商合作的时候，折扣可以谈一谈，争取 2 折、5 折优惠。

• 云原生

Kubernetes 是最佳的实践云原生工具；在实践过程中，云原生带来的服务器资源的减少约有 30%左右，特别是针对开发、测试、预发环境，使用人员不多不频繁，云原生带来的资源复用，利用率还是很高的，成本降低也会很明显。

云原生不仅仅是在服务上面的改造，也在基础设施上考虑全部云原生化，可以有效提升运维的效率和标准化的实践。

• Devops

市面上有很多 devops 商业解决方案，有一些都会和云原生和各自云平台兼容或者结合。但是可惜的是解决方案做的比较深入，跟自身的一些方案结合比较紧密，反而通用性降低一些，而我们需要的更多是可插拔的定制化方式。

自研 ops 自动化运维平台，配合自定义的标准化 cicd 方式其实更适合自身场景（另外配套其他的解决方案），但是这个不是银弹方案，究其本质目的是简化运维、简化发布。

• 企业协同办公沟通工具

市面上企业协同办公的工具有很多，而且很大部分都是免费的。比如企业微信、钉钉、飞书，从所有协同软件使用的经历来说，个人还是比较喜欢钉钉，当然飞书也还可以，企微最不喜欢。企业协同办公工具，决定了分布式远程办公，异地办公的沟通效率问题，效能提升好几倍；但是小团队成员同办公区域，一般感觉不出来，差异不明显。

• 自研标准化框架

技术选型基本上会考虑热门的语言、主流的技术，毕竟这样的人才会更多，比如 java。开源社区的活跃度，解决方案的成熟度和活跃度也都是考虑的范围，比如 spring 框架体系。特有的一些技术标准的整合和技术工具的整合，比如自研 bsf 框架，business 业务框架，脚手架，可以帮助开发人员一分钟快速上手进入开发，能效提升非常明显。

• 自研效能平台

阿里、腾讯、百度等一些公司都在研发效能平台，期望在研发整个链路上提升人员的投入产出比。

同样，我们也期望能够有一个简单有效的平台，能够将组织的文化、管理理念、制度、研发管理流程等沉淀到这样的平台中，能够实时反馈发现人员、项目、组织的效能问题并及时根据问题思考改进它；效能平台本质的意义在于科学化、指标化、精细化的管理，将管理过程可量化、可追溯、可对比。

这个也是研发体系管理一体化要做的，将管理的事情标准化、流程化；标准化、流程化的事情自动化、系统化；当然过程真正实操，其实挺难，但是团队上规模后必须要做。

• 自研监控平台 pms

监控平台是整个技术平台和业务平台稳定性的最后防线，而最快速度发现问题、解决问题，靠的是体系化的监控平台建设。

很多第三方也提供了商业化或者免费的，开源的监控解决方案，比如听云、skywalking、cat 等。大多数的解决方案其实并不能满足需求，比如一些自定义的中间件、组件、标准化的技术方案，我们需要植入自有的监控，也有一些业务监控和埋点可能需要动态的配置，同时也有一些特有的报警和相关的监控策略及代码质量情况都需要纳入监控体系建设，最终需要组织基于业务场景和管理规范等梳理一套监控标准和经验去帮助定级问题，及时发现问题、指导解决问题，甚至自愈服务。

• 自研全链路压测平台

如果对组织的业务有性能要求并将性能指标作为日常的技术标准及上线标准，我们可能需要全链路的压测平台，定时自动化的生成日常的性能报告及性能预测。其中会涉及流量的录制和精准回放及生成压测报告，最终让压测全自动化，解放测试人员的精力和重复工作。

• 第三方工具

业内最佳项目管理实践有很多，而且很多管理者都有相关的新工具沉淀，这就给其他技术管理者很大的借鉴。比如 tapd、worktile 等都可以使用一下，但是要结合自身组织的实际情况和管理的侧重点。

小结

管理之器引入的是工具和自动化实践所给予我们的效能提升，从而引爆整个技术生产力。然而管理者须知工具终究为工具，真正能带来改变的依然是人。

不同人对同一个工具尚且能带来不同的结果，那么不同的管理方式带领不同的人使用同一个工具最终的结果和效能也许也完全不同。所以技术管理者需要需要警醒，人和管理才是需要长期关注的核心，这样工具才能带来爆发式的提升。

势：在于建立或者迎合组织和行业的形势，懂战略，明方向。

这个时代有很多机会，整体的商业形势及技术形势都在不断地变化着，单纯的闭门造车去打造一个产品的时代已经过去了。

这就要求技术管理者能够对自身的行业商业形势足够敏感，对技术的更新迭代形势足够敏感，并做好提前的规划，所以技术管理者需要掌握或建立内势与外势的变化。

• 外势是外部行业的形势和商业的形势

几年之前互联网高速发展，很多行业都处于行业的风口，雷军说过一句话：“站在风口上，猪都能飞起来”，这句话是为了说明创业成功的本质是找到风口，顺势而为；源自于《孙子兵法·兵势篇》，“故善战人之势，如转圆石于千仞之山者，势也”，意思是善于指挥打仗的人所造就的“势”，就象让圆石从极高极陡的山上滚下来一样，来势凶猛。

而技术管理者需要去感知了解整体行业形势的，及早的配合组织的战略及时做业务的调整。特别是技术领域的变化，比如自然语言处理、人工智能、深度学习等一些新技术领域能够给予业务的赋能和创新，也都是非常有价值和值得去尝试的。一些业内的最佳实践和第三方成熟的商业解决方案（比如蓝鲸、听云、极光等），可以深入去接触及评估，考量这些技术带给业务的复用性，从而降低自研的成本。

• 内势是建立内部的成事的基础和必要条件（造势）

推进一些目标的执行和落地，要考虑天时、地利、人和等多方面的因素，天时指做事的时机是否合适，地利是指成事的资源条件是否具备，人和是指团队的凝聚力和心态。

优秀的技术管理者核心的工作内容是根据目标，建立内部这样的成事条件（造势），帮助团队成员在一堆事务中，找准真正高价值痛点，集结优势资源创造条件，推进并解决它。

比如一些技术的变革和标准化的实施，可以根据当前已经发生的故障（某些重大服务不可用故障）和问题进行复盘（找准痛点单点突破），梳理体系化的解决方案，找技术高 P 进行逐步规划落地。

小结

管理之势是需要让管理者跳出事务执行本身，从整个大局看清楚事情成败的主因，无论大到组织战略，还是小到内部事务的推进，都需要管理者能够深度思考本质，因势利导。

然后管理者依然需要警醒，形势虽然能够带来振幅和机遇，但是优秀脱颖而出的产品和成果才是带领组织走下去的真正实力，所以成事的关键依然来源于本身组织的优秀人才和团队的执行力，才能最终拿出产品和成果。

总结

研发管理体系的构建并没有完整的最佳实践可以直接复用，就如同世上没有一样的组织、一样的心路经历，所以需要技术管理者在不断地感悟中沉淀自身的一些框架性方法论，去应对未来组织发展所面对的挑战。我们依然需要学习、刷新、沉淀、分享、交流，与同路者砥砺前行！

标签：组织,会些,技术,激励,构建,管理者,团队,心得
来源： https://www.cnblogs.com/burningblade/p/16436681.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。