百度主任架构师谭待：如何让不带团队的程序员负责重大项目？

演讲 | 谭待

整理 | 赵新龙、尾尾

谭待，百度主任架构师、百度搜索公司技术委员会联席主席。主要研究领域在分布式系统和搜索引擎，是百度BVC代理计算和Matrix私有云的主要设计者，两获百度最高奖。主持设计了百度新一代搜索架构，在时效性和计算规模上实现了大幅提升；同时主导了极速搜索、全站HTTPS等百度搜索的一系列重大革新，也是百度MIP项目的整体负责人。

本文是谭待在EGO主办的第二届GTLC全球领导力峰会上的演讲整理而成。

不带团队的程序员如何负责重大项目？

非常高兴和大家探讨技术领导力的话题，首先，我简单介绍一下自己：我在百度搜索担当架构师，是一个不折不扣的程序员——这也是我觉得在所有参会嘉宾里非常特别的一点。在我十多年的职业生涯里，我一直保持着纯粹的技术专业序列身份，讲人话就是“我不带团队”。

虽然不带团队，但很多搜索方面重大的技术革新和产品升级都是我直接负责和领导的。能做到这个事情，不是因为我天赋异禀，这是因为百度搜索团队有独特的技术文化，这是它非常有特色和非常吸引人的地方。这种独特的技术文化，可以让不具备技术管理职能的工程师，在组织需要时承担起技术管理的职责，并且做出具有独特价值的贡献。

这种文化，或者说机制，就是我今天想跟大家分享的内容——非职权技术管理机制。

什么是非职权技术管理机制？

什么是“非职权的技术管理”机制呢？

首先说一下什么是非职权的技术管理。这个词是我拼凑出来的，简单翻译一下就是：你负责一件事、领导一项技术、负责一个项目，但是所有的项目成员都不向你汇报。

这个听起来特别诡异，因为一般的管理都是与职权挂钩的，否则很多直接有效的调节手段就没法用，比如薪酬绩效，比如需要项目团队加班时直接下规定说谁不来就扣钱——我没有这样做，我能做是谈天聊心。

技术领域为何无法避免非职权管理机制？

不管我们愿不愿意，一个非常可悲的事实是，非职权的管理方式在技术领域是基本不可避免的。原因很简单，职权一定和组织架构强相关，组织架构是公司和部门为了业务设定和优化的。

我们都知道，互联网上唯一不变的就是变化，当新机遇新时代到来的时候，一定会跟现有的组织架构产生非常大的冲突。

在座的很多人应该都经历过互联网从PC时代向移动时代的迁移过程。那时，公司一般会设立一个部门叫移动产品部，专门负责移动化。但当时公司主要业务肯定是在PC上，主要的技术资产还在PC部门。为了最大限度地用这款资产、让业务快速发展，一定会展开非常多PC部门和移动部门跨团队的技术联合，里面肯定有不少痛苦。后期移动变成主流，进行彻底的架构调整，这就解决问题了。我们现在都说，人工智能时代可能马上到来了，所以这个类似过程还会再经历一遍的。

非职权管理机制为什么很重要？

既然无法避免，那么反过来，我们乐观一点地看，非职权的方式对组织和业务来说也是非常重要的，这主要有三方面原因。

第一个原因，是它能很好地突破现在的组织架构限制，解决刚才说的问题。

虽然，最直接的一劳永逸的办法是调整架构。然而经历过的人都知道，调整架构是更痛苦的事情，等你调完，人也走的七七八八了。而且这里面有一个度的问题：什么时候开始调整？如果这个事太小，觉得还不足够；往往等到觉得这个事很大的时候，已经错过时机了。如果这个时候，大家都比较习惯在非职权情况下开展工作，那就很容易突破现有组织架构的限制。所以，我说它是一种比较灵活柔和的方式。

第二个原因是，它有利于保持技术的先进性。现代社会或者公司都是高度分工的战略组织，如果把大量的时间投入到人的管理上，那在技术领域一定是落后的。所以有时候让处在技术前沿的工程师做这些事情，有利于技术先进性的保持。

最后一个原因是，它会带来自主性的价值。你让工程师做管理的事，他会有一种农民翻身做主人的感觉，“我也能做很多事情”，他们的积极性、满足感和忠诚度都会有很大提升。

如何打造非职权管理机制？

既然非职权管理的情况是无法避免的，而建设相应的机制又是十分重要的，那么，与其被动逃避，不如主动打造这样的机制，让它成为新常态。

那么，如何打造这种机制呢？

要打造这个机制，首先要奠定好一个框架。

第一步叫“师出有名”。

前段时间很火的《人类简史》讲了一件很好玩的事：现代人的祖先只是人属中的一个人种，当时还有很多别的人种，这些人跟我们祖先差不多，都能够使用工具，都能够生火，都能够讲话，甚至比我们的祖先还强壮一些。什么原因导致这些人都被干趴了呢？突然有一天，我们的祖先开发出了一个非常有特色的技能叫做八卦，就跟我们现在的八卦差不多。因为有了八卦技能，所以就能发展出更复杂的人际关系。因为共同的喜爱和厌恶，更多人聚在一起，越聚越多，之后就发展出了第二个技能叫做编故事，特别是他们能够去虚构一些在自然世界里并不存在的实体，让所有人认同他、相信他并且传播他。部落就是一个虚构的概念，但是因为假想的共同体，更多人能够聚集在一起，为了共同体而努力。现在我们想打造一个新的机制，创造一个新的制度，首先我们一定要创造假想共同体，通过这个共同体开展事情。在百度，这个假想的共同体就是技术委员会。这是第一步。

有了假想共同体，第二步就是要挑选核心的班底。

核心班底非常关键，因为在早期他们会作为主力去实施管理，具有很强的示范作用，所以一定要在人员筛选上注意。有三点非常重要，第一是技术杰出，第二是理解业务，第三足智多谋。前面两点很容易理解，重点说一下足智多谋。足智多谋是说，一定要有千方百计挖掘能够利用的各种资源，以达到最终目的的能力。这是什么意思呢？因为非职权就是没有职权，但你可能会有其他资源，你可以说服大老板支持你，你也可以制造舆论——有些人就能看到这些点，能把这些资源利用起来，这是一个非常大的差别。

建完核心班底以后，还要做最后两步：授予权力和赋予责任。

首先，是授予权利。虽然我们一直在讲非职权，实话实说，如果你真的什么权利都没有，想做技术管理那也是太难了。虽然我们没法在管理上赋予他实际的权利，但可以赋予技术管控权利，比如说对工程师专业晋升的评审权，或者是对重大项目是否上线的Launch Review。一方面这些事情非常适合专业组织来承担，另一方面承担这些事情可以积累足够的权威，开展其他事情时大家都会听他的。这里有一个陷阱：我们一定要分清主次，技术一定是为业务服务的，而为业务真正负责任的其实是管理层、是经理。这个要搞懂，要平衡好，不要对着干。

最后一步，赋予责任。授予权利之后，就要让TC赋予责任，这样才能运转起来。这也是四步里最关键的一步，而且是常常出问题的环节。这一步一般会有两种问题：第一种是说我们赋予的责任太虚太泛了，比如说你的责任就是把控技术，但做什么是把控技术呢？第二个问题就是轻信工程师可以高度自律，所以不检查结果，最后TC变成纯粹只负责评审项目的临时机构。我的个人经验是，一定要非常清晰明确的定义他要做什么事情，而且定期检查，比如明确定义TC要做的就是阶段性疏理所有技术指标、制定技术规划，而且每半年做一次。做的过程中，发现任何问题，不管是机遇还是挑战，你都要把它变成具体的项目跟进，最后检查你的项目成果。只有通过非常严谨的规定和严格的检查，才能真正把责任落实到行动。

实际落地，反复练习

有了这样一套框架，接下来就是反复练习。不论是工程师还是经理都会很不适应，所以我们一定要反复地做、刻意地做，做成一个常态。

大家都听过一万小时定律，很多行业达人之所以卓越，不是因为他们是天才，而是因为他们付出了足够多的努力。对组织也是一样的，你想建立新的机制，必须经过反复的练习才能成功——至少你要做一百个项目。很多人成功从被动接受安排变成主动驱动，之前是你告诉他、他去做，后来他发现这个机制很好，就主动去发现问题和解决问题。

实际案例

下面举几个具体的案例来说明。

案例一：搜索架构

如下图所示，这是搜索架构，从流程来看，搜索业务分三步：离线、在线和前端，三者分别配备一位大经理。TC在里面起到非常好的补充作用。

从TC角度会这样看待：左边的图是从业务角度看有哪些技术方向，右边红色的是业务指标体系，即从业务角度来看哪些指标是重要的。有了这个图，就可以做几件事情，第一就是合并同类项，比如说在线有存储系统，离线也有存储系统。底层的技术可以合成一个方向集中发展。第二个更重要的是用这种方式驱动业务发展和技术创新。从业务角度看右半部分，现在的指标体系是不是完善？要不要加新的指标？已有的指标哪些需要提升？根据指标上的目标，再看左边。现有方向设施是否合理？如果不合理，我们就打破这个限制。

案例二：搜索安全

很多用户在访问百度搜索时会被劫持，有的会跳到竞品，有的会加很多广告。原先管理划分上并没有直接对应这个问题的组织，所以首先是TC在牵头，进行系统疏理会发现，绝大部分的发生在网络阶段，解决问题最直接的方式就是把搜索改成HTTPS。

这个听起来很简单，但其实很复杂。最复杂的一点就是，必须把页面上所有资源全部改成HTTPS。

搜索本身作为一个开放的平台，有很多第三方部门，甚至第三方公司在搜索上有资源展示，所以需要拉着所有的其他部门甚至其他公司一起进行改造。这个组织就进一步扩大，把运营人员还有产品都包括进来。花了一年时间，我们终于把这个事做了。对百度来说，还有很多重要的产品，比如贴吧、地图，用户都会遇到这些问题，所以应该是推动这些产品一起进行HTTPS改造。紧接着我们成立了一个全公司范围的推广小组，把这些产品都进行了改造。这时候形势又发生了变化，我们希望互联网上所有的网站都改成HTTPS，实现全网安全。这个过程比较漫长，而且要做的事情比较确定，这个阶段就变成一个实体化的团队在推动。我们回头看整个流程，其实有时候用的是职权管理，有时候用的是非职权管理，非常灵活。核心是，合适的时候用合适的方式。

案例三：搜索速度

还有一个类似的案例，就是搜索速度。对所有产品而言，速度都是一个最基本的指标，对搜索，速度也非常关键。

以前搜索速度是按照离线、在线、前端进行划分的，离线优化离线速度，在线优化在线检索速度，前端优化前端渲染速度。这里的问题是，尽管大家做了很多事情，但效果都不好。当我们意识到这个问题以后，我们就不是在各自职能范围，而是进行跨越，从全局角度看待这个问题。一旦从全局角度看待这个问题，就可以从全局角度提出解决方案：用户在搜索关健词的时候，预测他搜索什么，提前完成搜索结果，比如用户想搜刘德华，他输入刘德的时候我就知道他要搜索刘德华了。这个方案还是比较巧妙的，更重要的是背后管理机制的变化。

辅助机制

大家都知道，管理是非常难的，这个非职权技术管理其实更难。所以，为了达成非职权技术管理，也可以做一些辅助的机制。

比如，我们可以帮助设计交付经理的岗位，让他们进行相应的事情；再比如帮助没有太多经验的工程师进行项目管理、沟通流程、控制推动等等。这样刚开始时工程师没有那么痛苦，而且做的过程中会有非常好的保证。你做事的过程中，学习成长得更快。

还有，就是能力的培养，管理毕竟还是需要管理技能的，一般来说这种培训都只向管理层开放，不会考虑给工程师开放，这也是一个问题，所以应该提供这样一些机制。

总结与反思

最后，总结一下，这种非职权技术管理看起来怪异，却是我们无法避免的。同时，他对公司的发展也比较重要。如果想打造这样的机制，首先应该定一个框架；有了框架，需要反复练习，使之成为常态，并且提供尽可能多的辅助机制，让他加速。

技术总是在短期内被高估，在长期又被低估——世间很多东西都是这样子的。如果你能够保持足够的理性，能保持足够的耐性，它一定会在恰当的时候带给你惊喜。

Q&A

Q：怎么跟踪技术规范的落地与执行？

谭待：我们是技术人，所以做事情一定是技术驱动的。跟踪肯定不能只靠人检查，我们在开发流程设置自动化的一个工具，保证一定是执行这个流程之后才能发布；自然就能确保规划的落地。

Q：这一次主要讲的是在技术领域的管理，你已经是高级工程师，你通过TC或者晋升渠道去做管理。另外一些情况，比如设计师或者项目管理，而不是技术专家类的，如何操作？

谭待：类似的，可以成立一个设计师委员会。我觉得技术这个词很宽泛，设计也算是技术的一种，产品研发也算，都是非常类似的。技术可能更好评估一些，产品跟设计更难评估一些，这些都是专业性的，我觉得，只要有专业性就可以用类似专业委员会来解决的。

Q：我有两个问题，第一个是说关于TC的人是全职还是兼职，兼职会有投入和产出的问题，专职做TC工作是不是会影响自身职业发展。第二个问题，我们是一个快速发展的创业公司，也想搞技术委员会，让很年轻的工程师进入TC，会不会在沟通或者权威性上会受到质疑？

谭待：关于第一个问题，首先明确是兼职，不可能有一个这样的全职。其实他工作没有那么饱满，而且全职会导致脱节、达不到作用。

怎么解决兼职的问题呢？有人是有一定技术理想的，希望去推动大的事情，虽然不是他的本职工作，但他的目标跟这个重合，所以会花很多精力在这上面。要找到这些人，发挥他们的特长。反过来讲，有的人技术非常好，但没有这方面的想法，就没有必要把他硬塞进去，否则可能会适得其反。

第二个问题，因为组织还是很考量技术影响力，资历是一个很重要的考虑因素，但资历跟年龄没有关系。有些人很想做这个事情，但资历很轻，怎么办？我们可以在下面设工作小组，以小组成员的方式发挥作用，而负责人还是那些比较有影响力的人。这样就能起到比较好的作用。

Brilliant Open Web 

BOW（Brillant Open Web）团队，是一个专门的Web技术建设小组，致力于推动 Open Web 技术的发展，让Web重新成为开发者的首选。

BOW 关注前端，关注Web；剖析技术、分享实践；谈谈学习，也聊聊管理。

技术连接世界，开放赢得未来，关注 OpenWeb开发者，回复“加群”，让我们一起推动 OpenWeb技术的发展！

OpenWeb开发者

ID：BrilliantOpenWeb

技术连接世界，开放赢得未来