三年研发主管的感悟-一一网

前言

一个合适的错位，让我有了一个重新定位和审视自己的机会，人生就在于不断地清零中成长。或许自己累了，也或许是自己浮躁了，请原谅自己在这个时候离开，按照福报厂的说法，应该是要跟团队一起打个翻身仗的时候，却因为自己的不坚定而转身离开。

不过依然感激在C厂的时光，这是一个你想上进就会有机会的地方，当然每个组织都有不完美的地方，没有某乎上说的那么扯蛋。回想起做的第一个项目、第一个产品、第一个业务、第一次带队、第一次职级答辩，太多太多的第一次，至今仍有太多的回味。铁打的公司流水的兵，我珍惜每一个遇到的人与他们共事相处的时光。走之前给所有开发测试童鞋们做了一场关于《金字塔模型》的分享，其实就是给所有共事过的人一个告别，告别一个奋斗五年的公司。在散伙饭上二三十号人面前，我没有说太多，并不是对这个团队没有感情，而是作为这个事业部的零号员工，只想留下的你们更好，以前想到的都是自己是最后一个，没想到先撤退了。

自己从来就不是一个“安分”的人，三年研究生，五年工作生涯中，主业做过码农、当过TL，干过PM，副业做过老板(现在还合伙控股)，当过“高管”，干过技术顾问，并没有像某些大佬出书开讲座那样有些技术成就，但也过的非常有意思，认识了很多不同领域的专家或企业家。这里也鼓励大家多去探索新的领域，技术只是门槛，有好的技术是不怕35魔咒的，这就意味着有一份稳定的工作，要想有更好的人生视野与高度，只有带着好奇心，不断努力地缩减盲区，用于实践般的探索未知领域才能得到想要的视野。

在别人眼里，我自己一直都是个异类，从不是一个好说话的人，对自己和他人都极端苛刻，对效率与质量有极致的追求，对代码、设计、质量都有严苛的要求，曾经带过一个老兄，一段老代码他重构了差不多十遍，依然不满意，然后自己又上手改了七八遍，从不满意现状，只有更好没有最好，一直笃信自己出品都是精品。

在出发前的一晚，突然找到了八年未见的高中挚友，在广钢的后山上详聊了一整晚，仿若当年紫金山下的两个读书少年在侃侃而谈。两个人都有相同的境遇与瓶颈，但我不相信自己的人生高度仅此而已，坚定踏上新的征程。聊了很久，有两句话可以跟大家分享：

不给自己的人生设限，就是对自己最大的负责。

读万卷书不如走万里路，走万里路不如阅人无数，阅人无数不如自己****感悟。

像流水账似的说了五年的经历，最难忘的就是带队打仗的日子，废寝忘食，攻城拔寨，只为团队目标，业务价值，最欣慰的是看到每个人的成长，业务量的增长，给用户带来的价值。想来想去，技术TL(Team Leader)这个岗位给我带来的收获最大，最近也在看一些资深TL的经验总结，反思过去的点滴，还是有不少感悟，希望跟大家分享下这些内容。

1.研发团队是做什么的？

“不谋全局者，不足以谋一域“，要看清楚研发团队在组织架构中的关系很重要，一般正常的中小型公司组织架构按照职能划分为几个组或者部门，当达到一定规模时，就会有很多底座平台的部门或团队出现，总目的都是提高工作协同效能、降低公司运营成本。项目管理是个很好的利器，可以将公司的资源进行合理利用，并把控住风险。有个偶然的机会，笔者从“设计者”的角度经历了一次公司架构的调整，为这个公司梳理了整个愿景/使命/价值观/业务范畴等一些顶层设计，还主导设计了组织架构和各种管理制度，用周末时间足足搞了一年，也看了很多企业管理的知识和对标公司的做法，令人欣慰的是，这个公司总体还是按照当时设计的模样走着，虽然有点慢但没走偏。

一个典型的研发团队由技术线研发工程师为主，还有测试、产品、项目经理等小伙伴。研发团队需要负责一个模块、子系统、系统、领域服务的迭代开发，其中包括了需求分析、功能设计、代码实现，系统部署运维等工作职责。从研发团队自身的定位，一个研发团队为了能够较好实现自身的职责，需要如下几种角色，角色名字如研发主管还是部门经理在各大公司/组织中的名头可能是不一样的。

技术负责人(技术经理)：项目落实于技术组件/系统，每个系统需要有技术负责人，参与技术方案的设计与落地，负责最后的结果。
研发主管(部门经理)：成员管理、团队协同、资源协调、招聘、团队绩效;
项目管理者(PM)：研发活动经常以项目形式组织，需要团队内外的协同，项目的推进需要项目管理者的参与;
开发：研发团队的开发。

2.研发工作职责模型

研发工作职责可根据技术的能力模型去做拆解，可以定义一个如下的层次模型：

（A1）写代码（负责具体实现）
（A2）review代码，做方案设计（负责方案落地）
（A3）review技术方案设计（负责项目/落地）
（A4）建议新方向，把关新方向（负责整个领域的演进和结果）

“宰相必起于州部，猛将将必发于卒队”，大部分的技术大牛都是从一线研发中逐步成长起来的，只有实际承担了业务开发与解决问题才能从技能的本质去思考去提升自己。

技术负责人(技术经理)要负责系统，负责软件产品。每一个系统/产品，都需要有明确技术负责人。同时该系统内部可能还划分几个子系统，可以按照需要设定子系统的技术负责人岗位（当模块/子系统有多于一个工程师参与时）。子系统技术负责人在技术决策上需要服从上层系统技术决策。技术负责人需要承担系统真正owner的权责，并为结果负责，否则就不是真正的技术负责人。大部分的研发团队的管理者本身也兼任团队所负责的系统的技术负责人，但是并不是所有的管理者都有意识的做好了这项工作。当然技术负责人也可以和团队管理者角色分离。

3.如何做一个合格的TL

3.1 TL的初心

正所谓，诚心正意修身才能平天下，在哪个公司最不希望看到是转到管理者是因为对权力的追逐。对业务领地的追逐是大公司病的主要问题之一，谁不想地盘更大，人头更多？身处其中的管理者，如果把带不带人、带多少人作为自己追逐的目标，而且将这一条路看做是向上发展的唯一道路，那么我们会很容易看到抢地盘、内耗等诸多弊病。把帮助团队的发展，通过管理支撑团队带来更大的成就作为目标，是应有的初心。

3.2 如何体现价值

对团队没有帮助的主管不如没有。有贡献的主管一定是清楚自己带领的团队缺少什么，需要怎样的帮助。具体来说，一个好的团队主管需要做好以下的职责内容:

持续完善工具/流程/规范的建设：如果团队需要自己做技术负责人，要能够对技术方案决策负责，为技术演进的方向负责。能帮助团队解决技术问题，制订好设计评审，代码评审，将规范、设计思想、好的代码和设计的要求传递给团队成员；
清晰的团队目标与规划：主管需要明确团队的目标，并构建出初步的规划蓝图，并传递给团队成员；
清晰合理的团队内分工: 团队内的分工也是个技术架构问题，做好内部的分工，让团队成员可以相互信任和依赖，这是主管的核心职责；
及时给成员困难时的指导：每个开发都会在不同阶段遇到困难，识别并帮助他们走出这些困难，是主管作为教练角色需要承担的职责；
：团队和其他团队边界有冲突时，明确边界，解决冲突；
帮助团队解除阻塞：协助团队解决问题或者上升解决阻塞。
协助成员制定合理的成长计划: 无论是

简单来说，一个有价值的技术TL会让整个研发团队目标更清晰，协作更顺畅，能让团队的成员更好的发挥、更好的产出。

3.3 如何构建领导力

一个成功的技术TL肯定是具有较大领导力，说白了，就是你能让大家觉得要干的事情有希望，都愿意一起努力把这个事情干成了，这也叫”画饼“能力，我觉得会画饼并不是啥坏事，如果能让听者觉得这个饼是真实存在的，这需要领导者很高的水平，能让这个事情看上去是可行的。

3.5 如何跟团队沟通

指导和教练coaching：适用于两种场景，a.对于团队的新人、比较初级的工程师，需要采用教练的模式，主管应该花更多的时间，针对具体的案例帮助同学分析、明确目标、明确提升路径，教会同学未来遇到同样问题时的解决方案。具体的可参考GROW模型; b.团队成员寻求帮助，可以不必急于给出答案，尽可能做到授人予鱼，不如授之于渔，教会分析问题的方法论;
支持Support：支持和coaching不同，但可能是管理者最经常的模式，帮助团队的成员解决具体的问题，但是又不是代替成员去决策。
代理授权delegation：对于团队的有经验的成员，能够对某个模块、系统、方向承担起相应的职责，尽量将职责代理给能够承担的同学。代理是把一件事情或者一个方向的决策权交给这个成员。有团队成员可以被授权负责某些方向是团队逐渐成熟的很重要标志。
达成共识consensus：当前的问题，需要经过引导/讨论/脑爆的模式形成共识，可以设计合理的会议流程和话题引导，给大家充分表达机会，形成共识，促进更好的协同行动。
直接下达命令directing：总会有一些场景，因为时间紧迫，没有时间讨论形成共识，那么就明确告诉团队决策，大家按照决策执行。但是不管什么情况，管理者不能带给团队一个不敢反馈的氛围，如果因为自己的管理风格问题导致听不到声音是最危险的。