作为一名技术管理者，应该如何保持进化？

技术管理似乎是一个永恒的话题，因为它本身就无法用一种标准化的方式去定义，对于技术人来说，实践经验才更具备可参考性。本期《InfoQ 极客有约》，我们邀请到了来自网易智企游戏行业部总经理，网易云商 CTO 尹竞成，关于技术领导力以及如何构建一支高效的研发团队，他有着特别的思考。

本期栏目的对话内容整理如下，供读者参考回顾。

InfoQ：首先请尹老师做一下自我介绍，您的职业经历有哪些？

尹竞成：我 2005 年毕业于浙江大学计算机专业，毕业之后在日本有过两年工作经历，2008 年 11 月加入网易后，一直持续到现在有 14 年时间。虽然一直在网易，但是网易内部业务比较多元，在内部有过几次转岗经历，相当于内部跳槽。

我做过的业务有面向 C 端用户的应用软件，当时主要做企业邮箱的客户端开发；后来转去游戏部门做端游、手游的开发，这为后来做行业线的开发打下了基础。这段工作经历让我对游戏制作流程有所了解，也对游戏制作过程中面临的困难和挑战都有了一些体会。从 2015 年开始转到网易智企来做 ToB 的 SaaS 业务。目前主要负责两方面工作，一方面是网易智企旗下服务营销一体化平台网易云商的研发工作，另一方面是网易智企游戏行业线的拓展工作。

网易智企有三条业务线，分别是网易易盾、网易云信和网易云商，我们有很多行业线的客户，希望以行业线的视角去在客户实际业务场景下做探索，一方面能加深我们自己的产品在客户场景下的适配性，另一方面也希望能够让用户有更加一致的用户体验。这是我目前所负责的一些工作内容。

InfoQ：如果让尹老师划分您自己的工作经历，您会把它分为几个阶段？

尹竞成：我的工作经历主要分为三个阶段。第一个阶段是纯码农阶段，以自己写代码为主，包括业务代码的开发、系统架构的设计和落地、老业务的重构等等，主要是以具体业务开发为主。另外，这个阶段也开始逐渐地有一些简单的管理和协调工作，但是基本上不涉及到人事、考核，也没有组织架构的视角。

第二个阶段，当我开始转到 To B 业务领域，开始负责网易云商的一个完整的技术团队后，工作就变得更加复杂、多元。作为一个业务团队技术负责人，从事情的角度来看，要去做技术栈选型、架构设计、技术演进规划，以及对整个项目的交付周期、交付质量的把控，对线上问题的反馈及沟通等等，这些都要去做处理和跟进。从管理角度来看，需要根据我们业务的特点以及组织发展的阶段，去设计团队的结构，向上去争取资源，比如要招多少个人、不同岗位序列之间的人员配比，以及后面人员的培养、激励、保留等等。To B 业务的价值链相对比较长，因此我们组织内部相应会有很多的平行团队，比如市场团队、销售团队、售前团队、产品团队、售后团队等等，这时候另一个职责就是需要我们做好团队之间的沟通和协作。总之，这个阶段自己需要跟进的事情会特别碎，碎片化很明显。

第三个阶段，是近两年开始负责一些业务，从一个单纯的技术向开始朝业务向发展。这个时候不再纯粹是一个技术人员，开始背业务指标。要考虑的不仅仅是怎么把具体的明确的事情做好，而是要去想清楚整个团队做什么事情的价值会更大。要想清楚我们商业模式的设计，做好产品的规划，更大、更复杂的团队组合的设计。但这个阶段我也才刚刚起步，还是在不断地学习和成长的阶段。

InfoQ：您刚开始接触领导工作的时候，处于一个什么样的状态？有很多一线的技术人员，他的业务能力非常强，但是开始转管理以后，就会遇到各种各样的问题，存在一段阵痛期，您当时有没有遇到过这样的状态？

尹竞成：我自己也有亲身经历和体会。在网易智企内部每年都有管理者的培训沙龙，我在负责其中一节课的授课。课前课后往往会收到很多同学的咨询，他们在刚成为一线管理者的时候其实挺痛苦。原来只需要把自己管好，但是成为管理者之后，责任变得更大，组织对他的要求是管理好整个团队，所以要关注整个团队业务的产出，也要关注每个成员的情绪、状态以及期望，还要关注团队能力的成长。举两个例子，有一种情况是当看到下属工作做得不太好的时候，恨不得自己冲上去自己把事情解决掉，自己干可能效率更高、效果更好；另一种情况是，大部分中基层管理者都是从一线提拔出来的，原来平级的同事变成了下属，这种时候在情绪表达时就会有些困扰，比如在绩效沟通的时候，表扬夸奖很容易，批评的话不好意思说出口了。

如果想快速度过刚开始的阵痛期阶段，我有几点心得体会可以分享给大家：

第一，心里要有预期。阵痛阶段肯定会存在，大家要做好打硬仗、打持久仗的准备。不要把成为一个管理者当作晋升了一个官阶，而是要把管理当成一门学科、成体系化的一门课程。转型肯定需要周期，也必定会有阵痛。前面也有提过，我自己刚开始做管理的时候，工作是非常碎片化的，琐碎且繁重。基层管理确实比较辛苦，大家要调整好自己的心态，认真去面对这件事情。往积极的方面想，这个阶段是非常锻炼人的。

第二，不管是自己直接负责的业务工作效率，还是管理效率，都需要有所提升。我建议把事情分类，分清楚每类工作的优先级，在这个基础上主动去预见未来一个周期内的工作，做好时间的规划和管理，千万不要等着事情找上来被动响应。在向上、向下管理的时候，可以充分利用好各种管理工具，比如 OKR、周报。把很多信息沉淀在工具里面，将来再去回顾、做总结的时候，也会是很好的资料。另外，随着管理幅度变大，我们往往很难关注到每个下属的工作进展，其实也没有必要关注每个下属。有的管理者会把注意力放到效率不高或者能力没那么强的同事身上，但我认为其实可以反过来想，是不是把自己的脑力资源和时间资源投入在看起来不需要你的下属身上，可能会带来更多的投资回报。管理本身就是需要找“高杠杆率”的事情去做。

第三，多沟通、多交流。无论是一线员工，还是管理者，甚至更高 Level 的岗位，当遇到烦恼和苦闷的时候，不要自己憋在心里。沟通的对象包括上级、部门的 HRBP、平行部门的 Team Leader，以及业界的其他更优秀的人士等等，不要把自己闭塞在一个小的圈子里。要走向更大的圈子，收获新的思路。同时沟通本身其实也是缓解压力的一种方式。

InfoQ：领导是向上沟通好还是向下沟通好，您比较认同哪一个？

尹竞成：都很重要。一个优秀的管理者，向上与向下沟通都是工作中很重要的部分和内容，但是更最重要点在于沟通的主动性。我们不能总是等着领导来布置任务，也不能等着下属遇到了问题，然后再来找你沟通。我认为比较好的沟通是有规划、有节奏的，要有设计感。工作需要被动响应时，对既有时间分配和工作安排会有一定冲击，会影响工作的效率。

向上管理和向下管理目的是不一样的，向上管理的目的是去沟通资源、对齐目标；向下管理的目的除了对齐目标之外，可以给下属一些正反馈，也可以及时沟通相对不太好的工作表现，做一些牵引和引导。这两方面不冲突、不矛盾，都很重要。

InfoQ：成为技术领导者以后，您是怎么分配时间的？

尹竞成：我没有固定的时间比例分配，需要根据业务发展阶段以及组织成熟度来定。比如当整个业务在拼命往前冲的时候，我作为团队中的一员，会花很多时间在核心代码的编写，以及架构设计、技术选型上面。当研发团队和工作流程相当稳定下来以后，业务发展到另一个阶段，需要我往前向走，去和客户沟通、和产品沟通，我的精力就会放在另外一方面。

我认为最核心的地方其实自己要想清楚，组织把团队交给你，是希望你能够把团队带出来，你是撬动杠杆的那只手，要找到支点把团队最大的能力和效率发挥出来。至于管理者该做什么事情，与组织发展的阶段以及团队整体的成熟度有关。比如团队里有特别成熟的架构师来辅助你，那么你就不需要在编码或者架构设计上面投入特别多的精力。一个成熟的组织，团队成员能力是多元的，管理者需要充分调动发挥身边每一位同学的能力。

InfoQ：一个刚进入职场的程序员，怎么判断自己是适合走技术管理者路线，还是走架构师路线？您有什么建议吗，您在带团队时有没有观察到什么特征？

尹竞成：刚步入职场其实不用想太多，首先需要先把自己的基本功打好。做为程序员，职业生涯的起步阶段要先在技术深度和广度上有充分的磨练，即使成为了技术管理者技术能力也是非常重要的。团队的高管可能会空降，但是基层管理者和中层管理者往往不会空降，一般都是内部成长提拔出来的，因为这样的人会更加适应组织的文化和土壤。所以一个人想比周围的同事跑得快，必须在技术和业务上有更突出的能力。技术能力不是短时间就能练成的，需要多年的开发实践去积累经验。尤其是现在的技术发展更快，我们需要不断学习才能把握技术方向。所以一开始不要想太多，先把自己的技术做得更扎实一点会比较好。

我觉得管理需要一定的天赋加上后天的锻炼和培养。对于识别自己是否有管理能力，可以先试试自己是不是可以成为一个小模块的 owner，再慢慢变成一个小项目的 owner，再判断自己在沟通、协调、组织等维度上是否有感知，逐步地再向技术管理者去发展。当在这方面崭露头角之后，对一个事情逐步形成自己掌控力，开始对周围的同事有影响力的时候，组织自然而然就会去考察你，给你当管理者的机会。

InfoQ：一名优秀的管理者身上具备怎样的特质，怎么定义优秀？对于一名技术管理者来说，您认为是技术攻坚能力更重要，还是团队管理能力更重要？

尹竞成：想成为一个技术管理者，技术能力一定是非常重要的。互联网行业并没有纯粹的管理者，任何规模的团队，任何级别都需要有直接的产出，而不是只去做好企业管理、组织协调就好了，只是在不同的阶段产出会不一样。比如作为一个技术人员，最初是交付代码完成业务需求的开发，到后来变成架构设计和演进，当成为管理者之后，对团队整体技术和业务方向就要有所把握。

如果成为了一个基层的技术管理者，我认为技术攻坚能力可能是更重要的。但是当成为 CTO、技术一号位之后，管理水平会变得重要起来。管理者就是要不断去寻找高杠杆率的管理活动，并且加速它的完成。对于技术管理者，假设管理着 100 人的研发团队，带领团队制定好目标，做好计划、沟通、反馈，通过各种方式做好团队培训、能力提长、团队激励，帮助整个团队提升效率和成绩，显示要比自己编码带来的价值更大。

综合来看，我认为好的技术总监一定是复合型人才，综合的成熟度是组织成功的关键。在不同的阶段和不同团队配置下，技术和管理有不同的侧重。当成为复杂业务的技术一号位之后，管理能力显得更为重要一点。

InfoQ：现在是不确定性的时代，技术如何去成就业务？和过去相比，疫情当下技术团队承担了不一样的使命和责任，也给技术人员以及技术管理者提出了新的要求，尹老师是否感受到了这样的变化，在疫情之后这样的变化是否更加明显？

尹竞成：第一点也是核心点在于，互联网增速没有原来那么快了，已经过了爆发增长期。第二点在于，现在随着技术的进步、成熟，以及云服务的完善，原来很多业务需要的一些基础能力，现在不需要自己的技术团队去完成，可以去外采或者外包。原来对技术团队的要求往往是做好支撑就好了，比如完成业务需求，或者做好内部系统集成，把 IT 建设做好。现阶段对技术团队的要求在变化，技术团队要去完成外部采购无法完成的事情，推动业务的成功，否则就很难凸显出来团队价值。没有足够没有价值呈现，在现阶段会变成技术人员的生死线。外采的能力用来提升效率、节省成本是可以的，但是用来成就业务肯定是不够的。

我觉得一个好的技术管理者，很重要是要学会像 CEO 一样思考。比如一个业务的 CEO 会考虑，我们处在一个怎样的行业和赛道，客户是谁，客户为什么用我们的产品而不用其他人的，能不能用更少的成本去交付客户的需求，能不能更超前地去交付客户的需求？那么一个优秀的技术管理者也需要考虑这些问题，并沿着这些方向去思考和前进，解决 CEO 的痛点。这里有几个维度：

第一，一个好的技术管理者应该有行业知识，要比产品团队或者运营团队对行业有更深的理解。比如电商，不能只会做电商的业务系统开发，还需要知道仓储物流、供应链，以及电商的运营活动等等各种知识。只有深入了解行业知识和痛点，才能指导我们做好技术工作，并且做好前瞻性技术规划。

第二，要有客户思维。要站在客户的角度去思考问题，理解客户的需求并解决问题；我们的产品要给客户好的使用体验。这也是网易最新文化价值观中所倡导的，要和用户在一起。

第三，要有竞争思维。我们永远都处在竞争的环境。作为技术管理者需要去考虑如何帮助业务建立核心竞争力，如何去保留客户，并尽量提高客户的切换成本。

第四，成本的视角。很多成本在短期内不一定能够得到有效评估，但是从中长期来看，成本结构不仅是商业模式的重要组成部分，也决定了团队成长的天花板。而且研发人员的薪酬在公司里占比较高，合理优化团队结构，保持足够的战斗力和活力，对 CTO 来讲非常重要。

第五，CTO 一定要有创新的思维和视角，包括技术创新、业务创新，也包括组织创新。我们所处的时代变化很快，技术进步也很快，我们要努力去看未来 2-3 年的发展趋势，并提前做好规划。

我觉得一个技术负责人如果不能够像 CEO 一样去思考，他和 CEO 的交流和沟通就一定会存在错位和断档，会引发一些摩擦。

InfoQ：现在有很多新技术，怎样去评估某项新技术是否要引入系统，这很考验管理者的技术决策力。怎样去培养这种技术的决策力，您有什么建议吗？

尹竞成：技术管理者需要根据业务发展阶段、团队能力模型、团队成熟度等方面去看待技术选型，这是一个技术管理者的基本功。具体落地实践，可以小步快跑，我们可以从一些小的业务线、小的场景逐渐地去做探索和实践。通过小规模的发布或者一个小场景的线上用户的真实反馈，来判断业务的价值，这种真实的环境往往会带来比实验室环境更加真实有效的反馈，然后再通过小规模的试对或者试错决定是不是要向更大规模的范围推广。当然这对整个组织能力以及整个技术架构有一定要求，不一定适用于所有业务，但是要有这种思维和意识。

InfoQ：如何去打造一支高效的研发团队，在您理想当中一个高效的研发团队应该是什么样子的？

尹竞成：高效能的本质，是能够以较低的成本，持续地、快速地、高质量地进行交付。比如，随着业务复杂度的提升，随着团队规模的变大，系统的熵会增加，熵增会带来整体效率的降低。我们做的所有治理工作、研发效能提升工作，其实是希望能把熵控制在一个较低的水平。我们需要通过外力把组织的损耗降低。所以一个能够自我观测、持续学习、持续改进的团队，是我想打造的团队。

我们在职业组织的发展过程中一定会遇到各种各样的问题，包括商业环境、组织内外部环境，以及人员变动的问题等等。一个能够随着外部环境去自我升级、自我进化的团队是优秀团队的必要因素。培养和提升团队成员的能力，要比用流程规范去约束他们或者推广效能工具平台的使用更加重要。

InfoQ：您认为大企业或者超大企业与中小企业，在开展研发效能工作时会有什么不同，会侧重哪些关注点？

尹竞成：大企业或者超大企业，一般都会有专门的团队去做效能提升工作；而中小企业通常顾不上效能提升，只要能保证公司运转就可以。其实并没有本质的区别，比如在大厂的创新业务里面，研发效能不是最重要的事情，小步快跑、去验证商业模式的合理性才是最重要的。从落地形态来讲，大企业会更加立体，包括效能工具、效能指标、流程规范、考核体系等等各种方式系统性的优化；而中小公司不一定有工具，自动化能力会少一点，可能会通过流程规范去约束大家把事情做好。大公司团队人员多，每个人的效能即使只提升一点，对整个组织效率提升的收益也会很可观。

InfoQ：回顾您过往的经历，遇到的最大的一个挑战是什么？

尹竞成：举两个例子。我们把研发效能提升看成是一个项目，要有研发投入，需要去向组织争取研发资源和时间资源，需要向老板说清楚这件事的投入以及收益分别有多少。然而刚开始在做的时候很难把收益量化，甚至短期内收益可能是负的，所以资源争取会有些困难。这个时候管理者一定要有决心和魄力。自己要坚信这件事一定是对的，自己有信心时组织和领导才会对你有信心。另外就是信任，如果每次都半途而废或者无功而返，组织对你的不信任程度就会增加。只有不断地攻城略地，为组织带来正向收益，争取资源时也会更容易一些。同时，还可以拿出过往类似项目的成效数据，来佐证我们做这件事的价值。

另外，效能工具或者流程规范推广时也会遇到一些阻力。当然，如果能够争取到 CTO 或者 CEO 的支持，对于推广会带来一些便利，但不能经常利用自上而下的管理强压。任何的岗位和序列都会有工作惯性，他们习惯用原来的方式方法，习惯用原来的工具，在让他们替换成新工具时会有学习成本。用强压可能会起到反作用。需要让大家建立认知，通过一些培训或者小范围内试用，产生了效果之后，再逐步去推广和扩散，效果会更好。

InfoQ：今年在 QCon 全球软件开发大会上，有一个话题是，研发效能和 DevOps 有没有区别，大部分人都选了有区别，只有 4 票投给了没有区别，尹老师您怎么看待这个话题。

尹竞成：我认为这个问题是有相关性的，但是大家给出的答案不一致，应该来自于视角和思考角度的不同。比如偏一线执行的员工，或者负责 DevOps 职能的人，会用工具去对齐自己和上游的交付标准，提高自己的开发效率，提高自己的工作自动化、数字化水平，他会认为 DevOps 做好了，效率就提升了，这当然没错。但如果是以一个技术负责人的视角来看，研发效能的提升应该要更加立体一点，会包括员工能力的提升体系，培训、分享、赋能等，以及效能工具包括 DevOps 或者其他工具的推广和使用，还有度量体系、绩效考核体系等等。在我看来，DevOps 是效能提升工作中的一环，它无法代表全部。

InfoQ：不同的需求之间如何去公平地度量，在度量指标方面，尹老师有哪些经验和看法？

尹竞成：我个人比较反感为了考核而考核，为了度量而度量。只追求数据指标好看，动作一定会变形。我认为还是要回到本质，度量是为了我们能够以更小的成本，去创造更大的价值。所以任何指标的建立都不应该抛开业务发展的阶段以及团队能力的现状，盲目地去设定指标。

指标体系大概可以分为结果指标和过程指标两类，结果指标会看交付周期、需求缺陷密度，我们可以用结果指标来评估团队整体的能力，评估交付效率和交付质量。过程指标会看缺陷的解决率，平均解决时长，以及对一些特殊项目的交付时在各个阶段交付的耗时，我们可以通过过程指标来评估我们流程体系的合理性。有了指标，还需要度量的基线，基线设定很重要。我们可以拿行业中比较优秀数据作为基线，和它进行对比。如果拿不到数据，或者我们已经处于业界比较好的水平，我建议可以和自己做对比。用过去几个季度的平均数据作为基准，每个考核周期做提升，我认为大家应该不会有意见。

InfoQ：对想要提升研发效能的企业，您有什么建议？

尹竞成：第一，不要盲目跟风，其他企业的不一定适合自己。一个优秀的管理者要看清楚内外部的组织环境，团队当前的状况，团队成员的能力，以及当前阶段最重要的事情是什么，找到撬动研发效能提升最重要的点去做提升。第二，不要只着眼于局部的能力，一个好的技术管理者应该有更系统、更宏观地去看待事物的能力，系统性的提升会带来更加平衡、更加综合的收益，也会更具可持续性。第三，平台和工具是冰冷的，但是研发人员是有血有肉有情绪的，他们才是第一生产力，永远也不要忽视一线人员的感受，不要去强压指标或者强推东西，要站在大家的角度去看，可以集思广益，也可以和大家去做一些共创，充分发挥大家的创造力。

InfoQ：技术团队的年度规划应该怎么做？

尹竞成：以业务团队为例，有几个考核的维度：第一个维度，要以业务发展的视角去考虑问题，帮助业务得到更好的业务结果是最重要的。所以在业务规划中，需要充分体现如何去绑定业务结果，能够帮助业务更快速地交付，并且有更好的效率和质量。同时在过程中要能够考虑到如何帮助业务建立核心竞争力。

第二个维度，技术迭代和优化。技术体系的熵会逐渐增大，技术团队要把自己的基本盘做好，逐渐把技术债还掉。互联网的业务往往一开始都是单点切入，小步快跑，快速试错，在过往过程中一定会留下很多的技术债。要持续降低自己系统腐化的速度，逐步改良优化自己的系统。

第三个维度，要考虑组织能力建设。团队的技术水平和公司比、和业界优秀水平比，还有哪些能力短板，哪些方面已经做得不错了，要对自己的能力有一个比较清楚的认知；团队成员结构和组织架构是否需要优化，人员结构要不要做调整等；团队文化建议也是一个可以考虑的维度。当然，具体的细节还是要根据团队和业务的状况因地制宜。