本人没有作为长期 leader 一线经验，这是我自己在工作中的观察和构想，如果让我做一个5人以下前端团队 leader 我需要做的一些事情。
1. 分配任务
在开需求会议接任务时，一定要带上对应的开发人员。因为据我自己的经验，理解需求对开发来说很重要，能减少因为沟通理解产生的逻辑 bug，能够在需求会议上就发现需求不严谨或者逻辑有问题的地方，从技术上可能提供更优的解决方案。并且为了提高开发人员的这个意识，会在平时和他们强调以上的这几个点。
在分配任务时要把业务相同的模块劲量划分给同一个人，这样可以避免很多沟通成本，利于此人产出更高质量的代码(因为相同逻辑的的模块编码前需要统一规划，如果多人做，这几个人不但要沟通，还要处理风格不同的，代码质量不同的问题)。
2. 技术选型
评估团队的技术能力，选择最适合的人做首次选型(这个人可能是在某方面经验最丰富，可能是技术最强的)，然后让此人做完选型及基础“架构”，全队评估。一来是为了让所有队员知道如此选型和架构背后的逻辑(同时间接可以提高其他同事的技术视野)，二来可以帮助选型者弥补欠考虑的地方。
3. 技术规范
和第二点类似也是找经验最丰富的人来做(无论是队员或者是 leader)，然后也是评审，为了达到的目的和第二点也相同。但是技术规范这点在实施时要充分考虑队员的顾虑，因为在规范上有些东西比较主观，如果碰到特肘的技术人员不认可某些规范，也要做好妥协的准备。平时是否要长期念叨良好规范这件事情我也没有经验，怎么做我也不知道。
4. 成员任用
不要怕团队成员技术超过自己而打压队员，leader 的任务之一就是服务团队，最大化团队战斗力。这点是最近在书中看到的，个人感觉是很有道理，所以就列一下。
5. 新人培养
个人觉得一直手把手教是不太可取的，新人刚刚上手的时候可以这样，但是需要在平时逐渐培养自己就工作中就某个知识点进行自我学习的能力，如何debug 的能力。这些能力也不是一蹴而就的，可以通过布置非公司任务给新人，让其完成，并在完成后进行评审来帮助其进步。
6. 任务排期
这个我也是没有啥太多的经验，但是有一点是肯定要预留一点时间(无论是 leader自己排还是队员自己报工期)，而且根据队员不同的特点定期检查工作进度是否符合预期(技术能力强，做事一贯靠谱的不用天天盯，一个礼拜关心下就可以了，新人起初最好天天关心下，一来保证团队的整体进度，二来可以考察新人的工作能力，以便今后的任务能够准确评估工期。但是天天盯需要注意方式方法，不要引起新人的反感)。
7. 产出质量
作为小团队的 leader 一定要对业务熟悉，因为队员在开发过程中你是团队的首席技术业务官，你要解决队友因为业务不熟悉产生的技术偏差，产品经理没有你懂技术，和技术人员交流肯定不如你。 对代码虽然不需要每行都了解，但是对业务流程一定要清楚。只有 leader 对项目的全局了解，才能把控产出的质量。
