---

0. 前言

五月即将结束，这个月有很多很多的好消息，本文来给这个月画上一个圆满的句号。

---

1. 工作

考证

今天早上顺利考过并拿到了 AZ-104 的证书，接下来准备花 2-3 个月的时间搞定 AZ-305，这样就把公司今年的考证任务完成了！

说实话考证真的挺花精力的，为了考这个证我看了 40 多个小时的视频，做了 500 道题，五套 Whizlab 的模考前后做了 3 遍，笔记和错题也整理了好几遍。

回看了自己之前的文章，整个备考大概花了 6 周的时间，预估时间点还是蛮准的。

2023.04.21

现在我乖乖开始刷 Pluralsight 的 Learning Path 了，原本计划复习一个月去考，后来认清了现实，又要上班又要带娃又要刷剧的我复习时间太有限了，还是争取两个月考出来吧。

工作重心

这个月的工作重心依旧是在资源有限的情况下推进内部工具的里程碑，实现每两周出一个版本并且批量更新所有的客户。

随着产品的逐渐成熟，我作为 Product Owner，希望实现的目标也更加明确了。

1. Faster Rollout: Reduce Release Cycle

减少 release cycle 所需要的 manual effort，通过 decouple product version upgrade, git integration, automation testing, impact area analysis 来减少 config release 的风险，下一步的目标是把 Fortnightly Release 缩短成 Weekly Release；

这里的隐形 blocker 是我们的 deployment process 自动化程度还不够，所以 release cycle 再缩短下去其实意义也不大了，其他部门暂时无法支持这种 velocity；

2. Reduce Cycle Time: User Journey Improvement

这周我接到一个紧急任务，需要在 4 小时内完成一个新客户上线的需求，这类需求通常前前后后需要一个月的周期，之前最快的 onboarding 也花了一周，但是随着内部工具里程碑的不断推进，我这次真的在 4 小时内完成了这个「曾经不可能」的任务，这也证明了内部工具的价值；

虽然这个任务完成了，但是我在做需求的时候还是发现了不少卡点，可能换一个新人接手就没法保质保量地在这么短的时间内完成需求了，不断优化 User Journey，缩短新客户上线时间是我的工作重心之一。

3. System Integration: One-Stop Client Management Platform

我们的客户资源（比如图片、logo 啥的）都分散在不同的 repo 和 folder 里面，假如内部工具可以把所有的客户信息、资源都整合在一起，对于整个团队来说，就能清晰地找到 source of truth，不需要反复沟通和验证（e.g., 这个 logo 是最新的吗？）。

最简单的一个例子是客户发来的文件，我们一直没有一个 single source of truth，但我把 download latest file 做成了一个功能，从根本上解决了这个卡点。

4. Do Things Right: Product Terminology & Rollout Process Standardization

每当要上线一个新功能的时候，最耗精力的就是 CSM，Product，Sales，Dev，Test，Ops 心中都有个不同的版本，所有人都要反复 align，浪费了大量的时间，还容易出错；我已经画了一个版本的 rollout process diagram，接下来就是要跟不同的 team 沟通、Align，并且确保这个 process 可以被推行和实践；

这里的 blocker 是我需要拿到多个部门老大的支持，并且只有其他部门、团队有了实际的行动（包括流程变更），才能把整个流程跑通；

我也曾经想过，是否可以「不麻烦」其他部门，我自己的团队搞定这件事，但是实践下来的效果非常不好，所以我必须推这个新流程。

这里有个小插曲，一开始很多人觉得这种会议没有必要，直接看 wiki 不就行了吗？但是我坚持要开这个会，几次会议开下来，看似简单的功能都至少要花 30 分钟才能让所有人都搞懂，这个会议的价值也在实践中被验证了。

5. System Simplification

在推进以上四个目标的时候，我还发现，有些产品功能由于本身的设计过于复杂，导致后续的 maintenance effort 居高不下，即便有了内部工具，也无济于事。

对于这样的卡点，我准备主动提供一些 System Design，跟产品部门沟通这个变更的必要性和可能带来的价值，排进他们的 roadmap 里面。

只有上游系统简化了，内部工具才能跟上，把事情做对，简单地贴几个创可贴无法解决根本问题带来的瓶颈。

---

2. 生活

这个月最值得庆祝的事情就是 5.19 拿到了绿卡，同时确定了回国的行程（大概回去 6 周），机票已经订好了，好期待跟亲朋好友们再次相见！！

轩宝换了新的班级之后，拿到了第一个小奖状（数学）；他的英文也变好了，有时候会自言自语地说英语，还会问我 xx 单词是什么意思，太开心了！

这个月还听完了一个育儿课程，自从我把重心聚焦在他做的好的地方，并且除了真正的底线之外的事情不纠结之后，我的育儿焦虑感直线下降，跟轩宝的亲子关系越来越好了，我时常能发现他的各种优点，他每天都会甜甜地说：妈妈我最爱你了。

---

3. Best Case VS Worst Case

最后想分享一个自我觉察：在工作和生活中，每个人都有不同的默认配置。

有些人会把 Best Case 当做默认值（比如：我们上一个客户 4 小时就上线了，以后所有的客户都应该 4 小时搞定！）；

有些人则会把 Worst Case 当做默认值（比如：假如把所有的客户都升级到最新版，这个风险太大了，还是别搞了）。

工作中的我

我作为 Team Lead，看的是相对稳定的中位数。

客户上线，我能 4 小时搞定，不代表所有人都可以达到这个目标；

客户升级，搞砸过两次，成功了四次，不代表之后的升级全部都会搞砸；

Ray Dalio 曾说过，好的 manager 是 organization engineer，能通过流程和人来达成希望实现的目标。

Like great musicians, all great managers have both creativity and technical skills. And no manager at any level can expect to succeed without the skill set of an organizational engineer.

所以我的工作目标，说白了就是要「发现瓶颈」、通过「流程构建、迭代、优化」和「人才的选育用留」来提升团队的整体绩效。

我的默认配置，导致我给出的预估往往是根据中位数来给的，好处是我的预估准确率非常高（我排在每个 sprint 里面的任务基本上都能达成），坏处是可能会给别人带来「比较保守」的印象。

PS：我知道有些 manager 的心态是：先搞个 best case 预估，做不完是常态，我们已经尽力了；甚至有些 manager 会认为，计划的事情全部做完了，证明你的工作量不饱和啊。

对于这种 management style，我个人是比较反感的，有紧急任务的时候可以加压加码，但是假如常态的管理模式就是「超负荷的任务计划」，对于团队的长期健康和稳定都是完全没有好处的。

生活中的我

生活中的我，也是偏保守型的预估风格，比如预估 AZ-104 要两个月搞定，其实花了 6 周就考完了，本来预约的考试是 5 月 31 号，昨天感觉自己复习的差不多了，就改成了今天考。

好处：确定的目标往往都可以达成；

坏处：时常会有一些自我设限和怀疑（我真的能做成 xxx 吗？）；

比如我记得研究生最后一学期的时候，我离毕业还剩三个月不到，开始找工作。

于是开始写简历，参加各种 career advice workshop。

某天，有个嘉宾问我：你申请了几家公司？

我说：我还没开始申请 = =

后来虽然感觉自己没有 ready，还是投了五份简历，最终拿到了两个 offer。

在生活中的我，需要更加勇敢大胆一些，跳出自己画的条条框框，去尝试一些看似做不到的事情。

没准结果会超乎我的想象。