高绩效研发团队领导者的视野和格局

辍笔数月，期间曾蠢蠢欲动好几次，但每每拔剑四顾，又心生茫然。想总结的、想表达的内容，有点过于宏大，即便这些东西都是顺哥半年来不断思考着的事情。明人不说暗话，不卖关子了，这件事情就是：如何打造一个高绩效的研发队伍。

是不是有点眼熟？没错，很多招聘 CTO、研发副总裁、研发经理的岗位要求中都包含着这些格外亮眼的描述。不同人对这句话会有不同的解读，比如有些领导所谓的高绩效就是团队是否在加班干活，另外一些人则对这种解读嗤之以鼻。而顺哥我太老实，才愿意认真地去思考这个问题，毕竟自己长不出一张会忽悠的嘴，又想搬砖后能多换袋米回家，必须习惯于在暗淡无光的角落里苦苦思索和实践，从而能够实打实地为公司创造业绩，进而实现财富上的高回报。

坦白说，本人目前所带领的团队，并没有完全达到我眼中的高绩效团队，只能说是在前往高绩效的路上，如果说我们团队目前表现得还算不错的话，借用郭德纲的说法就是：那还不是因为有同行们的衬托。

尽管如此，顺哥还是斗胆来聊聊这个话题，毕竟也代表了本人一段时间以来的总结和思考，如果能够给各位读者哪怕是很微小的启迪，这篇文章就算没白写。

所谓“一将无能，累死三军”，高绩效团队首先要有一个合格甚至优秀的领导者，而这样的领导者又需要具备怎样的视野和格局呢？这是顺哥在不断思考并努力的方向。

无论从自己听到看到的还是从国家十四五规划的内容来看，都可认为当前已经进入了数字经济时代，各行各业都在谋求数字化转型。数字化和几十年来的信息化一脉相承，然而却具有不完全相同的内涵。

信息化时代还是以人为主、机器为辅，而数字化时代将是以机器为主、人为辅，这种思路上的改变带来的业务模式的变化是巨大的。除了业务数据化、数据业务化之外，组织的数字化管理也是重中之重。因此，所谓的数字化转型，包含了业务模式和组织管理的数字化转型，是企业作为一个生命体不断进化的过程。关于数字化的理论和实践分享可谓汗牛充栋，然而目前为止顺哥看到的最具实践指导意义的还是陆奇博士关于数字化的分享，即把企业看作生命体，包含感知体系、决策体系、执行体系，并分为细胞、骨骼、血液、局部大脑、完整数字生命体的进化阶段。

在此背景下，洞悉未来一个时期的技术发展趋势以及由此带来的业务模式、商业模式的转变，并知晓如何结合公司现状进行数字化时代的企业顶层架构设计，是数字化时代领导者具备足够视野的最基本表现。虽说数字化转型应是一把手工程，由老板亲自把控，但实际上数字化时代的领导者，具体到各企业，则往往落在了 CTO、研发副总裁等角色身上。

于是，众多没那么合格的 CTO、研发副总裁们，陷入了深深的迷思......

这样吧，先假设数字化领导者具备了一定的视野，与 CEO 进行了充分的交流，从企业战略层面出发进行了企业级顶层架构设计外，还需要具备扎实的技术功底，能够进行企业数字化底座的构建和夯实。数字化底座可以认为是企业的航母，基于这个底座，可以快速地开发出数字化产品，满足不同的业务需求。具体来说，这个底座大概就是企业的 PAAS 层，可以私自搭建，也可以基于公有云搭建。这也要求了相关角色在技术上具有足够的广度，比如能够较为深入地理解云计算、人工智能、区块链等技术的本质和演化方向，以及由此带来的社会影响，明白在公司业务的不同阶段应该采用怎样的技术更有利于达到成本和效能上的平衡。

接下来，如何建立一支高绩效的研发团队，将产品开发、客户服务等后续的工作落到实处，则是更令人头疼的问题。以我目前团队的组织架构为例，我们研发中心分别设有技术部、产品部、客服部，如何让部门内部、部门之间的人员高效地协同工作，按时按质地产出数字化产品以便及时推进和成就业务，是整个研发部门的价值体现。作为领头人，必须具备技术思维、工程思维、产品思维和服务思维，才能带领各个下属部门在正确的方向上发力，为客户创造真正的价值，先让整个团队值钱，赚钱就变成水到渠成的事情。

废话一下，要建立队伍，首先就是招人。多年的职场经验告诉我，很多问题的根源是人才的问题，而人才往往不是培养出来的，是挑选出来的。这也说明了招聘环节的重要性。我在招聘中，应聘者的项目经历是考查的一个方面，另外会比较注重进取心和学习能力、对规范流程的意识和工作习惯。后半部分很难培养，而且当成员不具备进取心和规范意识时，培养对于他们来说可能是一种痛苦，因为大部分人是不愿意蜕变的，更喜欢躺在舒适区，因此他们可能会滋生领导通过折磨让他们自动离职等各种乱七八槽的想法。

对于技术人员，倾向于考查项目经验、搜索和学习能力、对技术的热情；对于产品人员，则倾向于考查沟通协调能力、对产品的深入思考能力、对所要解决之问题边界的界定能力、对产品路线的规划和优先级判断能力、快速了解竞品和行业格局的能力、是否具备开放的心态，以及是否具备同理心从而更能站在用户的角度来思考问题。对所有岗位一视同仁的是工作态度、责任心，这些是能够成事的必要条件。

团队搭建好了，又面临团队管理的问题。这里面包含了团队的目标管理，任务的分解和分派，进度的跟踪和调整，问题的解决和复盘，人员的培养和调动。在顺哥看来，管理就是要消除混乱，因此最重要的是理，把问题和解决方案梳理清楚，然后按规范的流程来实施，才能最终消除混乱。当然在实施的过程中，可以适当地灵活应变，流程并不是死的，而且有必要的情况下，需要优化流程来提高效率，对研发来说一般就是提升 DevOps 反馈环的效率，从而提升迭代速度和交付能力。

在具体某个项目中，产品经理首先进行需求挖掘，撰写需求分析文档，组织开发、测试等相关人员召开需求评审会。需要注意的是，测试人员在需求分析阶段就要介入，而不是等到开发快完成之后才匆忙理解功能需求。在需求分析阶段，经验丰富的测试人员时常能提出自己的见解，对产品流程和功能的必要性提出建议，同时加深对产品功能需求的理解，对后续的质量保障工作大有裨益。

产品经理接着根据产品路线规划进行短期的迭代规划，每个迭代里面包含若干具体的需求项，一般一个迭代对应一个发布版本。相关技术负责人将迭代里面的需求划分为任务(需求和任务是多对多的关系)，设置好起止时间，并分派到相关开发人员。这期间，测试人员进行测试规划，编写测试用例，召集相关人员进行用例评审。

一般来说，研发团队里面开发人员相对较多，涉及到多人同时在某一代码库上进行开发，因此需要合理的代码分支方案。具体比如初级开发人员只能在自己的分支上进行开发，推送到远程仓库后，申请合并到主分支。一般主分支的合并权限只给到模块的负责人，这样初级开发人员不需要自己频繁地去做合并代码的事情，将更多精力放在业务功能开发上，同时也有效地保护了主分支代码的稳定，多人合并代码导致的各种问题被从根本上消灭掉了。因此，分支方案也可以认为是一种管理智慧。

相关功能开发完毕，开发人员将任务状态进行相应修改，并向测试人员提测。测试人员若发现缺陷则提交 bug，并设置相关任务的状态。一个迭代里面的任务都完成后，创建新版本，并关联到迭代、需求和任务，然后发布到预生产环境，测试、产品人员在预生产环境进行验收测试，通过后再发布到生产环境。

在团队成员水平参差不齐的情况下，必须足够重视质量保障工作，也就是要做好质量工程。测试人员除了进行功能、接口测试外，还需要对测试的结果进行统计，也就是对产品进行质量分析，最后可以对产品进行质量倡导，比如根据产品功能的关键性以及 bug 出现率，建议开发团队在某些功能、方向上投入更多精力，而一些无关紧要的东西，则相应降低其优先级，减少投入。

上面是以结果为导向的团队里面关于过程管理的内容。有些人以为，只要挑明了以结果为导向，就完全不用理会过程。这某种程度上是因为他们无法进行过程管理，是在管理上无能的一种表现。也许某些性质的工作确实不太需要过程管理，但对于研发团队来说，几乎是不可行的。如果只看重结果，通过最终的绩效考核来制约员工，而完全不注重过程，99%的情况下，你不会拿到自己想要的结果，而这时候，你只能通过惩罚的方式来淘汰一些人，引进一些新人，然后进入了一个恶性死循环。

研发过程管理中，我们主张管事，而不是管人，并且人往往是管不住的。所谓的管事，也就是将目标分段到各个时间节点，每个阶段设置限期，然后检查节点化。如果直接管人，就会出现这样的情况：

今天预计发布新版本，大家都准备得差不多了，争取在下班前或者加个半小时的班来完成发布，然后小李找到领导，说有什么事情需要到点马上回家，领导这时候也很为难，不批准面子上和道理上都不占优，但批准了的话，团队就因为小李的最后一点事情没弄完而无法发布新版。而如果检查节点化，在发版前一天就跟进小李的进度，让他清楚地知道今天是发布日期，不得拖延，作为领导者，也不想听小李那些真真假假的请假理由。这样的话，小李前两天可能就减少部分摸鱼时间，把任务稍微提前完成，于是当天就能顺利发布了。领导和小李、其它团队成员之间，通过约定的制度和流程协同工作，不仅能够顺利完成任务，还互不干涉业余生活，小李陪女朋友看电影也不需要向领导请假，领导也不需要皱着眉头给小李批假了，这不就其乐融融了嘛。

在过程中不可避免地出现修正目标的需求，这个时候可能需要重新进行小的规划，或者调整事项的优先级，小目标出现拖延的情况及时补救，以便不影响大目标的实现。也只有这样，整个团队才有可能顺利完成大的目标，如果缺少这些过程管理，风险就无法控制在一定的范围内，以结果为导向的管理方式最终也会以失败告终。

以上谈及的内容涉及了领导者的视野和技能、方法论，那格局又是什么呢？

大格局就是通盘考虑的思维模式、放长线钓大鱼而不是饮鸩止渴的做事风格、成就他人顺便成就自己的宽广心胸，一般来说，具有大格局的人也是一个长期主义者。同时，具有大格局的人，都是具有大视野的人，鼠目寸光不可能带来大格局。

有些领导者，为了巩固自己在公司内部的地位，会使用各种各样的小手段，这明显属于小格局。格局大一些的，更多是考虑团队的绩效，考虑团队的成长和自我的成长，将团队和自己放到行业里面去比较，而不是在公司内部斗争。因为很多公司都会倒闭，而成长是属于自己的，别人永远带不走，也是一个人行走江湖安身立命之本，切不可寄托于可能是浮沙筑起的高台之上。

还有些领导者，喜欢下属陪自己加班，即便完全不知道下属在干什么，这就是典型的寻求心理安慰的做法。让我头倍感痛心的是，很多年纪轻轻就走上管理者岗位的人员都具备了这样的鸵鸟心态，不愿意面对现实，选择了一种让自己内心舒适的却会两败俱伤的管理方法。殊不知大部分下属对这样的管理者避之不及，而且上有政策下有对策，当很多下属处于一种舒展不开的工作状态时，最终的成果不太可能让领导者舒服，他们也难以成为让下属尊敬和追随的领导者，当然遇到某些臭味相投的下属也是有可能的，这时候领导者还以为自己管理有方，但只要换一批人或者换一个地方，这些招数可能就失效，因此不能形成比较好的相对普适的方法论。

又有些领导者，不太顾及公司的长远利益，只会迎合老板的要求，这样的研发团队往往会有很多技术债，所谓债务，那一定是要还的，不是这一届领导还，就是下一届领导来还。当然，这事得有一个平衡，有时候确实业务系统上线的要求特别急，这种情况下可以通过一些取巧的方式先满足业务要求，后续再抽出一些时间来改进、重构都是可以的。

以上几种行为，都不是具有大视野、大格局领导者的所作所为，但现实中却有很多。我本人呢，这些年来一直在坚持杜绝那样做，我的做法很多时候也会让更高层领导者感到不解。比如我对对无效加班的憎恶，对劳逸结合的重视，都让我所带领的团队成为行业里面加班偏少的团队，然而整体效率相对还是比较高。从老板的角度来看，几乎没有人喜欢这样的团队，因为在他们看来，一个团队不加班就能有这样的产出，要是再加班，那岂不是效率更高、能为公司做出更大贡献吗？而事实并非如此。我要求团队在约定的时间内完成工作任务，这个期限往往需要他们在上班时段基本全心投入的情况下才能完成，如果完不成，他们自动加一点班，但我不会去管他是否加班。很多老板不明白，研发工作并不完全是体力劳动，举个例子来说，如果是真实搬砖的工作，加班一个小时，可能确实可以多搬 10 块砖，可是软件研发的并不完全像搬砖那么好量化，在精力不足的情况下加班写代码，不仅效率不高，还容易出现各种错误，导致后面返工花费更多的时间。这样带来的结果是，研发人员很疲惫，系统功能很脆弱，大家每天无精打采，并且有些原来上班时间很投入的同事，因为提前知道了会加班，在正常的上班时间内变松懈了，把一些原本可以提前完成的任务留到加班时段来完成。所谓的磨洋工、摸鱼是很难避免的，管理者也没有办法完全限制这样的行为，也就是说人基本上是管不住的，只能管事、管任务。长期的加班还会消磨团队成员的意志，使得团队在某些该加足马力冲刺的阶段也因为一直的疲惫而无法加速。目前行业里面的很多加班，要不是表演给老板看的，要不就是为了赚取加班费，这样的加班能带来多少效率上的提升，是值得怀疑的。

掰扯掰扯了这么久，是时候来个总结了。高绩效研发团队的领导者，无疑需要具备较为扎实的技术功底，较广阔的技术和行业视野，如果能有宽广的心胸和较大的格局，那自然会更好。这样的领导者，类似于军师，需要掌握各种方法论，同时有丰富的行业实践经验，还要略谙心理学、行为学，从战术层面到战略层面，都有着清晰的思路，能为团队指明方向，为公司成就业务。懂得大处着想，小处着手，不仅仅会做目标管理和结果考核，还要深谙过程管理。具有强烈的规范意识，对团队进行成长规划和培训，协同部门内外事项，保证信息沟通的顺畅，使得每一项工作都能高效协同，进而铸造良好的研发文化。规范的制度流程约束那些容易犯错的人，策略性地进行错误防御，提前阻拦掉一些可预知的风险行为，而良好的研发文化，则是让团队成员在可以犯错却不受惩罚的情况下，也就是制度约束机制有漏洞的情况下，也不愿意去犯错误，因为那样的做法和他们所接受到的企业价值观引导和研发文化熏陶不相符。

最后，谨以句老话与诸君共勉：知易行难，行者将至！

欢迎关注“技术人成长”视频号：