前言
先介绍一下自己的工作，我目前主要负责 B 端相关的前端开发，由于本身对管理线并不是很喜欢，所以在团队中一般作为 偏技术向 的意见领袖身份带领团队改善项目。
得益于并非整个团队的 直接管理人 外加此前所待的团队都是 扁平化的管理，个人不会存在对同事一个非常直接的领导地位，所以整个团队的维护处于一个相对较高的民主策略模式下，并且也可以非常良好、高效的维护项目，故总结了一些自己的想法和心得。
方法论的来源
我对于团队项目管理的想法主要来源于 毛选，文章通俗易懂。
我这里就不卖弄学识了，如果有兴趣的可以自行前往参阅，所以本文主要会从具体的例子出发去讲述怎么实践，以及碰到的问题。
实践
1. 要善于分摊任务
作为领导者要完成任务就不能只依靠自己，首先和你合作的一批人会有各式各样的能力，你不可能每一项能力都比的同事强，所以，你要完成任务就不能所有事情都亲力亲为。
你所需要做的是将合适的人放在合适的位置上，哪怕他的能力还有所欠缺，只要他有能力提升，能够在能接受的时间、代价去完成这个任务。
如果他完成的不好，你需要去沟通他为什么没法完成。
- 是时间给的不够？
- 是任务太难？
- 是不了解怎么实践？
对于不同的困难，你给他不同的支持。
2. 公开通报以及互通情报
一个团队风气快速下降的核心原因往往都是藏着掖着，在背后议论，且不解决实际问题。
我在工作中会将我每一次要做的内容如实的公布在我们的 slack 频道内，并且所有的讨论都会在公开的频道给所有人查阅。
如果和团队的其他同事产生了比较巨大的冲突，会选择开会去解决，开会解决后会将处理的结果公示在频道下。
谨记
必须记住开会不是为了吵架而设立的，是为了解决问题。
而另一前提是，整个团队所有人都必须要清楚明白：
如果团队内能更快的达成共识，那么团队的整体效率的提升最终会反馈到每一个人身上，最直接的结果就是大家都可以得到合理的上下班时间，不内卷且高效的完成所有的任务。
另外重要一点就是互通情报，上文提到的公布在 slack 频道中就是其中的一种方式，你可以使用其他的方式：
- confluence
- 看板
- 周报
- 等等
形式不限，只要你能确保每一个的行为都能告知团队内的其他人，而其他人也能理解你一直在做什么事情就行，而我在 前端规范 中提到的 code review 也属于其中的一种，是一种更弱的互通方式。
只有通过交流，把彼此的认知相互交流，理解，才能最终取得共同语言，共同语言是很重要的东西，有了共同语言以后，一个团队可以产生凝聚力，自发的去维护整个项目的健康。
这样能发挥每一个人的主观能动性，而不是被动的去推动一个组员去完成。这样无论是对领导者，还是组员都是有益的。
3. 不耻下问
不知道的就是不知道，要不耻下问，我有看到过不少领导者不懂装懂把团队带到沟里面去。
很常见的就是领导强制一定要用 xxx 方案来实现某个功能。
我们不需要懂所有的技术，如果不懂，那么就让你的同事解释，自己去学习，直到懂为止，你不需要做到精通，你需要恰到好处的理解这个东西是怎么运作的，怎么产生效果，依赖哪些东西就可以。
其次是要学会去采纳其他同事提出的意见，基于事实和客观规律去应用结果，而不是依赖主观偏好。
4. 抓住重点
你作为管理者，必然会面对很多资源分配和调度的问题，对于资源分配和调度，最关键的问题是要把重要的资源放在核心问题上。并且要抓紧核心问题，除此以外维持项目健康度的内容不能放下。
至于什么是核心问题，最重要的一点是能带来收益的才是核心问题。譬如一个经典的问题：
问题
vue2 需要升级 vue3 么？
站在一个技术人的角度，需要，因为未来长期来看 vue3 必然会占据整个市场的主体地位——这点是不容质疑的。
但是升级 vue3 是公司的核心问题么？恐怕不是！
升级 vue3 能带来什么？对于公司而言除了增加2-3个月的无产出期、大量的人力占用、新增的大量 bug 意外，没有任何收益。
所以作为管理者，你需要的是调度的团队资源优先去完成赚钱的项目，在完成这样的项目以后再去考虑升级。
除此以外，你需要找到 升级 vue3 的必要性，这个必要性是站在公司角度的。比如你花费了 20 人天，但是未来的3个月内你能节省出 20人天来收回成本，那就是有效的。
5. 落实的规范要严格执行
很多团队无法达成共识的很大原因是无法严格执行规范，你作为领导者首要的是以身作则，你必须要实打实的去完成团队制定的规范，严格的监督每一个团队成员的执行，并且要发动团队其他成员互相监督。
抓了不抓紧就没有意义，会丧失团队的凝聚力，会让团队制定的规则失去威信，最终整个项目快速劣化。
另外一点就是规范要让所有团队成员一起参与制定，并且要让所有团队成员认可，至少认可的这一个选项必须是满足所有团队成员底线的原则。这样才能让团队里面的所有成员执行。
原因很简单
你今天不执行别人在意这一条，别人就会踩到你在意的另一条咯～
6. 数量很重要！
作为管理者对于量的把控必须非常清楚，你必须要清楚你的每一个成员对于工作的量能达到什么水准，这样你才能灵活安排各个人的工作内容。如果你想做一个非常好的管理者，你甚至需要比他自己清楚他会花费多少时间完成一项任务。
数量的重要性还表现在维护上，你需要清楚的知道一个改动会影响的面有多大，产生的后续波动会有多广，这样才能提前预估出出问题的点可能在那些方面，减少错误的发生。
并且对于数量的敏感会让主动放弃一些不切实际的方案，比如：facebook 不会用 typescript 替换 flow。
7. 提前准备会议内容
你在团队开会前切记让与会人员提前准备好会议内容，我很强调做一个新方案的时候使用 RFC 的方式去写，就是这一个目的。
通过 RFC 方式的编写，可以清楚的知道你要做的事情最终会是什么样子的，例如我强制要求大家对于底层执行的方案采用下面的方式去描述：
所以不要急于开会，想清楚你要做什么。千万不要临时凑方案，另外对于方案还有很重要的一点是简明扼要，会也不要开的太久，按照我的经验，效率比较高的会一般不会超过45分钟，如果过长了一般有两种可能：
- 没有做好拆分，讨论的任务太大
- 扯远了或者产生了很大的分歧
如果讨论的任务很大，那么先讨论大的方向，然后拆分成若干的小任务依次讨论，执行，甚至可以执行后在继续讨论。
如果产生了很大的分歧，那么最重要的一点是停止继续争论，将争议记录下来，回去思考清楚以后在重新讨论而不是在会上抓着这个不放。
8. 不要唯技术论
很多技术出身的领导者都习惯于唯技术论，认为技术主导项目。
说白了
就是手里有把锤子，看什么都是钉子。
唯技术论很容易将简单问题复杂化，开发者的心态上总会尝试追求完美，我们需要接受自己项目的不完美。我们需要跳出唯技术论，最简单有效的实践便是“给问题做减法”。
习惯于去问
这样做的目的是什么？要完成什么事情？
这些问题就是为了给的目标做减法。
譬如很多人都会尝试提问：怎么样使用 xxx 方案完成 yyy 实现 zzz。
这样是不对的，不应该从使用什么方案为起点。
技术是服务于业务的，应该考虑我们要实现 zzz 应该用什么样的方案。
哦，有 aaa，bbb，ccc 这样的方案，例如 aaa 可以完成 yyy 的功能，这样的思考路线才是正确的。
最绝的例子就是 “如何通过写代码赚钱”，你的目的是写代码还是赚钱？赚钱一定要通过写代码来实现么？再多问自己两句，自然豁然开朗。
后记
环境大相径庭，而言人人殊，谨以此文参考，切莫盲从实践。
本文标题：怎样带好一个团队
永久链接：https://iceprosurface.com/thinking/lead-team-effectively/
作者授权：本文由 icepro 原创编译并授权刊载发布。
版权声明：本文使用「署名-非商业性使用-相同方式共享 4.0 国际」创作共享协议，转载或使用请遵守署名协议。