同程艺龙张海龙：从技术走向管理，该如何解决团队管理中面临的挑战
11 月 18 日，TGO 鲲鹏会邀请顶尖的科技领导者走进苏州，为苏州科技社区带来了全新体验的圈层交流。Bespin 高级研发总监刘宇、同程艺龙技术委员会主任 & TGO 鲲鹏会荣誉导师张海龙、PingCAP 联合创始人兼 CTO & TGO 鲲鹏会会员黄东旭，三位大咖在现场分别为大家带了不同方向的内容分享，全方位满足科技人的需求。
现场授予张海龙老师 TGO 鲲鹏会荣誉导师证书
期间，张海龙先生为大家分享「从创始人角度看大型研发团队的建设」，以自身经历分享干货经验，并为大家答疑解惑。以下内容根据现场分享进行整理，有部分删减：
三年前，我也不记得当时是谁给我介绍的 TGO 鲲鹏会，当时虽然晓波（同程艺龙机票事业群 CTO & TGO 鲲鹏会苏州分会会长王晓波）加入同程的时间不长，但是我觉得他还挺有潜力的，就让他加入 TGO 鲲鹏会试试看。
因为我觉得平时除了需要自己埋头去学之外，很多时候也需要与其他人交流。因为在公司，更多时候是需要外部的资源，如果自己没有经验，只能在与有经验的人沟通交流时得到一些答案。所以很多时候你都需要借助一些外部的力量，这样才更有利于你在内部声音的传播，所以我希望今天的分享能给大家带来一个新收获。
张海龙老师现场分享
当技术人一旦面临创业后就会发现，原来不止会写代码就可以了。当你忙不过来时，就需要更多人一起写代码，这时候必然会涉及到管人的问题。那么这时，你需要面对的是，从管理自己到管理同事，最后到管理干部的过程。
在这个过程中，站在技术人员的角度，并结合我多年的心得来说，不能过于注重管。比如，一个员工不太能接受控制，与其花很多时间去与他沟通，还不如花更多的时间去找一个适合团队的人。
所以，不要太在意一定要把一个人管好，当他需要去管的时候就已经有问题了。
很多人都曾说过，我觉得现在管十几二十个人都挺辛苦的，那如果要管上千个人时是不是十分困难？
其实完全不是的。当你的团队变成 500 人甚至 2000 人时，你会发现其实比 10 个人好管多了。因为团队人数为 10 人时，他一旦有变动，这个坑就没有人去填了，但是 2000 个人的时候你走 10 个人都不会有太大的问题。
所以大家也不用太担心说，将来真的有机会去管 500 人时，自己做不到。不会的，因为这是一个自然发展的过程，所以大家不用担心这是一件听起来很可怕或者很难的事情。
大团队在一定程度上比小团队更好管理，这是我个人的切身感受。我觉得在整个带团队过程中，最难的阶段其实是在几十个人的阶段，因为这时你能动用的资源十分有限。但是现在当你手里有几百人，甚至上千人团队时，会发现你可以动用的资源十分充足，如果发现一个小漏洞，你可以马上调动资源去弥补。
但是大团队和小团队确实有不一样的地方，那么究竟有哪些不一样的地方呢？可能对于很多创业团队来说，这是一个比较难定义的东西，那么大家可以从两点出发：
1、要匹配公司的能力和需求
2、可以适度超前，但不要滞后
在我们这么多年发展过程中，我们也犯过不少错误。其中我影响比较深的是，我们当时在拿到投资后，团队拼命的扩张。
我们在 2011 年的时候拿到了上亿元腾讯的投资，因为过去拿到都是一两千万，觉得好像在互联网做个推广就没了，也不敢再去研发或者其他地方去花那么多钱。但是突然拿到上亿元的时候，你就觉得自己能做任何事情，觉得市场好像全是你的。不管是什么团队，我们就开始拼命扩张。结果变成，上半年拼命招人，年底就开始谈话裁员。因为你会发现，招了这么多人不知道他明年能干什么，或者说你需要他做什么。
假设你现在是一个团队的主要技术负责人，首先，你需要知道公司愿意在这上面花多少钱；其次，如果是初创型公司，至少得知道公司明年还能不能发展下去，员工将在明年做些什么事情。我想，这是作为一个技术负责人你心里必须知道的底。最后，再思考公司需要什么样的人，这个人你需要花多少钱聘请他。
所以我想，我们作为一个技术管理者不管你现在处于多大的规模，不管你是在于 CEO 交流，还是与公司在看精英会，你肯定需要知道接下来至少一两年，我们的主要技术方向和我们可能面临的流量，以及可能面临的业务量是多大。这个时候你需要为这些去做储备，不仅是人员数量上的储备，甚至还包括技术上的储备，你需要考虑哪些核心人员能解决这些问题。
那么如何确定团队规模，可能没有一个标准的概念，但是一定是与你团队规模相关的。
技术负责人是需要与公司沟通，团队扩张、设备投入等问题，这对他们来说是一个很大的挑战。因为是你在问公司要钱，公司会思考该不该给研发批这么多钱。那么这时候我们该如何去向公司证明，你的团队需要这笔费用呢？
第一，拿同行研发投入来与公司做对比。比如，参考同类公司的营收，再对比他们对于研发的投入，虽然不是很精确，但是也是一个大体的比例。不敢说和它是一模一样的，但因为你仍然处于一个积累的阶段，所以你前期的占比应该比它更高。
第二个，当团队扩大后，决定团队结构也会降低难度，这时可以参考业务线的数量决定研发部门的数量。当团队越大时，公司也会考虑扩大对其的投入。
目前仍有不少公司的研发都放在一个团队里，统一称为研发中心。那么会面临一个很大的问题，所有的业务部门都会盯着需求什么时候完成，什么时候能够有足够的开发能力去完成需求。
这时，其实我们的研发负责人就被变得很被动。除了经常被人说系统不够稳定之外，还被追着说需求为什么总是做不出来。那么在公司里就会出现两种声音：
第一种声音，解决研发中心人员不充足问题，配上 HR 给你专门招人，业务部门决定人员数量；
第二种声音，业务部门设立研发部门，需要多少招多少。
说实话，这种挑战如果是放在一个部门里面，所有的压力都是一个人扛。但是如果分掉呢？那么可能你就能把这个锅甩出去了。事实上，甩出去的也是你的权利，因为你本来管 300 个人，突然说 300 个人分成三个部门，进了三个业务部门去了，你突然发现你也没什么可做了。我们在几年之前纠结过这个事情，如果这样分下去的话你的研发就不需要存在了。那么这时候该如何处理研发团队的结构呢？
按照业务条线来划分。
这其实可能没有一个明确的概念。
第一，拆。
关于研发团队拆分的问题，我跟腾讯、携程都交流过，我问他们遇到这种问题是怎么办呢？
他们的回答是，我们早就拆完了，拆分完之后，公司可以考虑让他们负责一些基础性的研发和组建了。
第二，根据部门业务决定。
我记得晓波当时来的时间不久，我们去北京 360 也交流过，到底我们这些轮子是每个部门自己做好，还是我们拿一个部门出来专门做呢？最后人家给我们答案是，不确定，根据业务进行划分，有有些是自己做的，有些是统一拿出来的做。
听完后，我们心里也踏实了。觉得这个问题没有一个绝对的答案，只是需要根据公司的不同阶段里面去做。
所以我们回来后，我们就把大团队逐步的给拆了，并设定了拆分的标准。大概在 300 个人左右时，团队基本都能够自成一体了，他们有各自团队的考核标准，那么这时候我把它交给业务部门，我是放心的。但是公共基础组建的部门，我们仍然放在同一做，这样更有利于减少研发的重复投入。
当团队人多了后，必然会形成一个层级，会出现小干部、中层干部，这在公司里面这是很难避免的，它必然会发展成这样一个传统的管理架构。
但事实上，我们真正在做事情时候，我的建议还是希望大家尽可能扁平化。因为如果当团队足够大时，你只管小部分人，那么你有很多声音会听不到，所以应该尽可能的扁平化。
所谓的扁平化是，上下的信息不要简单的通过一层层往上传，我们可以通过某些途径能够直接传递相关信息。
业务衔接也是十分重要的，你需要明白团队是划分给了业务团队，还是放在了自己手里。
举个例子，前段时间做信息化，财务部门提了很多要求，研发也很辛苦做了很多功能，但是最后财务部门不满意，研发的同学也一肚子苦水，都是财务部门让研发研发同学做的东西，但做出来了后，财务的同学又觉得不好用。那么这个问题到底出在谁身上呢？
其实谁都没有问题，但谁都有问题。因为提出这个需求的人是财务部门，他们认为反正是财务类需求，那么我提的当然是合理、专业的。最后我们真正找到一个专业的财务信息化的时候发现，过来以后发现财务提的需求根本就不专业，而且很零碎。
我们会发现，业务和研发对接大部分是这样的。一个经验丰富的开发被一个刚工作几年的产品经理指挥。产品经理认为，这个东西应该这么做，但是研发会觉得这么做会有问题，也不明白为什么要这么做。而产品经理就觉得，我说你怎么做，你就应该怎么做。所以很多时候产品和开发会有矛盾，它大多数时候就是出现在这个问题上。后来我们也在内部反思，如何解决需求变现的问题，不仅能变现，还要变得好。
现场来宾认真听张海龙老师分享
10 个人时，所有人都在眼皮底下你看得见的，这时我们更多只需要东西做出来就可以了，不用太多的去做一些管理。
举个例子，当你是一个刚刚起步的团队，这时你需要的东西都是自己去做。但是当团队变成 100 人时，你发现当时写的东西不好用了，你就很难受，忍不住想自己动手去做，但是你再想去做时，你是心有余而力不足的。
那么这时候你就必须逼着自己，把从自己做的事变成团队的事，克服自己心里想要做事的冲动，你必须要放下一些事情。
也就是小团队，大约分为中层干部、基层干部等等。
如果当团队达到 100 人时，你仍是团队负责人，那么你需要认真思考这个问题了，因为你并没有真正了解这 100 人到底能发挥多大的作用。
可能你会考虑选一些技术特别好的人来做干部，因为他技术好有影响力，他说话别人能听。如果我选一个很能讲的，但技术很差，那么在团队里同事肯定不信任他。所以你必然要牺牲一些好的开发人员然后让他来做干部，这个是你必须要做的一件事情。
以前经常有人质疑我，我从你们部门经过，看你们不少人电脑 QQ 开着。他在质疑我、质疑团队，用上班来在聊 QQ。因为那个时候我们还处于很传统的想法，觉得一个人上班 8 小时不把代码写满能叫正常上班吗？但我相信今天仍然有团队会有这种观念。但事实上，凭借我这么多年的经验来谈，我有一个很深的心得体会，对于不管是团队的考核还是目标的考核，我觉得都比时间管理更重要。
我觉得我们应该关注于，第一，你有没有制定目标；第二，定期之后目标完成的质量如何。对于团队来讲，目标管理如果做得好，更有利于项目效果的达成。
当你人多时，你必然要把一些重复的事情拿出来，交给专门的团队来做，不可能让每一个人都去自己做一套。
我们在 100 个人时，对于所谓人员能力的评定，很多时候就是凭感觉或者说凭资力。事实上当你到 100 个人的时候我认为应该要有能力模型的建立，这样更有利于去评价一个同事，实际上是一个什么样的能力水平。
当你团队跨过 100 个人的时候我觉得已经没有什么本质差别了，接下来其实一个复制的过程。当时我们团队超过 100 个人时，我觉得很快就能达到 300 人了，因为 100 个人我们刚从市区搬到园区，那个时候才 100 个人多一点点，但是我们变成 300 人的时候我印象里好像一年就完成的，也不知道怎么完成的，什么人都招进来了，然后就变成 300 人了，它会很快。
我以前在带团队时，并没有这个意识。只觉得团队不断扩张就可以了，人越多，我就越厉害，后来发现根本不是这么回事。当别人问你，你团队到底是一个什么样的团队？我说不出来。后来我想明白了，应该从两点出发：
第一，目标。你得制定一个团队目标，在行业里面不敢说我对标 BAT，但是在我们同类型的或者说在同行业里面我们应该处于一个什么水平。
第二个，文化、氛围。你这个团队大体形成的形成一个什么氛围这很重要，不能说反正人多了各有各的说法那也不对，对于研发来讲也是有要一定的团队文化。
曾经我也没有过分重视招聘，其中可能也与我们之前招人能力不高有关系。当时我认为只要找几个面试官去面试，适合的就招进来用就可以了。
但后来发现，其实招聘非常重要。如果你招聘这一关没有把握好的话，那么当很多人进来之后，你就会发现后续容易出现很多问题，这时候你再去处理是非常困难的。
所以，我们对于招聘的主管和面试官，不能随便应付了事，应该设置一个专门的团队负责。
当你认为一个人并不是太适合这个岗位，有点犹豫的时候，以我自身的建议是你不能犹豫。时间越长，处理起来越困难。所以我建议大家一定要重在评估和果断。觉得合适就用，不合适就不用。
如果你能重视员工兴趣的发挥，那么对于公司的发展是很有好处的。
当你选择要用他时，就要学会尊重和信任，如果你让他做，你又对他指手画脚，那么对员工来说是一件非常难过的事，如果你真的觉得他不合适，宁可你把他换了，也不能让他在那儿，然后你不停地去指挥他，让他变成你的执行者。
我认为很多人在能力和考核上有些误解。在评判员工能力时，应该将同等级员工相比，而不是拿等级高的员工与等级低的员工相比。
稳定，这是一个很难的事情。我记得在很多年前，我面对每一个要离开公司的人都觉得很痛苦，都要去和他聊一聊，并尝试性挽留，虽然最后还是走了。后来随着公司员工越来越多时，我发现这个压力会变得越来越小，开始关注为什么员工会不稳定。
第一，员工与上司相处不融洽。很多时候，员工的离开与他的直接上司有很大的关系，有时候甚至不一定和公司有关系。
第二，员工个人发展。举个例子，我们团队有很多不错的人，但是之后和我说去 BAT 公司发展了。那这个时候，我也只能祝福他们能去更好的平台。
所以，我们只能说让人员尽可能地稳定下来，不可能保证人员永远都不流动。并且，人员过于稳定也不是一件好事情，不流动反而会使整个团队缺乏新鲜的血液。
公司文化也是整个技术团队要做的，但是技术团队也应该有一些团队特色，其中团队负责人会直接影响了整个团队的基因。
我相信对于研发的同学来说，还是比较喜欢简单开放的团队，肯定不喜欢去讨好领导。所以我想，如果你能够把团队氛围营造好，那么在一定程度上能让你的团队更加稳定。
既然我们是做技术的，那么技术肯定是其中的一个重要指标。
给大家举一个实际案例，11 年时，我们招了很多人，年底面临着减人的痛苦。一开始，我们是通过 HR 和员工谈，但是谈了之后，同事觉得不满意，说一定要见我，问我为什么对他不满意。其实我也很为难，因为如果你要把这个人给裁掉，那么你得给他举出案例、列出数据，告诉他有哪些方面做得不够好。所以在技术团队里，最起码应该用数据说话。
让所有人进行 PK，能很直观的发现自己与他人的不足，那么就能很自然地知道，自己该朝哪个方向去努力。这个方式是非常好的，能为团队提供一个相对良性的竞争环境。
举办一些类似马拉松的活动。
研发团队其实是最容易进行创新的，所以推动创新在研发团队是非常合适的。
多与其他人学习，这是非常重要的。
张海龙老师现场分享场景
那么我们再回到团队变大的话题，团队从过去的 10 个人，变成现在的 100 个人，甚至 1000 个人时，很多声音你已经听不到了，那么你如何了解这个团队情况呢？又该如何处理呢？
政委体系指的是，HR 不仅仅负责简单的招聘工作，实际上更多的是对团队人员情况的摸底和调查。
采用匿名的调查方式去收集同事对于上级领导的评价，方便政委去针对性去看干部的问题。
我们会邀请在公司长期任职的同事，或者某一业务的同事，由政委组织同事说出大家对于目前公司发展过程中所遇到的情况和问题。这些是很多同事比较关心，但是他不会主动和你说。
那么如果在自座谈会上，前期做好铺垫后，他会比较愿意去问这些东西。所以通过这样的方式，虽然不能说 100% 能听到，但至少能听到大部分一些团队里可能潜在的一些问题。
刚刚讲了怎么样面对做不完的业务需求，我觉得业务需求肯定永远都没有做完的时候，那么我们应该如何进行安排呢？
这是需要经过比较慎重的评估后，我们才认为它是一个有效的需求，而不是突然想到了就要做。
很多公司会发现，可能花了很长一段时间，甚至加班加点做出来的东西，上线之后竟然没有人用。那么面对这样的情况应该如何处理呢？
我觉得应该通过一个上线评估和数据说话。当项目上线后，如果没有人使用，我们应该反过来看看曾经做过的东西，再倒推到我们业务部门，最后倒推到我们产品人员。在这个过程中去反思工作中有哪些是需要改进的，能力该如何提升。
除了无效需求以外，研发团队最怕的就是，出故障后公司来问责。这个时候其实对于研发人员的压力是很大的，因为他其实也不是有意地犯这个错误。那么我们该怎么办呢？
对标，我们需要引入行业里对于可用性的标准；
指标，决定自身指标可用性；
数据，拥有数据后，故障是允许在设定范围内发生，或者在故障时间内，公司没必要兴师动众，一查到底。
遇到故障时，该有一套相应的流程制度系统匹配，尽可能让同事少犯这些错误。因为在同事进来时，公司也没有规定不能这样做，所以出现问题时应该及时弥补。
在创新活动时，我们制定了一些奖励制度。但是这个奖励你如果是立马分掉，大伙儿一起聚个餐就没了，那么价值就不是特别大。我们会从奖励里拿一部分出来作为处罚备用金。万一哪位同事犯错了，或者出故障了时，这也是需要被罚的。当我们从奖励金里拿出来一部分时，那么同事的压力就会变小很多。
但是我觉得一个人犯错时，他的主观和客观态度很重要。比如他明明具备不犯错的能力，可是他还是犯了这个错误时，那么他应该好好总结和反思的。但是如果是一些突发的意外，或者以我们现有的技术水平是很难去避免的，我们如果非要去追求他的失误是没有太大价值的，这反而使同事之后不敢去做类似的尝试。
还有一个客观性的问题，避免做多错多。在团队里很多时候，有些人因为做得多，就比较容易犯错多，那么这种人我觉得应该是去保护他，而不是去打击他。
当你作为一个研发负责人时，你清楚自己的个人定位吗？
你是整个研发团队在公司的代言人，那么你能为研发团队在公司层面争取多少资源和理解这是很重要的。
你要明确整个公司接下来大的技术方向。假设公司刚起步时是微软体系，那么我们要不要慢慢转为开源体系，虽然转换的过程很辛苦，但是因为它是一个大趋势，辛苦也得做。
虽然你可能是团队里第一个写代码的，第一个维护数据库的，但是你可能不是团队里面最好的。如果你还总是认为自己是最用心、最投入的，那么你只会担负起这个团队，所以你要想清楚自己的未来方向。
在带团队过程中，需要不断地进行自我审视，不断地进行自我提升。如果你仅仅是用心、努力，那是不够的，你需要有很多方法和思考。
最后想要送几句话给大家，希望能对你们有所帮助。
如果你总认为自己是创始人，是公司的老员工，什么事都应该是你做得最好，这个其实是不对的，你要相信团队、相信同事。
这是我一直很认可的一句话。很多时候，同事出现问题时，我们第一反应会找到责任人，但实际上当你真正去反应时，你会发现同事的问题，实际上是自己的问题。
我想对于大部分管理人来说，如果你真正想做一个同事认可的干部，那么你还是需要有一些自我担当力。
当我和几个同程创始人聊时会谈起，我在管委会办事时，通常会很顺利，很多人都会认可我。他们是这么回复我的，你目前所得到的待遇，都是看在同程的面子，而不是看在你的面子。所以我想，不管是人还是平台，其实是一个相互成就的过程，很多时候人很容易就被平台的光环所迷惑了，所以希望大家不要被平台的光环迷惑了，要清楚自己真正是个什么样的人。
现场嘉宾集体照
点击下方图片即可阅读
从 Google 看技术公司成熟到死亡的八个阶段
你想与同程艺龙技术委员会主任 & TGO 鲲鹏会荣誉导师张海龙一起学习交流吗？