技术主管对自身职位的认知决定了他们愿意承受多大的压力和委屈。一种看法是：技术主管既是创业者，也是实干家。因为他们有机会利用公司的资源来实现自己的理想，同时也必须直面现实问题。而另外一种看法：技术主管既是梦想家，又是外交家，他们在复杂的协作环境中锻炼自己的团队管理能力、灵活的协作能力，以及取得有情感和有意义结果的能力。面对高压力和高前景的诱惑，技术主管需要不断提升自我能力，为成为 CTO 迈出坚实的一步。
技术主管的岗位对综合能力的要求极高：他们需要掌握业务知识，以跟上市场步伐，避免带领团队偏离方向；他们需要具备扎实的技术功底，带领团队攻克技术难题；因为他们需要拥有深厚的技术架构能力，洞察本质、化繁为简，从而开发出卓越的系统；他们需要理解人性，因为还要负责团队管理；他们还需要强大的领导力，不仅领导自己的团队，还要协调兄弟部门和上下游协同部门，共同朝着目标努力。
一个人同时具备如此多优秀品质固然可嘉，然而，要求越多元，越容易导致混乱；目标越繁杂，越容易令人迷失。这往往是许多技术主管日复一日挣扎的根源。要达到卓越，确实需要一定的天赋，但实现优秀应该有一定的方法和途径。多年的实践经历让我总结出了一些优秀技术主管的工作要点。
许多技术人担心未来可能被行业淘汰，因此会尝试扩展自己的能力范围，从技术深度的专业化转向技能广度的多元化。例如，他们可能会开始探索项目管理、产品设计或沟通协作等能力。此外，一些技术主管在绩效考核目标制定上可能存在偏差，认为仅仅完成本职工作是基本要求，要想获得更好的绩效评价，必须有超越本职工作的贡献。
这种趋势可能导致技术团队变得浮躁，出现职责错位的现象：技术人员可能过度介入产品设计，而产品经理可能过分关注业务市场的变化。这种组织混乱的代价是高昂的，也是内卷现象的原因之一。这种错位对技术主管的影响尤为显著，容易让他们迷失方向。
不忘初心，方得始终。技术团队的大部分时间应该投入到业务技术项目的交付上。对于技术团队而言，没有什么比这更重要。技术主管需要回归到技术的本职工作，专注于以下几个方面。
（1）项目交付：按时按质按量交付业务技术项目是技术团队生存的基础。技术主管需要亲自把握重大业务项目的实施方案、质量和进展，并通过实践指导团队如何正确地工作，建立正确的态度和评判标准。
（2）接口契约：对外接口是团队的承诺，它清晰地表达了团队的定位及与其他团队的边界。技术主管不应将这些工作完全委派给团队成员，尤其是新手。一旦委派将是技术架构失控的前兆。
（3）领域模型：领域模型是对业务的高层次抽象，是系统的核心。领域模型的变化意味着业务领域的重大变化。尽管领域模型至关重要，但在实际项目实施中往往不是关键点，这导致领域模型作为基础设施被忽视。技术主管需要通过跨项目横向管理来维护领域模型的清晰和一致性，以避免技术架构的混乱和长期业务交付速度的下降。
（4）数据模型：数据模型是业务最终呈现的形式。如何将业务信息转化为结构化数据，如何控制数据质量，如何利用数据挖掘机会以促进业务发展，这些都需要技术主管亲自掌控，而不能依赖他人。技术人做好技术本身是正确且必要的。只有在做好本职工作之后，额外的补位才会显得格外珍贵。
如同武林高手将基础招式练习到极致一样，要成为一名优秀的技术主管，也必须将基本的技能磨炼到精湛的水平。正所谓：“重剑无锋，大巧不工”，真正的技巧不在于花哨，而在于对基础技能的深刻理解和精湛运用。
技术主管需要摒弃不切实际的期望，专注于三个基本功：目标、架构和团队，以及如何在三个基本功中分配精力，如图 14-1 所示。这些能力是技术主管成功的关键，也是他们在职业生涯中不断精进的基础。通过不断磨炼这些基本功，技术主管能够更好地引领团队，实现技术目标，并推动项目的成功。
1. 目标
团队的目标是技术主管的首要任务，它关乎团队价值的证明和组织的期望。技术主管需要明确：组织的要求是什么，团队应承担何种目标，为何选择这个目标，如何量化目标，如何向团队传达目标的价值和意义，如何将目标拆解为可执行的任务，如何跟踪目标的执行，以及如何提炼目标的业务效果。
许多技术主管可能并未始终强迫自己去回答这些问题，但团队似乎也能正常运转。这种情况可能由两个原因造成：一是团队被业务需求压得喘不过气，忙于项目而无暇思考这些问题；二是团队成员虽然意识到某种缺失，但难以言表，也不敢提出。在这种状态下，尽管工作能够应付，但团队缺乏活力和意义感，更缺乏长远发展的想象力。
2. 架构
技术主管的根本职责在于理解和规划支撑团队负责业务的系统架构。这包括明确业务未来发展对技术的要求，确定应该采用何种能力的架构来支撑业务，识别当前架构存在的问题，评估当前架构的最大风险，规划如何将当前架构演进到目标架构，以及确定最应该首先治理的当前架构的哪个方面。
技术架构不仅要适应业务的发展情况，还要考虑团队当前的实际情况。技术架构是一系列复杂的动态决策过程。许多技术主管可能会在心里质疑，尤其是那些专注于应用技术，直接面向客户业务功能交付的技术团队，他们可能会认为，只要紧贴业务，让业务成功就可以了，技术架构作为实现目标的手段真的那么重要吗？有这样的疑问不奇怪：如果只是追求短期结果，杀鸡取卵式地往系统里面“树烟囱”，写临时逻辑总能让业务功能上线，那么技术架构当然不重要。但要想团队长期取得成果，利用技术创新为业务打造竞争壁垒，就必须仔细思考和管控技术架构。
3. 团队
人对了，事就成了，这几乎是创业的不二法则。共事实际上是一种双向选择，是一个不断寻找志同道合者的过程。作为团队的成员一定在不断探询：我在这里工作能获得什么，能有何成长，这里的团队氛围是否符合我的期望，公司所推崇的价值观是否与我的处世哲学相契合。作为团队的领导者，同样需要不断地思考：我们需要的团队成员应具备哪些特质和能力，哪些特质是我们不需要的，团队成员的状态如何，他们遇到了哪些困难，有哪些诉求，如何才能激励大家一起实现目标。
然而，有些技术主管可能只是将团队成员视为资源，只关注任务的完成，而忽略了团队成员的个人成长和需求。这种做法是错误的，因为它忽视了团队成长的本质。一个团队的成长就像培育一棵树，需要投入精力和心血，陪伴团队成员慢慢成长。
4. 精力分配
技术主管的精力分配对于团队的影响至关重要。团队成员不仅会听其言，更会观其行。如果技术主管口头上强调架构的重要性，但实际上从不参与架构讨论或优化工作，团队成员很可能会认为技术主管只是空谈，并不会真正致力于架构的改进。因此，技术主管的行动比言语更能体现其立场。通常建议技术主管在目标、架构和团队方面的精力分配比例大约为 4‥3‥3，但这个比例并非固定不变，应根据不同团队及其发展阶段灵活调整。更重要的是，技术主管需要敏锐地捕捉到精力分配变化的触发条件。以下是一些关键的触发条件。
（1）技术主管关注的事项是否达到预期目标。例如，如果技术主管最近将30% 的精力投入到技术架构上，目标是梳理当前风险基线和处理前三件高危风险事项，那么一旦目标达成，就应该主动调整精力分配，避免过度关注导致团队偏离方向。
（2）客户价值的变化导致目标改变。当目标发生变化时，技术主管需要投入更多精力来应对，包括总结上一个目标完成情况，清晰地论述下一个目标及其变化背景、原因和决策逻辑，确保团队理解和共识，并顺利完成整体转向。
（3）严重的技术风险事件。例如，重大的系统可用性故障或资金损失故障会打乱团队节奏，技术主管需要重新调整精力，不仅要进行严肃的故障复盘，还要仔细检查各个环节的漏洞，并迅速修复，以防止连续故障对团队信心造成影响。
（4）协作关系的变化，尤其是对外协作关系的恶化。这种变化可能会长期影响团队成员的工作效率。技术主管应及时介入，解决矛盾，改善协作关系，避免让团队成员自行消化问题。
（5）团队发展空间问题。技术人才追求不断成长，如果团队失去发展空间，各种问题可能会暴露和放大。技术主管需要特别关注绩效考核、晋升和市场招聘周期等因素，引导团队朝着扩大蛋糕的方向发展，而不是在既定蛋糕中争夺更大的份额。
面对复杂的工作，人们常常会寻求方法、原则和模型来总结经验，以应对未来可能出现的问题。然而，无论多么努力，仅仅依靠模板化的方法只能帮助我们避免一些明显的错误，达到基本的 60 分水平。要想达到优秀的 90 分，必须通过深入的思考和不断的打磨来实现。
在技术主管的成长过程中，学习和掌握团队管理、目标设定、技术架构等具体技能是非常重要的。但一旦这些基础技能已经能熟练运用，技术主管需要再次将自己归零，从实际出发，深入研究问题。我总结了一个“搬家理论”：就像搬家时总能清扫出平时不易察觉的灰尘一样，团队在发展过程中，即使看似一切顺利，也可能隐藏着许多问题。这也是为什么组织结构变动或新主管上任时，团队中可能会爆发问题的原因。
要成为优秀的技术主管，最低成本的方法是能够随时从团队中抽离出来，重新审视团队的目标、架构和团队管理等方面的问题，进行“起底”式的检查和清理。这样的过程就像是搬家时的清扫，可以帮助我们发现并解决那些平时被忽视的问题，对团队进行不断地优化和调整。通过这种方式，技术主管可以确保团队始终保持高效和健康的发展状态。
蚂蚁集团国际事业群的技术专家们结合了超过 10 年的互联网大厂工作经验，总结了一套技术人的工作方法，旨在帮助大家深入理解技术、架构和团队领导力的本质，从而获得持续成长的方法。
《P9工作法：夯实技术硬实力、架构力和领导力》一书便应运而生！
全书分为三篇。
第一篇重点讨论技术硬实力。内容涵盖如何编写优质代码、撰写 系统分析文档、进行领域模型设计、执行代码自测，以及识别典型的分布式技术 盲区等五个方面，以提升技术编码的硬实力。
要成为团队的资深研发力量，不仅 需要具备足够强的硬实力，软实力同样不容忽视，两者都需要坚实。
为此，我们还总结了技术人在日常项目协作中所需的软技能，包括沟通、协作、会议等。
第二篇重点讨论技术架构力。从技术人的成长路径来看，成为技术架构师是必 经之路。
虽然许多技术人都渴望成为架构师，但架构的复杂性往往导致他们仅学 会了方法论（套路），而未能掌握其精髓。
为此，我们根据实际工作经验，沉淀 并总结了一些实战技巧。
本篇将从客观认知技术架构的复杂性、理解技术架构是 做取舍的本质、清晰把握技术架构的演进过程，以及技术架构师的系统性思维这 四个方面，深入剖析如何提升技术架构力。
第三篇重点讨论技术领导力。常言道，“不想当将军的士兵不是好士兵”，在 技术人的职业发展道路上，大多数人都期望能成为 CTO。
CTO 这一角色的要求更 为综合和全面，不仅需要具备技术硬实力和技术架构力，更重要的是，还要拥有 技术领导力——即通过技术的掌握和运用，带领技术团队助力业务实现突破并取 得商业成功。
我们根据领导上百人规模团队的实际工作经验，提炼并总结了如何从团队绩效管理、技术目标的设定、技术组织的成长与发展三个方面打造一个持续发展的技术团队。
一般而言，团队的状态往往反映了主管的状态，团队的上限 往往由团队的主管决定。因此，我们也根据实践经验，总结了技术主管的自我提升方法。
技术硬实力是技术人的立身之本，技术架构力让技术人能够脱颖而出，而技术领导力则使技术人能够协同作战，取得更大的成功。
实践证明，这“三力”是 每个技术人精进成长的必备技能。
