️This article has been over 1 years since the last update.
随着经验与能力的提高，作为码农要开始承担团队的责任，推动团队发展。在团队中承担管理责任的主要有PL(Project Leader，非技术管理，本文不介绍)与SE(System Engineer，本文重点介绍)，本文将介绍如何完善这个角色。
读者: 技术以上，管理未满的初级SE。是面向技术者提高团队效率的入门文章。
综述: 通过自上而下的改变提高团队竞争力。作者以前写的“改进优化”只能说是自下而上的包工头级别，只顾了自己不加班爽了，而本文讲述的是如何承担更大的责任帮助提高整体团队的效率。
| 角色 | 作用 |
|---|---|
| PL | Project Leader，非技术管理 |
| BA | Business analyst，将客户不准确的需求转化为可以开发的方案，也可能称作业务SE |
| SE | System Engineer，偏技术侧的工程师，将业务transcompile代码方案 |
| 一般社員 | 纯编码与测试工作 |
只写代码行不行
有人说，我只喜欢写代码研究技术，不喜欢去做管理带团队。但是事实上就算只做技术，如果技术做精了，项目的架构维护要看护吧，总体设计方案要输出吧，团队的生产力要负责吧，所以专研技术也是少不了与团队互动的。就算是国外的大胡子专家，人家也能顺手进行培训赋能。
如果长期始终只负责自己的一亩三分地，那么相当于限制自己水平与应届生一致，写CURD并不需要匠人精神，而将会被看作“不胜任”的表现，在寒冬期很容易被优化掉。
可能这时有人又会说了，这样我的工作量与加班不就变多了吗？关于这个问题，我建议先提高自己的效率，将重复工作外包化与自动化，压缩出时间后，再阅读本文章。
推动团队进步
普通程序员在自身达到高效率与绩效后，比如工作不加班就能高质量完成，是不是自己的责任就到头了？Of course not，这种心态完全不够。当你的能力更高时(with higher paid)，负责的Scope不再将是自己个人的，而是整体团队，也将参与团队间的竞争。在格鲁夫的书中，有一个这样的公式
1 | 经理人的产出 = 管理活动A×杠杆率A + 管理活动B×杠杆率B + ...... |
你需要做的事情是充分发挥自己的杠杆率，提高团队整体生产力。对自己的效率改进是自下而上的改良方法论，而对团队的改进是自上而下的改变。
推动进步就是发现自己团队存在的Gap，并找到度量标准，然后实现的流程。这句话并不是正确的废话，因为发现自己的缺点就很难，发现他人的缺点很简单，但是发现整个团队的缺点却是最难的，因为自己的Level与Perspective受限导致很难与其它团队进行竞争对比，这个问题可以深入与领导详细沟通对齐。有的管理做得好的领导会主动找你沟通，而有的领导可能就当二传手了，因此你可能需要主动找下。
寻找Gap
常见的Gap有
非技术类
- 知识管理: 通过GitBook或者类似静态生成Wiki实现避免重复培训
- 代码规范: 通过可执行的度量降低缺陷(比如SonarQube/'səʊnɑːkju:b/可以具体到责任人)，通过编码规范考试降低人工评审耗时
- 需求分析: 降低需求分析中的无效会议
技术类
- 降低重复: 通过生成器降低重复劳动, 通过DSL(比如注解)降低生成器
- 架构改善: 通过服务化，组件化拆解项目业务逻辑
设定度量(Metric)
度量一般有两种，一种是业界如何/其它组如何，比如X宝就是这样搞的；还有一种就是与自己对比，挖掘已有的财富，比如降低了XXms的延迟，提高了XX天迭代速度
实施改进
要说改进，必须先制定方案来一波胶片给汇报一下。然后把能分的活给分下去。胶片是一种很好的整理思维方式，适用于大公司做集体决策。
这里我推荐直接用鼠标编辑胶片，而不用Markdown生成Slider，因为富文本，流程图与表格太多了
让自己有分量
这句话的意思是当其他同事有任何问题时，第一个求助想到的人是你，而不是堵住他人的嘴（沉默是失败的极致）。
想尽办法解决每一个求助
- 对于简单的问题(比如为什么无法启动)，不要抱怨为什么不去自己搜，很多人开发多年还是用CSDN与百度，你要心怀仁慈之心去普渡同事如何搜索关键词
- 对于中等的问题(比如如何通过注解降低工作量)，要给出路线方向，并且让对方补充文档到知识Wiki中
- 对于难的问题(比如脏数据定位)，要亲自投入，并帮助解决
这样通过多次求助后，再找你的就是中高质量的问题了，而初级问题将通过方法论与Wiki归档固化为流程
当然有一种特例，就是中老年员工的习惯固化（非年龄歧视，只有相关性没有因果性），这种的确需要逼一下，要不然就把你累死了。
保持个人持续学习
提高自己的知识水平，这个是持续的
做事情时克制抱怨
遇到能力弱的同事，要么就做到不抱怨，要么就委婉讲出，总的来说就是不要瞎BB，不少技术好，能力强的人都有这个清高的缺点。
- 不要通过贬低他人来抬高自己
- 允许严格地批评，但是要有证据，谨慎公开批评。批评后要有改进方案
不要赌气与隔岸观火
先举一个我以前失败的例子：客户侧提出了一个“优化”需求，但是涉及到底层大变动，BA与管理者认为比较简单，就交给其他SE同事去设计方案，当SE完成方案，告诉管理者需要“较长”时间，可能有“风险”。可惜管理者认为“风险”===“稍微延期”，导致方案被通过，耗时被低估，最终没法完成，以至于引发了开发与业务互相扯皮等严重问题。
这是一个多输的结果
- 客户很委屈：连简单的“优化”没有完成，反而被开发推脱为“需求不清晰”，导致积累的信任合作受伤
- 管理者很委屈：方案是技术出的，也都同意了，为啥就延期了呢？
- SE很委屈：我明明反复提示有风险了，管理者却强行推行，也罢，反正我有邮件证据，后面不关我事。
- 一般社員很委屈：我为啥要为领导的失误而加班买单？
- 我作为其他组也躺枪了：其它组加班，把我的人力拿走了，导致我这边也被动加班。
针对这种问题，虽然每个人都有问题，比如客户需求被BA低估，技术同事有赌气心态，管理者风险控制没有经验等。但是我认为我个人的隔岸观火也有责任，我做为双方都熟悉的人，本着避免吃力不讨好的心态，没有及时纠正走向，导致多输。
如果给我一次重新选择的机会，如果这位同事值得你帮助（也就是吃力能讨好），不管你作为管理还是技术，就不要隔岸观火，而是努力把这个矛盾解决，通过拉上各个代表进行SWOT分析量化风险与收益即可。