大家好，我是一名前端工程师，作为小组长带领3人左右一起开发，是一个半技术半管理的职能。个人从工作中发现了自己的不足，以及要改进的方向跟大家分享。
- 做好自己
首先做好自己的第一位的，从程序员角度，尽量问题考虑全面，考虑扩展性，代码多加注释，思考更高性能的解决思路，做好代码优化，把开发文档整理好等，做好自己的开发工作，积极完成任务，也是做一个表率，不然没法一起合作，更没办法管理。
- 信任队友
有新功能或者bug需要开发解决的时候，自己有很好的思路或者想法，一般我会提出一种或几种思路给同事参考，但是后面我都是加一句，我这只是思路或者想法，你有更好的想法可以完全按照你的思路来，代码大胆修改，有问题重新改呗。因为老代码过于庞大，有的同事不敢动，怕会影响其他代码，这种心情可以理解，但是偶尔会制约你的想象力的发挥，所以我们会根据实际情况，有一些地方感觉影响不大的地方，及时提醒到同事，这里可以随意发挥，当然有些改动影响大的地方还是会注意。
- 掌握全局
做了小组长，你就不能只关心自己的那部分的代码了，你的视野要放的更高点。基本的就从整个工程的角度去思考问题，自己写的代码，对整个工程有没有影响；再者，别人的代码影响范围多大也需要时刻关心；然后，包括一些功能的设计，整个项目的进度和方向，架构的稳定性和性能等，都需要时刻关注。要看到整个工程、整个项目，而不是某个一块功能。
- 沟通技巧
这个属于通用技能，每个人都需要沟通技巧，只不过管理的话，可能用的更多一点。在跟同事讨论某个技术难点的时候，怕是很多同事争论像吵架，通常总会有点收获，但是我觉得影响很不好，我觉得还是应该以个人观点讨论的形式来进行，原理性的东西无需争论，搜索资料即可解决，个人观点是主观想法，每个人的想法都应该尊重，无需硬怼别人的想法。管理的时候还涉及任务分配，这需要有技巧，虽然有指使同事干活的嫌疑，但是要沟通出这个事是为了团队协作、分工合作，这个有难度，个人还在学习。
- 承担责任
之前有同学也说道，领导是背锅的，话糙理不糙。日常开发任务进行，总会有或大或小的问题出现，无论是出bug，新功能与需求不符，还是工程逾期，确实是领导一层没有监管好，所以很多时候需要勇敢的承担责任，在其位谋其职。不过重要的是，出现问题以后，第一，要积极解决，要有足够的能力和信心把锅给补上，如果技术能力不足，那就花时间去学习，去请教，直到弄懂为止，因为你不去学这个搞这个，其他人更不会搞；第二，就是总结经验教训，问题出现一次，出现两次，还OK，出现多了，整个项目就可能会出大问题，所以总结出问题的根源，吸取教训，力争下次不会再犯，并且把这这些经验及时传达给同事们（这个会在第8点详说）。
- 乐于助人
之前一位大佬的文章提到的，适合做管理的人，可能有一个重要的品质，就是乐于助人。单是这个品质的好处就不多说了，我为人人，人人为我嘛。就技术职场来说，比如，同事有问题要去请教你，那你很乐于帮助他一起解决问题，一起研究更好思路，方法；很多时候，你不止关心自己的那部分工作，同事的工作跟你有衔接，有交集，你也积极参与，积极响应，帮助一起协同解决问题，然后你对项目的全局观就更强了；及时同事那里有bug了，你也可以帮助一起分析问题。很多时候，一个乐于助人的人，几乎就是一个管理者的形象，通过帮助别人，你也获得了对整个项目认识的提升和自我能力的提高。
- CodeReview
做不定期和定期的code review很重要，但是很多团队不做，我们也正在改进，要时刻记得代码前期留下的坑，后面都是要花更多时间补的，况且从代码层面查问题，会把问题查的更透彻，让工程优化的更健壮。所以道理是这样，行动上，我觉得应该定一些规则，比如，每完成一个功能，做一次review, 或者，每周五下午进行review,以团队一起写代码的人一起阅读代码，修正一些风格，bug, 探讨更优的解决方案。
- 技术分享
这个另一个和CodeReview一样很重要但是需要执行力的事，就像前面说的，在项目中踩到了各种坑了，那我们就应该积极把这些问题总结下来，最简单的，就立马告诉同事，自己遇到了坑，提醒同事注意这个问题；再者，内部整理一份问题简单的解决方案PPT，在办公室给大家分享出来，让大家积极参与讨论，或许同事还有更好的解决思路，形成一个技术讨论、技术提升的氛围，这样自己输出了知识，帮助自己沉淀，也帮助了同事提升，更是提高了整个团队的水平；后续，最好还能输出成文章的形式，写成博文，分享给网络上的朋友，这个的意义更大。当然，要让每个同事参与进来，定期分享，形成一个良好的学习+分享的氛围，分享的内容不限于工作中的问题，还可以是自己任何感兴趣的话题，这样能提高团队凝聚力。
总结：以上就是我自己的采坑经验，结合网络上大佬对管理的见解，总结出来的一点小收获，希望大家一起提高。