Luna说 | 拥抱变化
0. 前言
这周的主题是——拥抱变化：
- 轩宝周三换了新班级；
- 我周六要做轩宝足球比赛的裁判员（人生第一次）；
- 公司给我配了新的笔记本；
- 我开始通过 sprint goal 来推进产品里程碑；
- 我准备从下个 sprint 开始对团队管理方式做一些调整；
- ……
1. 轩宝换班
轩宝之前的班级里有个孩子 W 总是欺负他，好几次把他的午饭踢飞，弄脏他的食物，还有肢体冲突。
我跟老师沟通了好几次，老师的回复是：尽量把他们分开，但是轩宝有时候会主动去找那个孩子玩。
轩宝说他最好的朋友 H 正好也是 W 的朋友，所以他每次找 H 玩，都绕不开 W。
这周一老师给我打电话，说现在最好的方法只有把他们分到不同的班级里面，问我是否愿意让轩宝换班。
我当时的第一反应是——为什么要轩宝换班，而不是那个孩子换班。
老师解释说，那个孩子有一些行为方面的问题，正在进行矫正，假如换班可能会比较麻烦。
跟家里人商量后，我们决定还是让轩宝换班，因为他这段时间每天回家聊的都是跟 W 之间的各种纠纷，长期待在一起没什么好处。
轩宝的反应是——我不想换，我不想离开我的朋友。
我跟他解释了换班的原因，也表示理解他的害怕和担心，妈妈相信你在新的班级会很快遇到新的朋友的。
周二那天，老师尝试让他去新班级上课，他死活不肯，老师只好作罢。
周三我送他去上学，陪他一起到新班级参观，新老师想拉着他的手带他去上课，他一开始不愿意，后来勉强拉着老师的手离开了我的视线。
周三回来问他感觉怎么样，他说还不错。
到了周四的时候，送他去上学，他已经比前一天放松多了，虽然还是有点害羞（很正常），但是已经能够接受自己换班的事实了。
周四晚上，他说他在新班级有了第一个新朋友，我说你简直太厉害了，刚到这个班两天就有朋友啦，他心情很不错的样子，晚上跟我在一起的时候还哼着歌。
Luna 说
换班对于孩子来说，算是一个比较大的变化。
在变化面前，孩子和大人都一样，会害怕，会恐惧，会想要回到「原来的样子」。
其实我也挺害怕轩宝换班的，因为我要重新认识一个老师，进一个新的家长群，重新把家长和孩子的名字配好对（不然接送娃上学的时候有点尴尬）。
但是变化往往会带来新的契机，即使一个人都不认识，孩子也能在新环境中很快适应下来，建立新的社交关系，我也一样。
我周三晚上加了新的家长群，主动介绍了我和轩宝，群里很快就有十几个家长回复「欢迎来到我们班级」，周四送轩宝的时候我也主动认识了送娃的家长们，发现大家都很友好。
轩宝换班的经历，让我知道了人的适应能力是很强的，不要因为害怕新环境的不确定性而放弃尝试，不要因为留恋当前环境中的稳定性和确定性而抗拒变化；只要想清楚自己为什么要换环境，想要在新环境中得到与当前环境中不同的东西是什么，就够了。
2. 换电脑
某天我想把工作电脑升级到 Windows 11，但是升级失败了，因为电脑的配置不符合最低硬件要求。
这台电脑用了一年多，旧是旧了点，毛病也不少，比如麦克风很差（必须要正对着屏幕讲话别人才能听见）、电池只能支撑一小时（每次开会我都要带着插头）、跑代码的时候很慢……
其实我跟公司申请换电脑也有段日子了，只不过每次刚有了台新电脑，要么就是新人拿去用，要么就是正好有个同事电脑坏了，需要换一台。
我自己也没把换电脑当回事儿，能换最好，不能换也无所谓，现在这台虽然毛病多，但是也能用。
直到我发现身边的同事都开始用 Win 11 了，我连升级都升不了，换电脑这件事的优先级才提上来。
跟领导反应之后，过了两周，新电脑就拿到了。
虽然要重新装一遍项目和软件，足足花了一天时间配置，但是这一周用下来真的倍儿爽。
开机不用打密码了，直接面部识别或者指纹识别。
不需要外接耳麦，侧着头说话别人也能听见。
开会不用带着重重的充电线来回跑。
新电脑比旧的要轻薄很多，背包轻了好多。
原来换新电脑的感觉这么好！！为啥我不早点申请换电脑……嘤嘤嘤。
3. 技术团队管理方式的改进
之前的文章提到过我目前带的 Platform Team 的一些情况，在这里就不赘述了。
这周发生了一些事情，激发出了我的两个新想法。
版本 & 配置
首先，我发现每次做 deployment，我们都是客户需求主导，有了需求，才升级版本 + 更新客户配置，当出现了问题时，很难确定究竟是版本升级导致的，还是客户配置导致的。
比如客户 A 的当前版本是 1.0.0，我们推新功能需要把这个客户升级到 3.0.0 + 改配置。
外部产品团队每次出版本都只是把版本准备好，并没有把所有客户都升级到这个新版本，只有当客户来需求了，或者想要推新功能了，才升级一些客户。这种做法的弊端在于，测试的范围更大（既要做回归测试，也要做功能测试），风险更高，最终导致整个任务周期被拉长，客户满意度降低，生产环境出问题的几率也更高。
这个长期存在的问题让我很头痛，但我一直没有想到好的解决方法。
这周我突然想到了突破口，既然我每次做内部工具 release 的时候，要确保所有的客户都能正常运转，那么产品团队出新版本的时候，难道不应该把所有客户都升级到新版本吗？
为什么要等到客户来需求了，或者要推新功能了，才升级呢？
如果每次出新版本都能把所有客户回归测试一遍，这个版本出 bug 的几率就更小了呀。
我把这个想法跟 manager 和 stakeholder 讲了之后，大家都认同我的看法，但也担心由此带来的风险。
我再次主动提出，下个 sprint 我们团队会把所有客户的版本都升级到最新版，每个客户做一次完整的回归测试，但接下来的版本升级就应该是产品团队来负责了，我们必须把版本和配置的部署分开来做。
目前这个想法的 buy-in 还不错，接下来就要推进实施了。
On-call Duty（值班）
管理中另外一件让我很头痛的事情就是 on-call team，我每个 sprint 都要有两个 platform dev 值班待命，每当有了生产环境的问题，这个 team 就要去救火。
但问题来了，这两个 platform dev 没有全部的背景信息，假如某个问题是由于另一个 dev 做的 deployment 产生的，或者是由于版本升级导致的，也要由 oncall team 来帮忙找到问题且解决问题。
更让我抓狂的是，有时候明明是另一个团队做的部署有问题，但所有的责任和压力都放在了我这边两个 on-call dev 的身上。
这种「我搞砸无所谓、别人会负责修」的心态太不利于团队健康和长期良性发展了。
于是我提出，on-call 不光是 Platform Team 的职责，也应该是产品团队的职责，两边各出一个人。
除此之外，我们还需要更加健全的事故处理流程，在安排资源之前，要有人能够拍板决定事故的优先级。
4. 产品推出流程改进
产品团队出了新功能之后，需要 platform team 来做 rollout，这个流程之前一直是依靠「技术文档 + common sense」来运转的。
内部工具做了一段时间之后，我发现真正的瓶颈不是 rollout 速度慢，而是没有人知道我们到底要 rollout 什么东西。
产品 dev 根据产品经理的需求做了 A，但是没有部署到任何一个客户上，写了篇文档等着 platform team 来 rollout。
platform team 看到了文档，发现里面有 10 个配置可以改，于是把所有的配置都做进了内部工具里面。
到了真正要 rollout 给每个客户的时候，需求文档没有固定的格式，测试不知道测啥，UAT 的时候发现各种 bug，但是这个功能又已经卖出去了；在时间压力下，大家只能努力把这个 rollout 做完。
由于 rollout 的过程中总是出现各种各样的问题，导致我对这个流程非常不满意。
到底怎么改呢？
我给的方案是，产品团队做完功能之后必须部署到 2 个客户的生产环境里，然后我这边跟产品经理沟通大规模 rollout 的计划，全部 align 清楚了（需求文档长什么样，哪些客户不支持这个功能，有什么已知的 limitation）再开始 rollout。
为什么要改进流程呢？
因为我最近有个惨痛的教训，产品那边让我们 rollout 一个功能给客户 A，我们把这个功能做成了 default，但产品那边说 nonono，这个我们只是给客户 A 用，其他的不给哦。
于是我明白了，我是有盲区的，我不知道产品那边有什么市场宣传计划，准备以什么节奏来推进产品发布，以及 xx 功能要卖多少钱，有时候好心真的可能办坏事。
所以，这个 Gap 只能用流程和其他团队的技能来填补。
我的任务就是明确地告诉 stakeholder，我没有拿到清晰的需求没法做 rollout，我没有拿到 working example 没法做 rollout，但是只要前置条件满足了，我非常乐意做 rollout，不然我做的 rollout 可能是错的。
我和我的团队，不能把有限的精力花在「瞎忙活 + 各种返工 + 各种确认需求」上，如果有更好的方式来做对一件事，为什么不试试呢？
5. 结语
经历了一段时间的低谷和迷茫后，我这周又逐渐找到了自己的目标和方向。
对于未知，我依旧有些恐惧，但是我也知道，我不可能永远留在原地。
该变的总会变，该做的决定总要做，旧的不去，新的不来。
唯一不变的，是我那颗希望把事情做对做好，希望能持续提升自我，希望能让身边的人（不论是家人还是团队成员）都过的充实快乐的心。
这周最大的内心变化是：我突然真的相信自己了，我不光确信自己能在当前的环境中找到一席之地，也相信自己能在未知的新环境中走出自己的路。
Talk to Luna
Support Luna
