会带团队的技术人¶

稳定性¶

如何应对事故和做好复盘

衡量系统稳定性¶

• 统计系统不可用时长、次数。

• 按照影响划分事故等级

  • 事故类型：可用性事故、资损类事故
  • 事故前预防：主动治理减少系统风险隐患，重点在于变更管控、可用性设计、应急预案与演练
  • 故事中应急：止血、恢复
  • 事故后复盘：追查根因、改进架构、完善应急、总结经验。

事故分类¶

• 可用性事故

  • 定义：技术原因导致系统部分或者全部功能不可用，业务没办法正常完成对应流程或者提供对应服务。
  • 包括：接口实现、DB设计、中间件实现（偏实现）
  • 特点：发现容易、杜绝难、业务影响明显、应急处理速度要求高

• 资损类事故

  • 定义：系统的功能都能正常使用，但因为逻辑、计算等原因让业务的某一方产生了资金损失。
  • 包括：架构设计缺陷、产品逻辑、隐藏逻辑、业务错配等（偏设计）
  • 特点：非常隐蔽、难以发现，持续时间长、防控成本高，开发同学意识薄弱。

事故应急¶

• 控场：组织排障流程、确定信息沟通秩序、做好线上信息同步。
• 阿里 “1-5-10” 标准：1分钟发现、5分钟响应、10分钟恢复。其核心在于：快。

• 故障发现

  • 主动监控告警：系统监控、业务监控
  • 被动人工反馈：公开渠道、公司内渠道，具有不确定性性，易出现 小故障 * 长时间 = 大事故

• 故障排查

  • 直接锁定：最近变更点与异常现象有直接逻辑关联，进而直接锁定故障点
  • 排除法：当干扰因素过多，很难直接锁定到故障点，就要结合业务场景让整条架构链路上的所有关联方进行自查自证，通过排除法锁定故障。

故障复盘¶

• 复盘的核心不是为了追责或者甩锅，而是最大程度榨干事故的剩余价值，通过全盘的思考与总结，来看看系统设计、流程机制、应急处理、人员安排等各方面有哪些可以提升的地方，哪些问题是共性的，需要在各团队进行“大扫除”。
• 复盘关键
• 复盘建议

可用性治理¶

• 可监控、可灰度、可回滚

  • 变更需要有监控

  • 有效灰度要有耐心

    • 时间：每个灰度阶段至少有5~10min的观察，在监控、日志和各方反馈没有异常后再扩大灰度范围，确保一些运行时异常或量变积累质变的问题可以暴露出来
    • 流量：有时一些业务场景需要特定的触发条件

  • 回滚就是「后悔药」

    • 可回滚的本质是系统的兼容性设计与实现，比如“只扩展不修改改”

• 坚守 Design For Failure 的架构理念

  • “Design for failure and nothing will fail” 最早是AWS 的一条最佳实践，即面向失败进行系统设计。
  • 即考虑系统所有可能发生故障或不可用的情形，并假设这些可能都会发生，倒逼自己设计足够健壮的系统
  • Tip 1、非关键路径都要可以降级
  • Tip 2、核心系统一定要有熔断、限流、超时这些保护手段
  • Tip 3、架构上要避免单点

技术债¶

如何带领团队从困境中突围

定义¶

• 技术债务是由Ward Cunningham在1992年创造的一个比喻，被定义为我们有意或无意中做了错误的或不理想的技术决策所累积的债务。
• 大部分情况下指因为人为妥协，系统的设计和实现没有遵循最佳实践，所以虽然在短期做到了快速交付，但也制约了系统未来的可扩展性，并且埋下了稳定性的风险隐患。

四象限¶

• 无意识

  • 因为开发者能力不足，根本没有意识到债务的产生与积累
  • 比如开发者编写了低质量或者有潜在风险的代码；
  • 对系统的实现和运行不了解，重复代码被大量构造，缺少抽象与沉淀；
  • 缺少完善的开发机制和流程把控，比如测试、文档等方面做得不到位…

• 故意的

  • 交付压力(技术妥协)
  • 因为交付压力进而在技术方案与实现上妥协形成已知的技术债务

技术债的“坏味道”现象¶

• 每次迭代的成本逐渐增加
• 新Feature在测试和上线时Bug率都居高不下
• 几乎没人能清晰地讲明白系统现在的实现逻辑

为什么要重视技术债¶

• 1、影响系统扩展和需求交付

  • 随着技术债务的累加，系统的负担也不断增加
  • 糟糕的设计与实现导致系统变更时需要处理的代码、考虑的问题越来越多，影响最大的是系统扩展和需求交付
  • 大部分与架构及系统链路的设计有关(比如对业务代码缺少抽象，摸块间过度耦合、服务间职能边界不清晰等)
  • 当新业务需求出现时，这些问题的改造和修复成本很高并且大部分问题积重难返，这就使系统迭代非常困难最终影响项目进展使系统无法按期交付

• 2.技术债务的恶性循环

  • 新系统

    • 大部分研发喜欢从 0 到 1 搭建新系统；
    • 因为没有历史包袱，研发同学可以轻装上阵

  • 旧系统

    • 运行很久，出问题时影响大；又因为人员变化多、文档缺失严重，谁也说不清系统的架构，只能通过一行一行读代码，结合业务场景来理解。
    • 很多看似不合理的实现存在各种各样的原因，往往想改又不敢改；等梳理完所有关联后，又发现工作量太大改不动，只能靠打补丁维持；直到某些外界因素发生变化，问题无法再拖延，只能通过一次大的重构来解决。
    • 旧系统其中沉重的技术债务，会导致系统未来的迭代愈发困难；迭代困难会导致交付压力增大，所以只能再次做技术妥协以实现业务优先；进入恶心循环....
    • 如同修复一个破屋，每次修好一点，下次迭代时就会破坏更多...

  • 导致人员流失

    • 随着时间的推移，系统腐化加剧，开发难度越来越大，风险隐患越来越多，开发同学自身成长也有限，自然会导致人员流失。

如何从技术债困境中突围¶

• 找到技术与业务的平衡点

  • 技术债坏吗？既不好也不坏，它是债，而已。跟金融债一样，前期资源不足，借债业务先行；往后债多利息多，债少利息少，借债不还产生复利，直到系统崩溃。

  • 金融债务 vs 技术债务

    • 金融债务：为了解决当前的资金压力，从而在商业上赢得先机，着眼于未来的长远收益。
    • 技术债务：也是同样的道理，通过当前适当的技术妥协换取业务更早的交付上线，尽可能与业务的发展节奏匹配。在业务的发展与变化过程中不断完善而非一开始就追求完美。

  • 深入理解业务，找准还债时机：在功能迭代中变更代码结构，在处理Oncall 中修补文档、完善监控。

• 识别债务，CheckList 如下

  • 处理技术债务的第一阶段就是要识别出技术债务，将其从看不到的未知隐患转变为可视的已知问题。技术债务的度量一直是个难题。
  • 代码：代码重复缺少抽象、未遵守编码规范、代码结构过于复杂
  • 测试：缺乏单元测试、集成测试覆盖不足、测试用例设计不完善
  • 文档：内容错误、信息缺乏、文档过期
  • 配置：版本模糊碎片化严重、环境参数混淆
  • 架构：低内聚、高耦合、调用链路过于复杂、数据非必要冗余、字段使用歧义

• 有计划的分 优先级 偿还

  • 关键链路优先

    • 并非所有糟糕的设计与实现，都能产生严重后果；关键链路意味着业务影响最大，日常的改动频率和事故风险也较高，优先解决它的收益最大。

  • 历史事故命中优先

    • 线上真实问题的发生，相当于已经被证实过这类债务的严重性，所以应该尽早修复，避免类似问题反复发生

  • 可扩展性优先

    • 影响了系统演进，增加迭代成本及可维护性

  • 权责清晰优先

    • 受到历史设计、组织分工（康威定律）的影响，会导致系统的权责不清晰

• 核心思路及关键点

  • 通过CheckList做债务识别，然后定期诊断、水平扫描、债务定级、分期偿还来做技术债务的处理。最终在团队认识、机制氛围、资源保障上下功夫做预防，这就是技术债务管理的核心思路。

  • 提升团队认识

    • 通过项目复盘、系统重构、事故Review等各种机会
    • 通过实际的案例让研发同学清楚技术债务对团队产生的负担，以及对个人能力提升的影响

  • 建立机制流程

    • 比如在方案设计阶段向下深挖一下实现的要点，更多资深的开发参与到架构评审
    • 或者促进团队形成code review的习惯并且达成一个共识标准以提升系统质量

  • 确保资源投入

    • 在通过债务识别和分级后，将还债的投入提前计算到每次迭代中，确保有一定的资源投入其中

大项目¶

把握关键点，谋定而后动

项目分类¶

• 常规项目：开发模式多以项目制、或敏捷迭代为主
• 特殊项目：一号工程（老板的项目）、技改项目（核心系统重写）、倒排期的重大业务

常规迭代项目¶

• 一般流程

特殊大项目¶

• 意义

  • 一些公认出色的同学，都是从大项目中脱颖而出的；
  • 优秀者需要主导或参与几次重要项目证明能力，获得未来发展空间。

• 特殊性

  • 出发点不同，业务期望更大

    • 常规项目：产品研发模式侧重敏捷迭代。项目小步快跑，尽早试错、及时调整，通过逐步完善系统实现量变积累质变。
    • 大项目：完全相反，不再小步快跑，而是“蓄力憋大招”，希望以此建立公司的竞争优势

  • 规模不同，复杂性更高

    • 日常迭代项目：一般以周为单位，以小组为执行单元，需要跨部门协作的往往是单点的需求
    • 大项目：往往是重新建立一个产品或体系，以月为单位，涉及的人员跨多个部门甚至整个公司。需求拆分不细，随着推进会识别新的需求；整个项目动态变化，增加系统复杂度和应对难度。

    • 规模变大，问题放大

      • 比如你会发现跨部门沟通协同比系统Bug难处理，开会汇报项目进度比写代码更花时间
      • 项目往往会倒排期，开发资源永远不够，组织与组织间协同效率低下，在大项目中很常见。

  • 结果评判标准不同，影响更大

    • 日常迭代项目：往往只关心交付的时间、质量，无法在短期内判定业务上的效果
    • 大项目：最初立项就是奔着业务效果去的，所以相对而言，它可以容忍项目过程中的一些不顺利，但看重业务目标的达成情况。如果没达成目标，会浪费前期投入。

• 关键问题

  • 如何达成业务结果
  • 如何协同人与团队
  • 如何解决各种突发问题

• 操作流程

Story Point¶

• 定义

  • 故事点是Scrum团队使用的一种随机度量方式，用来度量实现一个故事需要付出的工作量。

• 要素

  • 要开展的工作量（The Amount of Work）
  • 工作的复杂度（Complexity）
  • 工作中存在的任何风险或不确定性（Risk and Uncertainty）

业务理解¶

深入业务是做好架构的前提

为什么要理解业务¶

• 产品需求并不等于业务诉求。

  • 造成关注点偏移：从业务要解决的问题，变成怎么在规定时间内搞定这需求。

  • 例子

    • 产品需求：需要一匹跑得更快的马。
    • 技术：饲养马、训练马。
    • 业务诉求：快速到达终点。

  • 技术处于价值创造的末端

    • 用户的真实需求 → 业务 → 运营 → 产品 → 技术

• 领域建模的前提是理解业务。

  • 架构要结合具体业务场景来设计。
  • DDD 是目前微服务架构落地的主流思想之一。
  • 深度理解业务才能为逻辑单元确定边界和能力范围。

• 提升团队的使命感。

  • 通过理解业务可以让团队的同学进一步了解自己工作的价值和意义。
  • 技术同学对业务的直观感受大多来自线上的产品和系统。比如，你觉得有些系统设计不太好，但当真正客诉过来，你才能知道或许不那么好、但也没那么糟糕。
  • 感知到自己的代码对真实世界产生影响，所产生的同理心很关键。

如何理解业务¶

• 不要盲信产品

  • 雷军：“永远不要试图用战术上的勤奋，去掩盖你战略上的懒惰”
  • 一个未经审思的流水线
  • 识别和严格把控伪需求和无价值需求，避免让技术同学充当需求的实现机器。

• 建立走进业务的机制

  • 技术领域大体上还是可以通过数据来判断，证明、证伪。
  • 但在业务领域，并不是所有的内容都可以通过数据判断对错，技术人员去理解业务，就是应该加强对业务的认知和体感，毕竟大家日常的思维方式已经很结构化和数字化了，更需要在理性之上去建立感性那部分
  • 要带着发现问题、解决问题的想法走进业务。建议你从客服入手，成本低、效果好、每次都带着任务来也带着问题走，很容易就形成一个可持续的循环。

• 业务上多参会多画图

  • 可以适当参加业务会议

    • 比如运营、客服、BD的月度复盘会
    • 或者给老板做的业绩汇报会，
    • 定期与产品一起参加业务需求的评审会

  • 画各种 架构图和系统链路图

    • 如果说技术了解系统，梳理架构是通过画各种架构图和系统链路图，那么对于业务同样可以结合自己的整理去画 业务流程图。
    • 技术视角的业务流程图并不需要特别复杂，也没必要一定遵守某个标准范式，只要能将「谁在、在什么时候、做什么、产生什么变化」这些画明白就可以了。
    • 技术人员梳理业务流程图时还有一个优势就是可以借助系统和数据来辅助你理解，因为系统是你做的所以你非常清楚数据流是怎样的，中间发生了什么变化，通过追踪数据来研究每一步的处理逻辑进而理解业务的处理步骤。

小结¶

• 图示

架构设计¶

治理好复杂系统才最务实

治理好系统复杂度才最务实¶

• 托尼·霍尔(快排算法发明者)：「软件设计有两种风格，一种是将软件设计得很复杂，以使其缺陷没那么明显；一种是把软件设计得很简单，以使其没有明显的缺陷。」
• 有道理，可能是这几年见多了「过于复杂」的系统，对简单和清晰异常执着。业务复杂所以设计出复杂的系统不是本事，业务复杂，而你依旧能通过 好的抽象与分层将系统做得简单 才是本事。
• 随着业务发展与人员变化，你几乎无法避免系统重构的问题，「系统腐化 —— 重构系统」的趋势近乎必然，背后的原因在于：日常系统的迭代以满足业务需求为主，其他精力都用来解决类似 高性能、高可用 这类明显影响系统「生存」的问题，而对 高可扩展（「长寿」） 的投入会比较少，因为系统的高可扩展是一个相对隐蔽的问题。
• 就算抛除产品和运营等诉求，从系统架构的角度来说，技术价值在商业环境（业务方）中最核心的体现就是让系统实现「可持续的快速交付」。而在这方面表现好的系统也都有一些明显的特征：系统的结构清晰、即使整体繁杂但是每个局部都相对简单，链路干脆直接、没有不必要的冗余。
• 所以，对架构 最核心的关注 点应该是复杂度的治理，即如何在满足需求的前提下，尽可能地降低系统复杂度、保持系统灵活。
• References

衡量复杂度¶

• 实际工作中，虽然能直观感受到系统复杂与否，但却很难找到类似QPS、响应时间等数据指标去准确地衡量它。所以，除了凭借主观感受外，还要参考系统和团队的一些表现特征：

• 理解成本高

  • 需要很长时间才能理解系统模块的组成及运作，比如新成员加入或系统交接时，老成员很难讲完整、新成员不容易听明白，要几周甚至1~2个月才能完全了解系统的实现和运作机理

• 变更牵连多

  • 哪怕是实现一个小的需求都要改造系统的多个部分、甚至多个系统（上下游等），有的还需要协调其他团队或部门，结果导致迭代成本高，并可能引入更高的风险

• 一张图装不下

  • 无法在一块白板上清晰且完整地画出系统主要功能场景的架构图，可能是牵连的系统、服务、组件过多或者链路设计不合理导致的

• 加人无法解决问题

  • 即便你增加人员也难提高系统的交付速度和产出质量，比如原本3个人负责系统，增加到 6 个人的交付产出可能和 3 个人时所差无几，原因在于复杂度过高并且系统结构模糊，很难通过清晰的分工让生产力最大化。

• 如果系统复杂度过高，可能带来一系列问题：迭代压力大、经常延期、稳定性问题频发等。

复杂度的治理思路¶

• 系统发展一段时间后，往往要对抗业务发展的不确定性。所以，或考虑不周、或为赶时间的妥协，在架构上总不完美。
• 注意，不要把「简单清晰」理解为「干净完美」，复杂度治理并不是一个污水净化的过程。在限定 ROI 和考虑到业务不确定的情况下，通过架构的设计与实现，追求系统的可控与可持续。
• 遵照「高内聚、低耦合」架构理念或治理原则，对系统 简化和分治。

• 简化

  • 简化就是去掉不必要的复杂，让设计与实现保持简单。
  • 比如画蛇添足的系统链路设计：业务上本该 A -> B，系统上被实现成 A -> C -> B.

• 分治

  • 分治则是将原本难解决的问题，拆分到可解决的粒度，然后再逐一击破。当然，分治不是单纯的「拆」，而是注重并管理拆分后，不同部分的关联关系。
  • 适当的拆分 可以把复杂度均摊到多个部分，让人均维护的系统复杂度降低。
  • 垂直拆分与水平分层： 垂直拆分把差异明确可以独立迭代的业务拆分开；水平分层把共性的能力下沉隔离。
  • 拆分与合并不绝对，过度地拆分会导致系统无法高内聚，零散分离的系统，会增加稳定性风险和治理与迭代的代价，并且造成大量的协作成本。Linus 曾说：把复杂系统拆分成模块，似乎没有降低整个系统的复杂度，它降低的只是子系统的复杂度。而整个系统的复杂度，反而会由于拆分后的模块之间，不得不进行交互，变得更加复杂。

复杂度的治理实践¶

• 相比 coding 更重视设计

  • “重视设计” 这点听起来简单到让人忽视，如果一个团队重视设计，那么其负责的系统肯定也不会差。

• 永远做 2 套以上的方案

  • 很多时候可行方案未必是最优方案，局部最优未必是全局最优，多几套方案不光能促使你多思考利与弊，也能让你对未来多一些考量。
  • 系统变得复杂，与我们选择最容易的实现方案有关，这就容易出现「为了实现某个需求，只能对系统做复杂改造」的情况，所以不要习惯于选择最容易的实现方案，也不要满足能 Work 就好。

• 从 MVP 的视角考虑设计

  • 从 MVP 去考虑系统要如何设计与实现，先做减法再做加法，比如有些设计去掉之后，系统也可以很好地实现，说明这些设计不必要，因为架构本身也需要「断舍离」

• 关注上下游的实现

  • 上下游的系统就是你负责系统的背景环境，了解它们的实现不仅会帮你进一步了解业务，也会让你避免出现更多的问题（如 API 契约、上下游的超时、降级等）

• 坚持「日拱一卒」

  • 如果日常迭代不能逐渐修复问题、完善系统，那么即使重写或重构，也只是短时间内「刷新」了系统状态，之后系统依然会出现各种问题，不会有根本性的改变。
  • 所以，不要把复杂度的治理当作一次性动作，它应该成为长久的习惯。

• 总之，架构的复杂度治理是为了让系统更简单、轻便，可以更灵活地跟上业务的变化。两手都要抓：先满足业务，后从技术的视角去前瞻业务，通过架构的演进让技术走在业务前面，为业务赋能。

小结¶

• 复杂度是一个隐蔽杀手，对很多人而言属于未知问题；它不会立刻让系统崩溃，但是会逐渐腐蚀系统，更像是慢性病，需要长期的治疗才能克服。

定目标¶

让你的方向与公司的方向保持一致

大纲：“管理三板斧”¶

• 第一板斧： 拿结果。围绕 事情 的三个关键动作「定目标」、「追过程」、「奖优罚劣」。
• 第二板斧：建团队。围绕 团队 建设展开的，三个关键动作：「勤沟通」、「建机制」、「知人善用」。
• 第二板斧：招聘与解聘。三个关键动作：「找到人」、「能落地」和「升级汰换」。

刚做技术 Leader 的人¶

• 角色转变后，从解决自己的问题变为要解决团队的问题，要解决的问题也由单点变成多点，在这个过程中，容易抓不住核心点，最终取得的结果自然会跟预期产生偏差；
• 工作是一个不停拿结果的过程，首先得有一个明确的目标作为参考，知道要拿什么结果、什么是好的结果，最终的交付与开始的目标间差值越小，结果才会越好。
• 怎么才能确定目标呢？
• 三个关键步骤：怎么解读目标、制定目标、传递目标。自上而下确定目标，自下而上完成目标

怎么解读目标¶

• 解读目标就是要确保自己做的事儿和公司的方向一致，顺势而为，没有走偏（「势」即公司的战略和目标），正因为有了目标才有根据目标制定的 KPI，才会有围绕目标的执行动作和最终取得的结果。
• 目标解读大图和解读自问点

• 目标解读的关键点示意图

  • 你的主管，确定你老板的目标是什么；

    • 通过反复对焦，将所有模糊、分歧的点都讲明白，讲到你清楚地知道为什么有这样的目标为止。

  • 你自身所在的团队、团队的成员们，根据团队情况确定现状；

  • 与你紧密合作的上下游（研发）
  • 直接对口的业务与产品，这是业务目标拆解、业务痛点、客户诉求的直接来源方

怎么制定目标¶

• 在这个阶段，核心点就在于把你的方向变成团队、成员的目标；制定目标并不是制定自己的 KPI ，而是团队整体的目标，要从整体出发。

• 4 个关键点

  • “短长”结合：事情分轻重缓急，你一直盯着“急”和“重”，“轻”和“缓”的事情就会转变成“重”和“急”，进入死循环。所以长短期目标是有关联的，达成短期目标是为了长期规划做铺垫，逐步达成一个大目标，但往往很多人会注重短期目标，忽略长期目标
  • 要足够聚焦：一些人在定目标的时候往往会列出十几个关键问题，觉得把问题都解决掉，团队就“干净了”。可这样做反而会因为资源、精力、时间不够聚焦，导致每一个点都没有解决到位。建议关键目标不要超过 3 个，最多控制在 5 个以内，要找最有客户价值、对公司战略最有帮助的点，目标越少、方向越清晰，当问题发生或者需要判断时越容易做决策，在有限的时间内做出更好的结果
  • 要有足够的挑战：系统可用性假如去年是 3 个 9，今年考虑业务会发展保守起见还是力保 3 个 9，这样的目标挑战性就不足，也无法体现技术的价值。这个度量是很考验你的，一旦极端就会出现过犹不及的情况。就好比考试前，你用希望考 80 分的努力可能实际只能考 60 分，但如果告诉你 99 分以下都是不及格，可能你就干脆放弃了
  • 要让组织有沉淀、个人有成长：很多人在目标制定特别容易忽略这一点，但其实制定目标的过程，也是一个让成员不断打磨自己的过程。通过一个个目标的完成，让参与的人得到个人能力的提升，未来可以承担更大的职责，组织也在这个过程做能力的积累与沉淀

• 关于落地

  • 越简单的道理，在做起来的时候就比较难，如何做：定策略、拆任务、细到人。然后结合 KPI 或者 OKR 等考核方式，进一步落到每个成员的结果考核上，目标的达成也就是成果的交付，一定要有考核。

怎么传递目标¶

• 这个阶段的核心是让员工把你的方向和目标变成自己的目标，最终走到同一个终点
• 目标传递的关键点
• 目标的传递是一个连贯的动作，要落到日常的管理动作、重点项目与任务、KPI 的过程管理这些平日的点滴中。目标要反复讲，要经常对焦，重要的事儿，3 遍是不够的，要说“300 遍！”

小结¶

• 解读目标非常重要，切勿陷入极端，要么不解读，要么领导说什么就是什么
• 制定目标一定要够聚焦，但切勿只考虑眼前，注意“长短结合”
• 注意目标传递，要充分考虑团队成员的感受，选取合适的方式

追过程¶

如何用PDCA做过程管理

缺乏过程管理，全凭经验直觉的风险¶

• 范围 越做越大， 本来想解决一个问题，但是在项目过程中，不断识别出关联问题，导致原本计划一个月的重构可能延续半年甚至更久；
• 交付质量 不理想， 项目节奏缺少关键点的把控，加之任务安排不合理，项目节奏一拖再拖，交付质量也随之下滑。

什么是过程管理¶

• 管理就是追求事务的可持续发展，而想要达成这个目标有两个基本点：
• 1、管理动作要形成可持续迭代的闭环；
• 2、管理动作足够简单到可以复制和个性化升级

PDCA 模型¶

• 过程管理的方法很多，PDCA 模型就胜在简单、实用，还能让我根据自己的习惯和积累不断优化。
• Plan(定计划)：围绕着目标明确里程碑，确定关键节点，与执行的员工达成共识。
• Do(做执行)：多给员工空间、多走动、多观察、少干预，放手而非放任，你也不能置身事外
• Check(勤检查)：狠抓关键节点做检查、问进展、问困难、给建议、做辅导、协调资源
• Action(复盘调优)：小事尽快复盘、大事分阶段复盘、事后全面复盘，抓住每一次提升和优化的机会

如何用 PDCA 做过程管理？¶

• Plan：目标的制定要「定策略、拆任务、细到人」。Plan 的重点就是把复杂的任务或项目拆解出它的关键节点与里程碑；才能确认自己应该跟进什么、什么时候跟进、跟进到什么程度。
• Do：怎么拿捏干预的度，这其实是你管理动作的核心。因为计划实施的主角是员工，过度干预会让员工束手束脚，所以给负责具体任务的成员足够的时间和空间，Leader 少干预，日常以观察和帮助为主。

• Check 要做好关键节点的把控与对焦。

  • Check 的误区：
  • 1、到了里程碑和关键点时间才进去 Check，日常对进展不关注、不跟进；
  • 2、把追杀结果当作追过程，与员工不讲 Why，不讲方法，这是“管理者”的常见病。
  • 3、团队 Leader 要清楚，成员需要的是你的帮助和支持，而不是简单的情绪发泄；
  • 4、关键动作不够连续连贯，做出决策或者给出解决办法之后就默认问题已经解决，后续缺少跟进。

• Action的核心在于建立循环，复盘优化。 没有一成不变的计划与执行，只有不断调整的行动力。

  • 复盘前：复盘前的核心在于思考复盘的目的和产出是什么。借此，你才可以明确复盘会议主要会聊些什么，哪些人会参加
  • 复盘中：自省是复盘会的基调，复盘就一个目的“找到团队的不足加以改进，以便在未来取得更好的结果”。所以每个人没必要甩锅，也没必要全盘否定。在复盘的过程中，一定要把问题找准，内部对齐，达成所有人的共识
  • 复盘后：会议有结论，结论有计划，计划有责任人，责任人有行动，要建立机制保证在复盘会上讨论出的结论能够落地
  • 总之：小事儿尽快复盘，借此向团队成员传授自己的经验；大事儿分阶段复盘，抓住重点矛盾，推动事情的顺利发展而非追求完美；事后全面复盘，不管对个人还是团队，找自己的问题都是 ROI 最高的方式，找到问题的一方才有改善提升的可能

总结¶

• 1、目标不会自己长腿走向终点，你一定要做好过程管理以取得可靠的结果
• 2、追过程不意味着事无巨细都要做，追哪些、什么时候追、追到什么程度才是你更应该关心的
• 3、复盘是 PDCA 管理动作中的闭环，如果每次都能提高一点点，长期积累的变化就很大了

奖优罚劣¶

怎样传递我们要什么与不要什么

为什么要「奖优罚劣」¶

• 「奖优罚劣」之所以重要，是因为它能让团队形成可持续发展的氛围，是拿结果的闭环。而我们在这个过程中要注意的就是： 引导人性、而非对抗人性。
• 趋利避害是本能，任何人都希望付出和回报成正比，这是人性所驱。如果你在「奖优罚劣」时，团队中的优等生和差生得到的回报（收益）一样，就是在对抗人性，高绩效的同学缺少奖励，低绩效的同学缺少鞭策，势必会引起不满，影响团队发展。那具体要怎么做呢？

什么是奖优、罚劣¶

• 奖优是通过一些具体的动作（调薪/晋升）告诉大家团队选择什么样的人，鼓励什么行为，罚劣表明团队不需要什么样的人，不能容忍什么行为。 其本质是传递团队要什么和不要什么。也可以理解成论功行赏，按结果问责。

• 奖优

  • 物质奖优作用大、但频次低，如以半年/年为单位的晋升、调薪。
  • 精神奖优体现在日常行为、频次较高，如关注、肯定某位成员的行为，在团队内鼓励、推广他的行为。

• 罚劣

  • 动作而非目的，通过罚劣来传递团队不能容忍什么样的行为。
  • 奖优和罚劣是相互依赖的。

• 误区

  • 没有意识到奖优罚劣的示范作用。要让成员产生想要学习和模仿的热情，发挥示范作用，引导团队风向。
  • 注重罚劣，忽略奖优。当你只能用惩罚来驱动一件事儿时，你未来也只有惩罚这一条路；惩罚带来的是负面的能量和情绪。
  • 奖惩动作过于儿戏，容易被滥用：“奖惩动作”要建立在尊重的基础上，让成员有收获和反思。

奖优罚劣的关键动作¶

• 绩效考核

  • 要通过绩效考核清晰地将我们「要什么，不要什么」明确、公开且坚定地传达给所有人。

  • 容易踏入的陷阱

    • 新人和老人之分
    • 高P和低P之分
    • Leader和成员之分
    • 离职和在职之分

  • 绩效考核对于技术 Leader 而言是一个给团队做体检、给自己照镜子的过程。其中你会发现积累了很多的问题， 问题多不可怕，不知道问题、看不出问题、对问题视而不见才真正可怕。

  • 目的：让大家看到付出和能做出好成绩的同学，回报是远远高于其他人的，对于拖整体后腿、持续不能改善的同学，团队是不欢迎的。

• 绩效面谈

  • 核心出发点

    • 绩效面谈的核心出发点是通过这次绩效的结果改变某些行为与认识，让团队在未来取得更好的成绩，并不是单纯地通知结果。

  • 绩效面谈流程

    • 开场定基调：讲清楚你们接下来要谈什么、怎么谈、过程是怎样的，让成员明确这是一个可以平和而坦诚的场合，沟通是为了彼此更好地发展与未来。
    • 员工自评：听员工讲自己对绩效的理解，以倾听为主，这一点是最重要的（不建议你讲的比员工还要多，真诚且认真的倾听会给你带来更多的收获)不要随意打断对方，不清楚的地方可以问但要让员工完整表达出自己的理解和认识，从中可以看到员工自己的感受，也侧面反映出对组织、对管理和对你是怎样的态度。
    • 主管评价：结合绩效考核的结果，以及刚才员工自评的内容，逐条说出你打分的Why，要给出你的观察、你的思考。
    • 对焦共识：往往员工自评与主管评价会有落差，这个落差往往是双方所处角度和所思考问题的方式不同造成的。这些分歧要掰碎了、揉开了，一条一条地聊透。
    • 面谈总结&后续跟进：管理动作一定要形成闭环并且可持续。 换句话说，面谈结束后你一定要有所行动，光说不做不仅会让大家丧失对你的信任，这是大忌。

  • 除此之外

    • 除此之外，在整个绩效面谈环节，不排除有同学情绪会比较激动。作为Leader要保持清醒，不要陷入情绪化的对抗中。
    • 可以体谅但不能对结果妥协，不能用情感和主观去驱动你的逻辑，带有同理心地从理性的角度探讨并陈述事实，讲明原因和背后的思考才是你最正确的选择。

• 薪酬激励

  • 薪酬是对绩效和结果的激励，如何分配这些资源为未来创造价值对你来讲就成了考验。

  • 薪酬分配可操作空间很大，三个基本原则

    • 1、问自己是否敢将资源分配的逻辑与规则在阳光之下讲出来。一个逻辑越是黑盒，问题与矛盾就会越多，可能不需要你真的公布出来，但是你具备可以正面讲出来的能力。
    • 2.、别做大锅饭，让好的结果超出预期。资源分配时，最忌讳的是想「不患寡而患不均」；想让每个人都满意的结果就是所有人都不满意，这与奖优罚劣的初衷相违背。对于绩优的同学，参照8/2原则，可以更极端地超出预期，他预期100 就给他 120。
    • 3、面向未来而非现在去做考虑。资源的有限性决定了必须有取舍，是要苟且还是要断臂求生，这个决策一定是要 Leader 来做的，你应该面向未来去权衡。

  • 小结

    • 资源总是有限的，资源分配本身是博弈，有人多就要有人少。
    • 平均分配的结果不是普天同庆，而是所有人都不满意，每个人都觉得少。与其如此，不如把资源倾斜到那些你团队最优秀、绩效最好的同学身上，让他们得到预期的收益甚至超出预期。

小结¶

勤沟通¶

在信任的基础上，让沟通简单且纯粹

沟通的核心原则¶

• 理解沟通

  • 沟通是内心想法和思考逻辑的外延。
  • 沟通就是通过在整个团队中营造公开透明的信任氛围，保障团队内部的信息流通，让团队成员能根据信息做出利于工作的决定。

• 错误做法

  • 但实际上，很多人会有意或者无意地过滤信息，让团队内存在信息差（Leader 知道团队成员不知道的事情），进而主导一些决策和工作安排，从而让团队成员因为缺少关键信息，难以彻底发挥自己的价值和创造力。

• 核心原则的定义

  • 在相信对方的基础上，让沟通氛围变得“简单且纯粹”。

沟通的不同维度¶

• 阿里：「向上沟通有胆量，平行沟通有肺腑，向下沟通有心肝」

• 向上

  • 如果你确定领导方案本身存在很严重的问题，我建议你在会上提出。虽然我们重视人与人之间的沟通，但项目以及沟通的目的是事情本身，事情要搞砸了，再顺畅的沟通都没有意义。
  • 而你需要注意的是沟通方式、技巧、口吻、语气，比如你可以肯定和老板方案之间共性的部分，对于差异点应该说明自己的判断和思考，并且尽量用事实和更好的方案来佐证，而非“你觉得”。

• 平行

  • 平行沟通有肺腑是指你要真诚沟通，不要油滑套路。
  • 把业务方当作合作伙伴，甚至是你的客户（为他服务），就应该抱着解决问题的态度与其沟通，尝试着重新梳理资源或在你的职权范围内微调项目优先级，或者进行需求的合并，又或者借助其他团队的力量完成这件事儿，如果实在解决不了，再跟业务方共同努力寻求一个最佳方案。
  • 总之，你能不能解决是一回事，但你是不是真的想帮他解决问题又是另外一回事儿，我相信对方是能感知到这两者的区别的。
  • 另外，你可能会觉得平行沟通有肺腑意味着“直言不讳”，行就是行，不行就是不行。其实在我看来，“直言有讳”才是真的懂得沟通，也意味着你真的站在对方的角度去考虑问题。

• 向下

  • 向下沟通有心肝是指有同理心，有尊重的同时要感同身受。
  • 如果下属犯错，好的方式是严肃但是不情绪化地做沟通，围绕事情本身来沟通，客观地表现出自己的态度，并告诉犯错方事情的严重性。

沟通的不同场景¶

• One One 沟通

  • One One 的沟通不应该有特定的时间和场合，沟通成本低、容易调整沟通的深浅，要注意三点：

  • 接地气，说人话

    • 不必整个话题事情拔高，讲官话，讲意义，比如战略层、价值观、公司文化；
    • 沟通的内容最好是团队成员容易理解的、关心的。

  • 视人为人

    • 要尊重并考虑对方的感受，注意“人性的傲慢与偏见”

  • 沟通要“勤”

    • “勤”并不是单纯指时间和频率，而是说，你要一直对团队成员以及大家主要做的事儿保持关注，当发现一个合适的契机后就主动发起沟通。
    • 比如有同学最近状态不好、或与他人发生不愉快；要善于把握时机，以事情作为切入点，就事论事地进行沟通，会对团队同学有很多的提高和成长

• 团队沟通

  • 团队沟通目的性更强，频次不高，考验你的控场能力。
  • 最关键的应该是搭场子，类似新组建团队、新人加入、年度考核、事故复盘等重要场景。

建机制¶

规则流程越建越多，为何效果越来越差？

理解机制¶

• 规则和流程都是某种机制的具象化；
• 通常我们为了解决某些问题、达成某些效果会定义一些规则，希望人和事物发展在规则内进行，这就是一个建立机制的过程，而机制的落地的方式则是很多事物的组合（人、流程、工具、信息等）

机制的作用或目的¶

• 通过机制让团队有统一的行为与规则，让组织像人一样，言行举止有规律可循

如何设计机制¶

• 背景

  • 比如因为问题和环境已经发生变化，但是原有机制没有随之更新，不再合常理；
  • 比如为了解决 1 个问题所建立的机制又源源不断地制造了新的问题
  • 不要着急着推翻重来，而要明确 “解决什么问题，想要得到什么结果”，先了解问题、梳理思路然后再想办法调整和优化。
  • 建机制是一种管理动作，因此遵循「简单、容易理解、便于操作、完整闭环」的原则

• 三个关键点

  • 规则统一，不自相矛盾

  • 简单有效，便于增删

    • 不要设计需要成员用 10min 理解的机制；
    • 机制的设计一定要围绕某一个要解决的问题，否则 Cover 的场景越多、条件越复杂，用的时候就会面临很多困难，机制本身也很难真实地发挥作用。

  • 紧盯整体结果，机制的 ROI 要足够高

    • Bad Case：比如有的 Leader 为掌握团队的开发工作，要求每人每天按照一定的格式书写日报，然后由他进行汇总。也许这个机制确实会帮团队发现一些问题，但也会增加低价值工作量，成员大量的时间在做计划和总结却没有精细化执行。
    • Good Case：树立机制的维度可以围绕 4 点：奖罚、反馈（当发现线上出现异常时，怎么把相关信息反馈到对应的负责人）、沟通（周报、OneOne）、决策（需要多人针对某一个问题给出具体的答案，比如决定某一个技术方案）

如何落地机制¶

• 需要所有人形成统一的共识 3点内容：
• 先说 why： 即机制的内容是什么？为了解决什么问题？你在设计机制时是如何思考的？
• 共识的要与不要： 和大家讨论我们要不要这样做？看看大家是怎么想的，通过对话和引导形成一定的结论，有些内容需要保留，有些不合理需要剔除，促成结论最为重要。
• 承诺行为举止： 确认机制之后，需要让结论形成对各自行为的约束。比如不同的成员认领不同的角色和任务，或者在 IM 中一起公告规则，总之每个成员要与机制的参与感。

小结¶

• 希望团队内所有成员都按照统一的方式去合力解决一个问题非常困难，而建机制在某种程度上就是 为了解决「群策而不群力」的问题。
• 另外，每一个机制的创建都存在成本，如果一个组织内名存实亡的机制过多，那么大家对机制的认识和执行都会越来越差，最终团队会一盘散沙、毫无凝聚力。
• 反之，设计良好的机制会让团队整体的执行力提升，并且最大程序的将每个人的能力与特长整合起来。

知人善用¶

借事修人，借人成事

理解知人善用¶

• 建团队最后一个动作：借事修人，借人成事。
• “人” 与 “事” 相辅相成，如果把事情安排给对的人，不光会取得好结果，人也能得到更多的成长。

知人善用的三个关键¶

• 找对人（寻找）

  • 自问一下：你是否了解团队的成员？并清晰说明他们的特质（特征）？
  • 而所谓的找对人就是指：你要有意识地观察团队成员，寻找不同的特质，这些特征往往是一些闪光点。
  • 比如张三非常愿意和他人沟通，能够把复杂的事情讲得很简单；李四代码质量很高，再复杂的逻辑他都能处理得很清晰。

• 培养人（培养）

  • 找对人之后，还需要培养人。培养人是指：为事情找到匹配人选的同时，也为有良质的同学安排特定的工作，借事修人。

• 养成人（出师）

  • 古话：“青出于蓝而胜于蓝。” 要想养成人，你对他的要求和期望一定要是超过自己的。本质上，养成人是互相提高的过程：你希望他比过去的自己更出色；你也会比曾经的自己更出色。
  • 这样，双方才会有一个更好的结果。不要受“人性所趋”，认为我培养一个人，他肯定不如我，如果存在这样的想法，后果很容易是：带的人都不如你，自己也得不到成长。
  • 总的来讲，“找对人——培养人——养成人”是一个过程：你首先要通过观察、了解，发现优质的成员，针对性地培养他（无论是性格，还是软技能，或者硬技能）最后通过养成人达到彼此提升的目的。听起来，这个过程十分简单易懂，但在实际操作时需要格外用心，而且不是所有的团队管理者对这方面都有清晰的认知。找到合适的人、创造让他成长的机会、给他帮助并同时提高对自己的要求，在做事的过程中让人也不断成长与提高，可以说这对管理者本身也是一个持续成长的过程。如果将这整体看作一件事，那么这也是在对管理者本身“借事修人”。

如何落地知人善用¶

• 团队盘点

  • 公司在做年底考核时，会做人才盘点（比如能力、潜力、价值观等），其实你自己也可以经常做团队盘点（和公司的人才盘点类似）。
  • 定义你认为对工作结果有主要关联的能力维度，然后将团队同学根据你的观察做不同的匹配，最终将这个盘点结果可视化作为自己未来判断的一些依据。
  • 当有具体的工作出现时，可以根据这个盘点结果判断团队成员目前担任的工作与其能力是否匹配，对其的成长是否有帮助，从而决定进行相应的调整。这样能有效地提高你用人、识人的能力，深入了解团队成员的长短板，帮你找对人。

• 激发意愿

  • 激发意愿指的是：很多同学能力不错，但是投入意愿不足，影响最终结果。
  • 换句话说，很多同学不认可现在正在做的工作内容、担任的职位等。这时，Leader 要主动与他沟通，和他一起确认自己想要什么，想要变成怎样的状态或角色，具备什么能力，主动明确当前工作对他目标达成的作用与影响，把他内心想做这件事的热情激发出来。

• 改善计划

  • 可能很多时候都觉得改善计划是针对一些改善计划表现比较差的同学，但从我过往的经验来看，大多数改善计划往往对一些表现优秀的同学更有帮助，他们会针对性地弥补自己的一些短板。
  • 反而对一些表现比较差的同学来讲，改善计划几乎无用。所以你可以围绕一个同学的成长提高点，结合具体的工作内容、与他一起制定改善计划，从他内心意愿的激发到你给予的帮助一起，逐步提升。

经验之谈¶

• 不怕没缺点，就怕没特点： 借人成事，不能一味地关注他的缺点，而是要寻找其特点，发挥他的擅长点，有缺点不可怕，就怕没特点。
• 新人做老事，老人做新事： 如果在团队中老人一直做老事，新人做新事，那么会出现老人没有新的提高，新人也要克服很多未知的困难；反之，可以重新激发老人的活力，也让新人有借鉴之处。
• 不要越俎代庖，什么都自己上： 用人的过程中会出现「事情做错」的情况，一旦你发现这样的情况，千万不要直接去帮他纠正，这样无法帮助团队成员成长，团队成员只会当犯错误时，等着你来帮他解决。好的 Leader一定是要在明知前方有坑（这个坑一定是你能控制的）的情况下，也要让团队成员去踩一回，让其有试错的机会，让每个错误都物有所值。
• 给机会的同时，给压力和帮助： 很多时候压力是成长的催化剂，有了压力也就有了 120% 的动力，所以把某个任务或职责给到一个同学的时候，也要把适当的压力传递过去，让他感受到事情的重要性。与此同时，时刻关注，该给的帮助一定要给到，不能不闻不问。
• 既敢于承认错误，也允许别人犯错： 好的 Leader 在培养团队成员时，既要让团队不怕犯错（敢干事），也要敢于承认自己不足，去改善去提高。

找到人¶

招聘是 Leader 的事，不是 HR 的事

理解招聘¶

• 作为团队的一号位，自然最应该了解团队现状，以及团队需要的人选。同时，找到合适的人对你的影响最大而非 HR，因为你才是对团队 “生老病死”、进人和离人最直接的决策者和结果的影响者，你既要为招来的人负责，也要靠其去优化并改变团队的现状。
• 逻辑：主动出击、寻找合适的人。
• 三个步骤：定需求找人选、面试甄别、做决定。

定需求找人选¶

• 思考一个辩证的问题：加人能不能解决问题？

  • Brooks法则：“向进度落后的项目中增加人手，只会使进度更加落后。”

  • 原因如下

    • 时间上赶不及： 新加入的成员需要花费大量时间理解业务和系统，并不是人员到位之后就会立刻发挥作用，这个周期可能是几天也可能是一两周。
    • 拖慢整体进度： 新成员加入势必要老人花费时间与精力帮助他们熟悉系统，老人反而增加了任务，影响整体进度。
    • 质量上有风险： 新加入的成员在短时间了解业务和系统基本情况后，为了赶进度就会尽快上手，但是因为系统复杂度很高，会有更大概率交付Bug，后期要么是风险增加，要么为了覆盖这些风险要额外多做很多事，最终看进展可能和不加人时所差无几。

  • 因此，招人不是无目的、无脑、无意识的加人。

  • 反对🙅：大部分管理者都希望自己的团队规模越大越好，能管理更多的人，能 hold 住更多的事情，从而证明自己的价值。

• 该如何做呢？

  • 明确业务目标
  • 盘点团队需求

  • 做出岗位设计

    • 强调一点：在形成岗位 JD 时，你要做好假设（脑海里要有画面感），假设已经有人符合 JD 的要求，那么他加入团队之后，大家是怎么配合的？他如何展开工作？团队的运转是否能严丝合缝？这些都要提前考虑下，这也涉及面试甄别的内容。

  • 提炼岗位要求

面试甄别¶

• 好的面试习惯

  • 面试前看简历：不管是出于对职位的重视，还是更彻底的人员考察，建议在面试开始前花 10 分钟“细看简历”，思考其中你感兴趣的内容，结合岗位的需要，简单设计面试题。
  • 面试中更多倾听：不要随意打断候选人的发言和思路，学会倾听 > 不断提问，只有他说的多你才能考察到更多。
  • 面试后速写评价：经常在面试完要去参加其他的会议，当第二天 HR 问我的面试评价时，当时的感受已经忘得差不多了。所以你在面试完候选人时，要立刻记录下面试评价（这时，你的主观意识会更强，感受更强烈），同时也加快面试反馈的时间。
  • 面试技巧：“问事实——看能力——闻味道”。

• 问事实

  • 结合框架 STAR：情境（Situation）、任务（Task）、行动（Action）、结果（Result）。也就是：在什么样的情境下？候选人的任务是什么？采取的行动是怎样的？结果如何？
  • “问事实” 并不会侧重考察业务或者技术，也并不是完全对能力的深挖，更重要的是：看候选人所说的内容他是否真正做过，以及他的思考过程。

• 看能力

  • 技术能力（比如编程语言、工程化、性能优化、稳定性等）；业务能力（比如候选人做过电商，那就看他对电商领域的理解深度与广度）。
  • 当候选人准备充足，应对一些纯粹的技术问题，问题可能是 "背出来" 的，并不代表他有解决这类问题的能力；要把纯技术问题与业务场景相结合起来问。

• 闻味道

  • 直白点儿说，就是看候选人与你、与你们团队是否合得来，你们是不是同路人，是否可以一起共事，会不会为团队发展一起努力？如果味道不同，很可能对团队造成不好的影响，拿不到好的结果。
  • 那怎么闻呢？交流中的感觉占据很大比重，其次是一些回答的倾向，比如有些候选人不管你问什么都会先反驳下你说的可能，那么有可能你会觉得他比较傲或者沟通困难，但是在他看来自己并没有什么问题，所以闻味道是一个比较主观的事儿，和找女朋友类似，并不存在客观标准。
  • 个人倾向候选人特质：皮实、自省、乐观、聪明。

做决定¶

• 一边觉得候选人不太合适但是也不是不能用，一边业务压力大非常需要人，该如何考虑呢？

• 关注未来

  • 明确招聘是为了未来的，远水解不了近渴，你重点关注的应该是候选人来了之后团队会有何改变。考虑4点：
  • 1、他是否有能力的同时还有潜力？比如很强的发展欲望或学习能力？
  • 2、他身上是否有特质足够吸引你？比如让你觉得当他未来会比你更优秀？
  • 3、你是希望与他这样的人一起共事的？
  • 4、当他加入团队后，能否将团队氛围激活，形成鲶鱼效应？

• 宁缺毋滥

  • 宁缺毋滥，守住底线，需要考虑这样 2 点：
  • 1、能力水平超过团队 50% 的人以上：确保团队越来越强，而不是越来越弱，有的 Leader会觉得候选人比团队最差的两个人好就可以了，但这样一来，随着时间拉长，你的团队会越来越差。
  • 2、内心是否非常犹豫？犹豫往往意味着 “不想要 > 想要”，如果是迫于业务压力不得不加人，我建议你还是不要勉强，因为有可能本来解决业务压力就可以的问题演变成还要额外解决不适合的新员工的问题。

小结¶

• 对 Leader 而言，比找人还重要的事非常少，很多时候缺人不会立刻死，但是找错人会让你和团队万劫不复，一个不正确的人对团队的杀伤力，要远大于因为缺人大家要多加班造成的影响。
• 而且，我们不是要「招」更多的人，而是人海中「找」到对的人：和找伴侣有点儿类似，未必是最有钱、最优秀的那个，但一定是最适合、最舒服的那个。
• 你要相信一个足够出色的同学，对团队和未来的影响是一般同学的 10 倍甚至 100 倍，有追求和没追求的人在同一件事上会交付两个完全不同的答案，正所谓「兵贵胜不贵久」。

能落地¶

90 天试用期，转正时要考察什么

理解试用期与落地¶

• 那么当你找到人之后，是不是就可以高枕无忧了呢？并不是。
• 因为最终目的并非招聘，而是通过招聘增加团队战斗力，这里至关重要的一步就是 “新成员的落地”；
• 有时 “能落地” 比 “找到人” 的影响更大，招聘只是开始，让新同学能落地、发挥价值才是最终目标。

新人试用期 Checklist¶

转正述职要考核什么¶

• 默认转正的两个极大的隐患

  • 面试通过 = 转正就稳，没有把本不合格的同学在试用期淘汰掉，不仅对团队不负责，也为未来埋下了隐患。
  • 新同学入职初期，是他熟悉环境最重要的阶段，在该阶段没有让其建立合理的认识，没有建立团队的底线和标准。而且大家对工作标准的要求参差不齐的同时也减弱了团队凝聚力。

• 转正述职才是真正意义上的招聘结束

  • 把控转正时间： 提前半个月跟 HR 或者「师兄」确定转正述职时间点。
  • 建立评委会： 由 Leader 主导，与其合作伙伴（技术同学、产品或者运营）组成小的评委会。要注意，合作伙伴的反馈也许会比较主观，你在参考时要尽量保持客观。
  • 明确考核内容： 硬性要求+软性要求。硬性：业务了解、稳定性学习、业绩成果；软性：对技术和业务的思考。

成长期的跟进¶

• 转正通过后，不少新人潜意识觉得自己通过了最难的一关，会放松下来，出现纰漏。但事实是： 转正成功后的一年，是新同学能否快速成长最关键的一年。
• 慢慢叠加： 试用期阶段，新同学主要做一些小需求、小任务，在成长期就要让他从负责小任务逐渐向负责大任务转变。
• 主动跟进： Leader 要与新员工保持沟通，帮他分析问题，确定阶段性职业目标（比如定期沟通他哪里可以改进、为他设定榜样确定可以参照和模仿的对象）
• 树立信心： 转正述职阶段，大部分新人小心翼翼，成长阶段要帮他树立信心，让他有阶段性成果，敢于发表意见。

升级汰换¶

心要慈，刀要快

理解升级汰换¶

• 认识误区：有的 Leader 甚至把「不开除人」、「团队 0 流失率」当作谈资。
• 可是你要知道，一个合格的管理者不但要做好招聘，还要果断开除不适配团队的员工，如此才能维持团队整体的健康，才是真正对团队内优秀的成员负责。

解聘核心原则¶

• No Surprise： 不要突然Fire一个人（离职一定不是一个突发行为），没有任何征兆告诉员工 A“你被开除了”，这是典型的管理失职。如果A存在问题，你应该先告知，然后一边和他一起制定改善计划，一边督促其改正。离职往往是一个可预期的结果，无法满足工作需要或者对团队有其他伤害而 A 依旧无法改变时，为了避免对团队产生持久不利的影响，就需要让他离开。
• 心要慈、刀要快： 杰克·韦尔奇（Jack Welch）曾经说过这样一句话“如果一个人到了中年之后，还没有被告知自己的弱点，反而在某一天因为节约成本的原因被裁掉了，这是最不公平、最不应该发生的事情。就是因为这个公司太仁慈了，他连出去找工作、提升自我的可能性和机会都没有。”你可能觉得，在情感上解聘一个人非常糟糕，但是换一个角度想，如果你对一个人很不满意，却又不找他谈话，不要求他改进，又不开除他，那么从最终结果看不仅对他很残酷，这种“拉锯战”对团队也是不负责任的。
• Happy stay、Happy go： 很多时候，送走一个同学对彼此来说并不是一件糟糕的事，换个角度看，如果他在当前环境下一直无法适配团队，对他来说也是很难受的，这时分开对他对团队都是解脱。尤其是当公司出现变化时，如果一些同学不再合适，换环境来讲对他是新的机会，所以你不要存在太多的情绪，而是要往“好聚好散”的方向上推动。

两类人不能留：狼和白兔。¶

• 人才九宫格

  • “狼” 业绩强，但是价值观、态度极差，甚至有才无德；
  • “明星” 不但业绩好，价值观和态度也极好；
  • “黄牛” 就是业绩和价值观平平，虽然不出彩，但是兢兢业业、任劳任怨；
  • “小白兔” 就是价值观、态度极好，但是没有业绩。

• 狼

  • 决定了就下狠手，敢于承担影响
  • Fire是一次团队培训的机会
  • 解释：有的技术 Leader 会纵容“狼”的存在，因为这类成员会给团队甚至公司创造极大的利益，但是他很可能为了达成目标，触碰高压线，比如泄露公司机密、不服从组织安排、影响其他团队成员等，甚至一个人会把一整个团队拖向深渊，所以我们建议你不要容忍这类员工，及时开除，要关注长期价值，而不是短期利益。

• 白兔

  • 先辅导给机会，再快刀不纠结
  • 永不低估白兔的危害
  • 解释：每一家公司都有这样的人，看着勤勤恳恳，但却拿不到任何结果，如果你纵容白兔的存在，那么长久下去，很容易滋生一群白兔磨洋工，针对这类员工，你前期可以给予改正的机会，如果依旧没有改善，应该毫不犹豫将其送走。

离职面谈 “TRF”¶

• 离职面谈前，要遵循 TRF 原则

  • Train him 是指如果他能力跟不上，你可以给予其帮助；
  • Remove him 是指如果他的能力和岗位匹配有问题，你要更多地采用转岗的方式，为他的发展打开空间；
  • 如果在你给予他机会之后，他还是无法改善，那你就应该 Fire him。

• 离职面谈常见问题

  • 解聘还是一个被否定的动作，虽然理性上能分析出一些客观的内容，但是感性上很容易情绪化，离职面谈时情绪崩溃的更是比比皆是。
  • “谈不了”：辞退的事实依据不充分，对 离职原因 讲不清楚。
  • “无重点”：对有关问题避重就轻，只说无关痛痒的祝福。
  • “没技巧”：对员工工作横加指责，面谈完反而加深了矛盾。
  • “从不谈”：是对员工存在很大偏见，不面谈直接一拍两散。

晋升¶

是不是技术到位、项目做好就够

晋升流程¶

• 晋升启动——主管提名——部门提报——述职答辩——结果表决——公司复审——结果公布

四个关键环节¶

• 提名沟通

  • 很多人会把「提名」当作给予团队成员的奖励，这会让团队同学形成一种错觉：只要努力工作，就一定能晋升，甚至有种 "今年排队也该轮到我晋升的感觉”。
  • 但苦劳不等于功劳，是否具备下一个角色所需要的条件才是晋升考核的侧重点。
  • 不要为了奖励某个同学而让他去晋升，这不仅是对晋升这件事不负责，也是对这个同学和整个团队不负责。
  • 你可以在薪资、年终奖等激励上体现自己对苦劳同学的关注，而对于想要晋升的同学，战功与武功缺一不可。

• 资料准备

  • 技术的 5个维度

    • 架构能力： 从业务或者现状复杂度以及你的改进切入，要有 架构图 做说明。
    • 细节把控： 从一些隐蔽的坑、风险、线上问题或者技术难点来切入。
    • 工程能力： 对规范、效能、质量做了哪些改进？有什么效果？
    • 团队能力： 如何带人？培养人？最好有数据说话。
    • 技术视野： 足够了解其他团队、其他BU、整个集团、甚至业界在这个业务领域的架构与技术，并对比出优劣，可以想到哪些能力在未来可以沉淀输出，并表达出一定的技术前瞻性。

  • PPT 编写

    • 突出重点： 不要广而全，十几页看不完，也不要一页走天下，答辩全靠讲（这是我在做评委时遇到的两个极端情况）；详略得当，突出重点，评委才能针对性地对你建立认识，区分出该问的问题。
    • 内容翔实： 你呈现的内容一定是你亲自做过，并有所思考的，假设 B 项目很成功，而你只负责其中的数据监控，但你却夸大其词地突出了整个项目，这很容易给自己挖坑，评委问的问题你答不上来，不但会怀疑能力，还会质疑你的人品。
    • 数据说话： 技术要习惯用数据说话，比如你优化了 B 系统，运行时间由 1分钟提升至10秒，为团队节省了500万，总而言之，用数据替换掉“很好”“突出”“巨大”等形容词。
    • 功劳大于苦劳： 晋升看中的是能力，有挑战的功劳可以细说，如果你说自己为了完成 B 项目，一直在加班，那么这种堆砌时间和体力的表述没人在乎。
    • 突出自我： 如果你提到某个产品或系统，那么评委关注的是你在这个系统中起到了哪些关键作用，你的思考、判断、决策、行动和结果。

  • 赛前演练+心理辅导

    • 让提名的同学预演一遍自己准备的内容，从中指出存在的问题争取让他脱稿，逻辑严谨，减少紧张感；
    • 一些同学会格外在意晋升这件事，患得患失，Leader 要帮他平缓心态，帮助其建立正确的认知：把晋升当作一次分享和总结，就当是对过去一段时间的回顾，不管结果如何，总有所收获。

• 晋升答辩

  • 考察的核心问题：候选人牛在哪里？他如何思考某一个具体问题？之后如何行动？效果怎么样？未来还要怎么做？ 直白点儿说就是：找问题、定义问题、分析问题、解决问题、看未来的能力。

  • 除了技术 5 个维度的能力，要考察 “拿结果的能力” 与 “业务理解能力”

    • 拿结果的能力： 清晰的客户价值产出，有思考沉淀和可复制的方法论；
    • 业务理解能力： 客户视角、前瞻性思考与判断、可以持续提升客户价值。

  • 现场 QA

    • 评委会根据你的讲述以及 PPT 准备的内容进行提问，并不是对你某个项目，或者说法产生怀疑，或质问你。
    • 所以，回答问题一定要言简意赅，不要随意发散，更不要产生情绪，不停地反驳评委。
    • 另外，有的评委会问到 “你是否有项目失败的情况”，如果存在，那么你没必要抵赖，直接真实地说出经历，并表达自己过后的复盘与反思。
    • 在评委提问时，也会很大程度上考验你的临场发挥，如果平时没有足够的积累和思考，这时很容易翻车。

• 结果安排

  • 晋升失败：让候选人认识到成败两种结果，并告知尽最大的努力，考虑最坏的结果，避免形成落差，候选人离职；
  • 晋升成功：简单庆祝过后，还需要为其新角色明确新的要求和职责，让他有更明确的努力方向，在团队内发挥更大的作用，不要把晋升当作终点，而是后面工作的起点。

经验之谈¶

• 明确晋升是件什么事？

  • 对一些同学而言，可能意味着 “升职加薪”，对公司而言可能意味着 “组织建设”，不管你从哪个角度去理解，都应该清楚： 晋升不是奖励，是责任与担当，是为未来做的事。
  • 我们希望一个同学晋升，是因为他有明确的战功、决策背后充分的思考、业务以及技术上深厚的沉淀，同时还具备未来发展潜力。

• 什么人晋升？传递一个信号，树立一个风向标。

  • 我们要什么？不要什么？
  • 推崇哪些人，认可什么结果？
  • “榜样”应该什么样？

• 一次晋升是一次照镜子

  • 技术人的成长和环境是相互作用的，很多时候容易被环境驱动，而往往想要获得能力上的提高就要克服一些环境的惯性。
  • 比如，随着业务体量增长，技术的话语权、决策力在减弱，其本质是技术驱动力跟不上业务体量的发展速。最终我们没有走向技术深度驱动业务，而是想办法最大程度满足业务、提高交付。
  • 所以很容易出现一种情况，一位同学可能做着公司最核心、并发最高、风险最大、业务需求最多的系统，过去一年也搞定了很多需求和项目，但是都在做事，并没有思考怎么更好地做事，或者说为什么用这种方式做事。
  • 另外，高强度的交付一定程度上也扼杀了创造力，导致一个创意工作变成体力劳动，最后还要在脑力环节（晋升场）证明自己，大部分人会在主观上轻视了技术沉淀的价值，这需要所有人，尤其是技术 Leader 反思。

跨团队¶

没有汇报关系就推不动？横向领导力

跨团队推进项目的难点¶

• 方案无法达成一致：实现成本、方式、资源等方面存在明显差异。
• 时间无法达成一致
• 优先级无法达成一致： 协作方一直有优先级更高的项目插队，导致交付时间一变再变、一拖再拖。
• 阶段性交付结果不一致：比如结果质量无法满足你的需求，又无法直接管理对方团队的成员。

常见原因¶

• 协作方不清楚项目原因和意义，会优先考虑自身利益，根据利益高低推进难度由易到难；
• 协作方有自己当前的工作内容和优先级，突然配合进行其他事务，引入的风险往往较高；
• 各部门对彼此之间的工作方式、团队经验以及当前现状往往不了解；
• 任务细化，跨团队合作受时间、空间等因素影响沟通成本较高，有些问题不知道该找谁。

基本态度¶

• 不要做情绪的奴隶，先找自己的问题

  • 切记下意识地认为 “环境有问题”、“对方不配合” “公司文化糟糕”；
  • 审视自己有没有把事情想明白、讲清楚，该传达的信息是否到位。

• 快刀斩乱麻，避免因复杂的问题陷入沼泽

  • 假设在推进某类复杂业务时，产生了 A 问题，而你在解决 A 问题时，又延伸出 B、C、D等问题，而你将所有的精力都用来解决一个个小的问题（而你根本不擅长 B 问题），事倍功半；
  • 找到最关键的问题，并找到能解决这些问题的人，不要让自己陷入链式的解决问题中。
  • 越是复杂的问题越要致力于寻找能破局的关键点，盯着最核心的要点。

• 慢思考，快执行

  • 当事情受阻时，不要第一时间做应激反应，推不动和无法达成一致都是正常的。
  • 凡事三思后行，在脑海中梳理整件事情，有了脉络和眉目之后，再快速调动所有资源去执行（该借力就借力，该凭职级就凭职级，该找老板就找老板）

原则方法¶

• 方法

  • 解决“跨团队事务推进不畅”：要么把问题解决掉，要么搞定制造问题的人，要么换能解决这个问题的人来解决。
  • 总结成一句话： 换位思考、摆事实、讲道理、凭职级、借势而行、想尽办法达成目标。

• 合作前（明确目标，确保信息完整）

  • 一些同学在沟通时，很容易直接说“接下来要改造 A 系统，希望你配合我做……”忽略了合作前的信息互通。我建议你先梳理项目目标，搞清楚为什么要“改造 A 系统”？这个项目对产品、运营、业务三个团队的重要性是怎样的？它们能通过“改造 A 系统”获得哪些价值？它们需要配合的程度？做成会有什么结果，做不成又有什么结果……总之，你要把所有已知的信息给到对方，并换位思考，寻求平衡。
  • 因为团队毕竟不同，不同团队的诉求也不同，尽量秉持友好与中立的沟通态度，多换位思考、去了解对方的诉求与困难，不要总想着让对方帮你什么，也同步想一下你能帮对方什么，充分的信息互通，把做事的逻辑讲明白来赢得各方的信任，制造良好的协作氛围。

• 合作中（定位问题，借势而为）

  • 事务的推进和处理中，出现问题在所难免，保持冷静的态度去分析和处理，找到问题的核心点避免陷入无休止的陷阱。
  • 同时掌握适当的技巧，比如某件事儿你做完了，需要 B 团队继续，B 团队遇到困难或者犹豫不决，或者有些问题你无法解决时，要借助这件事情的势能。找你的老板、找对方的老板是一种，形成压力也是一种方式，比如 C 团队还在等 B 处理完的结果，那么 B 夹在你和 C 团队之间，自然会有一种紧迫感。

• 合作后（承担责任，公开肯定）

  • 一个协同项目如果最终结果还不错：不要忘记合作伙伴的支持与帮助，在IM、邮件或者会议上应该公开给予肯定，为下次更愉快地合作留下基础。
  • 如果结果不理想：也要敢于承担责任，不要第一反应都是甩锅，毕竟谁也不想未来和遇到问题就甩锅的人合作，这样之后让以后的事情越来越难做。

小结¶

• “跨团队合作” 这件事无法避免，项目推进也十分复杂，过程中处处是坑，永远不要以为别人配合你是天经地义的事情，时刻保持一个比较高的风险意识，把事情想明白、在脑海中推演所有的可能、针对不同的问题寻找他们的关联，并且探寻最关键的破局点是什么。
• 虽然跨团队的事务推进很难，但也最锻炼人，能把这些事做好意味着你能解决职场工作中的大部分场景和问题，对未来职业生涯的帮助非常大。
• 横向领导力：让被你管理的人配合你很正常，让大家都能配合你，你就很了不起了。

做规划¶

除了交付和稳定性，还要规划什么

什么是做规划¶

• 技术团队负责人主动去做，说明愿意长期去完成一些事情，是好的习惯。
• 团队规划解决的核心问题是：让你在有限的时间和资源内，明确怎么去创造最大的技术价值(ROI)。
• “团队规划” 所确定的内容，将会作为原则或判断标准。
• 总之，做团队规划需要一些思考、流程和章法，当然，技术团队的规划流程大同小异，比如从公司、上级部门、业务团队得到一些规划线索，结合团队现状（问题+痛点）一起敲定规划范围，从价值优先级的角度不停排序打磨，形成规划初稿分析难点和可执行计划，形成共识并在接下来一段时间内严格执行，阶段性带领相关人员进行复盘。

做规划要考虑团队现状¶

• 先定义清晰自己团队的现状再做规划：比如团队现阶段承担的具体职责是什么？今后的发展目标是什么？分哪几个阶段实现？

• 切入点

  • 明确定位与职责：你的职责以及团队的定位是什么？公司对你们的期望是怎样的？你与上一级目标的关联点在哪？
  • 人员情况：成员能力、团队结构、团队规模以及当前团队负载
  • 业务情况：业务当前的侧重点是什么？阶段性目标如何？业务的执行计划是怎样？技术能解决的痛点在哪？

• 梳理后发现大量的 TODO、痛点、问题，如何决断？

  • 一个可以参考的思路是：盯着业务目标去延展人员和业务，从而判断哪些是依赖项，哪些是前置项？
  • 比如确定业务是第一目标，调整人员结构、升级汰换，探索新技术等。

规划中包含了什么¶

• 6点自问

  • WHY：为什么做业务目标/技术创新/团队建设的规划？
  • WHAT：是否能说明业务目标/技术创新/团队建设规划解决的问题、价值与作用？
  • WHO：由谁承担？负责人的优势与跌势是什么？
  • WHEN：所做的规划着眼于现在还是未来？能否保证长期有价值？
  • HOW：针对不同的部分，具体的落地细则如何？
  • HOW MUCH：规划要做到什么程度？是否可以形成可衡量的KPI?

• 业务结果

  • 即业务层面的战绩，你团队打造了一个公司级别的应用，或支撑了某个快速发展业务，这些是业务结果，用业务数字来说话。
  • 线索：从协作部门的规划、公司整体的战略目标、老板的诉求、团队成员的理解出发。
  • 比如你要明确现阶段上级领导关注的重点是什么？是转化、流量、留存、还是产品的用户体验？作为技术Leader，你和团队成员的到达路径是什么？

• 技术创新

  • 由技术人员发起或完成的所有降本提效的动作，但是同样要看优先级和投入产出比。
  • 四个方面：稳定性、效能优化、驱动业务、视野展望
  • 稳定性：是基础、前提、生死线。
  • 效能优化：坦白讲，效能优化是比较难做，除了研发结果量化困难外，研发效率跟人、流程、当前业务状态的绑定非常紧密，牵一发而动全身。尤其是一个业务如果处于不确定的背景下，研发效能优化比较难以寻找合适的着手点，很容易优化来优化去，效率越来越低。建议你从几个最痛的点去着手，看如何通过工具、流程、新技术等手段减少不必要的损耗甚至颠覆现有的开发模式来逐步优化，不要总想着一口吃个胖子。
  • 技术驱动业务：是很多同学的期望，有时会对旧模式的旧问题产生「降维打击」式的效果。
  • 视野展望：又叫作 “团队对新技术的探索”。技术Leader自己对新技术的敏感和接受程度，决定了你团队的技术上限。

• 团队建设

  • 让团队可以长期健康发展下去，要在Backup、人员组成、机制建设等多个方面下功夫。

  • 团队建设的关键不只是知人善用，而是：

    • 1、团队未来需要什么样的人？
    • 2、目前团队成员需要什么样的状态和能力？
    • 3、团队成员需要承担什么样的责任？

  • 团队建设的核心在于思考团队的未来和终态如何，反推每个人、每件事。不然难有质的改变。

规划落地时的问题与思路¶

• 规划不等于计划

  • 计划是一张时间表，它严丝合缝，不能打乱；
  • 规划则是某个阶段内的优先级，做规划是为了让你知道哪些是重要的？ROI 高的？值得做的？是盘点和创造技术价值的过程，并不是执行的过程。

• 规划内容想得太多，做成的少

  • 规划并不是囊括万物，需要有落脚点，有要核心解决的问题，并以周/月为单位去调整自己的规划，不要放任不管。

• 业务压力大，盲盯痛点，忽视目标

  • 解决痛点最终是为了实现目标，如果你一直盯着痛点的话，会发现自己永远没有目标，只有痛点。

• 规划最终成了技术Leader的规划

  • 目标规划一定要形成KP，落到每一个人身上，让每一个人都跟结果息息相关，一定将规划拿出来讲、拿出来看，每周带领团队成员查看进度，同学们一定会重视。

小结¶

• 做团队规划是一件比较综合宏观的事情，有时哪怕只是几个人的团队，想做好一份规划而非执行计划也很考验Leader的思考深度；
• 某种程度来说，规划是你定义一群人在未来一段时间内做什么、怎么做、最终变成什么样。
• 有目标和没目标的团队，是有很大的差别的。

接手新团队¶

士气低、交付迟、事故多发如何下手解决

通常背景¶

• 「接手新团队」 是比较综合且棘手的场景：离开自己熟悉的团队和业务，去接手一个全新的团队。
• 往往在团队管理上有出色的表现的同学，越容易遇到这种情况，因为你老板遇到类似的问题肯定优先想到你。
• Leader 接手的团队通常是在一段时间内一直出现各种问题，且原负责人无法很好地解决团队出现的问题，同时一些问题已经造成了严重的影响，如系统出问题影响用户和业务、工作任务完成不了或交付质量低、团队成员分崩离析等。
• 当然也有不那么糟的，如原负责人调整，因此安排你去接手。

困难挑战¶

• 涣散的团队士气与人心

  • 随着团队情况恶化的时间变长，团队成员也会越来越沮丧、工作状态逐渐变得糟糕甚至没有信心。
  • 这一过程中，一些非常优秀的同学也会因为这个糟糕的环境而选择离开，同时为了解决这个团队状态，可能已经做了很多人员调整，每个调整都增加了人员的不确定性。
  • 同时，更令人头疼的是，因为之前糟糕的结果和团队状态，团队成员彼此之间和其他团队的信任感非常弱，协作变得十分困难。

• 糟糕的业务现状

  • 一个糟糕团队最基本的表现就是无法完成对应职责的工作，在研发领域比较明显的就是需求无法交付以及系统稳定性无法保证。
  • 而一旦这样的情况持续一段时间，就会进入一个恶性循环，本来糟糕的系统为了应付业务压力所以做得更糟糕，等你来接手时，可能会发现系统的很多实现与功能已经一塌糊涂，难以在未来进行迭代和维护，甚至现在是不是有严重的问题一直存在而没被发现也不确定。
  • 更糟糕的是对口的业务也一直受技术团队拖累，而此时上级和业务部门都会对你有比较高的解决问题的期望。

• 自身的适应与改变

  • 接触一个新团队和进入一个新环境有很多类似，往往我们可以依赖的就是过去的经验，但是很多时候影响我们判断的也是过去的经验。
  • 要明白，并不是过去所有的经验放在当前的场景里都是对的，真正有效的经验是活的，不是死的，要随着场景变化而变化。

行动措施¶

• 明确了环境和这件事有多么棘手之后，我们就要开始着手解决，这里我比较推荐的是一边盘点一遍想办法，尽早行动得到反馈。大部分情况下，可以从人员盘点和事务盘点两个方面切入去分析和思考。

• 盘人

  • 通常面对一个问题或情况，要优先侧重于梳理事务，但是这个场景里是优先盘人，为什么呢？因为这是一个你并不熟悉乃至了解的团队，要知道事情都是人做的，磨刀不误砍柴工，不把团队的人员梳理干净，你连人员的基本信息和特征都不清楚，如何分配任务？不借助现有成员对现状和业务的理解，完全靠你自己主观判断，目前的情况怎么做好判断？
  • 人员的盘点，最关键的围绕能做事和想做事两方面去看团队人员目前的情况，这样就基本可以把目前的同学分成4个象限。
  • 重点是找出两类人：能做事并且想做事的，不能做事并且不想做事的。前者是我们最需要的，也是接下来能否扭转局面的关键，后者则是需要尽早清理出团队的，不能给他再作妖的机会。说着容易，但是具体如何识别呢？可以结合几个方面来看，最具备说服力的就是每个人对应职责的业务结果，其次可以通过其他人的反馈和当事人OneOne的感觉来判断。
  • 比如张三在团队中负责A系统的开发，A系统线上问题频发，需求完成的质量非常糟糕，那么其他人再怎么为他点赞，与你沟通得再顺畅，你都要多思考一下，为什么说得这么好但是结果完全不一样？OneOne的时候不仅要听他讲干了什么，也要听他讲为什么做得不够好。是能从自己身上找原因，还是大部分点都认为是其他人乃至环境的问题，这对你判断一个人是否“靠谱”很有帮助。并且很多时候如果真的是受环境或者其他情况影响导致事情的结果不理想，那么自身也会有足够的思考，而不是甩锅似的一点想法都没有。
  • 如果确实是有意愿做事，但是在糟糕的环境下能力无法发挥，这样的人要给予包容，想办法帮助并激励他，给他权限为他创造机会。而那些明显结果不行，一直推卸责任甚至态度也非常差不愿意配合工作的人，就是典型的既没能力也没意愿。这样的人多留在团队一分钟都是一种伤害，应该尽快清理出团队，避免继续创造负向价值。
  • 这里面还有一个需要注意的点，与现团队的同学沟通时一定也同步摆正自己的心态，并不是说你过去的经验都是对的，他们做的全是错的，然后你带着正确答案来拯救他们了。如果你是这种居高临下的自傲心态，大概率最后要做砸，并且也没人愿意和你一起做。真实情况是，在原来的环境中即使是你负责可能也会出现一样的问题与状况，保持空杯心态，去探究过去为什么没做，未来应该怎么做，才是真的有用。团队成员也会感受到你到底是他们的一分子，还是来指责、批评、教育他们的。

• 盘事

  • 相较于人员的盘点和安排处理，盘事相对思路会更清晰，并且在前面几讲我也有提到过相关的内容。这里面最终要的两个方面是就是找出最重要的几件事去做以及在做的过程中争取到一些支持。
  • 往往我们梳理好人员、了解清楚业务后会发现，历史包袱非常重，很多事情都没有做到位，留下了很多麻烦。然而此时也不可能把每一个点都修正，所以没必要纠结于过去哪些事情没有做好，而是着眼于未来去给现在的团队找价值和定位。比如你看到很多过去的需求实现的方案都是有问题或者有缺陷的，那有没有必要一一更正吗？大概率是没有必要的，除非这个问题发生的概率以及可能造成的影响都足够巨大，否则不如先不动，而是把最重要的几件事梳理并确定下来，团队先去把这些按照新的标准和要求做好，一步步来重新形成团队状态。
  • 这就非常考验Leader在局部和全局之间做判断的能力，往往我们总想把眼前的问题解决掉，而忽视这个问题在整体中重要性的占比以及ROI的高低。同时如果现实情况非常复杂，难以梳理出一个清晰的脉络和头绪，我认为最好的方法是画图，在白板上把所有的事情一一画下来，然后通过连线的方式把不同事情之间的依赖或关联关系也表明出来。此时再结合之前从其他同学、你老板、合作伙伴等各方面得到的信息，做出一个判断或者说决策，即这个团队下一步做什么，有时候哪怕不是最好的选择，也比一直不选择要强得多。
  • 同时，因为你是接手了一个问题团队，所以要适当地争取上级和其他团队的支持，会哭的孩子有奶喝是真的。比如一段时间内业务需求实现的放缓、对线上系统稳定性问题的一定容错、其他团队技术高手的支持等等，结合你的实际情况去寻找这些支持，只要能让团队的情况有所改善，都值得一试。

小结¶

• 虽然接手一个问题团队很难，要处理很多问题并且非常辛苦，但是对一个Leader的锻炼也是无与伦比的，我见过几乎所有优秀的技术Leader都是一次次这样磨炼出来的。
• 毕竟技术管理能力很重要的一个落地场景就是这种情况，也是最能发挥技术Leader管理能力价值的场景之一。

References¶

阿里巴巴管理的道、法、术、器¶