团队管理经验分享

团队管理经验分享。大部分的工作者都是从低做起，一直往上爬，爬上管理层的这个位置。经验都是从零积累起来的。看看别人的管理团队经验，从中更好的学习。下面跟大家说说团队管理经验分享。

团队管理经验分享1

一、分配任务的时候，一定要具体通知到特定的人

如果只是发在群里周知一下，可能没有人有积极性去做这个事情，因为一个团队里面，大概率不是所有人都积极接受工作挑战。

二、不要轻易的和你的上级老板沟通手下哪个员工不给力

不能因为一次表现不好，或者出了线上事故，就和老板沟通这个员工不行，因为这会影响这名员工的绩效考核，应该慎重再慎重，没有人不犯错，也不怕犯错，犯错之后，应该再给予机会观察一段时间， 如果实在不行的话，再找老板和HR沟通优化问题。

三、抓大放小，把握几个关键节点，事半功倍

不用跟进开发过程中的每个细节，但有几个关键节点，一定要做到！！

1、需求评审时，做到判断需求的合理性和可行性

2、出技术方案时，做到了解其中的实现方法、实现成本、风险及收益

3、需求提测前，一定要走查，发现问题还有时间在测试阶段修正

4、需求上线后，一定要验证线上效果，定期收集线上数据，分析项目的业务价值

四、带头发起技术分享

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

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

五、每日站会

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

六、因人制宜

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

十三、技术团队KPI如何做

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

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

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

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

团队管理经验分享2

一、新手阶段：3人团队

第一次管理团队，严格来说是在实习阶段，公司总人数10000+。

或许是求学阶段就一直有班级管理、社团管理的经验，所以在实习和工作期间也较早的担当起了管理的职责。

在这家公司管理一个3人的小团队，一个UI，一个前端，一个没有多少产品设计经验的后台转产品的产品新手，加上我（一个近两年经验的产品leader）。

实事求是，当时年纪轻，能够在实习阶段参与管理，主要还是感谢领导提携和信任，感谢后来都当上副总的两位大哥的支持。

虽然个人干劲足，能够超质量完成所负责的工作，但是对于工作阶段的团队管理，确实没有什么经验。

所用的主要还是在学校管理班级和社团那一套，稍微加上一些从书里读到的一些团队管理的理论，期间踩了很多坑，也有很多感悟，现在回头看来真的能感觉到当时的稚嫩。

1、 思维转变的重要性

刚开始接受管理职能，其实会有些不适应，虽然笔者在校期间已有管理经验，但是工作中确实不太一样。

工作上，更讲究能力优势和为人处世。

在接受这个管理职能前，工作中笔者一直都是单枪匹马，做好自己的本职工作，毕竟当时还只是一名实习生。虽然那时候工作能力上已经具备甚至超越了部分毕业一两年的同事，但是整个人都是踏实做好本职工作的心态。

这样的心态，导致笔者开始一段时间，都不太适应去管理团队的其它成员（或者说任务分配吧）。认为彼此就是一个小团队，认为大家把事情做好，没有谁安排谁的必要。

但是这样的心态，导致后来的工作出现了一些状况。

比如团队里有的成员，一旦工作完成了，没有人安排，就进入闲置状态，或者有的成员（当时另外的那个产品大哥）需求没沟通清楚，确认阶段出现了问题。

所以最后领导安排给我解决，我解决过程中，只顾着自己把事情做好，却忘记了作为管理者最重要的一点：就是教会其他人解决问题的能力。

这样大家会一起成长，团队的合力才更大，你的领导力和同事向心力才更强，可当时确实没考虑到！（还是太年轻）

所以，对于刚接触管理职能的新手来说，个人思维和管理思维的转变特别关键。

2、 3人团的管理策略

3个人的小团队，算是一个最小单位的作战小组吧，我当时管理的经验就是：短平快的交流和协作。

无论是任务分工，进度规划，工作交流，都一定要缩短交流、协作路径，足够扁平化的管理（除了做决策，平时大家并没有上下级之分）。

减少开会，加强快节奏的直接沟通，可保持高效的作战状态！

二、上一阶段：8人团队

笔者第二阶段的团队管理，管理人数8人，公司总人数100左右。

虽然有了第一次团队管理经验，但是严格来说，第一次的团队管理，仅仅是一次“新手村”的锻炼罢了，基本就是靠笔者自己的理解和不断的试错。

8人团队的管理，对我来说，是个不小的挑战，也是一次不错的机会。

在这里，很感激信任我的总监（一位气质实力俱佳的职场精英），感激她对我的认可和信任，感激她对我工作的鼓励与支持！

这个8人的小团队，我作为Leader，其他包括一个UI，一个新媒体编辑，一个小程序研发，一个IOS开发，一个Android开发，两个后台，一个运营人员。

在这个团队里，因为有了之前一些粗浅的管理经验，自己对各端的工作职能和相关技术都有了更深的了解和理解，所以我的团队管理能力也得到了更大的发挥空间。

1、 流程控制的重要性

笔者认为这个阶段流程控制最重要，当然这只是个人看法和感受。

这里讲到的流程控制，指的是对产品流程中每个阶段目标和完成质量的把控，每个端口工作内容的规划和饱和度管控。

这样描述，是不是感觉到其实并不简单，而且当中的重要性，应该不言而喻了吧。因为既包含了对产品各阶段的管控，也包含了对团队人员的管理。

作为团队的管理者，你需要对成员负责；作为产品或项目的管理者，你需要对产品或项目负责。

在这个8人的小团队中，真正让我感受到了，麻雀虽小，五脏俱全。

整个团队，就是一个完整的互联网产品线的研发团队。

角色层面：包含了产品，设计，研发，运营；职能层面，包含了设计，新媒体编辑，移动端研发，小程序研发，后台研发，运营等岗位。所以，做好流程控制，你就需要对每个岗位做好工作安排，包含工作内容，进度安排，交付目标，质量管控，工作的'饱和度（包含工作任务，学习任务等）等。

一个良好的，伸展性强的流程控制，在应对紧急突发事件时，才能较为自如的应对。

2、 8人团的管理策略

8个人的小团队，算是一个完整产品线的最小作战单元。

管理这样的团队，对于管理者来说，相比压力与挑战，对自身能力的锻炼反而是难得的机会。

管理这样的团队，笔者总结的策略如下：

少决策：作为管理者，也就是决策者，在这样的团队里，少做决策不是说减少决策更不是不做决策，而是要珍视自己每一次决策的机会，尽量保障决策出，必有顺利的执行和良好的结果反馈。少做大决策，多做小决策：做大决策需要考虑更多，更长远，耗费的时间和人力也更多，承担的责任和风险也更大，所以，大决策要精简；做小决策，讲究高效和短期成效，因为小的决策基本都是对工作进程的小调整（临时任务等），讲究迅速响应，快速见效果。每天一小结，每周一大结：团队管理中，团队工作总结和个人工作总结是非常有必要的。团队成员每天工作前，做个人晨会总结，目的是成员清晰对过去工作的反思和对当天新工作的安排，管理者也能清晰知道成员的工作进展和个人对工作进度的把控情况；每周一次周总结，团队一周的工作进展和下一周的计划与安排；这样能够从较紧凑的，让每个成员和管理者都能清楚工作的内容和进展。不定期团建：团建很有必要，既能增进成员间的感情，也能让繁忙工作中的团队短暂的抽离出来，适当放松。保障张弛有度，团队才能维持长期的战斗力。项目管理：一个8人的完整产品线团队，有必要进行项目管理，不管是通过微软系的软件进行管理，还是通过一些现成的第三方项目管理软件进行管理，目的都是通过将工作任务按照到人到事到天/时的方式进行有记录可追溯的管控。

三、当前阶段：15人团队

笔者当前阶段的团队管理，管理人数15人，可以说是企业内部小型团队的高配版了，公司总人数500+。

严格来说是12人，因为其中3人是临时征调进来的。

这次团队管理15人，横跨三条产品线，人员分配为：4人、5人、6人。

对我来说，多产品线的管理，比单产品线管理复杂许多，加上团队人数也达到了15人，真的是不小的挑战，当然更是一次不错的机会。

在这里，很感激信任我的CTO，感激支持我工作的各部门领导，感激各位技术组长对我工作的支持。

在这个团队里，因为有了之前积累的一些管理经验，所以我在这种跨多条产品线的团队管理中也算是有所凭仗。

1、 项目管理的重要性

笔者认为多产品线的管理，项目管理最重要，当然这只是个人看法和感受。

项目管理对每个阶段的团队管理都很重要，但在跨产品线的团队管理中，我认为项目管理是比其它更重要的关键环节。

在单条产品线的时候，因为团队都集中在同一个目标中，所以项目管理内容相对清晰，可以简单的描述为：单线管理。

然而多产品线的管理，项目管理涉及多个项目团队，对于这样的多线管理，项目管理相对复杂些，对于进度、风险的把控则显得尤为重要。

2、 15人团的管理策略

15个人的团队，算是一个高配版的多线作战团队。管理这样的跨产品线团队，压力不小，对各方面能力的提升也很大。

管理这样的团队，笔者总结的策略如下：

学会放权：多线管理，一定要在每一条线发展一个分线负责人，让其协助管理分线工作，和他们成为朋友，让彼此都认可对方的能力，共同推进各产品线工作。定期跟进：跟进每条线的任务和进度，项目管理软件的使用，能够极大程度的帮助管理者进行项目管理。管理组总结：管理者们（多线管理者和分线管理者），定期开会总结，总结工作中的问题，成员的情况等。全员总结：定期全员总结，重点关注团队一线成员对于自身工作的认识，和思考，以及可能存在的问题。定期分享：分享内容包括技术分享，产品建设思路分享，成员日常心得和体会等。不定期团建：团建很有必要，既能增进成员间的感情，也能让繁忙工作中的团队短暂的抽离出来，适当放松。保障张弛有度，团队才能维持长期的战斗力。

四、总结

笔者分三个部分介绍了自身在三个阶段，三种体量的团队中，担当管理者的经验，仅做交流用，没有高大上的理论或套路，只是笔者实际的体会和经验。