---

0. 前言

终于终于到周五啦！这周是新年上班第一周，虽然只有四天，但事情还是挺多挺杂的。

更难的是，很多思考似乎也不方便在公众号里面写了，所以这个系列不知道会持续更新多久，大家且读且珍惜吧。

---

1. 技术的进步

这两周我花了很多时间在技术任务上，从同事给的 PR review comment 里面也学到了很多，总的来说大家都是很关注代码质量的，review 看的也很仔细。

虽然我在做任务的过程中还是会卡，有时候还是要问人，但是我也接受了自己短时间没法快速提高的现实，所以我基本上是白天问问题，晚上一个人加班去把别人写的 comment 里面的东西消化一下，把代码里面该改的东西都改完，等第二天再让别人 review。

不过，这周发生了几件事，让我突然觉得，我死磕代码这件事，虽然慢了点，但还是有点进步的。

CSS

我有个 task 是跟前端相关的，一开始我一直卡 CSS，然后就经常要问别人这东西为啥老是对不齐之类的问题（lol 我真的好菜）。

在组里人耐心的教导下，我这周似乎突然开窍了。自己做了一个前端的 task，还独立解决了一些之前需要问人的小问题。

虽然这个进步很微小，但还是有些成就感的！！

查 bug

另外有个 task 是需要看为什么有些数据库里面的数据在前端渲染出来的效果不对，这个 task 需要对整个数据的处理过程有所了解，我也花了很多时间去理解这个流程，并且通过打断点，跑测试等方式去缩小问题的范围。

在同事休假的期间，我改了下代码，让它能达到我心目中的效果，然后等同事回来，我再去问我的思路对不对，对方有什么建议。

这个过程也是挺磨人的，折腾了一周，昨天同事跟我说要考虑几个 edge case，我想了好几个小时，在晚上 12 点之前总算搞定了这部分。

换作一个月前的我，肯定是没法做到的，所以可以肯定的说，我比以前的自己变厉害了一点点。

On-call

除此之外，我还主动承担了 on-call duty，在出现 incident 的时候去问队友如何查 log，花了好几个小时写 incident report，去了解问题出现的根源是什么。

今天我 on-call 的时候出现了一个 production issue，需要 revert change + deploy，我又通过亲自实践学到了整套流程。

总的来说，在技术这块，我没有因为自己慢就放弃，在遇到了相似的问题时能够更快地找到解决方案，在遇到新的问题时能独立找到解决方案的概率也更高了。

---

2. 管理的思考

在团队管理方面，我最近也有一些新的感悟。

找准时机匹配人和事

首先，在团队成员成熟度都比较高的情况下，管理者的角色更多的是给大家空间去发挥自己所长，帮助他人找到成长的机会，把人和事匹配起来，提供团队成员需要的支持。

在这个过程中，假如团队成员能够主动表达自己的兴趣点（比如我想多做点后端的任务，我想多一些 ownership），就更容易得到自己想要的机会，因为我能够在看到机会的时候第一时间想到跟我提过类似要求的人。

最近的一个例子就是某个成员跟我表达了 TA 想升职的意愿，我正好知道有个项目缺少 ownership，而且我们组的人都没有相关技能，我就把 TA 和那个项目的临时负责人对接了起来，既满足了 TA 想要多学新技术，增加 scope，为升职做打算的意愿，又给这个没人管的项目找到了负责人，还给 TA 找了个 mentor，一举多得。

团队管理没有标准答案

另外一个感悟是，在接手新团队的时候，可能这个团队在大部分的时候运作都是挺正常的，也没有很多迫在眉睫的问题，但我还是需要通过跟团队成员 1:1 来听取大家的想法，在时机成熟的时候去做一些改进，而且还要不断地去迭代解决方案。

比如我们组在我刚来的时候没什么流程，大家交付项目全靠自觉，项目延期了也没啥后果，这种运作方式可能在团队初期，人比较少的时候是最有效的，但是团队人数增加了之后，不同的成员对团队有不同的预期，包括上级领导也对团队有了更高的期待值，管理者就需要根据团队当前的需要来进行调整。

流程是为解决问题服务的

在之前的团队 strategy week 工作坊期间，我跟团队讨论了我们的 Jira board 管理方式，大家都不喜欢 Kanban，但我们的 sprint 又完全没有 task estimation 这个动作，也没有 backlog prioritization，有点四不像。

跟大家深入聊完以后发现，他们抵触 sprint 的原因是 estimation 和 planning 太浪费时间了，搞很多形式主义。

但是完全没有 estimation，又看不出来一个 task 到底有多复杂，PM 即便想把一些简单的事情优先级排上去，也不知道哪些 task 是简单的。

我刚来的时候就面临这个问题，由于整个团队都很抵触 sprint 的一套流程，我就先让大家在每个正在做的 task 上加了 estimated delivery date。

但是这个流程没有起到帮助大家了解任务大小的作用，预设的时间也完全不准确，我又不想天天催着大家更新时间，所以算是一次失败的尝试。

拉着大家一起开会的好处就是可以达成团队共识，在团队工作坊期间，大家都认可优先级很重要，不同类别的任务也需要分配不同比重的时间，我觉得这是一个很好的时机，让团队尝试用 story point 的方式来做 estimation。

我知道大家都不喜欢繁琐的流程，所以我跟大家说，每个人 estimate 自己的 task，如果这个 task 之前被别人 estimate 过了，你觉得你要改，也没问题，到最后花的时间比预计的要长，也无所谓，反正先从建立 estimation 这个习惯开始。

我不在乎 estimation 准不准确，因为不准是正常的，但是完全不做是不正常的。

而且我相信，大家自觉性独立性都这么强，肯定也不会瞎估时间。

PS: 天时地利人和，才能办成一件事。

创造一个团队项目

在团队工作坊期间，大家还提到了「如果能有更多的团队协作会更好」这个点，因为大家平时都是自己做自己的项目，对别人做的东西了解比较少，这样容易造成瓶颈，也不利于知识共享。

我的任务就是帮助大家找到这样的项目，创造团队协作的机会。

某天我看到大家在讨论一个前端的升级任务，但是大家手头事情都挺多的，也没人愿意把这项目接下来。

眼看着这件事就要搁浅了，我找了个办事积极的组员，让 TA 去做一些前期的调查，把任务分解做完，我还跟 TA 明确说了这个项目你只负责协调，不需要自己把所有的事情干了。

这周，组员完成了任务分解，还用 story points 做了 estimation。我有了相关信息之后就跟我的 coach 汇报了进展，TA 说本来以为这任务挺简单的，现在看起来要搞一个多月啊（estimation 的好处体现出来了）。

我跟 coach，组员，以及 PM 聊了我的想法，说这是一个很好的团队协作机会，虽然目前看来优先级不是很高，但是正好可以在大家需要 pick up backlog item 的时候用上，是个非常有价值的尝试。

聊了大半天，中间遇到了一些小问题，但总算跟所有人都对齐了，接下来就可以实行啦~

---

3. 结语

昨天我 coach 休假回来之后，我当天给他在 slack 上发了一条汇报性质的消息，讲了每个团队成员的情况，项目的进度，以及其他在发生的一些事情，问他我是否有遗漏的点。

将心比心，管理者都希望知道团队的近况，在对方问进度之前提前主动汇报是非常加分的。

另外，今天在公司正好碰到了 skip coach，就约了个 catchup，我跟他汇报了团队管理相关的进展，他听了以后很满意，觉得一切都在朝着好的方向发展，他对我们团队也有很高的期望值，包括团队的定位，产品的大方向等等，他都有一些想法。

我自己呢？

虽然还是处于适应期，但发现自己比之前有进步之后心态要好一些了，相信随着时间的推移、经验的增加，我会在目前的岗位做的更加得心应手的！