原创不易，求分享、求一键三连

爱恨纠葛：“年终盘点一对一”之一生之敌孙狗！

继续整理技术团队最近的年终盘点，「采用我问他答的形式」主要是聆听，今天这位同学之前在腾讯工作了几年，被我忽悠到现在的团队，他一年的角色变化是这样的：

凝聚者属性降低，监督员、推进者属性升高，和从一线技术开发到一线Leader的身份转变有关。

作为一线leader，会更多地调度资源，做项目推进和管理，包括技术方案评审、产品需求PK，相应地，推进者、监督员属性会有提升。

依然是实干主义者，以事为本，执行力强，关注能不能做成事，带着这些印象，我们来看看这一大公司登陆中型团队是个什么样的情况。

你一年印象最深的事

工程轮岗业务

轮岗机制是团队人才运营中重要一环，用以防止单点产生和骨干Leader培养，我刚好被小钗强制调岗了......

这次调岗产生了很多后续影响：

• 工程组开发陆续离职;
• DevOps流水线被下线;

针对我的调岗，组织目的是为了让我熟悉业务，看清并抓住研发团队真正的痛点，能更好地推动工程落地，之前业务接触较少，工程推动阻力很大。

目前在业务线呆了快一年了，从结果来看，个人认为这种调岗并不是必需的，每个团队其实都有各自的痛点，有些并不是通病，深入某个业务可能会导致看不到全局。

但作为工程线Leader，一定要主动去熟悉业务，同时要具备或者提升一定程度的外交家属性，主动与业务线Leader多沟通多交流，从多方交流中来把握住整个研发团队的痛点，才能更好地提出适合团队的方案，这样落地时也能减少阻力，更好推进。

再说工程组同事陆续离职，其实工程部的同学整体实力是比业务团队强的，但当时在外界看来输出不如业务团队，作为Leader，我有一定责任的：

1）不熟悉业务、工作安排优先级有问题，没有及时去解决研发团队遇到的痛点；

2）与业务团队交流不够，整体上有些脱产，闭门造车。

3）工程组开发陆续离职其实和「孙狗」说的「统一网关」没有关系，那时候网关并不是工程部的重点，所以不存在争输赢的说法，只是工程组的同学觉得不被重视，工作成果也不被尊重(被要求改来改去，打杂的，或者做出来不被采纳)，更多地是工作「成就感的问题」。

作为Leader善后工作做的不行，这里我是有责任的。

小钗有话说：

这个同学这里说的工程团队的问题，「因为与业务弱绑定」容易「闭门造车」，工程线和业务线经常脱节，这样会导致工程线同学变成「垃圾桶」和「经验包」

业务组同学忙不过来，就丢一些基建任务外包给工程线；

业务组同学稍微优点时间，便直接以实际业务为起点，做工程建设，变成自己额外的「加分项」；

对于以上情况，工程线同学往往没有太多办法，因为缺少业务创新、技术创新的事情难度太低，大家都能做。

但如果任由业务线自己做基建，很容易重复造*，得不偿失。

重复造*

再说DevOps流水线被下线，调岗之后DevOps流水线就下线了。

但有趣的是，后面质效平台也做了一套流水线出来，包括提测流水线和发布流水线，还运转的挺好的！

后面就在反思，当时我为什么没做成，其实当时也是有支持的声音的？

从事前来看，当时DevOps流水线这个概念在整个研发团队的普及度不高，很多人对这个持怀疑态度，所以先天的势能不足，造势不够，盟友不足，这其实为后续孙狗等同学集体反对已经埋下了伏笔，在这之前其实应该把质效同学先拉过来的，毕竟质效后面也做了，他应该是盟友才对。

从事中来看，整个项目的推进没有及时和其他人同步进度以及功能点，导致项目上线时很多人觉得很突兀、不适应，导致工程一直在孤独奋战。

同时，当项目遇到阻力时，也没有及时向老板获取支持，专注做项目，过于被动。

从事后来看，没有及时和相关同学做好沟通和安抚，导致相关同学陆续离职。

从整件事上来看，一个团队的贡献度和稳定性，除了公司大环境，和一线Leader还是有很高的正相关性的。

作为Leader，提升的能力要更多地从团队视角出发，团队缺乏什么样的能力，Leader应该做相应补齐(或者招人补齐)，保持团队的健康度和稳定性，工程团队更应该做好对外的技术影响力和透明度。

业务压力

于个人而言，今年同时上线了三个大的业务项目，还是蛮有成就感的。

但对于项目组的同学而言，并行开发3个项目，经常在项目间切换，负荷很高，但其实效率不高，bug较多。

作为一线Leader，整件事下来还是过于偏执行了，决策之前没有先搞明白业务整体的规划就开始盘点人力开干，实属草率。

作为持续投入的长期运营项目，节奏感和人员稳定性还是相当重要的，这样太卷的方式对项目其实是有伤害性，一线Leader需要做好项目与团队兼顾，把控好项目进度，也需要做好团队健康度和稳定性。

你的心得

时间管理

作为一线开发可以一整天写代码，作为Leader，几乎不可能，需要关注团队、需求、会议、项目管理、其他杂事。

时间分配上，从100%，变为70%处理事情，30%时间开发。

自然而然的，开发工作的分配产生了变化，分配到自己身上的开发工作，都不是核心，不会对项目产生阻塞性。

目前来看，这项是不及格的，还是要坚持技术，毕竟P9以前更多还是要靠技术吃饭，以技术驱动，管理为辅，需要做好时间管理，希望今年能做到40%处理事情，60%开发。

视角变化

个人视角转团队视角，个人项目视角转整体项目视角。

会更多地关注产品需求、项目整体的规划，团队负责的业务边界，跨团队合作等问题上。

管理思路和风格

不管是负责工程还是业务，首先都会了解团队成员的过往经历，了解团队内每个人的特点，寻找领头羊，筛选出哪些能独挡一面的，哪些是配合者，再给予领头羊相应资源(导师制，配学徒)，发挥其主观能动性，带领团队正向循环。

双周分享，提升团队整体技术实力。组内同学轮流做项目owner，加快团队磨合，以战养战。

目前做得较差的还是在团队思考上，业务之外，团队应该有怎样的输出，发挥怎样的技术影响力，对整个研发能沉淀哪些优秀的系统设计和工具，这个是需要认真思考的。

产品思维

发现关注开发、项目管理那点事是不够的，需要关注产品端的需求。

有时候看着一堆堆功能的需求，其实挺困惑的，运营是ToC的，流量运营是不是该作为运营重点，而不该是功能运营？

就和一架没油的飞机一样，一直在修修补补或者换飞机表面的图案，但一直没有加油，飞不起来。

但目前还没法驱动产品，只能砍砍需求，需要更多地补齐行业、业务、领域知识。

想对我说的话

1）希望能适当扩大信息漏斗；

有些时候一个事情落到研发这里来感觉没头没尾，不清楚这件事的重要性、优先级，就开始要做这做那，说实话心里是排斥的，毕竟这样太偏执行了。

如果手上还有事情在做，那动力就更不足了。还是希望能保持上下文相对畅通，一件事或者一个项目过来能经过5W根因法看到全貌。

2）希望能把产品的OKR做起来；

说实话，现在的OKR做得挺烂的，一个合格的技术团队会有两类OKR，业务OKR和专业OKR。

业务OKR会根据产品的OKR做出相应的技术规划，如产品的OKR是日活增长一倍，那技术团队是需要相应的OKR去支撑的，比如xx系统扩容、xx系统重构、xx系统优化等，如果有这类OKR，也不会出现技术优化完全没有人买单的窘境。

专业OKR主要针对团队内部的质量和效率优化，这个就是我们目前做得这些xx技术优化、xx重构、工程基建建设。

3）重视工程基建；

CEO驾驶舱这个项目正常其实应该由工程或者质效团队来做，而不是临时拉人去搞。

工程整体人手是不足的，目前只能做一些系统维护、bug修复，很多基建规划没人力去搞，2021年过去了，基建整体上改变并不大。

很多时候都是这个文档填过来，那个文档填过去，说实话挺烦躁的，还是希望能有一些系统和平台出来，提升效率。

小钗总结

该同学作为业务Leader后，开始适应业务，接触的面也更大了，会站在业务角度思考工程问题，这些都是好事。

另一方面，现在带的业务团队，后续他再轮岗回工程线做Leader时会对他产生莫大的助益，这也是轮岗的附加好处。

好了，今天的分享就到这，希望对各位有用。「原创不易，多多分享」

想要更多交流可以加群：