对内：带头做技术分享，培养团队的技术氛围

对外：输出技术文章，帮助团队建立技术影响力

五、每日站会

每天都要对前一天的工作进行复盘，一方面是保证大家的工作产出，避免摸鱼，另一方面可以及时了解到大家在工作中遇到的问题，及时给出解决方案。

六、因人制宜

对于团队中喜欢挑战的人，就需要不断给予更高难度的工作任务，激发他的潜力和工作热情，一旦从工作中获得了成就感和认可，也就对团队有了归属感。

对于工作经验或者工作能力不突出的团队成员，可以给予easy和middle级别的任务，不断积累经验，结合他的工作动机，看是否需要给予更高级别的挑战。

一个团队一定是有梯度的，但是这个梯度不是固化的，随着工作经验的积累和团队leader的培养，是有可能从一个小萌新成长为团队重量级人物的。

七、每周五下班前分配好下周的工作

因为我们团队规定每周五下午六点半之前提交周报，周报包含本周工作和下周计划，收齐周报后，结合团队成员自己的下周规划，以及需求池，分配好下周的工作任务。

如果到周一再分配，那大家可能因为没有明确工作计划，周一上午就浪费过去了。

八、控制技术项目的资源投入比例

如果你的团队不是专门的基础架构组，那就需要控制纯技术项目的人力占比，一般不会超过20%，比如你的团队有10个人，那么最多只能投入2个人力focus在纯粹的技术项目上，超过这个比例的话，一般会影响业务项目的进度。

但也不能一点都不投入资源在技术项目上，因为技术项目一般是为了提升研发效能服务的，业务在快速奔跑，一边开飞机一边换发动机，怎么保证不坠机，就是团队要有技术功底。

九、经常和团队同步整体规划

我一般以月为单位，和团队同步整体规划，选在周会上，大概花10-20分钟左右的时间，跟团队成员说一下近期的规划，让团队成员有个方向感，而不是只埋头做眼前的事情，对团队发展没有参与感。

说到参与感，最近在研究怎么做团队共创，还没有实践，等执行完有结果再分享出来。

最近经常和CTO一起开会，从大佬身上学到很多，比如沟通技巧，经常会有这样一个场景：

大佬和你聊天的时候会抛出一个topic，然后问你的看法，等你发表完意见之后，他会再讲一讲他的看法和方案，也就是说在问你之前，其实他自己已经有方案了，那为什么还要问你呢？我想这就是参与感的培养，这个沟通技巧也可以应用到日常和团队小伙伴的沟通上。

我们不应该直接地告诉下属该怎么做，而是通过引导他有自己的思考，然后经过和他的讨论，最终完成一个方案的制定，这会让团队成员的成就感和参与感翻倍，从而执行起来就更有效率。

十、带核心组员参加需求分析阶段

一般一个需求落地有这样几个阶段：需求分析、需求评审、开发、测试、上线。很长一段时间我让组员参与的是需求评审以及之后的几个阶段，但是我发现让组员只参与评审，对需求的来龙去脉理解是不透彻的，所以最好在分析阶段就把核心的组员叫上，一方面是让他们更了解业务，有利于梯度培养，一方面是对需求了解更多之后，在开发阶段才不容易出问题，而且也要让大家珍惜每次需求分析和评审的机会，因为这是开发同学能够了解业务最直接的机会了，要积极参与到需求的分析思考中去。

十一、复杂些的项目，一定要老带新一起做

如果是有技术难度的项目，需要老带新一起做，如果丢给新人去做，大概率项目会有延期风险，而且新人一般都急于表现自己的工作能力，不到最后一刻，不愿意承认自己的能力不足以承担整个项目，常常会出现项目马上要上线了，新人才迫不得已告诉你自己搞不定了，有延期风险，这种情况也可以理解，所以我们要从战术上避免类似现象出现，那就是复杂项目，有条件的情况下，搭配一个有经验的老手，带着新人一起做，这样新人的压力也会小一些，项目的风险一般也在可控范围内。

十二、不要轻易给下属画饼给承诺

除非你有信心能实现承诺，否则不要轻易给下属画大饼给承诺，因为一旦承诺不能兑现，会对好不容易建立起的信任关系有个毁灭性的打击，如果你画大饼是为了激励员工，那我建议你换其他方式。

十三、技术团队KPI如何做

技术团队的KPI来自两部分：1. 快速支持响应业务需求 2. 团队技术基建。

如果只停留在业务需求迭代上，团队价值很难突出，所以除了支撑业务需求之外，团队基建也要跟上，只有团队有更多的能力积累，能解决更大的问题时，价值才能体现出来。

十四、让员工能把事做好，除了激励，还有优秀的团队

薪酬激励是一种手段，还有一个因素也能让员工更热爱工作，那就是优秀的团队，一个是在招聘的时候，要招优秀的成年人，注意，这里的成年人重点指心态，因为我发现即便是工作了好几年的人，也有很多心态不成熟的。另一个就是人员优化，这是一个很沉重的命题，但也是职业生涯中需要面对的问题。

未完待续...有新的经验积累了会持续更新此文，我分享的也不一定都适合所有团队，欢迎一起探讨。