如何带领一个多项目的团队（上）

如何带领一个多项目的团队，笔者想从氛围搭建、工作安排、人员培养以及业余沟通四方面去分享一下心得体会。

前两天笔者和老同学相聚时，老同学问及笔者最近是不是很闲，怎么有时间每周都会发表一篇公众号文章？其实不然，目前笔者所带领的团队涉及的项目越来越多，由于慢慢地摸索出了一些关于带领团队的心得体会，很多以前笔者亲自处理的事情，现在可以渐渐地交托于团队的小伙伴去处理，再加上每天平均6点半起床去学习和思考的习惯养成，所以可以保持每周一篇公众号文章的分享。

笔者记得当初是2017年底进入的这个团队，只有5个人，当时主要的事情就是围绕一个精准投放平台的建设，靠着大家的齐心协力，一次次地创造奇迹，项目亦越来越多，目前规模已经拓展至30+人。如果还像小团队管理的模式，那么事必会造成团队的不健康运转，如何带领一个多项目的团队，笔者想从氛围搭建、工作安排、人员培养以及业余沟通四方面去分享一下心得体会。

一、氛围搭建

就像培养小孩一样，如果小孩在一个充满爱的家庭里长大，那么这个小孩长大肯定会很善良。一个团队的氛围同样如此，它决定了这个团队以及团队里的人到底能走多远。笔者认为氛围主要包含如下4个方面：

1. 积极性

虽说是在为公司打工，但其实也是为自己打工，各个行业目前都是优胜劣汰的状态，如果不趁着现在升值自己，那么只会让自己越来越不值钱。离开学校2年多了，笔者认为观测一个人的价值主要看的是碰到问题如何去解决的能力，碰到事情不要怂，要积极地去思考如何解决、下一次如何更好地解决。

所以笔者一再地和团队内部的单项经理（团队内部的一种组织架构模式，后面会着重介绍）强调，无论事情有多困难，我们不能抱怨，要乐观，要淡定，一起想办法去解决，一定要保证团队内不要存在消极的因素，这个东西就像是瘟疫，本身每个人平时工作就很忙很累，免疫力就很差，如果被感染就很严重。

2. 责任心

一件大事的诞生，必定不是一个人的行为，而是一个团队的行为。一个很大的目标是靠着团队成员的分工和相互配合完成的，如果缺乏责任心，分派的任务没有按时完成或是低质量地完成，那么整体的进度或是质量就会造成影响。人是靠项目养的，既然项目影响了，那么后果可想而知。所以在分配任务的时候，笔者会重点强调该件事情的重要性，以及如果黄了的后果。

3. 目标感

没有目标就没有方向，人就会迷茫、会累。就像Teradata公司的目标是帮助各种规模的企业获得崭新的数据洞察力，并将获得的更全面的业务智能转化为决策和行动能力，最终帮助企业在大数据时代的竞争中脱颖而出。

更近一步，笔者团队的目标是挖掘运营商数据的价值并对外变现。再近一步，笔者的目标是打造出一支高价值的团队，这里面的价值包含产品的营收和影响力，人员的能力和素质。所以，当有新的团队成员加入时，笔者首先跟ta们说的就是公司的目标以及团队的目标，然后让ta们思考自己的目标并时常总结。

4. 归属感

无论走到哪里，不要忘了自己的根在哪里。当有同样的目标时，大家才会为之一起努力，革命友谊才会产生。同时要尽可能地结合各自成员的目标以及需求，让ta们能够迅速成长。另外笔者也会经常和团队成员聊一聊各自所做事情的价值所在，要对自己所做的事情有认同感才会有价值感，才会有归属感。

二、工作安排

项目的稳定运转主要是靠工作的合理安排，笔者这里主要分享以下3个方面：

1. 组织划分

伴随着团队项目的日益增多，需要将人员进行划分，在这里笔者采取的是纵向管理+横向支撑+专家委员会的方式。所谓的纵向管理是按照产品将常驻的人员进行合并形成单项，例如开发、数据准备的人员，每个单项设置一位单项经理，针对单项经理的人选，在保证技术专业能力的基础上，要有一定的沟通能力、责任心以及抗压能力。同时在角色落定之后，要给予充分的信任和尊重，要相信ta能把对应的单项管理好。

日常的产品规划、需求分析以及实施要与之沟通，千万不能单纯把ta当做一个功能的实施者和跟踪者，否则ta不清楚需求的背景以及最终要达到的程度，会造成做的辛苦同时交付的产物与需求方期望偏差较大。

另外笔者觉得适当的时候要针对单项经理进行施压，千万不要试图把所有事情都安排好，这样只会造成ta的惰性，一碰到问题就找你沟通拿主意，要适当地进行施压，碰到需要拿主意的时候考虑清楚相关人的立场，找出采取某种方式的理由，说服自己说服ta人即可，如果需要决策，制定出可选方案后方可去沟通。

所谓的横向支撑是指一些支撑各个产品的公共人员，例如文案、UI等。由于是公共资源，难免会碰到各个单项集体式需要或集体式不需要的时候，所以其中的优先级、处理方式以及时间安排需要笔者去协调处理。

一般而言，笔者处理该类问题的方式是先让相应的横向支撑人员评估相关需求的投入人天，然后分发至各个单项，各单项拟定相应的时间计划，这时候单项冲突的时间区间将会减少，如果仍然存在冲突，那么则根据相应需求的背景、面向对象以及优先级进行处理方式的抉择。

一般而言，有些需求完全不需要横向支撑即可解决，例如某些海报的制作，网上有大批量的模板或是同类产品的海报皆可以参考，简单地进行修改即可。

所谓的专家委员会即是指团队中的资深专家组织成立的虚拟小组，为什么称之为虚拟小组，因为其中的专家日常工作过程中需要担任相关的单项经理或是横向支撑人员，只是在特定的时候需要站出来解决技术难点、研究新技术、人员规范的监督等，这对于整个团队的实力展示、能力提升以及专业强化均起到关键性作用。

2. 会议召开

笔者前前后后参加或组织会议不计其数，其中笔者认为会议主要分为如下两大类，一是周期性会议，例如日常的周会、月会、以及需求评审会，二是临时会议，例如项目启动会、总结性会议以及决策会。因为项目性质存在或多或少的差异，笔者这里不详细阐述各个会议的具体方式，只是针对需要注意的事项进行简述。

（1）周/月会，建议各单项单独召开，从而节省大家的时间

各单项经理可以在周结束日或月结束日将本周期内工作完成内容以及下一个周期的计划梳理成文字，同时注意文字的措词，建议如下，为达到XX目的，完成XX功能开发，包含XX，当前的效果是XX，后续围绕XX继续深入。同时注意文字需要简练，不要出现“了”、“然后”等口语性文字。

可以在下一周期的开始召集各单项进行会议的沟通，一般情况下，笔者会单独找各个单项经理进行沟通，主要就上一周期完成的内容以及本周期需要完成的内容进行沟通确认，同时会针对各单项涉及的产品规划以及人员的安排和稳定性上进行沟通。

（2）需求评审会，一定要定一个固定的时间

需求评审会作为需求确认的正式会议，由于参与人员包含产品、运营、以及开发，所以务必要保持会议的高效性。笔者一般是每周三下午固定的三点进行召开，一定要注意该时间如果没有意外的事情一定要固定。正因为时间是固定的，所以相关人员会养成提前准备的习惯。

同时在这里需要注意的是，产品在该会议是核心人物，所以相关的需求分析一定要准备充分，不要把运营的简要需求描述直接当成需求分析的结果给到开发，如果是简单的需求，可以通过文字进行描述，例如在运营视图一级菜单中增加活动跟踪报表，报表字段包含XX、XX…一定要将每一个字段罗列出来，如果可行，相关有疑问的字段还需要口径的备注，如果是比较复杂的需求，建议利用原型设计工具进行设计。

另外，由于各方日常工作都比较紧，所以此次会议开发需要把握好机会，一定要将需求确认清楚，因为事后产品也需要进行新增需求的分析。

由于篇幅有限，以上为笔者分享的如何带领一个多项目团队心得体会的上篇，主要包含氛围的搭建以及工作安排中的组织划分和周期性会议召开的注意事项，下篇将会分享工作安排中的临时性会议召开的注意事项、任务安排以及人员培养和业余沟通等心得体会。