成为会带团队的技术人

本文是拉勾专栏《成为会带团队的技术人》的笔记，图基本也来源于专栏，自己以前也有带团队经验，但自我感觉做得不够好，这个专栏给我很多启发。

技术人三要素

技术人三要素：稳定性、债务、架构

稳定性

怎么衡量系统稳定性？

一般来讲，通过统计系统不可用的时长或次数就可以对稳定性进行量化，比如业内常说 4 个 9 的可用性（即 1 年内 99.99% 的时间系统是可用的，不可用时长仅为 52.6 分钟）。

针对稳定性的提高也可以看作围绕事故的治理，可以从事故发生的前、中、后分阶段来看对应的关键点。

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

事故的类型

从事故特性上看，我们可以分为可用性事故和资损类事故。

1. 可用性事故：技术原因导致系统部分或者全部功能不可用，业务没办法正常完成对应流程或者提供对应服务。比如因为网络、接口 Bug 等原因，用户没办法登录、商品列表不显示等。

2. 资损类事故：系统的功能都能正常使用，但因为逻辑、计算等原因让业务的某一方产生了资金损失。比如某电商部门错发无门槛优惠券、某公司商户清结算少打款给商户等等。

故障处理的生命周期

故障处理的生命周期，可以分为 4 个阶段：发现异常、排查问题、判断决策、恢复处理。
这 4 个阶段对应的行动并不是完全串行的，虽然有一定的依赖关系，但在实际的处理过程中应该并行展开。类似 fork/join 的模式，不断完成小任务、不断汇总信息，不断做出判断与决策，形成循环直到故障恢复。

1. 故障发现

总的来说，人工的被动反馈在时间和速度上有较强的不确定性，很容易出现“小故障 * 长时间 = 大事故”的情形。而纯粹的技术指标监控又会忽略掉接口正常响应，但是业务异常的场景，只有两者结合，通过监控告警，最大程度上缩短故障感知的时间，才能早发现早解决，减少业务影响。

2. 故障排查

• 直接锁定：最近的代码更新与异常现象间有直接的逻辑关联，进而可以直接锁定到故障点。比如，刚对下单接口进行了发布变更，客户反馈大量失败，可以基本断定是刚才的发布导致。

• 排除法：当干扰因素过多（用户、订单等几个系统同时发生变更，引起订单异常），很难直接锁定到故障点，就要结合业务场景，在整条下单链路上及关联代码进行自查自证，通过排除法锁定故障。

3. 故障决策

业务决策非常复杂，能否第一时间止损很大程度上取决于技术 Leader 的现场反应和操作， 要注意故障决策的两个关键点 ：

一定要有明确的决策人、主导者和有效的沟通方式（钉钉群、多人电话会议等），让信息可以通畅地交流出来，并且决策人可以根据情况做判断与取舍，形成所有人明确的处理结论，最好还能落成文档，可追溯。 比如，第一时间停止错误红包的发放，确保故障没有增量，并把决策第一时间同步给团队成员，并同步相关负责人后续的动作，对已发放的红包，明确要求负责人汇总各类关键信息（红包数量、涉及金额、涉及用户数、有效时长、可能资损等）。

所有的信息一定要数据化，不同的数据量级会导致决策不同，比如红包错发 5W 可能只是暂停发放，但是存量红包依然可以核销，损失公司可以承担。但是如果错发 5000W，大概就要涉及一系列的调整，这是非常影响决策的。

4. 故障恢复

应急“三板斧”：回滚、重启大法、降级限流。

如何有价值地做事后复盘？

你可以从时长、现象、处理时间轴、根因、改进计划这几个维度进行复盘， 在以下几个方面进行深究：

事故时长：1-5-10(即 1 分钟发现、5 分钟响应、10 分钟恢复) 是否达成，如果没有是为什么？哪个环节用时最多，如何提高和改善？

事故根因：根因不等于直接原因，一个事故的直接原因往往并不复杂，但是根因可能是多个维度的缺失，需要像剥洋葱一样一层层找下去。拿库存接口变更这个Case来说，直接原因就是某段代码逻辑变更导致，但是应该在测试、发布、监控、应急影响、预案设计等多个环节展开去看，根因的挖掘并不忌讳“吹毛求疵”。

事故改进措施：由点推到面、明确到人、明确时间。与根因类似，要结合多个维度形成组合拳的改进点，避免一次性动作，要将重点放在对未来、对同类问题的预防上。核心就是如果再一次发生类似的问题，这些改进措施是不是能起到作用。

关于事后复盘，我们就是要深挖事故如何发生的、如何处理的、未来怎么预防。但要避免情绪化，在复盘会上的反思、感悟、懊恼没有任何意义，如何带领团队把精力放在改进措施的落实以及事故前的治理上更有价值。另外，你需要留出时间让团队伙伴进行内部 Review，避免为了开会而复盘。

没有质量的交付，再多再快都毫无意义。

变更会引起90%以上的故障

1. 变更需要监控

有效的监控要回答三个问题：

• 是否有问题发生？
• 哪里发生了问题？
• 发生了什么问题？

2. 有效灰度必须有耐心

灰度从来不是为了测试，也不等于 A/B Test。它本身是为了对抗“未知的不确定性”。

要想实现灰度的有效性，关键点在于时间和流量。

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

流量：有时一些业务场景需要特定的触发条件，比如满足某些条件的用户或满足某些条件的订单，那么在灰度时就不能仅通过单位时间内有没有异常来判断，还要确保有足够的有效流量。

3. 回滚就是变更的“后悔药”

要知道，系统并不是天然可以无缝回滚的，想要系统具备回滚的能力，在设计与实现阶段需要付出额外的精力。可回滚的本质是系统的兼容性设计与实现，比如常见的“只增不改”，一个 API 内要调整很多实现逻辑才能满足新业务的需求，此时不妨直接新增一个 API ，两个 API 保持参数一致，那么一旦新 API 有异常直接切换回旧的 API 即可。

所以，不论是灰度计划还是回滚策略都应该在架构设计阶段就去考虑，结合排期、风险程度、成本投入这些方面，要做好评估与平衡。

坚守 Design For Failure 的架构理念

“Design for failure and nothing will fail”，最早是 AWS 的一条最佳实践，即面向失败进行系统设计。可以理解为：考虑系统所有可能发生故障或不可用的情形，并假设这些可能都会发生，倒逼自己设计足够健壮的系统。

1. 将经验教训沉淀下来

历史是最好的老师，我建议你总结并分析过去发生过的事故，并结合常规分布式系统的可用性风险，以此梳理出一个围绕事故隐患的风险点 Checklist，在需求迭代或者架构设计时，通过它高效地找到系统实现的薄弱环节。

除了完善 Checklist，在团队普及这种设计理念之外，更关键的是将这些解决方案沉淀成设计原则，让研发人员可以在实际中落地。

2. 通过演练验证预案设计

设计并实现了自己的故障演练系统，日常主动制造事故上下文来验证我们的设计与系统是否可靠。

把稳定性当作机制与文化去建设

系统稳定性结果好坏很大程度上取决于技术 Leader 的重视程度，如果一个团队的管理者都不能身体力行的去重视它，而仅仅只是喊喊口号，那就不要指望团队成员能认真地对待这件事。

1. 新人 Landing 从稳定性学习开始
2. 每人不低于 35% 的稳定性 KPI
3. 好的坏的都要在阳光之下晒一晒

建立资损概念的宏观认知

从广义上来看，存在理论损失也应该算资损， 比如因为搜索推荐系统出问题（不论什么原因）导致这一阶段广告的收入减少，或者因系统 Bug 导致用户取消订单的申请被默认同意（虽然原本商户可能也会做同意处理，但是申诉的话平台依然要赔付），类似预计收益减少或者因系统问题产生赔付的场景都应算为资损。

资损防控的三个关键

1. 防：资金视角做风险点识别

2. 监：一致性与正确性双核对

针对资损感知的核心思想是：基于线上业务结果收拢进行监控，基于线下业务场景扩散进行核对。

与可用性监控围绕接口的技术指标不同，资损更关注的是数据核对，监控的并不是运行状态而是运行结果，并且资损监控的粒度要求非常高，精细到每一笔交易、每一次金额计算、每一个红包发放。所以资损监控的有效性很依赖于场景的覆盖率，仅覆盖几个关键场景是不足以规避资损风险的，除了要定期梳理外，每次系统有变更或者新功能时，都需检查是否有新的核对点，以及旧有核对公式是否需要调整。

3. 控：资金拦截 + 资产控制

除了防和监，资损防控的关键主要在“控”字上，我们希望在问题发生后第一时间止损，这就需要技术在系统层面对资金和资产有很强的控制能力。这种能力的表现就是： 不仅可以通过预案将某些场景与链路降级，还可以拦截资金的流出和资产的使用，同时具备快速订正错误数据的能力。

在我们开始处理资损事故时，会有三个共性的需求。

• 问题止血不新增：核心是关闭问题产生源头，往往通过业务场景降级来实现，比如对错误红包或者满减活动进行下线。
• 控制资金流出：核心是对资金和资产进行拦截与冻结，避免外流后损失无法修正，比如禁止用户下单时勾选使用有问题的红包。
• 存量数据订正：核心是捞取问题数据后可以快速地批量处理，比如批量更改红包的金额、甚至直接将红包无效。

虽然其中一些操作对用户体验是有损的，但有而不用是一回事儿，无能为力则是另外一回事儿，其中：

资金拦截的能力主要从资金的流入和流出这两端进行把控。以红包而言就是管控其创建与核销。在红包创建时，有预算系统进行管控，避免无限制地生成红包进而超发。在红包核销时，由交易和营销系统进行验证，确保订单上下文以及红包合法，避免问题红包被核销进而造成无法挽回的资损。

资产管控的能力则是资产的快速锁定和数据订正展开，以红包而言，如果不同模版不同活动的红包都有一个统一的批次号，就可以通过这个标记快速捞取某一批有问题的数据。同时如果提前准备批量订正的脚本，或者有订正数据的平台，就可以快速修改红包金额、使用时间、使用门槛等关键信息，甚至批量无效所有问题红包。

你需要注意，这些能力的实现更多依赖于技术 Leader 在日常需求迭代和架构设计时，是否有意识引导团队加强这方面的建设。大部分的预案思路来源于过去已经发生的问题，或者对未来可能发生问题的假设，将预案常态化是你重点关注并推进落地的。

除了建设预案，还要有预案演练，以此保证预案的有效性。技术 Leader 更应该鼓励测试和开发的同学主动做攻防演练，寻找漏洞、验证止损方案、及时发现并修复问题。

技术债务

技术债务在研发领域类似于“金融债务”的概念，大部分情况下是说因为人为妥协，系统的设计和实现没有遵循最佳实践，所以虽然短期做到了快速交付，但也制约了系统未来的可扩展性，并且埋下了稳定性的风险隐患。

重视技术债务的原因

• 影响系统扩展和需求交付
• 恶性循环导致人员流失

技术债务的恶性循环会影响开发团队的生产力，并降低团队的士气和成员的驱动力，而低生产率导致团队只能优先交付功能，这就推迟了技术债务的解决，从而进一步增加技术债务。

如何从循环的债务困境中突围而出？

1.债务的 Owner 是技术 Leader

要想解决技术债务，你需要找到技术与业务的平衡点，我的经验是“内外双修”：

内：加强团队的战斗力，减少债务产生的机会，增强债务处理的能力。

外：深刻地理解业务，并且做好与其他协作方（尤其是产品、业务）的沟通。这样你才能理解协作方想解决什么问题，他们以为要么A、要么B才能解决的问题，既懂技术又懂业务的你能否找到方案C？

建议：面对选择题时不要只看到可选项，要永远寻找第三条路。如果实在没有其他选择，在技术妥协的同时，做好沟通，让协作方明白方案的临时性以及对未来的影响，争取到承诺在未来给你足够时间解决这些问题。

2. 通过 CheckList 识别债务

建立一个债务 Review 的 CheckList ，并且不断完善。技术债务从表象上可以做一些细分：

通过现象我们就可以反推出一些导致现象的原因，将这些原因结合系统的架构进行分类，就会形成一个个具体的关注点。这些关注点往往是结合我们之前踩过的坑、发生过的问题，以及编码、架构上广为遵守的一些最佳实践所形成的，这样你就可以制定出一个较为详细的 CheckList 用以具体的债务识别（下图供参考）。

3. 有计划地分级偿债

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

• 历史事故命中优先： 一些设计与实现在过往导致过线上真实问题的发生，不管是否发生在本系统还是当前团队，都相当于已经被证实过的这类债务的严重性，所以应该尽早修复它们，避免类似问题反复发生。

• 可扩展性优先： 在 CheckList 以及债务现象中我们可以发现，有些问题影响了系统未来的演进，增加了迭代成本，有些问题影响系统的维护，比如代码风格没有统一、缺少文档，在处理时应该优先处理影响可扩展性的问题，后续逐步处理影响可维护性的问题。

• 权责清晰优先： 一些问题在处理时受到历史架构、组织分工（康威定律）的影响，会导致系统的权责不清晰，这类系统的推进和改造往往需要花费更多的时间精力，并且从顶层设计出发去重新考量，所以权责清晰的部分可以优先处理。

总的来说，通过对技术债务进行分级，实质上也是一个问题分治的过程，将大问题切分成一个个小问题，这样就可以将它们加入日常的迭代中，形成一个分期偿还技术债务的计划，逐步减少技术债务，减轻负担让团队与系统可以轻装上阵。

4. 正视债务做好预防

除此之外，预防永远胜于治疗，技术债务汇总预防的关键点在于那些“原本未知”的技术债务要逐渐减少，大家对于实现质量的追求不能止步于“测试没有明显 Bug”，写出能运行的代码是不够的，还要易维护易扩展。

可以从几个方面着手：

• 提升团队认识，通过项目复盘、系统重构、事故 Review 等各种机会，通过实际的案例让研发同学清楚技术债务对团队产生的负担，以及对个人能力提升的影响。
• 建立机制流程，比如在方案设计阶段向下深挖一下实现的要点，更多资深的开发参与到架构评审，或者促进团队形成 code review 的习惯并且达成一个共识标准以提升系统质量。
• 确保资源投入，在通过债务识别和分级后，将还债的投入提前计算到每次迭代中，确保有一定的资源投入其中。

5. 一些常见的误区

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

而这个过程中，有一些问题是日常你很容易走入误区的，我简单总结了一下几个注意点：

• 存在即合理，动态变化才是王道。 不要总想着毕其功于一役，也几乎不太可能有完美的实现或系统，接受技术债务一定会存在的事实，重点在于控制债务积压的程度，欠债本身不可怕，欠债不知且不还才可怕。

• 不积跬步无以至千里。我们往往过度轻视日常积累，又过度重视“大事件”产生的影响。日常这里凑合一下，那里妥协一点，没人关注小问题发生的原因。而一旦发生重大的影响，则恨不得把之前的系统全盘推翻重做一遍。

• 机制流程外还要讲策略和方法。很多技术 Leader 觉得这件事很重要，讲的同时设计了很多流程和机制，不遵守就要承担怎样怎样的后果，这样往往事半功倍。机制流程不是越多越好，也不能光有惩罚而没有激励，同时最重要的是你不能只追杀要结果，要给帮助、给方法、给支持。

大项目：把握关键点，谋定而后动

认清异同，做到心中有数

在这个常规流程中，技术团队的重心是把执行做到位，你要更关注过程管控，确保系统交付。

大项目与常规项目的核心差异点，我认为主要在于这个“大”字上，你可以从三个方面去理解。

• 出发点不同，业务期望更大
• 规模不同，复杂度更高
• 结果评判标准不同，影响更大

把握关键点，谋定而后动

关注效果更重于关注交付，这是大项目的核心特征。

不要为了重构而重构，要知道你要的结果是什么。

大项目的失败存在一个共性的问题：围绕业务结果的思考、计划不足，目标的定义不清晰或没有充分同步给所有相关人，项目同学知其然而不知其所以然。连目标都没有共识，何谈执行到位，项目成功？

所以我认为越是重大的项目，在计划、设计、准备上投入的精力就应该越多，谋定而后动。

• WHY（项目为什么做）

• WHAT（项目做成什么样）

• WHO（哪些人来一起做项目）

• HOW（启动项目后如何做）

  • 合理拆分任务（模块）是项目成功的一半

  • 保持风险意识，敬畏墨菲定律

做好充分的准备之后，可以召开立项会，将 WHY、WHAT、WHO、HOW 的信息与思考同步给项目相关人员。通过 Kick Off 会议确定项目的基调、同步必要信息，为项目推进扫清障碍。

如何处理棘手问题

问题一：缺兵少将怎么办？

项目组人时你要注意以下几点。

• 当项目开始时，从更大的范围内寻找合适的同学，而不是看你团队有哪些人。
• 将参与项目的同学在一定时间内的汇报关系和绩效考核汇总到项目组中，由项目负责人根据实际情况重新安排每个人的权责，并确定绩效的绑定关系与比例。
• 项目交付并不等于结束，所有人的绩效结果都应和项目目标的达成情况紧密且长期关联。

最后，有时不仅要解决“缺兵”的问题，还要认真考虑是否“少将”？要充分考虑当前的人员是否适合做项目的 Owner，以我的经验来看，项目 Owner 几乎决定了项目成败的 80%，如果 Owner 能力不足，你要给予帮助和支持，或者另找他人，乃至上级的帮助，不要在 Owner 的人选上妥协，毕竟项目成败才是关键。

问题二：推不动的到底是人还是事？

• 搞明白冲突现象下的利益诉求： 不同关联方产生观点冲突的现象背后其实是利益冲突，你要搞清楚彼此的顾虑。比如我不愿想让某个系统字段落到订单中，主要是考虑到订单系统的可维护以及稳定性，如果你能解决我的顾虑，会容易说服我。
• 为项目结果适当妥协： 在很多情况下，我们无法做出完美的方案，可能就是要在系统内通过很糟糕的实现去实现需求。项目没有 100% 完美，抓住核心原则不放弃，可控部分适当妥协换取项目前进是很好的策略。
• 通过项目地位和决策机制推动项目： 大项目往往是公司重大战略下的产物，一般情况下，不会有人去反对公司的某项既定战略，而你可以通过大项目的重要性在体系内争取更多的资源和帮助。如果你面临一些冲突，要学会利用决策机制，通过更高级别成员的沟通决策拿到解决方案。

问题三：一定会有项目变更吗？

常见的变化往往有两种：

• 项目演进过程中识别出之前未能识别或考虑缺失的点，导致方案需要调整。
• 出自老板的需求变更，很多情况下都是要新增内容。

3个重点

1. 驾驭大项目是你的试金石和分水岭，对自己职业规划有一定要求的同学一定不要放过打磨修炼的机会。

2. 在大项目中，往往人的问题会比技术与系统的问题难解决，因为与人相关的问题未必完全理性和逻辑，那么此时你也不妨看看感性的沟通与交流是不是有更好的效果。

3. 时刻牢记你将项目按时上线没有故障只是做到了60分，更关键的是业务效果，所以除了盯紧开发过程外，还要在最开始的业务与产品设计阶段就投身其中。

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

为什么技术要理解业务？

产品需求不等于业务诉求

同样的，技术 Leader 可能会花时间参加各种会议，尤其是产品需求的会，在会上如果仅仅是听“自己团队应该做什么”，而没有思考和探究业务的根本诉求，那么就我的经验来说，技术团队不可避免的会成为工具人。Leader 缺乏独立思考，人云亦云，最后整个团队都会被拖累，这也是为什么大多数研发团队被产品以及业务按在地上摩擦的原因！

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

正因为没有仔细看业务的现状、推测业务的发展、去思考业务上对交易的诉求，我们认识的只是一个个需求，而非整体的从业务维度思考系统的设计，导致系统复杂度越来越高。所以要想设计可靠、简单、真正可持续迭代的系统，深度理解业务就是前提，你对业务的理解程度影响了你对系统未来发展的预判程度。

提升技术团队的使命感

你写的每一行代码，线上的每一次发布，都会改变用户的体验，解决实际的问题，你就会发现这份工作的意义。

如何理解业务？

1. 不要盲信产品（不要盲信产品与 PRD，在讨论 PRD 和执行开发任务之前学会独立思考，深入理解业务想要解决什么问题，需要什么效果或作用，严格把控那些伪需求和无价值需求，防止它们侵占团队的技术资源。）
2. 建立走进业务的机制
3. 业务上多参会多画图（参加评审会，梳理流程图等等）

架构设计：治理好系统复杂度才最务实

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

C.A.R. Hoare曾说过：“软件设计有两种风格，一种是将软件设计得很复杂，以使其缺陷没那么明显；一种是把软件设计得很简单，以使其没有明显的缺陷”。

系统的结构清晰、即使整体繁杂但是每个局部都相对简单、链路干脆直接，没有不必要的冗余。

衡量复杂度

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

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

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

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

而你可以结合这 4 点表现特征以及自己的主观感受进一步判断系统的复杂度是否过高，如果系统复杂度过高，可能带来一系列问题：迭代压力大、经常延期、稳定性问题频发等。这时，你要着手治理复杂度，尽力不让问题扩大到难以解决只能重做系统的程度。

复杂度治理的思路

“高内聚、低耦合”，系统简化和分治。

简化就是去掉不必要的复杂，让设计与实现保持简单。

分治则是将原本难解决的问题，拆分到可解决的粒度，然后再逐一击破。

常见的拆分方式是垂直拆分和水平分层： 垂直拆分把差异明确可以独立迭代的业务拆分开；水平分层把共性的能力下沉隔离。比如电商场景中，购物车和订单可以分成两个服务，它们虽然在业务流程上前后关联，但是各自具备独立完整的业务场景和生命周期，商品加入购物车未必会交易生成订单，可以各自独立存在；而库存和商品则是强依赖的关系，库存无法独立于商品存在。

拆分与合并不绝对，过度地拆分会导致系统无法高内聚，零散分离的系统，会增加稳定性风险和治理与迭代的代价，并且造成大量的协作成本。Linus也曾说过：把复杂系统拆分成模块，似乎没有降低整个系统的复杂度，它降低的只是子系统的复杂度。而整个系统的复杂度，反而会由于拆分后的模块之间，不得不进行交互，变得更加复杂。

复杂度治理实践

1. 相比 coding 更重视设计
2. 永远做 2 套以上的方案
3. 从 MVP 的视角考虑设计：从 MVP （最小完整业务的角度）去考虑系统要如何设计与实现，先做减法再做加法
4. 关注上下游的实现
5. 坚持“日拱一卒

没必要一定把系统做成中台

没必要一定把系统做成中台，不做中台就会落后更是无稽之谈，不过，你可以借鉴中台的思路作为系统设计与演进上的形态参考。

---

管理三板斧：拿结果、建团队、招聘与解聘

定目标：让你的方向与公司的方向保持一致

怎么解读目标？

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

目标不是一句口号，它是一个个层层拆解、递进的过程。说白了，解读目标是把公司的方向变成你的方向，把上一层的问题转变成你可以改变的问题。

确保目标解读正确有很多技巧和方法。根据目标逐层分解的特性，可以考虑四个方面。

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

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

• 与你紧密合作的上下游（研发），比如你是做订单系统的，那么支持属性很重，商户、导购、用户很多研发团队都是你的上下游关联方；

• 直接对口的业务与产品，这是业务目标拆解、业务痛点、客户诉求的直接来源方。

怎么制定目标？

结合 4 个关键点来考虑：

1. “短长”结合：事情分轻重缓急，你一直盯着“急”和“重”，“轻”和“缓”的事情就会转变成“重”和“急”，进入死循环。
2. 要足够聚焦：建议关键目标不要超过 3 个，最多控制在 5 个以内，要找最有客户价值、对公司战略最有帮助的点，目标越少、方向越清晰，当问题发生或者需要判断时越容易做决策，在有限的时间内做出更好的结果。
3. 要有足够的挑战：系统可用性假如去年是 3 个 9，今年考虑业务会发展保守起见还是力保 3 个 9，这样的目标挑战性就不足，也无法体现技术的价值。这个度量是很考验你的。
4. 要让组织有沉淀、个人有成长：通过一个个目标的完成，让参与的同学得到个人能力的提升，未来可以承担更大的职责，组织也在这个过程做能力的积累与沉淀。

结合以上四点，围绕目标和团队一起讨论策略与打法，将目标拆解成几个关键任务，明确到责任人，总结一下就是：定策略、拆任务、细到人。

怎么传递目标？

大部分情况下，你会发现信息不对等、传递过程中的损失、个人理解的差异，直接导致不是所有人都清楚“我们要往哪去”。

最后，目标的传递是一个连贯的动作，要落到日常的管理动作、重点项目与任务、KPI 的过程管理这些平日的点滴中。目标要反复讲，要经常对焦，重要的事儿，3 遍是不够的，要说“300 遍！”。

所谓的方向与目标就是：你要往哪去，你要走多远，你要走到哪。清晰的目标就好比沙漠中的指南针，让你能比其他人更快找到水源并生存下去，今天这节课，我提醒你注意这样几点：

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

追过程：如何用 PDCA 做过程管理？

只有掌握过程管理的方法，才会尽可能减少事务往不好方向发展的波动，从而更轻松、更低风险、更稳妥地去拿到结果，让一切尽在掌控。

什么是过程管理？

管理就是追求事务的可持续发展，而想要达成这个目标有两个基本点：

• 管理动作要形成可持续迭代的闭环；

• 管理动作足够简单到可以复制和个性化升级。

过程管理是为了让你的想法、灵感、不稳定的发挥逐渐规律化，可以持续迭代被你应用，它的本质就是希望结果越来越好，让你原本靠运气或者模糊经验得来的成功可以被复制，让你在项目中灵光一闪的 Idea 变成你的常规能力。

PDCA 模型

• Plan（定计划）：围绕着目标明确里程碑，确定关键节点，与执行的员工达成共识。
• Do（做执行）：多给员工空间、多走动、多观察、少干预，放手而非放任，你也不能置身事外。
• Check（勤检查）：狠抓关键节点做检查、问进展、问困难、给建议、做辅导、协调资源。
• Action（复盘调优）：小事尽快复盘、大事分阶段复盘、事后全面复盘，抓住每一次提升和优化的机会。

如何用 PDCA 做过程管理？

很多能力和经验是历练出来的，只要过程可控，过程中走一些弯路也未必是坏事，要允许犯错。但是你要注意，放手不等于放任，更不等于不闻不问，你依然要对最终的结果负责。

• 复盘前：复盘前的核心在于思考复盘的目的和产出是什么。借此，你才可以明确复盘会议主要会聊些什么，哪些人会参加。
• 复盘中：自省是复盘会的基调，复盘就一个目的“找到团队的不足加以改进，以便在未来取得更好的结果”。所以每个人没必要甩锅，也没必要全盘否定。在复盘的过程中，一定要把问题找准，内部对齐，达成所有人的共识。
• 复盘后：会议有结论，结论有计划，计划有责任人，责任人有行动，要建立机制保证在复盘会上讨论出的结论能够落地。

总的来说，小事儿尽快复盘，借此向团队成员传授自己的经验；大事儿分阶段复盘，抓住重点矛盾，推动事情的顺利发展而非追求完美；事后全面复盘，不管对个人还是团队，找自己的问题都是 ROI 最高的方式，找到问题的一方才有改善提升的可能。

三个重点：

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

---

奖优罚劣：怎样传递我们”要什么”与“不要什么”？

“奖优罚劣”之所以重要，是因为它能让团队形成可持续发展的氛围，是拿结果的闭环。而我们在这个过程中要注意的就是：引导人性而非对抗人性。

什么是奖优、罚劣

奖优最终会落到物质和精神上：

• 物质上的奖优作用大，但是频次较低，比如以半年/年为单位的晋升、调薪，它能够打开成员的天花板，比如拿了A绩效的同学，第二年他依然希望是A而不是B，从而提高对自己的要求与期望，更容易取得好的成绩。

• 精神上的奖优体现在日常行为上，频次较高，比如你关注和肯定某位成员的行为，在团队内通过邮件、钉钉等方式简单鼓励推广他的行为。

罚劣也会落到物质和精神上，但它是动作而非目的，你要通过罚劣来传递团队不能容忍什么样的行为，以此提醒、鞭策大家。奖优和罚劣是相互依赖的。

“奖优罚劣”的误区：

• 没有意识到奖优罚劣的示范作用。 你要把“奖优罚劣”当作宣传动作，把结果辐散出去，引导团队风向。

• 注重罚劣，忽略奖优。

• 奖惩动作过于儿戏，容易被滥用：“奖惩动作”要建立在尊重的基础上，让成员有收获和反思。

奖优罚劣的关键动作

绩效考核

我们要从一开始被主观因素影响，逐渐认识到客观的环境与现实，最终在理性与人性中寻找一个平衡，让大家看到付出和能做出好成绩的同学，回报是远远高于其他人的，对于拖整体后退、持续不能改善的同学，团队是不欢迎的。

绩效面谈

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

面谈流程：

1. 开场定基调
2. 员工自评
3. 主管评价
4. 对焦共识
5. 面谈总结
6. 后续跟进

薪酬激励

三个基本原则：

1. 问自己是否敢将资源分配的逻辑与规则在阳光之下讲出来。
2. 不要撒胡椒面，也别做大锅饭，让好的结果超出预期。
3. 面向未来而非现在去做考虑

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

---

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

要知道，沟通是有目的的，既然沟通的对象是人，我们还希望通过沟通去达到一定的结果（效果），那么就要懂得一定的道理与技巧。

沟通的核心原则

沟通是内心想法和思考逻辑的外延，如果你有良好的沟通能力，可以在整个团队中营造公开透明的信任氛围，让信息透明的同时，也让团队成员愿意发出自己的声音。

沟通核心原则的定义是：在相信对方的基础上，让沟通氛围变得“简单且纯粹”。

不同维度的沟通

向上沟通有胆量、平行沟通有肺腑、向下沟通有心肝。

• 向上沟通要有技巧、有原则，认清沟通的目标与目的，不轻易妥协导致更严重的后果。
• 关于平行沟通有肺腑是指你要真诚沟通，不要油滑套路。
• 向下沟通有心肝是指有同理心，有尊重的同时要感同身受。

两个具体的沟通场景

One One 沟通

1. 接地气，说人话
2. 视人为人
3. 沟通要“勤”

团队沟通

与One One沟通不同的是，团队沟通受人数的限制，是一对多的沟通，所以除了参考OneOne沟通的核心点外，你最关键的应该是搭场子，发起团队沟通。

团队沟通目的性更强，频次不高，考验你的控场能力。

---

建机制：规则流程越建越多，为何效果却越来越差？

机制发挥什么作用？

两类机制：

• 与管理相关： 比如为了信息互通，约定每周固定时间通过邮件、会议、IM 等方式，将提前定义好的信息做一个汇总交互（表现为周报、周会等），这就是机制的一种具现。

• 与技术相关： 比如为了多人协同，制定开发流程、Bug 处理、发布上线流程，甚至在日常实际开发的工作中，往往也先定义 API 契约，然后在联调测试时再真正实现验证，这些约定、契约、流程都是对应机制在落地时的具体表现。

站在团队的角度，建机制尤为重要，你要通过机制让团队有统一的行为与规则，让组织像人一样，言行举止有规律可循。

如何设计一个好的机制？

• 规则统一，不自相矛盾
• 简单有效，便于增删
• 紧盯整体结果，机制的 ROI 要足够高

机制要怎么落地？

• 先说 why： 即机制的内容是什么？为了解决什么问题？你在设计机制时是如何思考的？

• 共识的要与不要： 和大家讨论我们要不要这样做？看看大家是怎么想的，通过对话和引导形成一定的结论，有些内容需要保留，有些不合理需要剔除，促成结论最为重要。

• 承诺行为举止： 确认机制之后，需要让结论形成对各自行为的约束。比如不同的成员认领不同的角色和任务，或者在 IM 中一起公告规则，总之每个成员要与机制的参与感。

先考虑目的， CodeReview 主要是解决两方面的问题：提高代码质量；帮助开发同学认识到如何写出更好的代码。

不同的侧重点设计出来的机制也有所不同，按照我的理解，CodeReview 的主要作用还是帮助大家成长，打造团队内的技术提升氛围，次要才是促进产品质量的提升。

确定了核心想要达成的效果，接下来就可以着手确定机制的内容，这里面要考虑几个方面的内容：可能会遇到的问题（阻力）、机制实施的成本、机制运行的时机和周期、站在一个机制参与者的角度考虑他要做什么。

具体 CodeReview 的机制方案可以参考下图：

---

知人善用：借事修人，借人成事

知人善用的三个关键点

1. 找对人
2. 培养人
3. 养成人

怎么落地执行？

• 团队盘点
• 激发意愿
• 改善计划

tips

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

找到人：招聘是 Leader 的责任，不是 HR 的

招人不等于盲目加人

明确业务目标；盘点团队需求；做出岗位设计；提炼岗位要求。

闻味道、问事实、看能力

面试前看简历，面试中更多倾听，面试后速写评价。

• 问事实（STAR法则，看候选人所说的内容是否真正做过，以及思考过程）
• 看能力
• 闻味道（是否和团队匹配）

宁缺毋滥，守住底线

关注未来

1. 他是否有能力的同时还有潜力？比如很强的发展欲望或学习能力？
2. 他身上是否有特质足够吸引你？比如让你觉得当他未来会比你更优秀？
3. 你是希望与他这样的人一起共事的？
4. 当他加入团队后，能否将团队氛围激活，形成鲶鱼效应？

宁缺毋滥

• 能力水平超过团队 50% 的人以上：确保团队越来越强，而不是越来越弱，有的 Leader会觉得候选人比团队最差的两个人好就可以了，但这样一来，随着时间拉长，你的团队会越来越差。

• 内心是否非常犹豫？犹豫往往意味着“不想要 > 想要”，如果是迫于业务压力不得不加人，我建议你还是不要勉强，因为有可能本来解决业务压力就可以的问题演变成还要额外解决不适合的新员工的问题。

能落地：90 天试用期，转正时我们要考察什么？

1. 明确新同学落地的整体节奏
2. 重点抓试用期考核以及工作习惯的养成
3. 转正结束后依然保持跟进

既要帮，也要严

“既要帮，也要严”是我定义的“能落地”的核心原则，“帮”与“严”是双向要求：帮是指帮助新同学融入团队（针对的是师兄和 Leader）；严是要让新同学在团队中提升自己，遵守团队的做事原则，发挥自己的能力与价值（针对新同学自己）。

招聘只是开始，让新同学能落地、发挥价值才是最终目标。

明确新同学落地的整体节奏

1. 用迎新打破大家在情感上的壁垒；
2. 给新同学安排“师兄”；
3. 明确新同学的作业与目标（做出一些成绩达到转正）；
4. 明确告知转正应该怎么做（把转正做重、做实）。

转正述职要考核什么

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

• 把控转正时间： 提前半个月跟 HR 或者“师兄”确定转正述职时间点。

• 建立评委会： 由 Leader 主导，与其合作的伙伴（技术同学、产品或者运营）组成小的评委会（如果团队成员较少，也可以只有 Leader 和 HR）这里要注意，合作伙伴的反馈也许会比较主观，你在参考时要尽量保持客观。

• 明确考核内容： 硬性要求+软性要求。

成长期的跟进

慢慢叠加、主动跟进、树立信心

升级汰换：“心要慈，刀要快”

开除人“心要慈，刀要快”

• No Surprise： 不要突然Fire一个人（离职一定不是一个突发行为），没有任何征兆告诉员工 A“你被开除了”，这是典型的管理失职。如果A存在问题，你应该先告知，然后一边和他一起制定改善计划，一边督促其改正。离职往往是一个可预期的结果，无法满足工作需要或者对团队有其他伤害而 A 依旧无法改变时，为了避免对团队产生持久不利的影响，就需要让他离开。

• 心要慈、刀要快： 杰克·韦尔奇（Jack Welch）曾经说过这样一句话“如果一个人到了中年之后，还没有被告知自己的弱点，反而在某一天因为节约成本的原因被裁掉了，这是最不公平、最不应该发生的事情。就是因为这个公司太仁慈了，他连出去找工作、提升自我的可能性和机会都没有。”你可能觉得，在情感上解聘一个人非常糟糕，但是换一个角度想，如果你对一个人很不满意，却又不找他谈话，不要求他改进，又不开除他，那么从最终结果看不仅对他很残酷，这种“拉锯战”对团队也是不负责任的。

• Happy stay、Happy go： 很多时候，送走一个同学对彼此来说并不是一件糟糕的事，换个角度看，如果他在当前环境下一直无法适配团队，对他来说也是很难受的，这时分开对他对团队都是解脱。尤其是当公司出现变化时，如果一些同学不再合适，换环境来讲对他是新的机会，所以你不要存在太多的情绪，而是要往“好聚好散”的方向上推动。

不要给“白兔”生存机会

白兔看起来人畜无害，繁殖能力极强，大公司里最容易存在的就是“白兔”（不干活的好人）。他们目标和价值观认同度较高，但是业绩长期拖后腿。每一家公司都有这样的人，看着勤勤恳恳，但却拿不到任何结果，如果你纵容白兔的存在，那么长久下去，很容易滋生一群白兔磨洋工，针对这类员工，你前期可以给予改正的机会，如果依旧没有改善，应该毫不犹豫将其送走。

离职面谈“TRF”

Train him、Remove him、Fire him

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

需要避免的：

“谈不了”：辞退的事实依据不充分，对离职原因讲不清楚。

“无重点”：对有关问题避重就轻，只说无关痛痒的祝福。

“没技巧”：对员工工作横加指责，面谈完反而加深了矛盾。

“从不谈”：是对员工存在很大偏见，不面谈直接一拍两散。

---

技术管理的常见痛点

晋升：是不是技术到位、项目做好就够了？

经过多少“关”才能晋升？

晋升步骤：

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

提名沟通

可以在薪资、年终奖等激励上体现自己对苦劳同学的关注，而对于想要晋升的同学，应该更多给他能力培养的机会，因为对技术同学而言，技术是晋升的基础，战功与业绩也缺一不可，后者是为了证明自己的能力和担当足以承载更多职责。

大部分情况下苦劳不等于功劳，是否具备下一个角色所需要的条件才是晋升考核的侧重点。

资料准备

4 个关键词：资料素材来源、证明实力、PPT编写、赛前演练与心理辅导

素材来源于“过去财年总结 + 新财年的规划 + 汇报材料 + 分享材料 + 项目总结”，因为经过沉淀的资料才最有价值。有了一些素材资料后，就要把控准备阶段的核心：通过素材去证明你具备下一职级所需要的能力。

围绕 5 个维度（架构能力、细节把控的能力、工程的能力、团队的能力、技术视野）去梳理和提炼关键信息，准备相关资料。

编写 PPT 将证明你能力的框架可视化，突出重点、内容翔实、数据说话、功劳大于苦劳、突出自我。

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

晋升答辩

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

结果安排

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

晋升不是奖励，是责任与担当，是为未来做的事。

跨团队：没有汇报线的人和事就是推不动？

跨团队事务推进的难点

• 方案无法达成一致： 你提出的 A 方案与运营团队提出的 B 方案，在实现成本、方式、资源等方面存在很明显差异，陷入僵局。
• 时间无法达成一致： 协作方赞同 A 方案，但对“一周上线项目”的时间节点有意见，认为至少需要 20 天，这会从“时间无法达成一致”回滚到“方案无法达成一致”，陷入新一轮僵局。
• 优先级无法达成一致： 协作方赞同 A 方案，对项目用时一周也无异议，但该项目优先级在他那儿没有提到很高，一直有优先级更高的项目插队，导致交付时间一变再变、一拖再拖。
• 阶段性交付结果不一致： 因为某些原因（线上突发状况、同学请假、人员能力较差……），与你协作团队在配合时交付你的结果质量无法满足你的需求，比如运营给的方案有很大漏洞、技术给的接口 Bug 比功能点还多，你又无法直接管理对方团队的成员，最终即使更正了也可能浪费了额外的时间。

难点产生的原因：

• 协作方不清楚项目原因和意义，会优先考虑自身利益，根据利益高低推进难度由易到难

• 协作方有自己当前的工作内容和优先级，突然配合进行其他事务，引入的风险往往较高

• 各部门对彼此之间的工作方式、团队经验以及当前现状往往不了解

• 任务细化，跨团队合作受时间、空间等因素影响沟通成本较高，有些问题不知道该找谁

跨团队事务推进的基本态度

1. 不要做情绪的奴隶，先找自己的问题
2. 快刀斩乱麻，避免因复杂的问题陷入沼泽
3. 慢思考，快执行

借力前行，摆事实讲道理，凭职级，行进办法，达成目标。

跨团队事务推进的原则方法

• 合作前（明确目标，确保信息完整）
• 合作中（定位问题，借势而为）
• 合作后（承担责任，公开肯定）

换位思考、摆事实、讲道理、凭职级、借势而行、想尽办法达成目标。

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

团队规划解决的核心问题是：让你在有限的时间和资源内，明确怎么去创造最大的技术价值（ROI）。而且在做团队规划的过程中，其实是一个深入思考、梳理的过程，你可以复盘过去、梳理当下、展望未来，少走弯路。

做规划要考虑团队现状

1. 明确定位与职责
2. 人员情况
3. 业务情况

一个可以参考的思路是： 盯着业务目标去延展人员和业务，从而判断哪些是依赖项，哪些是前置项？在大部分公司中，技术很难直接创造商业价值，往往还是要依赖于业务，所以把业务作为第一目标，为了达成某个业务结果，需要调整人员结构，招聘一些更厉害的人汰换一些不行的人，研究并实现一些新技术，这是比较自然的。

你的规划中包含了什么？

不同的技术团队，在规划时所拟定的内容都是不同的，但你其实都可以提炼成共性的3 部分。

• 业务结果： 直白说就是业务层面的战绩，你团队打造了一个公司 GMV 占比超过 50%的商城，或者支撑了某个快速发展业务，这些都是业务结果，用业务数字来说话。

• 技术创新： 由技术人员发起或完成的所有降本提效的动作，但是同样要看优先级和投入产出比。

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

自问：

• WHY：为什么做业务目标/技术创新/团队建设的规划？

• WHAT：是否能说明业务目标/技术创新/团队建设规划解决的问题、价值与作用？

• WHO：由谁承担？负责人的优势与跌势是什么？

• WHEN：所做的规划着眼于现在还是未来？能否保证长期有价值？

• HOW：针对不同的部分，具体的落地细则如何？

• HOW MUCH：规划要做到什么程度？是否可以形成可衡量的KPI？

业务结果

你要明确现阶段上级领导关注的重点是什么？是转化、流量、留存、还是产品的用户体验？作为技术Leader ，你和团队成员的到达路径是什么？这是线索来源之一。

技术创新

稳定性、效能优化、驱动业务、视野展望

团队建设

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

1. 团队未来需要什么样的人？

2. 目前团队成员需要什么样的状态和能力？

3. 团队成员需要承担什么样的责任？

总的来说，你希望未来自己的团队成为怎样的团队？以此推导离理想状态多远？怎么缩小差距？

规划落地时的问题与思路

容易出现的问题：

1. 规划不等于计划
2. 规划内容想得太多，做成的少
3. 业务压力大，盲盯痛点，忽视目标
4. 规划最终成了技术Leader的规划

做团队规划是一件比较综合宏观的事情，有时哪怕只是几个人的团队，想做好一份规划而非执行计划也很考验 Leader 的思考深度，某种程度来说，规划是你定义一群人在未来一段时间内做什么、怎么做、最终变成什么样。这个过程中需要考量的点非常多，这些深入的思考也会促进你日常的一些行为和结果，对于团队的季度乃至半年规划我是非常推荐你要定期梳理并落地的，有目标和没目标的团队，还是有很大的差别的。

接手新团队：士气低、交付迟、事故多发，如何下手解决？

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