在职场多年，但凡大一点点的公司，周报/日报大多成了标配，而各家公司对于周报的要求也不相同，大家写周报的方式也不相同，有些是为了应付一下，如有这样写的： 本周周报：完成了上周工作，和领导交待的事项，下周继续；

有些的好一些，记了个流水账，大概是这样：

周一做了 XXX
周二完成了 XXX
周三对接了 XXX
……

再好一些的，对这些流水账做了一个分类：

上周完成：
重点事项：XXX
非重点事项：XXX
临时工作：XXX
下周计划：
重点事项：XXX
非重点事项：XXX

再好一些的，就会加一些可衡量的内容，或者一些量化的数据。 如此种种 还有更好一些的，都写成小作文了。 然而不管上面的这些如何，大家「苦周报久矣」。是什么让我们觉得周报是种负担，为什么我们不想写周报？

我们可以先看一下周报到底是什么？

1. 周报是什么

从公司管理的角度来看 周报是公司流程化管理的一部分，是正式沟通地一种手段或方式，其目的是为了更好的向下管理和向上反馈。 作为管理者可以通过周报了解一线的情况，如项目的进展，工作的动向；作为普通员工可以通过周报系统性地表述一线的状况。

从个人成长的角度来看 周报是个人反思成长的载体，是自我管理的一种方式，其核心逻辑是：在过去一周你的时间花在了哪里，解决了什么问题，过程中有什么思考，个人有哪些成长。

2. 周报怎么写

2.1 明确受众和主题

写周报和写其它文档一样，需要明确要写的东西是给谁看的，会有一个目标或目的，大的思考结构逻辑如下：

对象：这个周报是写给谁看的，受众是谁？

主题：你想在周报里面主要写什么内容

目标/目的：为什么要写这份周报 / 希望周报受众了解什么 / 希望他/他们给予你什么帮助

在搞清楚以上这些问题后，基本上要写什么就确定了，目标确认，接下来就是要怎样达到这个目标。 针对不同的受众，需要有不同的逻辑。在职场中，看我们周报的人无外乎上级、团队/下属和自己，下面我们就这三个维度看看一份合格的周报应该怎么写。

2.2 写给上级的周报

写给上级的周报主要是向上汇报，向上管理，其主要作用是让你的上级清楚知道你/你的团队在这周主要做了什么，其关键有 4 点：

1. 有成果 一周你的团队肯定有产出，挑重点或上级关注的点呈现，不要太细节，大的事项就可以了；
2. 有数据 对于成果的展现尽可能做到具体而有数据，可衡量或可量化，以确保上级能精确了解状态和相信结果
3. 有思考 作为管理者，思考团队的问题是你的本职工作，在周报中要特别体现这点；
4. 有格局 有格局是指不要把自己的眼光只停留在自己的一亩三分地，至少尝试站在你的上级的角度来思考问题。

作为一个技术管理者，一个合格的周报大概如下：

1. 核心事项同步，你的上级当前的 OKR/KPI 关联的事项，你作为一个信息源提供信息，因为你的上级需要通过你拿到一线的情况，对于核心事项中需要上级协助的点也一并体现出来，加粗，需要上级协助的点要明确具体，大概标准是上级看到了就知道自己要做什么才能帮助到你；
2. 业务里程碑，记录在业务事项推进过程中的阶段性成果，以业务价值为主，对于有明显价值或者有明显变化的予以体现；
3. 研发流程、效率和质量，记录研发管理过程中出现的流程变更，组织结构的变动，效率的改进、质量的优化和线上的问题等等，如研发需求延期，线上事故复盘总结，人员变更（离职，转岗，入职，并说明情况）。对于一些问题或较大一些的事项，建议以 STAR 原则表述，Situation（情景）、Task（任务）、Action（行动）和Result（结果），同时在后面附加相关文档，如果问题需要上级来协调，在这部分内容中用加粗等较明显的方式标出；
4. 思考和总结, 这里主要是体现你的思考和总结，可能你会想我哪有那么多总结和思考，这是一个问题，但是是可以解决的问题。如果在一周中你有持续思考团队的价值，团队的问题，并把这些思考和问题记录下来，在周报中一定可以呈现；
5. 人才培养 这一项根据实际情况来，如果有长期的人才培养专项，可以单列体现，如果只是间歇性的，考虑整合到第 3 项。

在写周报之前，需要阶段性和上级沟通确认他在关注哪些事情。因为随着时间的推移，关注点是会变化的，此时我们需要调整我们周报的内容。

2.3. 写给团队的周报

写给团队的周报主要是从你的角度来看整个团队做了什么？哪些做得好的？哪些做得不好？当前团队状态是怎样的？思考如何改进？ 并把你所看到的内容表述给团队成员看，让整个团队了解我们的方向和进展。

写给团队的周报的逻辑大概如下：

1. 工作内容和业务价值的关联和进展 我们在做什么，做的东西的进度如何，做的东西服务于哪个业务的哪个目标，将会产生哪些业务价值；
2. 问题和卡点 过程中我们有遇到哪些问题或卡点，解决了没有？解决了，是如何解决的？没有解决，需要哪些努力或协助，现在进展如何。如一些人员的变动，组织流程的变更，公司级的变更周知，大家捅的娄子，线上的事故，需求延期等等；
3. 里程碑 过程中我们有达成哪些激动人心的小目标，如某大功能上线，某业务增长超出预期，某基建阶段性产出等；
4. 时间维度的交付逻辑 落到细节上，从时间维度看，我们这周在哪些业务线交付了哪些内容，下周要交付哪些内容，哪些内容会跨更长的周期；
5. 状态 整体团队、业务等状态如何，团队成长如何；
6. 思考和总结 过程中我们有哪些思考和总结。

团队的周报更多的是从团队管理者的角度来看问题，抓大放小，持续思考。

2.4. 写给自己的周报

其实我平时很少单独给自己写周报，一些要写给自己看的东西基本都在写给团队的周报和写给上级的周报中，但是如果只是写给自己看的话，也是可以单独拎出来的。

写给自己的周报，其目的是强迫自己思考，如果不思考，你的周报将会流水账式的，每周例行公式的写本周总结，下周计划。 写给自己的周报其核心是自我反省和个人成长，反思一周工作中的表现和思考，一周中自己的学习和成长。

个人周报大概逻辑如下：

1. 本周重要产出 每个人的工作都是为企业创造价值，我们在对本周进行总结时，需要把与业务价值相关联的事项拎出来，关注重要的事项，最多列三项，并且 review 这些事项的进展，问题以及下周我们要解决的点；
2. 下周重点事项 列出下周要做的重点事项，有些是从本周的重点事项中引申出来的，还有一些是新增的；
3. 问题和思考 列出工作中的问题和卡点，把问题反馈出来，并把思考总结的方案也写出来；
4. 总结和成长 对个人一周内的成长做一些总结，是否比上周更好一些了？在哪些方面有所进步，技术基础技能，软技能，知识性的？技能性的？这里是关系个人成长关键的一节。

于公问自己：规划的三件事情有没有做好？三件事是怎么做的？成果怎么样？下周应该怎么去规划？

于私问自己：相比上周你有进步吗？有投入时间提升自己吗？投入了多少时间？有没有系统性地去规划自己的成长？

3. 写周报中的术

3.1 如何提高写周报的效率

1. 养成写工作经验笔记的习惯；
2. 养成系统性地回复问题，并在临时文档中存下来的习惯；
3. 养成写日报的习惯。

3.2 STAR 原则

STAR 原则即情景(Situation)、任务/目标(Task/Target)、行动(Action)和结果(Result) 四个英文单词的首字母组合，STAR 原则是结构化面试当中非常重要的一个理论，常用于面试过程中涉及实质性内容的谈话程序。

我们写周报和面试时类似，都有给一个不熟悉某块东西的人讲清楚一个事情的逻辑，在这个场景下 STAR 原则会让你事半功倍，其结构化表述如下：

情景(Situation)：事情的背景是什么，在什么情况下发生的； 任务/目标(Task/Target)：明确要做什么，目标在哪； 行动(Action)：针对以上的情景和目标，做详细分析的，你采用了什么行动方式； 结果(Result)：有什么可衡量的结果。

如果要表述的是事故或问题类的，可以把原因分析和后续规避方案等加上。

4. 其它注意事项

• 尽量不要有数据类的报表，数据类的报表通过数据系统来解决；
• 细节不要写，要有重点，有主次；
• 流水账不要写，要有结构化的表述；
• 请求帮忙和协助最好是符合 SMART 原则，协助的点要明确具体，大概标准是上级看到了就知道自己要做什么；
• 抓大放小，放开平时讨论的细节，更多地对大目标大问题进行讨论，思考目标达成，业务价值等重要的问题；
• 要有观点，要有重点，要有想法，要有业务，要有数据。

5. 结语

写作并不难，重要的是思考，对于周报也一样。

如果你不能对自己想要在周报中表达的内容和观点有清晰、准确的认知，那么你将根本无法写好周报。

如果你在带一个团队，如果你想在团队中执行周报的逻辑，那么先思考一下你的目的是什么？ 是想让同学们养成工作计划/思考/总结的习惯？还是想让他们快速成长？还是想拿到一线的情况？ 对于技术管理者来说，周报是一个管理动作，而我们在做管理的时候不要做无效的管理动作，思考一下本质的逻辑。

写了这么多，斟酌反复，还是觉得有些想说的没有说出来，就这样吧。

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

以前听到过这样一个故事：

两个人在森林里，遇到了一只大老虎，A 赶紧从背后取下一双更轻便的运动鞋换上。 B 急死了，骂道：“你干嘛呢，再换鞋也跑不过老虎啊！” A 说：“我只要跑得比你快就好了。”

从这个故事中你感悟到了什么？可能每个人的感悟不一样。我在这里看到最多的是：丛林法则，危机感，没有危机感将会是我们最大的危机

特别是最近经常有人说 35 岁危机，是否你有思考过 35 岁的危机的本质是什么？我认为 35 岁危机的本质是核心竞争力的不足。 那么如何应对这种危机呢，特别是作为一个技术管理者，可能随着年纪的增大，越发“年老色衰”，体力、精力可能都会有些跟不上，从而显示竞争力不足，我们如何破这个局呢？

如果能扎扎实实的做到以下 5 点，你将不会有 35 岁危机的焦虑。

1. 做一个成年人

这里的「成年人」概念最开始的出处是在介绍网飞的那两本书《奈飞文化手册》和《不拘一格：网飞的自由与责任工作法》。网飞文化第一条：「只招成年人」，真正的成年人在公司是一个有机的整体。 成年人有如下 4 个特质：

1. 有能力安排好自己的时间；
2. 不会只是抱怨问题，会自己去解决问题；
3. 懂得纪律和规则的重要性；
4. 面对一个巨大的难度，能够和一群合适的同事一起解决它，成功是最好的激励；

除此之外，咱们这里的成年人还包含以下的一些特点：

1. 随着年纪的增长，情绪越发的稳定，对同级，对下级都一样的稳，当然，情绪稳定不是指没有情绪，该生气的时候还是要生气的，需要有目的的生气；
2. 有事能扛事，遇事不怕事，是一个有担当的人，能够被大家所依靠，遇到事情的时候，上级能第一时间想到你，下级遇到问题的时候，也能想到你；
3. 不急于名利，稳打稳扎，一步步往前走，不要在过程中问：我现在应该有什么样的名利，要有什么样的待遇，要有什么样的地位。「但行好事，莫问前程」
4. 有自己的品牌，刻意在职场中建立自己的专业品牌，比如当说到你时，别人会说，技术大神，业务专家，脾气好，能解决问题等等？

2. 执行力强

说到执行力强，想起 18 年在即构的时候，LYY 老板推荐我重读的那本《致加西亚的一封信》，虽然这本书销量很惊人，但褒贬不一，于我来说，书中主人翁罗文的使命必达最是感动，但是对于执行前的一些规划，书中没有重点体现（其实是有的）。那么在职场中，一个执行力强的同学应该是怎样的呢？

1. 执行前有目标，有规划，有方案；
2. 执行中有反馈，有节奏，有坚持；
3. 执行完有结果，有思考，有沉淀。

2.1 执行前有目标，有规划，有方案

最简单的，看一个人执行力强不强，就看他守不守时，比如大家一起去出游，约好了 10 点集合，A 匆匆忙忙，大家都在等他，最后以各种理由解释迟到的原因; B 早早的就到了，可能还慢悠悠的吃了个早餐，问他什么时候到的，9 点就到了，为什么这么早，他说这个点是上班高峰期，中间会不会堵车，是不是可能遇到一些异常之类的，这些都会影响到最后的结果，提前计划好，早点到，事情就会顺很多。

在上面这个例子中，B 同学有计划，有章法，大概率是一个执行力强的同学。在执行前他有目标，10 点集合，有规划，提前出发。 在职场中，当上级指派一个事情的时候，我们第一步是要弄清楚，老板要的是什么，需求是什么，而不是傻傻的直接开干。这里有一个常用的思维：黄金圈思维，如图所示：

黄金圈思维分为三个维度，最外面表层是「 what 层」，也就是做什么，指的是事情的表象特征；中间是「 how 层」，也就是怎么做的，是实现目标的一些途径；最里面是 「 why 层」，就是为什么做这件事。

一些任务更多的是表述的是 「 what 层」，比如给的是方案，此时我们需要多问一些为什么，找到最核心的需求，其最终要的是什么，这样往往事半功倍。在「耗子叔」很早的一篇文章里面特地提了一个类似的问题《X-Y PROBLEM》，大概意思是：有人想解决问题 X，没有去问怎么解决问题 X，而是去问解决方案 Y 应该怎么去实现和操作。我们常常在执行的时候犯类似的错误。

当我们需要解决某个问题，或者要搞定某件事情的时候，可以先问自己三个问题：

1. 这是否是核心的诉求或根本原因？
2. 有想好怎么去做，有分析过行业内有人遇到过类似的问题吗，如果有人遇到，他们是怎么做的？
3. 有结合自己的实际情况去思考吗？有形成可执行的方案吗？

2.2 执行中有反馈，有节奏，有坚持

当我们确认了目标，方案后，下一步就是实际操作了，这个时候可能就会有同学问了，这不就是执行了吗？还有其它讲究吗？蒙着头一直做是一种执行的方式，但不是一个好的方式，我们在执行过程中，特别是当执行需要持续一定时间的时候，需要不停的反馈。

比如你是一个商业化的团队的负责人，带着几十号人，运营到产品，到研发都有，在一个季度开始的时候已经和老板确认了目标，在执行的过程中，当有一些好的突破，应该和反馈给老板；或者有难题，拿着问题和方案和老板沟通；也可能业绩四平八稳，此时也可以定时汇总反馈给老板，让他知道一切正常，这样就让你的上级会觉得事情在控制之中。

在执行的过程中，我们经常会遇到困难，对于一个执行能力强的人，困难只会是路上的坑，没有趟不过去的，坚持到底，使命必达。 关于执行过程中的反馈、控制和坚持，我印象最深的还是在大学的时候选修课的老师给我们放的余世维的讲座视频，已经不记得是哪场培训了，只记得他举了他在日本航空的工作的例子，故事大概是这样的：

一次，有 4 个日航的本部长（相当于区域负责人），要到台湾东边的一个小岛南屿去度假。 南屿岛很小，上面只有两个饭店，而公司要求给 ４ 个本部长安排 4 个连在一起的套房，而且套房要面对太平洋。

余世维立刻打电话联系，饭店答复说一间都没有。他马上给东京发电报（当时电报是最快的联络方式），说一间都没有， 但他会努力去找。东京方面的回答只有两个字：了解。

余世维继续找，后来找到了两间，一个饭店一间。他马上致电东京：现在找到两间，可惜不在同一个饭店， 但我会继续努力找。东京的回电仍然是两个字：了解。

余世维继续协调查找，终于找到了 3 间，在同一个饭店里。他给东京方面发报，回答依然是那两个字。 报告之后，余世维就乘小飞机飞到南屿。向服务员打听：旁边的房间是谁住的呢？ 服务员说：“那是一对夫妇，马上要来度假，今天下午就要来登记入住。” 余世维就坐在饭店等。那一对夫妇到了，带了一个孩子。他马上走过去自我介绍：“我是日本航空的，我非常喜欢您的房间， 您能不能把它让给我？”

那位先生说：“我为什么要让给你？” “您说的没错。不过，我在隔壁替您定下一间套房，面对太平洋，傍晚可以看到夕阳，波涛在您的窗下澎湃， 远处有千帆点点。关键是房费我已经付了，您可以免费入住。”余世维提出了自己的条件。 那位先生半信半疑：“真有这样的事？” 在确定无误之后，那对夫妇带着孩子，向隔壁房间走去。

余世维马上给东京发电报：4间套房全部找到，在南屿的绿岛饭店3楼，4 间套房连在一起，面对太平洋。 这次，东京方面的回电多了两个字——“谢谢”。

没多久，4 个休假的本部长到了。他们轻轻地拍着余世维的肩膀，说：“余桑，你做事很像我们日本人。” 余世维并不觉得“像日本人”是多么光荣的事情。但在日本人看来，这是极高的赞赏，是一种极大的荣耀。 整件事，余世维一共给东京方面发了 7 次电报，主动报告工作进度。那个免费的房间是他自己掏的腰包， 花了他半个月的薪水。其中的辛苦，东京方面并不了解。 但他认真做事的精神和主动报告的态度，给日航高层留下深刻的印象，很快，他就得到了晋升的机会。

2.3 执行完有结果，有思考，有沉淀

我们常说「凡事有交代，件件有着落，事事有回音」，这是指我们做事要有结果。 有结果分为两种：

1. 最终结果，比如在约定的时间内达成了目标，或者延期了，此时需要告诉对方原因，解决方案以及最终延期到什么时候，或者根本就无法完成，这种情况应该早点告知，特别是对于老板，不要让这个结果变成惊吓；
2. 中间结果，这个就是我们前面说的执行过程中的反馈，但是也属于结果的一种：阶段性的结果。

在一件事情结束后，特别是一件略大一些的事情，我们需要对这一件事情进行复盘，开放心态，对于整个事情的过程和结果进行复盘，看下好在哪里，不好在哪里，帮助自己和一起执行的小伙伴在过程中发现问题，并找到问题的背后原因，制定下一步改进计划，通过解决问题最终提高大家的能力。如果可以，提炼出做事情的方法论或固化的机制，将经验沉淀下来。

一个好的执行，基本上都能做到 「 PDCA 循环」。简单说一下 PDCA 循环，PDCA 是美国质量管理专家沃特·阿曼德·休哈特（Walter A. Shewhart）首先提出的，由戴明采纳、宣传，获得普及，又称戴明环。PDCA 循环包含四个阶段，即 Plan (计划)、Do (执行)、Check (检查) 和 Act (处理)。在管理活动中，要求把各项工作按照作出计划、计划实施、检查实施效果，然后将成功的纳入标准和固化为机制，不成功的留待下一循环去解决。如图所示：

3. 问题终结者

技术管理平常都是围绕「解决问题」而展开，从发现问题，认识问题，分析问题，最终解决问题，这就是我们常说的「发现问题解决问题」。

3.1 发现问题

作为管理者，在大家都低头走路的时候，你要多抬头看路。这里所说的看路一个是指战略规划，另一个是指发现问题，那么在哪里可以发现问题？ 我们常见的发现问题的方法或位置如下：

1. 外部用户、内部员工投诉或反馈的问题
2. 1v1 聊天，绩效聊天，日报，周报等沟通渠道反馈的问题；
3. 自建的一些质量监控报告，自动化测试报告，自动构建的结果等；
4. 系统的告警、线上的事故；
5. 定期观察业务数据，在分析数据过程中发现的差异，这里的差异可能是时间对比的差异，部门间的差异，和友商业对比的差异等，从这些差异中找到问题，这个发现问题的过程可以依赖于大数据平台，做一些观测指标；、
6. 工作氛围相关问题，这个偏向于个人现场的感受；

在以上发现问题的过程中，我们需要用到系统化的思维，多问一些为什么，对问题时刻保持敬畏和危机感。

3.2 解决问题

解决问题笼统的包括认识问题，分析问题和解决问题，主要分为 6 步：

1. 认识和分析问题，这里不仅仅是指问题是什么，有时候我们发现的问题只是表象，使用前面的「黄金圈思维」，多问问为什么，找到隐藏到冰山下真正问题，全面且客观的看问题。并且要找到问题的背景和出处，大环境是怎样的，利益相关有哪些，问题解决的价值是什么等等。
2. 集思广益，他山之石，尽可能找到你可以找到的解决方案。
3. 评估解决方案的优劣，必要项，可选项及其权重，对可选项评分，量化，加权汇总，选出最优方案。
4. 对优选出来的方案进行全面的风险分析，对可能出现的风险制定风险应对措施。
5. 执行方案，解决问题。
6. 评估问题解决的结果，并复盘整个过程。

作为一个问题的终结者要能快速的发现问题，并且要发现问题的本质，有章法的从根本上解决问题，并形成一定的机制来保证问题不再重复出现。快速解决短线问题，有规划地解决长线问题。

4. 躬身入局

躬身入局是罗胖在 2019 年的跨年演讲中讲的一个故事，这个故事最开始是曾国藩讲的。 故事是这样的：

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

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

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

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

何为做事之人？

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

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

一个管理者带一个团队要时刻思考如下的三个方面的问题：

1. 团队变化
   • 有设定有挑战的目标并带领团队一起达成吗？
   • 有帮助其它兄弟部门完成相关目标吗？
   • 在下属遇到问题时有帮他们解决吗？
   • 有帮助下属成长并给团队带来了好的变化吗?
2. 技术变化
   • 有给技术架构带来了哪些变化?
   • 有提升研发的效率和质量吗？
   • 有思考技术架构的难题并解决吗？
3. 业务价值
   • 有给业务带来了哪些价值?
   • 有能做到和别人不一样的地方吗？

5. 终身学习

曾国藩曾写到：“盖世人读书，第一要有志，第二要有识，第三要有恒。有志则断不甘为下流；有识则知学问无尽，不敢以一得自足，如河伯之观海，如井蛙之窥天，皆无识者也；有恒则断无不成之事。此三者缺一不可。”

翻译到现在说我们读书要具备三个点：

1. 要有方向，向上的方向，不自甘落在人后；
2. 要有见识，眼界，要有自己独立思考和独立判断的能力；
3. 要坚持，行百里者半九十。

我理解的终身学习，是一种态度，对于知识保持着天然的敬畏和谦卑，以虚心的状态不断学习；是一种价值观，坚持长期主义，做时间的朋友；也是一种活着的方式。

终身学习所希望我们做的，并不是为了让我们变得高深莫测，而是让我们拥有好奇心，知道自己不知道。好奇心让我们能有极强的动力地去追问关于这个世界的真理。

后记

絮絮叨叨说了这么多，回到最开头的故事，从这个故事里面我们还看到了：机会从来都是留给有准备的人。你准备好了吗？

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

前言

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

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

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