「盘家底。」

「梳理资产。」

「摸排现状。」

说法不同，但干的都是同一件事——技术资产盘点。

这些朋友有从大厂跳到创业公司的，有从创业公司到大厂的，有接手十几人团队的，也有管上百号人的。按理说，不同规模、不同阶段的公司，管理重点应该不一样吧？

但为什么大家不约而同都在做技术资产盘点？

这事儿其实跟公司大小没关系，跟一个更本质的东西有关——手感。

什么是手感

做技术管理，手感是个很玄妙的东西。

举个例子： 团队和你汇报一个系统改造方案，说要花 3 个月，投入 10 个人。你如果此时心里犯嘀咕：这个时间是长还是短？人力是多还是少？如果你没有手感，你大概率会说：”方案不错，但能不能再优化一下时间？”

如果团队回复：”已经是最优方案了。”

然后呢？然后就只能批准了。或者再想其它办法来核实，但心里始终不踏实或者耗费时间。

这就是没有手感的典型表现。

手感是什么？是一种基于深度理解的直觉判断力。

有手感的状态大概这样的：

• 听到「数据库 CPU 占用 80%」，马上能判断是 SQL 问题还是数据量问题
• 看到「服务器 500 台」，立刻知道是不是合理规模
• 团队说「这个需求要一个月」，心里有数是真需要还是在放水
• 出现故障时，能快速圈定问题范围，而不是干着急

而没有手感的管理者呢？就像在迷雾中开车，处处都是未知，步步都要小心。

有手感的管理者，心里有地图，走到哪里都知道车怎么开。

当一个技术团队的管理者没有手感，你的每一个决策都依赖下属的汇报，而你提不出实质性的意见，这样，你的管理权威就会一点点流失，团队也就不好带了。

这也就是为什么空降管理者都急着做技术资产盘点——不是为了显得自己在做事，而是真的需要通过这个过程快速建立手感。

没有手感，你就不是在管理，而是在被管理

手感从哪里来

手感不是天上掉下来的，也不是靠看几本书、听几次汇报就能有的。

我曾经见过太多空降管理者犯同一个错误：急于证明自己。

刚到一个新环境，看到这也不合理，那也不规范，马上就想大刀阔斧地改革。结果呢？不是改革受阻，就是改出更大的问题。

为什么会这样？因为我们所看到的「不合理」可能是合理的。

听说过一个案例。一个朋友刚接手一个团队时，发现新团队的部署流程特别繁琐，一个简单的上线要过五六道关卡。他当时就想，这也太低效了，必须优化。

还好当时忍住了，先做了技术资产盘点。这一盘点才发现，这个「繁琐」的流程背后是血的教训——两年前因为上线流程太简单，出过一次重大故障，损失上千万。从那之后，团队宁可效率低一点，也要确保稳定性。

如果当时贸然「优化」，很可能会重蹈覆梯，当然，也可能不会，至少不要那么急着做事，先缓一缓，看清局势。

手感这个东西，来自于对系统的深度理解。而这种理解，对于一个新接手的管理者来说，可以通过技术资产盘点一点点建立起来。

技术资产盘点就像考古，我们得一层层挖掘：

• 这个服务为什么会存在？解决什么问题？
• 这个架构为什么这么设计？有什么历史原因？
• 这个配置为什么是这个值？踩过什么坑？
• 这些技术债是怎么欠下的？为什么一直没还？

每个不合理的背后，都可能有一个合理的故事。每个奇怪的设计，都可能是特定时期的最优解。

只有当我们了解了这些前因后果，才能真正理解这个系统，才能培养出那种「一眼就能看出问题」的手感。

这就是为什么技术资产盘点如此重要——它不仅仅是在清点家底，更是在建立我们对整个技术体系的认知地图。有了这张地图，我们才知道哪里能动，哪里不能动；哪里需要改进，哪里需要保持。

手感，就是这样一点一点积累起来的。

掌控感是管理的基础

做管理，最重要的是什么？是掌控感。

什么是掌控？不是说我们要事事插手，而是当出现问题时，能快速定位；当需要决策时，有充分的信息；当团队需要支持时，知道资源在哪里。

没有掌控感的管理者是什么样的？

• 技术评审时，只能听团队汇报，提不出实质性意见
• 出现故障时，只能在旁边干着急，帮不上忙
• 做预算时，不知道哪些该花哪些不该花
• 定目标时，不知道什么是合理的预期

这样的管理者，很难获得团队的信任和尊重。

而手感，正是掌控感的基础。

有了手感，才能在关键时刻做出正确判断。有了手感，管理才不是空中楼阁，而是脚踏实地。

这就回到了我们的核心问题：为什么空降管理者都要做技术资产盘点？

因为这是建立手感的最快途径，是获得掌控感的必经之路。我们可以慢慢熟悉团队，慢慢了解业务，但技术资产是实实在在摆在那里的，是可以快速盘点和掌握的。

当我们知道每一分钱花在哪里，每一个系统如何运转，每一个瓶颈在什么地方，我们就有了管理的抓手，有了改进的方向，有了说话的底气。

这，才是技术资产盘点的真正价值。

技术资产到底包括什么

很多人以为技术资产就是服务器、数据库这些硬件资源。其实远不止于此。

我把技术资产分为几个层次：

入口层：掌控用户的入口

域名是最容易被忽视的资产。

以今年 6 月初的阿里核心域名 aliyuncs.com 故障为例：6 月 6 日凌晨，阿里云核心域名 aliyuncs.com 遭遇罕见的域名劫持事件，导致其对象存储服务（OSS）、内容分发网络（CDN）以及云解析 DNS 等多项核心云服务出现大范围故障，波及众多依赖阿里云服务的网站和应用。

除此之外，各企业网站、学校网站等等都出现过域名导致的线上故障。

还有 SSL 证书，很多公司的证书管理一团糟，快过期了才想起来续，结果用户访问时浏览器报警，体验极差。

为什么要盘点入口？因为这是用户接触我们的第一步。域名解析慢了，用户可能就走了；证书有问题，用户可能就不信任了。这些看似小事，实则关乎生死。

接入层：了解流量的来龙去脉

负载均衡怎么配的？有没有做 DDoS 防护？WAF 有没有？规则合不合理？

我在上一家公司，一个月 CDN 账单接近百万，我在做技术成本优化的时候发现，是其接入策略有问题，使用的是 OSS 的流量计费，并且当月受到一些图床攻击。这种浪费，比比皆是。不盘不知道，一盘吓一跳。

还有一些业务上线了，基本的安全策略都没有，直接服务器裸奔在线上，最终被黑客侵入，变成「肉鸡」或矿机。

计算层：服务器不只是数量

“我们有 500 台服务器”——这个信息对管理者来说几乎没有价值。

真正有价值的是：

• 这些服务器的利用率如何？
• 是否存在资源闲置？
• 扩缩容策略是否合理？
• 有没有僵尸服务器在白白烧钱？

我曾经做技术资产盘点发现 30% 的服务器 CPU 利用率不到 10%。为什么？因为之前为了应对突发流量，扩容后就没缩回去。这一项优化，一年就省了上百万。多说一句，大家还真都是草台班子。

中间件层：那些看不见的成本大户

消息队列、搜索引擎、大数据组件……这些中间件往往是成本大户。

比如消息队列，很多团队的使用方式是「能用队列的地方都用队列」，结果消息堆积严重，不仅成本高，还影响性能。盘点时你会发现，有些场景用简单的异步调用就够了，根本不需要引入消息队列。

甚至，连异步调用都不需要，同步调用就能解决问题，当时只是为了考虑扩展性，才做的甚至队列的最终一致性。然而业务一直用不上。

再比如搜索，Elasticsearch 集群动不动就是几十个节点，但真的需要这么多吗？数据的冷热分离做了吗？索引优化了吗？

存储层：数据是核心资产

数据库的盘点要细到什么程度？要细到表、甚至字段级别。

为什么？因为：

• 得知道核心数据在哪里
• 得了解数据的流转路径
• 得评估存储成本是否合理
• 得发现那些该清理的垃圾数据

曾做过一次数据库盘点，发现数据库中有超过 20 个 copy 表，还有几个超大的日志表，占数据库 80% 的空间，而这些表根本没有人在用，只是当时备份一下。

盘点存储，本质上是在梳理数据链路。

当我们能在脑海中清晰地描绘出「用户在界面上的一个操作，数据是如何流转并最终存储的」，我们才算真正理解了这个系统。

代码资产：不只是代码仓库

代码资产包括：

• 有多少代码仓库？活跃度如何？
• 技术栈是否统一？有没有历史包袱？
• 代码质量如何？技术债务有多少？
• 文档完善吗？新人能快速上手吗？

很多团队的代码仓库就像仓库一样，堆满了各种「以后可能用得上」的东西。结果就是，真正在维护的可能只有一半，另一半都是历史遗留。

流程资产：效率的关键

CI/CD 流程顺畅吗？从代码提交到上线要多久？

我接手过一个团队，上线一个小改动要两天。为什么？因为 CI/CD 流程设计得太「完美」了，各种检查、各种审批，结果效率极低。

盘点流程，我们会发现很多「以前合理现在不合理」的设计。比如，创业初期为了快速迭代，可能没有代码审查；规模大了之后，可能审查流程又过于繁琐。

在制品管理：别让半成品成为负担

什么是在制品？就是那些做了一半的项目、POC 了但没上线的系统、试验性的功能……

这些在制品是隐形的成本黑洞：

• 占用服务器资源
• 消耗维护精力
• 增加系统复杂度
• 埋下安全隐患

盘点时会惊讶地发现，可能有 30% 的资源被这些”半成品”占用着。

制品管理：那些容易被遗忘的二进制资产

什么是制品？简单说，就是我们的代码编译打包后生成的那些可执行文件——jar 包、docker 镜像、npm 包等等。这些东西看起来不起眼，但管理不当会成为大麻烦。

我见过最混乱的场景是什么样的？一个团队，所有的jar包都扔在一个共享文件夹里，文件名是这样的：

• app-1.0.jar
• app-1.0-final.jar
• app-1.0-final-final.jar
• app-1.0-final-真的final.jar

你猜哪个是生产环境在用的？没人知道。

为什么要盘点制品？因为制品管理的混乱会带来一连串问题：

版本追踪的噩梦：出了问题要回滚，找不到上个版本的包在哪。或者找到了，不确定是不是真的上个版本。

存储成本失控：没有清理机制，历史版本堆积如山。我见过一个团队，三年积累了2TB的jar包，其中90%是没用的历史版本。

安全隐患重重：制品里可能包含敏感配置、硬编码的密码。如果管理不当，这些信息很容易泄露。

部署效率低下：每次部署都要到处找包，或者重新编译。本来 10 分钟能完成的部署，硬是搞成了 1 小时。

盘点制品资产时，我们需要搞清楚：

• 制品存在哪里？是 FTP、还是专业的制品仓库？
• 版本管理策略是什么？保留多少个历史版本？
• 制品的构建和发布流程是否标准化？
• 有没有制品安全扫描？
• 制品的访问权限管理是否合理？

建立规范的制品管理体系，看似是个小事，但对提升研发效率、保障系统安全都有重要作用。这也是为什么现代化的研发团队都会使用专业的制品仓库，而不是简单粗暴地用文件夹管理。

盘点的过程就是发现问题的过程

技术资产盘点最大的价值，不是得到一份资产清单，而是在这个过程中发现的问题。这些问题，往往就是我们这些空降的技术管理者的破局点。

比如：

• 为什么同样的功能，A 团队用 10 台服务器，B 团队要用 50 台？
• 为什么数据库连接数经常爆满，但 QPS 并不高？
• 为什么 CDN 流量忽高忽低，找不到规律？
• 为什么某个服务的日志特别多，一天就是几个 T？

这些问题的答案，可能是架构不合理，可能是代码有 bug，可能是产品设计有问题，也可能只是配置错误。但不管是什么原因，都是改进的机会。

如何做好技术资产盘点

说了这么多为什么，该说说怎么做了。

1. 不要贪大求全

很多人一上来就想把所有东西都盘点清楚，结果战线拉得太长，什么都没做好。

正确的做法是：先盘点最重要的，最花钱的，最容易出问题的。比如先看数据库和服务器，这通常占技术成本的大头。如果是内容业务，还有存储，如果是 AI 业务。还有算力或者外部大模型 API 等等。

2. 不要只看数字

“我们有 100 个 API”——这是数字 “我们有 100 个API，其中 30 个是僵尸接口，20 个性能有问题，10 个存在安全隐患”——这是洞察

盘点不是为了得到一个数字，而是为了理解现状，发现问题。

3. 要深入但不要钻牛角尖

盘点数据库要不要细到每个字段？大部分情况下不需要。但核心业务的核心表，我们必须了如指掌。

把握好粒度，既要有全局视角，又要有局部洞察。

4. 借助工具但不依赖工具

市面上有很多资产管理工具，可以自动发现服务器、统计资源使用率等。这些工具很有用，但不要完全依赖它们。

真正的理解来自于和团队的深入交流，来自于对业务的理解，来自于对历史的了解。工具只能告诉我们「是什么」，但只有人才能告诉你「为什么」。

5. 让团队参与进来

技术资产盘点不是管理者一个人的事。让团队参与进来，既能获得更准确的信息，又能让大家都有「当家」的感觉。

可以让每个小组负责盘点自己的模块，然后一起 review。这个过程中，我们会发现很多有意思的事情，比如 A 组和 B 组对同一个服务的理解完全不同。

盘点之后呢

完成技术资产盘点只是开始。真正的价值在于基于盘点结果的行动。

建立资产台账

别让盘点结果躺在Excel里吃灰。建立一个活的资产台账，定期更新，让它成为团队的知识库。

新人入职，先看资产台账；技术决策，先查资产台账；故障排查，资产台账能帮大忙。

制定优化计划

基于盘点发现的问题，制定优化计划。哪些是quick win，可以马上做？哪些需要长期规划？哪些需要跨团队协作？

记住，罗马不是一天建成的，技术债也不是一天能还清的。有节奏地推进，比急于求成更重要。

建立监控体系

光盘点不够，还要建立监控体系。资源使用率、成本趋势、性能指标……这些都要持续监控。

很多问题都是慢慢积累的。如果没有监控，等我们发现时可能已经很严重了。

形成资产管理文化

最高境界是形成资产管理的文化。让每个人都有成本意识，都知道自己用的资源值多少钱，都会主动优化。

这需要时间，需要机制，更需要管理者的坚持。

最后

技术管理空降，最难的不是推新技术、搞创新，而是先把现有的东西搞清楚。这就像医生看病，不把脉、不验血，上来就开药，那是江湖郎中。

技术资产盘点，就是给技术体系做一次全面体检。只有知道了哪里健康、哪里有病，才能对症下药。

这个过程可能很枯燥，可能会发现很多历史遗留问题让人头疼，但这是建立手感、获得掌控、赢得信任的必经之路。

记住，管理的本质是通过他人完成工作。而要想通过他人完成工作，我们首先得知道工作是什么、资源在哪里、问题在哪里。

技术资产盘点，就是回答这些问题的第一步。

不要急着证明自己，先把家底摸清楚。当我们真正理解了这个技术体系，知道了每一分钱花在哪里、每一个系统为什么存在、每一个问题因何而生，我们的管理才能真正落地。

毕竟，空降兵最重要的不是会打仗，而是先活下来。而活下来的第一步，就是搞清楚自己降落在哪里。

如果你是一新手管理者，或者你是一个刚升职，从带一个几人的小团队到带几十人的团队，或者你空降到一个新公司做技术管理，都可以看一下这六张表格。

要搞定一个新技术团队，主要是四步：

1. 弄清楚有哪些人；
2. 搞清楚有哪些事；
3. 把人和事关联起来；
4. 确定好目标并执行

前三步中我总结了六个表格来梳理这些结构，在这些结构的基础上我们明确团队的目标，并执行下去，将会有一个不错的结果。

1. 弄清楚有哪些人

弄清楚有哪些人的关键点是人才梯队和人才发展计划的表格，确认哪些会有下一步晋升，哪些可能会走，哪些是有问题的，做好 1v1 沟通，先熟悉起来，了解每个人的工作状态，特别是核心骨干。

1.1 成员信息表

成员信息表能帮助你了解你的团队成员的背景，在职时间等，这些信息可以找 HR 或者之前团队的负责人去了解，或者当面沟通的时候了解等。

可以通过透视表的方式使用成员信息表，其可能的用法：

1. 看人才职级占比，是否梯队不合理；
2. 看职场分布，是否多地，沟通成本有多大；
3. 看在职时长，是新人多，还是老人多；
4. 看工作年限，看年轻人多，还是资深的人多；
5. 看职位，各技术工种占比，配比是否合适；
6. 看老家分布，下次出去吃饭点菜心里会有点谱。

1.2 人才梯队表

人才梯队表主要是帮助你理清当前团队的梯队情况，哪些是能带项目的，哪些是只能执行的，以及当有人才流失的时候，哪些同学是可以补位的。

一般人才梯队表如上，也可以有更多级，具体看团队规模，几十人的团队大概三级左右就可以了。 如果是一个研发中心，其人才梯队表组成如下：

• 负责人主要是某一块技术的负责人，是这块的掌控者，不仅要求技术，还要求有较强的管理经验；
• 第一梯队主要是骨干同学，是负责某一块业务的模块负责人，不仅要求技术，还需要有一些项目管理的经验；
• 第二梯队主要是偏执行的同学，负责某一块具体的事务。

1.3 人才发展计划表

人才发展计划表主要是识别出团队中成员的当前状态，以及下一步的发展计划。

人才发展计划表主要是了解团队的成员的具体情况，多和老员工去聊聊，工作接触中多观察，并且可以通过下一级的 Leader 了解一线同学的状态，这个过程中可能会有一些信息的过滤，需要批判的接收信息。

1.4 做好沟通

做事之前先做人，做人之前先熟悉。

对于新同学，先认识一下，让对方知道你是怎样的人，以及了解一下对方是怎样的人，背景如何。可以从 HR 或其它渠道拿到简历等信息。

在破冰后可以多聊一下现在手头的工作内容以及将来团队的情况，目标等。 沟通过程可以适当的记录一些信息，整理到上面的成员信息表和人才发展计划表中。 至少都做一次 1v1 沟通，以及一次全员沟通，全员沟通可以和周例会合到一起。

2. 弄清楚有哪些事

在理清人的同时，也要同时开始了解有哪些事情。

作为技术管理者，多看文档，多看代码，多看表结构。多和原来负责的产品沟通，聊聊天，和原来负责的开发也多勾兑勾兑，在这个过程中把一些信息落成表格。

2.1 业务模块重点问题表

重点问题表主要是提取当前业务的重点问题，并从中找出能早点出成果的破局点。

从以上的表格中找到能快速解决大家工作中的痛点或者业务痛点的问题，尽量以 ROI 较高的方式处理，打破局面，获得一定的信任，当这种小的成功累积多了，你在团队中的口碑也就建立起来了，后续要做一些大的改变也顺理成章。

2.2 RASCI 矩阵表

RASCI 矩阵表主要是澄清项目组成员权利与责任，明确事项，作为项目管理中必要的沟通工具存在。

有了 RASCI 矩阵的表，我们就可以知道业务边界在哪里，出了问题应该找谁，找谁去决策问题，做好了找谁去汇报或通知。

3. 把人和事关联起来

人和事关联，主要是找到事情的是什么，是团队的什么人在负责什么内容，这里重点要关注模块负责人。

3.1 模块负责人及成员表

模块负责人及成员表主要是理清具体某个事项是谁在负责，谁在执行。而模块负责人是一块业务的技术负责人，是一个小的技术 Leader ，负责掌控该业务模块，包括人和技术，是各端 Owner 的后备人才池，这个制度是人才梯队的核心制度之一。

模块负责人的主要职责包括：

1. 参与需求规划并评估模块需求所需人力；
2. 与模块成员对齐迭代需求，分配并拆解需求；
3. 识别和管理模块内的需求，及时暴露风险；
4. 对模块负责，推进并协调模块成员解决问题；
5. 迭代完成后回顾模块内的需求；
6. 关注并引导模块成员成长。

4. 明确团队的目标

这里更多是的向上沟通，和产品，老板多做沟通，了解公司整体目标，业务目标，技术目标等，在这些目标的基础上结合当前团队的现状，和团队成员做一定范围内的讨论，一起制定出团队的目标。

在初步确定目标后，和上级沟通团队目标，并达成一致。

5. 清晰目标和持续跟进

达成共识的目标后，将目标分解向下同步，确保大家对于目标能有清晰的认识。

这里我们会用到 OKR 、KPI 等技术，通过周报将 OKR/KPI 和具体的产品需求，技术需求关联起来，将目标，过程需求，过程进展，业务价值通过周报的逻辑持续的跟进起来，反思一周之中我们所做的内容是否向着我们的目标前进。

同时，建立沟通机制，周报机制，周会逻辑等等。

结语

接手新团队不是一个一蹴而就的过程，需要时间，把工作做实，该聊的天要聊到位，该开会的会要开，该喝的酒不能少。 就像一个又大又重的飞轮，开始的时候很艰难，努力转动一厘米，两厘米，一段时间后，发现转完了一整圈。飞轮开始转动，不停的努力，飞轮又会转完第二圈。继续沿向一个方向努力，3 圈 …… 4 圈 …… 5 圈 …… 6 圈，轮子开始加速，7 圈 …… 8 圈 …… 9 圈 …… 10 圈 …… 轮子有了动量，已经可以开始自己转动了，再坚持就能很快的飞转了。

最后引用冯唐的九字真言「不着急，不害怕，不要脸」，2022，加油吧！

模板在这：

飞书 Docs Link: https://fgr6cngqqy.feishu.cn/space/sheet/shtcnywzAOBxaeiU5ofJTYNXrGb Password: x1w8

你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com

高阶技术管理空降落地的关键点我觉得主要是两个大的方面，一个是心态，一个是节奏。

1. 心态

中国古代有一个”心态过门尤当先“的寓言笑话：

  洞房花烛夜，羞羞答答的新娘低头看着地上，忽然掩口而笑，指着地上对新郎说：“看，看，看老鼠在吃你家大米。”

  第二天，新娘早早起床洗漱，看到老鼠又在吃大米，大声怒喝：“该死的老鼠，竟敢偷吃我家大米！”

  接着是“嗖”的一声，一只鞋飞了过去。

  新郎听了大喜，知道新娘的心已经离开原来的娘家，过门到现在的这个家了。

  过了门儿啦，新娘心态的转变从她对待老鼠的态度上就可见一斑，所以说，“心态过门尤当先”。

这个笑话对于我们新加入一个公司同样适用，心态很大程度上决定了是否能适应这个新的公司。 心态可分为 4 个点

1.1 对过往的态度：保持敬畏

在大厂工作多年，已经熟悉了大厂的流程和做事方式，习惯了有完善的制度和流程，习惯了强力的支撑系统。到新的公司，可能会觉得这里不行，那里也不好，甚至觉得自己是过来拯救团队的，是救世主。一上来就高谈阔论，方法论，高可用高性能等等，或者直接全部推翻重来，甚至会有直接换一个技术栈，这样操作往往会闹笑话，出问题，这里背后的原因是在于心态。有些急了，有些不切实际。

高 P 技术同学新入职一家新的公司，负责某块的技术，首先要有谦卑的心态。谦卑，就是对万事万物怀一颗敬畏之心，持一份包容情怀，谦卑的人更懂得尊重别人。

新的公司肯定是存在一些问题才会请你过来，所以有问题是一件很正常的事情，但是我们来了后，要保持谦卑，对原来的架构保持一颗敬畏之心，一个公司发展到这个规模，经历了非常多的风风雨雨，还能存活到现在肯定是有其道理的，而且还有一些从表面上看不到的问题，如冰山一样，深埋在水下，保持敬畏，尊重历史成绩。

1.2 快速融入的秘诀：不着急，不害怕，不要脸

“不着急，不害怕，不要脸”是冯唐在《冯唐成事心法》中常提的九字真言，对时间不着急，对结果不害怕，对别人的评价不要脸。

到新的公司，每一个新同学都会想想快速融入，想快点搞清楚公司的做事逻辑、业务流程，技术实现，想快点出成绩，想快点……

这些都是正常的，不要着急，给自己一些时间，给周围的同学一些时间，给事情的发生和发展足够的时间，遵从事物发展的客观规律，尽心尽力，有定力和耐心，在理解公司战略的基础上，沉下去把业务做起来，不用害怕，一切都会是最好的安排。

不要脸，是指快速融入现有团队不要脸，多听听大家的意见，为大家争取一些小的利益，和大家一起吃饭，一起加班，一起讨论问题，有空出去多聚餐，喝点酒，喝多了才好称兄道弟。

同时，放下过去的种种，不管你在过去是什么岗位，带多大的团队，不管是 CTO 还是技术总监，这都是过去的平台给你的，都已经是过去式，在新的地方你就是一个萌新，最多算一个工作很多年的老萌新，作为一个萌新就是要多看，多问，多想，不要脸的那种。

多看看公司的文档，虽然文档刚开始不那么全，但是只字片纸也能让我们对业务有更多的了解；多看看同事的做事方式和流程，知道在这样一个新团队里面大家的工作方式和节奏，发现好的地方和不好的地方，先记下来；多问问公司呆的久的人，有问题的时候多问问业务线的负责人，寻根究底的把项目搞清楚；多想想一个项目或一个团队是放在那里，多想想一个人为什么会出现在某个项目，多想想自己是来做什么的，多想想自己能带来什么价值。

在融入的过程中，不要怕丢脸，敢于被打脸，你问问题的人可能年龄比你小，工作年限比你少或者各方面都不如你，但是在这项目就是比你熟悉；或者一个完全陌生的人，很慢才回你的问题，甚至不回，这些都不重要，关键点是能得到你要的信息，能够帮助你更多的了解公司或项目。在公司的会议上敢于发表自己的意见，可能是错的，可能会被打脸，这些都不重要，关键点是能让更多的人认识你，更快速的融入新的公司。

如此，不着急，不害怕，不要脸，快速融入。

1.3 应有的工作态度：尽心

是尽心，而不是尽力，因为尽心和尽力是两回事。尽心做事和尽力做事，有天壤之别。

其差别关键点在于投入度，如果有人问有没有把握把事情做好，回答是尽力而为，这个回答没有错，也显得很敬业，但是其潜台词通常是“我的能力只有这么多，所以就只能做这么多”，但是每个人的潜力都是很大的，个人的力量可以释放得更充分一些。

如果是尽力，其潜台词是“我一定能完成任务，而且能做得更好、更多”。尽力有些给自我设限，只对自己的能力负责，缺少一些进取之心，只有尽心才能释放潜能。在选择团队成员的时候，一个尽心的员工，哪怕能力差一些，技术差一些，进展慢一些，但是投入度高，能全心全意的投入来完成工作，非常积极，假以时日，能力，技术、进度都将不会是问题。假设一个人的能力值是 1 ，一个尽力的人最多只愿意发挥 1 的能力值，甚至 0.8 ，而对于一个尽心的人来说，哪怕自己的能力值没有 1 ，其也会想办法达到 1 ，甚至超过。不给自己设限，释放自己的潜能。

尽心能带来安全感。尽心做事的时候会有特别重的 Owner 感，有那种这个事情就是我的，和其它东西无关，纯粹是想把这个事情做好；我的心血，我做的东西都在上面，就有了极强的安全感。 这里还有一个前置逻辑，就是信任，组织对个人的信任，组织认为这是你的事情。

1.4 能成事的做事方式：躬身入局

罗胖在 2019 年的跨年演讲中提到了一个概念–躬身入局，是曾国藩讲的一个故事，让人印象至深。 故事是这样的：

  两个农人，挑着沉重的担子，相遇在农田间狭窄的田埂上。
  他们谁也不愿意相让，因为那样的话，想让的那人就要一脚踩到泥泞的水田里，沾一脚泥。他们就那样顶上了，谁也不让谁。

  作为一个旁观者的你该如何相劝呢？
  我们能想到的是：退让一步，海阔天空，要不都走不了。
  其实大多数人，有时候脑子里想的就是：“我凭什么要让你？大不了都不走，看谁犟得过谁！”

  曾老先生从另一个角度提出了解决问题的方法——做一个躬身入局的人：
  旁观者跳入水田，接过其中一个人的担子，让他先过。这样，问题就解决啦。

  这也就是曾老先生所说的：”所谓天下事，在局外呐喊议论总是无益，必须躬身入局，挺膺负责，方有成事之可翼。“

何为做事之人？

不是置身事外，指点江山。而是躬身入局，把自己放进去，把自己变成解决问题的那个人。

躬身入局是对一个管理者基本的要求，是对其执行力的要求。真正的执行力是深入业务场景，和产品，运营、开发小伙伴在一起，共同解决问题、共同克服困难、共同面对挑战、共同承担责任。败则拼死相救、胜则举杯同庆。时时刻刻思考“自己在团队发展过程中扮演什么角色”这个核心问题，以及如何把深度思考后的结论付诸行动，持续迭代。

清晰了心态，我们再聊一下入局的节奏。

2. 入局节奏

人生犹如棋局，职场更甚。能识局者生，善破局者存，掌全局者赢。

2.1. 识局

1. 了解行业大背景，公司所在的赛道是什么？如果是创业公司，投资人是否关注这个赛道？主要营收靠什么？竞争对手有些？竞争对手的生存情况如何？这个步骤应该是面试这家公司之前就做了一些，本次就是细化其中的更多的关键数据，为后续的一些判断和决策提供顶层的支撑。
2. 了解公司大背景：公司的文化是什么？大家是如何协同工作的？时间管理是怎样的？做事的价值观是怎样的？怎样的人在公司会更能得到大家的认同？
3. 了解所在位置： 所负责的业务在公司的位置在哪？所负责的团队在公司的位置在哪？对接的部门，合作的人是哪些？有哪些诉求？业务边界在哪里？利益的边界在哪里？公司大的项目有哪些，干系人有哪些？项目历史情况，现在的情况如何等等；
4. 了解团队成员：逐一和团队成员做一次 1v1，了解其背景，从 HR 处拿到入职时间 / 工作年限 / 级别 / 薪资结构等信息，了解人才梯队
5. 了解现在的问题有哪些？挑战点有哪些，是人的问题，流程的问题，还是历史的问题等等，了解清楚公司招我过来是希望我解决什么问题的。

2.2. 破局

2.2.1 先小后大，以点破面

新官上任不用着急，先梳理业务逻辑，人才梯队，业务流程等等，找到问题点，找到破局点。

不要图大而全，不要一上来就搞大系统，先做小，从小点突破，拿到业绩和成果，建立信任，然后再做大的规划。 大的规划从规划到落地需要的时间太长，这样一个很长的时间里面如果没有产出，没有看到有成效的内容出现，可能还没有等到开始落地就已经出局了。 做小点是为了解决生存问题，做大的规划是为了解决发展的问题，顺序不能搞反了。

常见技术破局点：某些服务的性能问题，频发的告警服务，高负载的数据库，客诉问题多的点，新项目的技术架构方案，研发流程中的卡点，构建发布流程的优化，长期没有人能解决的问题、痛点或难点并且能快速解决的。

2.2.2 搭班子，带队伍

除了专注于破局的点和事项以外，尽快搞定人的问题，把团队搭起来，把人才梯队搭建好，管理者更多的是通过一线同学的手来拿结果，没有一个合格的团队，破局难，掌局更难。

首先，做好现有团队的沟通工作，不要让人觉得你是来抢事的，要让他们相信你是来帮忙的，来帮大家解决问题的，空降后和团队在行政上是上下级关系，但是根本上是合作的关系，来的作用是帮忙大家的。带领大家一起赢，遇到问题，是跟我上，而不是给我上。

其次，尽量用现有团队成员，也可适当新招或带一些人过去。现有团队有其优点，也会有其缺点，这些人在公司的时间长，掌握的信息量和资源都是一个新人缺失的，甚至有的人是跟了老板多年的老员工，能在老板面前说上话，甚至可能老板会问新来的这家伙感觉怎么样。在刚到团队的时候，要团结这些原有团队的人，有助于快速掌握资源和信息，加速你融入和破局的过程。

最后，在团队中找到志同道合的人，作为核心成员培养他们，让他们成为你的得力助手。饼还是要画的，落到手的实际也是需要有的，大棒和枣一个都不能少。

如果现有团队里面有不服你的人，极度不配合，但是还是要想办法去融入，不要脸的那种，等站稳后再看怎么处理。比如有一个 leader 不服，到处鼓动大家不配合工作，没关系，继续安排工作，只要工作能完成得好就行，而且还给比较好的绩效，针对好的绩效再提出高的标准，如果没有达到标准再降绩效，同时，招聘或内部提拔一个可以替代的同学，半年或者一年以后，站稳了后再视情况考虑后续的操作。

凡事都有套路，还是套路得人心，常用管理套路：

沟通反馈：1v1、个人目标制定、OKR、反馈、周报、周会、月会、团队建设、非正式沟通、向上管理
项目管理：项目进度、风险管理、紧急需求、复盘、跟进、反馈、拿结果
项目质量：线上稳定性、代码质量、Code Review、交付质量
人员管理：备份、淘汰、晋升、激励、绩效管理，360
人员招聘：业务盘点、人才盘点、人才素质模型、人才梯队、实习、试用
学习：总结、分享、交流、达摩院

2.2.3 破局

在和团队充分沟通，了解一些业务，了解业务中的痛点后，根据难易程度和优先级，选择个人觉得有挑战，好突破的点，找到破局点后，和领导沟通，得到充分的支持和授权，拉兄弟们一起干，和团队一起拿结果，在这些小点的累积中，上级对你的信任、团队对你的信任慢慢就建立起来了，如此，在这个新环境算是存活下来了，至此，已破局。

2.3 掌局

破局以后，随着时间的增加，从一个新人慢慢变成老人，对业务越来越熟悉，对人也越来越熟悉，此时不能飘，得躬身入局，把自己放进去，把自己变成那个解决问题，能掌控全局的人。

掌控全局可以从人员管理、团队演进和流程机制三个方面来掌控。

2.3.1 人员管理

人员管理主要是人的聘用育留。

• 招人：招人得先有业务，研发是为业务服务的，先搞清楚业务是要做啥，然后才是盘人，看看现在有什么人，都有什么样的人，还需要什么样的人，这样的人在哪里可以找到，以及给这些人我们可以提供什么样的待遇，什么样的机会等等；常用套路：业务盘点，人才盘点，人才画像，人才素质模型，人才地图，面试流程，面试官标准，人才策略，内推，专场，
• 用人：一线执行的同学看才能，对于技术同学来说就是技术水平怎么样，另外，还会看态度，或者说是工作的投入度，对于投入度高的同学会有一些资源倾斜；中层看德行和才能，这里的中层是指有管理职能的同学，同样也需要看技术能力，同时要看规划的能力，项目管理能力，沟通能力等等；高层看格局，是不是能从让公司更好出发来解决问题，而不是局限于自己的一亩三分地；常用套路：聚集，复盘，人才梯队，人才密度，分层用人，360度考核，加减分制，模块负责人，需求负责人，项目管理，风险管理，老人做新业务，新人做老业务
• 育人：这块主要是培训分享，新人融入，以老带新，员工成长，常用套路：IDP，导师制，分享会，管理培训，技术通道，自我迭代，培训体系，职级体系，文化，价值观，方法论，系统化
• 留人：基层基本上是看待遇，这里的待遇除了薪水，还看一些软性的福利和团队氛围，说白了就是看呆得爽不爽，有没有成就感，有没有感受到成长；中层靠情感，主要是领导是不是靠谱的领导，能不能帮助他提升，是不是一起奋斗过，对团队有感情了就不那么容易走；高层就要看事业了，主要是看这个事情是不是能做得大，大家在一起最后会不会把这个蛋糕做得更大，能让自己有那种事业的成就感，并且在事业中能得到较大的回报。

2.3.2 团队演进和价值观

对于一个团队来说，一般分为三个级别，初级，中级，高级，但是这三个级别并不是泾渭分明的，可能会三个级别的东西会同时存在，因为团队中包含的内容模块较多，不同的内容模块所在的级别不一样。

• 初级团队：初级团队靠骨干，以人治为主，这个阶段把核心骨干找到或者培养起来，让他们来搞定事情；
• 中级团队：中级团队靠规范，以人治 + 流程规范为主，在核心骨干的基础上，把好的经验以流程规范的方式沉淀下来，就算是核心骨干走了，还有东西可以传承；
• 高级团队：高级团队靠系统，把好的规范做成系统，用系统来驱动团队的进步，在系统的支撑下，让好的东西传承下来，让大家更高效更好的工作。

三个层面团队不是一蹴而就的，也没有清晰的分层，是一个演化的过程，从培养骨干开始，到规范化，到系统化落地，一点点积累，这样整个团队就会变得更好一些。这也是带研发团队最大的挑战。

在清晰了解团队所在阶段的同时，团队领导者需要从平时的工作中提炼出适合自己团队的价值观。

价值观是什么？

团队的价值观就是表达一个团队赞同什么，反对什么，是一个团队做事的行为准则。 价值观会潜移默化地体现在团队成员的做事的态度和方式方法上。

如我们的价值观是：

• 允许犯错，但不容忍罔顾教训、一错再错 这个是《原则》这本书里面提到一个观点，也是我们非常认可的一个观点，允许犯错是让大家不要畏惧挑战，敢于试错，不容忍罔顾教训是我们遇到问题和错误要复盘和总结，找到问题的根本原因，总结出方法论，后续可以规避类似的错误。
• 长期有耐心，基于深度思考的持续迭代 长期有耐心是一本讲美团的书里讲的内容，对于我们同样适用，持续迭代，长期有耐心的把业务做好，提升自己，自我迭代。

2.3.3 机制和系统化建设

带研发团队，在流程机制方面主要是关注研发效率和研发质量。对于研发效率和质量需要有一个完整的研发流程来保证，一般的流程如下：

流程保障之外，还需要和产品，UI 等各方确认协同的节奏，如周需求评审机制，双周 APP 版本发布，版本回顾会等等。 同时我们需要制定团队的标准和规划，并且在过程中根据需要迭代这些标准规范，常见标准和规范如下：

• 人员标准：技术职级标准、绩效考核标准、候选人评估标准、干部评估标准
• 质量标准：代码质量标准、Code Review 标准、测试质量标准、线上质量标准
• 性能标准：服务端性能标准、客户端性能标准、前端性能标准
• 安全标准：代码安全标准、数据安全标准、线上安全标准
• 研发规范：代码风格规范、数据库设计规范、代码分干管理规范、代码提交规范、错误码规范
• 协同规范：架构规范、技术方案规范、技术文档规范、接口规范

在流程规范和协同之外，研发的效率和质量需要有一些基建来保障，如好用的框架，集成在框架中的静态代码分析，流畅且稳定的构建系统，靠谱的日志系统和监控系统，好用的链路跟踪系统等等。如果公司暂时没有这些，那么先看看业界有哪些，做一些选型后，把最合适的用起来。

你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com

除了眼前的苟且,还有架构与远方。

介绍创业路上的技术选型和架构、大型网站架构、高性能高可用可扩展架构实现，技术管理等相关话题，紧跟业界主流步伐。