---

0. 前言

今天这篇文章，跟大家聊聊我对自己目前的职位 —— Platform Team Lead（平台部门负责人）—— 的理解。

大纲

1. 我的工作职责及主要挑战是什么
2. 如何平衡管理工作和个人成长
3. 带团队意味着什么
4. 如何建立确定性
5. 如何建立纠偏系统

---

1. 一次谈话

上周有幸跟一位 Google 的朋友进行了一次深聊，我讲了我的工作职责和遇到的瓶颈，他提供了几个让我印象深刻的点。

背景

我们公司主要做的是客户满意度调查问卷、数据的收集和展示，为企业提供商业价值和洞见。

每个客户都有自己的问卷和独立的网站，登录进去可以看到相关的数据、图表、并且对每一条客户反馈进行跟进。

公司的架构为：

• 销售 + 市场部门
• 客户部门：负责收集客户需求，维护客户关系
• 数据部门：提供数据报告、市场分析等
• 产品部门：UX 相关
• 程序部门
• 测试部门
• 运维部门：负责产品的最终上线流程，解决客户提出的问题

在实际的工作中，大致可以分为两组：

• 产品组（产品部门的 UX + 负责产品开发的程序员 + 产品测试员）
• 平台组（平台程序员 + 平台测试员）

平台组的工作职责

1. 客户相关需求的交付：包括维护已有客户、配置新客户，以及把老客户迁移到新的技术平台上等等；
2. 平台工具的开发：目标是用更少的资源来支持更多的客户，并且提高客户需求交付的质量和速度；

平台组的挑战

1. 多线程工作：我们组的事情多且杂，需要对接不同部门的不同成员，对每个程序员的沟通能力要求很高；
2. 紧急度高：凡是跟客户相关的交付内容或者在生产环境出现的问题，都需要我们部门快速响应并且在有限的时间内解决；
3. 组员的成熟度低：平台组只有 2 名「老员工」能独立完成大部分的任务，另外的成员要么是在读大学生（每周上 3 天班）或者是刚毕业的程序员（工作经验小于 6 个月）；
4. 平台工具的成熟度低：我们正在开发的平台工具还不能直接在生产环境使用，而且由于公司业务不错，客户需求一直在增加，导致我们无法分配资源去做平台的开发；

朋友说

1. 首先，他指出我所在的 Platform Team 其实做的是 DevOps 的工作，也就是解决内部流程、产品交付流程相关的问题，这部分的知识是很难通过书本和课程学到的，所以在工作中能有第一手的经验是很宝贵的；
2. 其次，他说任何 IT 公司，在创业阶段都会把主要精力放在产品上，但想要扩大规模，就必须做好 DevOps 这一块，优化内部的流程，所以中等规模以上的 IT 公司都会有 Platform Team，这部分的瓶颈假如能突破，公司就可以继续成长扩大，否则就一直是个小公司；
3. 最后，他说我目前做的事情其实是 Technical Leadership + People Management，其中最有价值的是 Technical Leadership 这部分，属于稀缺资源；

Luna 说

这次谈话让我从另一个视角意识到了我目前职位的重要性、我所肩负的责任，以及摆在我面前的机遇。

然而我手头负责的事情实在是太多太杂了，我说很多时候会感觉自己忙了一天却没有什么成就感，还有好多事没做完。

朋友说 —— “Time is your biggest assests”，如何用好自己的时间，专注于做高价值的事情是管理者最大的挑战。

---

2. 时间日记

做管理和执行的一个最大区别是，管理者有更大的自由度可以决定自己到底要做什么。

于是，谈话过后的这一个礼拜，我开始记录自己每天的时间使用情况。

我想知道我的工作时间到底用在了哪里，是否有优化的空间。

观察

首先，我大部分的时间都用在了会议、面试、1 对 1 面谈、帮团队成员解决问题等事情上。

低效的会议

但我意识到，很多会议的效率都不高，要么是因为我经常听着听着走神，或者是我在想其他的事情，或者是我对会议的内容不够了解，听到一半没听懂，然后就彻底跟不上了。

还有很多会，开完就结束了，没有达成书面的共识和行动方案，与会的成员不清楚自己到底要干嘛，更别提因故无法参与会议的重要干系人了。

没有足够的专注思考时间

其次，我每天都忙于解决各种问题，参加会议，像个陀螺一样不停地转，但是我很少有时间能静下来去思考团队中存在的问题和瓶颈，也就是去做那些真正重要的、对团队有杠杆效应的事情。

改变

会议纪要必须当天写完并发送

我要求自己做的第一个改变是：凡是我组织参与的会议，必须明确会议的目的，提前发出会议议程，在当天写好会议纪要和行动方案，并且发给与会人。

在这里插播一句话：会议纪要听起来是很常规的事情，但是假如公司没有这个文化，就必须有人先做出表率，只有大家看到了做这件事的好处，才会慢慢改变思维方式，参与到这件事里面来。

做这件事给我带来的好处是，它让我最大化的利用了会议的时间去达成想要的沟通效果。

我在实践中发现，会议纪要的大部分内容可以在会议时间中完成：

• 假如我是会议主办人，我会通过分享屏幕，让大家看到我写的会议纪要，在讨论中把要点记录在每一项议程下面；
• 假如我觉得大家话题跳转的太快了/我没听懂对方的意思，可以主动控制会议节奏（比如：不好意思我刚才没听清楚，我这里应该记录什么？）；
• 假如有人临时有事走开，也可以通过浏览文字来抓住会议的重点；

做这件事的缺点是：比较消耗脑力，而且忙起来很容易偷懒不做（尤其是一个会接着一个会的时候）。

但是不做这件事，对管理来说简直是致命伤，不光浪费了所有与会人的会议时间，还没有达成想要的会议目标。

会议之外的临时需求，先问三个问题

1. 这件事必须做吗？
2. 这件事必须现在做吗？
3. 这件事必须我做吗？

最后，我还会问自己，如果不是我做，我要如何保证这件事情完成的质量？

前面提到团队成员的成熟度低，这就需要我在授权的时候明确期待的产出和时间节点。

为自己的思考和成长留出时间

管理者很大一部分的工作都与决策相关，决策的质量对团队的影响至关重要，所以我要确保自己有一个好的精神状态。

每天留出至少 15 分钟的时间来做一些与项目规划、管理、大方向、团队状态相关的思考。

除此之外，每周要给自己留出一些做技术需求的时间，了解项目代码和团队成员的工作流程，我通常会选一些时间不太紧急的任务做。

---

3. 哪些事情是必须由我做的？

我不能授权的职责

1. 建立并优化平台组的工作流程
2. 跟上级对齐平台项目的大方向、里程碑以及 KPI
3. 每两周一次的平台部门的 Sprint 规划
4. 跟团队成员进行 1 对 1 谈话和每半年一次的绩效评估
5. 招聘和面试

在我看来，技术管理者的职责核心在于「人」，我需要构建、培养出一个有层次，有不同纬度的技术能力的团队，通过流程优化和自动化等方式来保护他们的注意力，让他们能够集中精力完成有意义的任务，并且从中获得个人成长。

想要完成这个职责，我需要做两件事：

1. 确定任务的优先级；
2. 安排合适的人去做不同难度的任务；

团队任务规划 - 如何有效使用团队成员的时间

我是用 Sprint 的方式来规划团队需要完成的工作的，每个 Sprint 周期为两周，每个周期开始前，我需要做以下准备工作：

1. 盘点下一个周期有多少人力资源可以分配（收集大家的请假安排），把团队成员分为两个组：
   1. 客户组
   2. 平台组（这个组的成员需要兼顾 oncall duty）
2. 看一下当前周期未完成的需求有哪些，把它们移到下一个周期的 backlog 最顶部；
3. 跟客户部门过一遍我下一个周期准备做的需求，看看是否有遗漏，如果客户组的资源不足以完成所有需求，则需要客户部门提供最终优先级；
4. 把客户部门的需求分配给客户组的程序员；
5. 把平台组的需求分配给平台组的程序员；

历史教训

1. 一定要安排 2-3 个 oncall 资源来做临时任务，平台组的任务时间线相对较宽松，所以这个组的成员可以在紧急情况下做 ad-hoc request。
2. 在分配任务的时候需要考虑每个人的能力，结合任务的紧急程度来安排；
   1. 例：A 程序员经验较少，适合负责复杂度低的任务，根据成长速度穿插几个中等复杂度且不紧急的任务，如果完成的不错，就继续分配中等复杂度的任务；
   2. 例：B 程序员能力强，能独立完成中等复杂度的任务，这样的成员适合做更有挑战性的任务，一些紧急的任务，并且鼓励他们多帮助经验少的程序员们成长起来；

---

4. 我的盲区

盲区的定义就是自己看不见的地方，而一个管理者成长的过程就是发现并补足盲区的过程。

盲区 1：平台部门的 KPI

之前那位朋友一语道破：我做的事情其实就是 DevOps，平台部门是组织发展的必经之路。

另外一个佐证是，在备考 AZ-400: DevOps Expert 的时候，我发现这个课程设计的内容就是我目前需要的技能啊！

• 比如如何管理 pipeline，如何加速产品的上线流程，如何做 CI/CD，如何增加 deployment frequency，如何确保质量……
• 比如如何改变组织的习惯和文化，如何构建新的流程，如何用自动化来提高效率，最终能让用户体验到产品的价值……

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.

搞清楚了部门的定位和使命之后，我的关注点从部门层面提高到了组织层面。

我以前认为我的职责在于发现平台部门的问题并且解决「本部门的问题」，但我看到这个盲区之后才领悟到，我们部门的成功依赖于整个组织流程的变革，所以我要发现的是更高一级的问题，并且要通过部门间的协作来达成平台部门的 KPI。

盲区 2：产品标准化

照亮上一个盲区之后，我看到了一个组织层面的盲区 —— 产品标准化。

因为我在思考自己职责的时候，漏掉了一个重要的环节，就是平台部门跟产品部门之间的衔接。

之前提到，平台部门需要负责产品的上线，每当产品组做出了一个新功能，我们就要 rollout 到不同的客户网站中。

这个盲区其实挺明显的，就是产品部门和平台部门对接时没有提供一个标准的产品模版和客户需求文档，比如哪些字段是可配置的，哪些字段是统一的值。

平台组的程序员会跟产品组的程序员进行技术层面的沟通，但是产品经理没有构建一套标准流程和产品文档来定义产品究竟应该做什么，最佳实践是什么，局限是什么。

也许你会问，那平台部门如何去完成产品上线需求呢？

很多时候，人们都会通过在线聊天工具来沟通，然后依靠个体的记忆去实现配置，当然这也会导致后期有各种 bug，整个流程的时间被拖长。

这个环节的缺失似乎已经成为了常态，因为它是盲区，是没有人看到的地方，所以也从未被提及。

乍一看，它似乎不属于我的职责，而是产品上线流程标准化的一部分，但我既然看到了这个问题，就需要想办法去解决，因为这件事是对整个团队有意义的。

解决方案

我思考了之后，发现解决方案很简单。

说白了，就是每当有一个产品新功能需要平台组负责上线之前，我要把产品的人、程序、测试拉在一起开个功能沟通会。

产品方跟我们讲清楚标准化的产品是什么，哪些字段是需要配置的，标准的需求文档是什么样的，然后程序和测试可以提问，并且给出自己对这个产品功能上线的预估时间。

Luna 说

平台部门作为优化组织内部流程的主力，需要看得到部门协作之间的障碍和盲区，从组织层面思考如何优化整体流程。

上面提到的这个盲区，造成的表面问题是：产品上线的速度慢，bug 多，内部沟通成本高。

但经过思考后，我发现造成这些问题的深层原因是「缺乏产品标准化的文档和流程」。

PS：产品上线速度慢 + 质量不佳是跟平台部门的 KPI 挂钩的。

---

5. 结语

这篇文章写的有点长，最后来总结一下要点：

1. 我的工作职责及主要挑战是什么
   1. 职责：优化组织层面的流程，看到更高层次的问题并提供跨部门的解决方案，助力实现产品的价值
   2. 挑战：多线程工作 + 团队新人多
2. 如何平衡管理工作和个人成长
   1. 记录时间使用情况​
   2. 让会议变得更有效：会议议程+纪要+行动方案
   3. 有效授权：分对象分任务
   4. 留出深度思考时间：提高自己的决策质量
3. 带团队意味着什么
   1. 做好 Sprint 计划和优先级排序：为团队成员提供确定性
   2. 有专门的「救火队」：做计划时要考虑分配机动性高的资源
   3. 针对不同个体的成熟度来安排任务和挑战：时不时地提供跳出舒适区的机会
4. 如何建立确定性
   1. 有效会议：文字版的内容记录可以提供更多确定性
   2. 发现并补足流程中的缺失环节：沟通成本高、次数多的表层现象往往意味着有一个系统性的深层原因需要解决
5. 如何建立纠偏系统
   1. 通过他人的反馈发现自己的盲区
   2. 把长期无法突破的瓶颈和痛点记录下来
   3. 思考：我想达成的目标是什么？我的时间花在哪里了？我是否偏离了目标？