说起周会，可能大多数的团队，都在以流水账的形式汇报自己的工作：A做了什么、B做了什么……以此类推。如果有特殊的情况，则简单说一下，具体的方案也要等到会后讨论了。周报也是类似，我们越来越强调周报要“简单”、“简短”，背后也是不希望再以流水账的形式说自己做了什么，久而久之，不仅写的人疲惫，看的人也没什么兴趣在周报上面了，只会复制粘贴一下重点，然后继续发团队周报。

这其实是一个不太好的趋势，那就是团队的工作越来越业务化了，每个人都在从事自己的事情，自然就谈不上团队中的“横向互动”。对于技术团队来说，尤其是做数据的技术团队，如果越来越没有技术的感觉，那么不仅周会周报流于形式，技术人员的成长性和发展性，也很难继续搞下去。

周会和周报的目的，其实在于技术上的协同：技术风险、最新行业情况、CodeReview、干货分享等等。其实如果换个形式，让大家自由讲述工作中的困惑，或者是一些未来发展的探讨，那么气氛可能立刻就不一样了。周会和周报有必要吗？肯定是有的，但不定期的技术分享&自我批评，提醒团队成员改进不合理的地方，营造开诚布公、透明的团队氛围，才是周会周报形式的核心。

关于团队协作

团队协作中，最怕的是“将就”。“将就”对技术团队，尤其是数据技术团队来说，是一种非常不利于成长和发展的事情。很难想象一个没有技术追求的团队，能开发出一个健壮的、可维护性好、可扩展性好的数据模型。久而久之，曾经埋下的坑，都要一个一个填上，团队的发展速度，在泥泞的“坑”中，只会越走越慢。

很多工作是需要跨团队组织的，我们必须要承认这点；但跨团队组织就一定存在不合理的地方，我们同样需要承认这点。对于一线工程师而言，团队协作的难点是最清楚的，必须要鼓励大家提出解决问题的方案，简单写写PRD也好、写一段文字描述也罢，总之要把自己的想法说清楚。大部分情况下，一线工程师如果能说清楚的事情，推广起来也就不那么难了。如果方案合理可落地，那么剩下的工作就需要交给主管去协调，或者是开发资源遇到了瓶颈，也需要主管去协调。如果一堆大头兵在相互协调资源，很难想象这个团队会解决什么实质性的问题。

关于风险管理

最近公司一直在提倡Leader来写代码，虽然评价不一，但确实在某种程度上反映了Leader有些脱离技术的现实。因为很多时候，仅仅协调资源是不够的，能够深入到系统中、深入到技术细节中，带来技术上实实在在改变的Leader，同样非常重要。

风险管理，就立足如此。当前部门的技术栈如何、开发-线上流程有无问题、数据质量监控做的怎么样、出了问题能不能及时定位和查清楚原因？方方面面的情况，非常考验一个Leader的风险意识，以及团队责任心。

什么样的团队是好的团队？有很强凝聚力，目标一致，每个人都有较高积极性投入工作，能够在分工中发挥各自优势和潜力，这就是好的团队。而未雨绸缪、提前识别项目中的技术风险，协调研发资源投入项目，及时消除技术风险，这就是好的风险管理动作。

关于文档撰写

业务做的久了，很多同学就非常排斥写文档了，因为这只会拖慢工作的速度，影响自己的产出，这很现实。小团队可以这样，但人数一旦多了起来，通过口口相传，或者是定期的培训，就已经不足以快速的共享和传播知识了。而在每个项目结束后，及时把工作内容沉淀到文档上，或者是公共平台上，就显得非常有必要。

并不一定说这是强制的工作，只能提倡把文档沉淀的时间也加入到项目排期中。对于管理者，可以随时了解技术和项目的细节，补足宏观思考的漏洞；对于开发者，能够快速了解项目的背景、过程、风险及应对。“一个人很强”，只代表了个人的战斗力；“整个团队很强”，才是真的强。

关于价值观和沟通

阿里总是在各种场合强调价值观，不少人有负面的看法，但价值观的本意，是传达一种“建国理念”。很多非阿里人，来到阿里后，通常会有一种非常不适应的感觉，似乎一件事情，从头到尾，都要自己负责，非常的“不专业”。其实，对于一个公司而言，做大了，内部的管理，就是一定是个不小的问题。对于价值观产生比较负面看法，也是站在行业通识的角度上进行评价，而非深入到企业发展的核心。

价值观的本意，是在传达一种“建国理念”，阿里是一家市场化思路主导的公司，而非计划经济主导。在对内的管理上，提倡员工激发主观能动性，通过个人的能力，来寻找更多志同道合的人，来做一些有价值的事情。换句话说，虽然我们在阿里这家大公司里，但我们的部门，本质上仍是一个创业部门，阿里公司本身，就是一个封闭的小市场。

在市场化的创业环境中，沟通、干练，非常重要，所以要以价值观的形式传达下去。

很多工程师被提拔到管理岗后，依然喜欢撸起袖子自己干，而不是指导员工解决问题，其实本质就是给自己留退路：干不好管理，还可以回来做一线工程师。但如果学不会放手，就学不会新的技能：技术前瞻性和技术广度，很快你自己就会成为团队的天花板。有时候“背水一战”是对管理者的最好的鞭策。

关于CR和故障

作为技术团队，代码写的好不好，风格是不是统一了起来，注释是否完整，CR机制是否完善，故障管理是否畅通，直接决定了我们的工作效率。由于很多细节工作交给了一线员工，所以管理者可能没有办法了解每一个技术细节，因此需要经常和员工们进行沟通，指导写代码的风格，但是这里要强调是指导，而不是命令和安排。

CR和故障管理，看起来是孤立的工作，业务压力大的时候，往往成为累赘。但是这个过程不走，就无法真的掌握一线代码的运行情况，给未来的维护，埋下种种多的坑。

|0xFF 管理从来都不是一件比写代码简单的事

是的，管理从来都不是一件比写代码简单的事。

很多人，能力很强，做事也非常棒，但到了晋升的时候，往往被卡住，认为组织对自己不公平。但如果看晋升的规则，大体就是两点：技术能力可以跨部门复用，或者是能够领导部门内的重点项目。再总结一下，就是你要能把自己的能力推广给其他人，而不仅仅是自己强。

把合适的人安排在合适的位置，公司的发展因人成事，“授之以鱼不如授之以渔”。

管理也是一种学问：如何面对负面情绪、如何调动团队氛围、如何指导部门技术发展、如何为部门寻找更多的资源支持…… 归根结底，就是如何带领部门走的更远。就像写代码一样，如果不是从小事一点一滴的积累，如果不是夜夜反思自己刻苦读书，如果不是经常寻找同行交流内心的困扰，如果不是经过实战从而“知行合一”的话，晋升的一点小问题，终会变成职业生涯的大事情。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！

本文笔者基于以往的工作经验，总结出了的团队管理经验，希望能带给正在管理团队或者接受管理的你一些帮助。

1.1前言

团队管理对于公司来说至关重要，它决定了公司是奋勇向前还是一团散沙。然而团队管理并非易事，需要在不断探索中找到适合团队的管理方法。本文笔者基于以往的工作经验，总结出了三个阶段的团队管理经验，希望能带给正在管理团队或者接受管理的你一些帮助。

本篇主要分享笔者在工作中，管理团队时的感悟和踩过的坑，可能没有那么多高大上理论，但是足够接地气!

本篇适合想了解0-20人小团队管理经验的朋友阅读，20人以上的，笔者暂无相关管理经验!

1.2阶段

笔者已有的团队管理经历，可以分为3个阶段：

• 新手阶段：3人团队
• 上一阶段：8人团队
• 当前阶段：15人团队
• 1.3新手阶段：3人团队

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

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

实事求是，当时年纪轻，能够在实习阶段参与管理，主要还是感谢领导提携和信任，感谢后来都当上副总的两位大哥的支持。虽然个人干劲足，能够超质量完成所负责的工作，但是对于工作阶段的团队管理，确实没有什么经验，所用的主要还是在学校管理班级和社团那一套，稍微加上一些从书里读到的一些团队管理的理论，期间踩了很多坑，也有很多感悟，现在回头看来真的能感觉到当时的稚嫩。

思维转变的重要性

刚开始接受管理职能，其实会有些不适应，虽然笔者在校期间已有管理经验，但是工作中确实不太一样。工作上，更讲究能力优势和为人处世。

在接受这个管理职能前，工作中笔者一直都是单枪匹马，做好自己的本职工作，毕竟当时还只是一名实习生，虽然那时候工作能力上已经具备甚至超越了部分毕业一两年的同事，但是整个人都是踏实做好本职工作的心态。这样的心态，导致笔者开始一段时间，都不太适应去管理团队的其它成员(或者说任务分配吧)，认为彼此就是一个小团队，认为大家把事情做好，没有谁安排谁的必要。

但是这样的心态，导致后来的工作出现了一些状况。比如团队里有的成员，一旦工作完成了，没有人安排，就进入闲置状态，或者有的成员(当时另外的那个产品大哥)需求没沟通清楚，确认阶段出现了问题，所以最后领导安排给我解决，我解决过程中，只顾着自己把事情做好，却忘记了作为管理者最重要的一点：就是教会其他人解决问题的能力，这样大家会一起成长，团队的合力才更大，你的领导力和同事向心力才更强，可当时确实没考虑到!(还是太年轻)

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

3人团的管理策略

3个人的小团队，算是一个最小单位的作战小组吧。我当时管理的经验就是：短平快的交流和协作!无论是任务分工，进度规划，工作交流，都一定要缩短交流、协作路径，足够扁平化的管理(除了做决策，平时大家并没有上下级之分)，减少开会，加强快节奏的直接沟通，可保持高效的作战状态!

1.4上一阶段：8人团队

笔者第二阶段的团队管理，管理人数8人。虽然有了第一次团队管理经验，但是严格来说，第一次的团队管理，仅仅是一次“新手村”的锻炼罢了，基本就是靠笔者自己的理解和不断的试错。8人团队的管理，对我来说，是个不小的挑战，也是一次不错的机会。

在这里，很感激信任我的总监(一位气质实力俱佳的职场精英)，感激她对我的认可和信任，感激她对我工作的鼓励与支持!这个8人的小团队，我作为Leader，其他包括一个UI，一个新媒体编辑，一个小程序研发，一个IOS开发，一个Android开发，两个后台，一个运营人员。

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

流程控制的重要性

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

这里讲到的流程控制，指的是对产品流程中每个阶段目标和完成质量的把控，每个端口工作内容的规划和饱和度管控。这样描述，是不是感觉到其实并不简单，而且当中的重要性，应该不言而喻了吧。因为既包含了对产品各阶段的管控，也包含了对团队人员的管理。

作为团队的管理者，你需要对成员负责;作为产品或项目的管理者，你需要对产品或项目负责。在这个8人的小团队中，真正让我感受到了，麻雀虽小，五脏俱全。整个团队，就是一个完整的互联网产品线的研发团队，角色层面，包含了产品，设计，研发，运营;职能层面，包含了设计，新媒体编辑，移动端研发，小程序研发，后台研发，运营等岗位。

所以，做好流程控制，你就需要对每个岗位做好工作安排，包含工作内容，进度安排，交付目标，质量管控，工作的饱和度(包含工作任务，学习任务等)等。

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

8人团的管理策略

8个人的小团队，算是一个完整产品线的最小作战单元。管理这样的团队，对于管理者来说，相比压力与挑战，对自身能力的锻炼反而是难得的机会。管理这样的团队，笔者总结的策略如下：

1、少决策：作为管理者，也就是决策者，在这样的团队里，少做决策不是说减少决策更不是不做决策，而是要珍视自己每一次决策的机会，尽量保障决策出，必有顺利的执行和良好的结果反馈。

2、少做大决策，多做小决策：做大决策需要考虑更多，更长远，耗费的时间和人力也更多，承担的责任和风险也更大，所以，大决策要精简;做小决策，讲究高效和短期成效，因为小的决策基本都是对工作进程的小调整(临时任务等)，讲究迅速响应，快速见效果。

3、每天一小结，每周一大结：团队管理中，团队工作总结和个人工作总结是非常有必要的。团队成员每天工作前，做个人晨会总结，目的是成员清晰对过去工作的反思和对当天新工作的安排，管理者也能清晰知道成员的工作进展和个人对工作进度的把控情况;每周一次周总结，团队一周的工作进展和下一周的计划与安排;这样能够让每个成员和管理者都能清楚工作的内容和进展。

4、不定期团建：团建很有必要，既能增进成员间的感情，也能让繁忙工作中的团队短暂的抽离出来，适当放松。保障张弛有度，团队才能维持长期的战斗力。

5、项目管理：一个8人的完整产品线团队，有必要进行项目管理，不管是通过微软系的软件进行管理，还是通过一些现成的第三方项目管理软件进行管理，目的都是通过将工作任务按照到人到事到天/时的方式进行有记录可追溯的管控。

1.5当前阶段：15人团队

笔者当前阶段的团队管理，管理人数15人，可以说是企业内部小型团队的高配版了。严格来说是12人，因为其中3人是临时征调进来的。这次团队管理15人，横跨三条产品线，人员分配为：4人、5人、6人。对我来说，多产品线的管理，比单产品线管理复杂许多，加上团队人数也达到了15人，真的是不小的挑战，当然更是一次不错的机会。

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

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

项目管理的重要性

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

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

在单条产品线的时候，因为团队都集中在同一个目标中，所以项目管理内容相对清晰，可以简单的描述为：单线管理。然而多产品线的管理，项目管理涉及多个项目团队，对于这样的多线管理，项目管理相对复杂些，对于进度、风险的把控则显得尤为重要。

15人团的管理策略

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

1、学会放权：多线管理，一定要在每一条线发展一个分线负责人，让其协助管理分线工作，和他们成为朋友，让彼此都认可对方的能力，共同推进各产品线工作。

2、定期跟进：跟进每条线的任务和进度，项目管理软件的使用，能够极大程度的帮助管理者进行项目管理。

3、管理组总结：管理者们(多线管理者和分线管理者)，定期开会总结，总结工作中的问题，成员的情况等。

4、全员总结：定期全员总结，重点关注团队一线成员对于自身工作的认识，和思考，以及可能存在的问题。

5、定期分享：分享内容包括技术分享，产品建设思路分享，成员日常心得和体会等。

6、不定期团建：团建很有必要，既能增进成员间的感情，也能让繁忙工作中的团队短暂的抽离出来，适当放松。保障张弛有度，团队才能维持长期的战斗力。

1.6总结

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

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！