|
|
# 大咖对话 | 余沛：打造以最佳交付实践为目标的技术导向
|
|
|
|
|
|
你好！
|
|
|
|
|
|
本周作客大咖对话的依然是同程艺龙副总裁、研发中心负责人余沛，其在2012年加入艺龙旅行网后，先后担任技术总监、首席架构师、CTO，除负责过基础架构、分布式计算、酒店垂直搜索引擎等一线工作外，也持续的推动公司在技术方向上的全面转型、技术委员会体系建立、技管分离等管理相关工作。在加入艺龙之前就职于百度，负责自动化运维相关系统建设。今天，我们和他聊了聊CTO的使命与职责，以及技术文化等话题。
|
|
|
|
|
|
**极客时间：在您看来，CTO的使命与具体职责是什么？又该如何衡量CTO的表现？**
|
|
|
|
|
|
**余沛：** 使命与职责可以从两个不同的角度来看，自上向下和自下向上分别有不同的视角和答案。
|
|
|
|
|
|
## 1.自上而下
|
|
|
|
|
|
自上而下自然是指站在公司或CEO的角度来看待这个问题，他们对技术条线有着怎样的期望、想达成怎样的使命。我认为这个答案就是以最优性价比（成本、时间）来交付业务的预期目标。衡量方式也很简单，就是从质量和效率两个维度衡量技术条线的业务交付能力。
|
|
|
|
|
|
## 2.自下而上
|
|
|
|
|
|
除了完成公司、老板的期待外，技术人员自己也是有追求的，他们希望自己、以及技术团队能为公司创造更大的价值，通过以技术为主的手段，摸索、论证新的产品、业务甚至商业模式，并投入实践，帮助公司获得业务增长。
|
|
|
|
|
|
以AI为例，这两年AI已从技术领域的研究走向前台，进入公众视角。最初，非技术领域的人可能难以判断AI具体能给业务带来何种直接帮助，这时，技术人员应主动站出来，往前多走一步，研究、思考、并实践其怎样与业务特点相结合、在哪些点上能够帮助业务获得创新、突破。
|
|
|
|
|
|
自下向上的衡量也很简单，就是看由技术驱动的创新和改进，在公司业务中的地位、对业务增长的帮助，以及在此过程中，技术条线的工程师们所获得的存在感、荣誉感和归属感是否强烈。
|
|
|
|
|
|
这里我想多聊一下**技术人员的存在感、荣誉感和归属感**。优秀的工程师，待遇薪酬当然很重要，但他们往往更看重自己的付出在公司成长过程中起到多大的正面作用，公司又是否认可他们的能力与付出。如果答案都是确定的，那他们自然会有归属感和荣誉感。
|
|
|
|
|
|
以我们所在的垂直领域为例，很多年前，在地域性很强烈的本地产品排序案例中，最早产品的排序是由负责当地的运营人员来调整决定的，因为从行业惯性来看他们更熟悉当地产品的情况、更清楚当地的运营状况，丰富的经验赋予他们有更好的技巧来手动调整产品排序，以维持一个不错的转化率。
|
|
|
|
|
|
而在技术方面，我们开始利用大数据、利用用户行为进行更精细的分析，利用机器学习的算法来做机器排序、或者个性化排序。初期的训练模型出来后，AB测试的结果并不如运营人员手工调整的效果好，这时大家总会有一些疑问，但以技术方向来讲，这一定是趋势与方向。经过不断的迭代、优化算法和调整模型，最终结果便会远远优于人工排序。
|
|
|
|
|
|
这时，技术人员自身会有很强烈的荣誉感，因为你的技术确实在某方面能帮助公司成长，等到这些结果落下“实锤”以后，其他部门的同事也会对技术条线同事的工作从质疑到认同，并真切认可技术的价值。而不是技术人自己说做了多牛的架构、写了多少代码，却难有人认可这些技术到底对业务有何种帮助。
|
|
|
|
|
|
**极客时间：作为CTO，对于中层技术管理者的培养，您有哪些经验？**
|
|
|
|
|
|
**余沛：** 首先强调重要的一点是，技术团队还是要尽量扁平化、尽量减少一些中间层级。当然这跟团队规模与业务结构也有很大关系。回归话题，对于培养中层技术管理者，可以从两方面出发，一是培养中层管理对管理工具和管理方法的合理利用；二是帮助公司打造技术文化，以相对降低管理中层技术管理的成本。这两点其实是相对的，技术文化强一些，管理工具和管理方法就可以相对弱一点；反之，如果没有良好的技术文化，就不得不通过高昂的管理成本来进行管理。这当然不是一个很好的状态。
|
|
|
|
|
|
具体的培养理念，我们更倾向于让中层管理者有能力成为和一线同学一起往前冲的领头人，而不是站在背后执鞭指挥的纯管理。至少在技术领域，我也相信一线的工程师更愿意跟随有使命感、以身作则、以能力服众的Leader。
|
|
|
|
|
|
同时，我们也会尽量检视，避免中层管理者过早脱离一线，成为“站在后面执鞭指挥的人”。我们曾经定下一套“CDR”指标，来度量中层技术管理者和高级别的技术专家。所谓CDR指标即Code、Document、Review。我们期望中层管理，仍然不要太脱离一线，虽然他们身兼团队培养、项目管控、应急指挥等管理职能，但仍然要在这三个指标上有对应的完成度。要么与团队一起完成部分核心代码，要么参与重要系统的设计文档，或者帮助团队成员做code review，提交有意义的comment。至少在CDR的其中一方面有突出贡献，总之不能太脱离一线。
|
|
|
|
|
|
包括我自己，即使现在大部分精力与管理相关，但依然会不定期参与部分系统的讨论、评审。不敢完全脱手。技术管理者坚持不脱离技术岗，其实更能带动文化并将它更好的传递下去。
|
|
|
|
|
|
顺便说一句题外话，在CDR三个指标中，我很想强调一下Document的重要性。我们从来不认为文档是交付过程中的一个任务。我们一直强调：代码是思考的产出，而文档就是思考的过程。我们见过很多工程师，认为写文档麻烦、浪费时间，不做设计直接coding，边写、边思考、边改。其实以建筑工程为对比就能明白，你见过没有图纸就开始施工的工程吗？为什么就能允许不做设计、不落地文档就开始写代码呢？还美其名曰“快速交付”。
|
|
|
|
|
|
再怎么样求快，也应该在写代码之前有一个良好的设计过程。文档并不是为了产出一个file，而是在过程中思考、梳理逻辑。撰写文档看似会在前期花费一些时间，但在写完后转成coding的过程中就能够一气呵成，整体速度其实并比直接闷头coding、发现不对又删了改，改了删来得慢。
|
|
|
|
|
|
当然，互联网领域竞争激烈，公司业务发展快速，产品模式迭代快速，大家都在追求快时，如何能说服运营、产品及技术人员坚持速度与质量并行，很大程度上还是与文化挂钩。
|
|
|
|
|
|
**极客时间：您之前提到技术文化，那同程艺龙的技术文化是什么？又是如何打造落地的呢？**
|
|
|
|
|
|
**余沛：** 我们的技术文化很简单，就是“简单、匠心、交付”这三点。
|
|
|
|
|
|
**先来看简单。** 简单有两个层面，一是做人简单，二是做事简单。
|
|
|
|
|
|
技术人其实真的是非常单纯简单友好的群体。，我们希望能将这种简单保持下去，不要将问题复杂化。比如面对一个问题时，大家能就事论事、拿数据说话，不用因为顾虑对方是上级或者其它的办公室原因而难以启齿，以最直接有效的方法来解决问题。
|
|
|
|
|
|
其次，将简单的原则沿用到做事中，做技术的同学都应该清楚：事情越复杂，则出错的几率越大。
|
|
|
|
|
|
在技术上，我们不赞成求多、炫技，而是更倾向于做减法。比如，为了实现某个功能需要做一个架构，在初步的架构设计中需要十个组件，这时，我们一般会鼓励大家想办法做减法，将组件变成8个、7个，或者6个，尽量将它简化。
|
|
|
|
|
|
另外，即使今天看起来很好很适用的技术系统，我们也要随着时间的推移去持续做减法、优化。就像衣橱中的衣服，换季时不合身了就要敢于淘汰。
|
|
|
|
|
|
举个例子，很多前年前团购很火爆的时候，我们在系统中有很多团购相关的模块与服务，如今业务形态早已变化，相应的逻辑如果还在流程中存在，其实是一种负担，也容易因为业务萎缩后，过少维护而引起其它地方的问题。
|
|
|
|
|
|
况且互联网公司的人员变动较为频繁，如果你没有在合适的时间调整架构、优化内容，等过了N年之后再去清理它们，到时已经无人能懂这些代码，也可能没有人熟悉风险点有哪些。自然会面临极大风险。所以，我们提倡及时简化、优化系统架构。
|
|
|
|
|
|
**再来看匠心。** 简单和匠心不冲突，就像苹果的产品，虽然它的设计理念趋向简单，但确实从很多细节中能够感受到非常用心。
|
|
|
|
|
|
我们有时会检视一些不太好的系统，发现它们并不只有一两处糟糕的实现，而是从整体到细节都没有用心，一片糟糕。在我看来，一个优秀的工程师，做一个优秀的设计，可以把事情做少、做简单，但质量要高，至少达到95分以上，否则后期返工、维护的成本会更高。
|
|
|
|
|
|
我们曾经有一个基础组件系统的研发，出了第一版设计，不合格，被评审打回，之后的第二版、第三版依旧不合格，依旧被打回重做，这样来回返工六七次才通过。看起来似乎对交付有一些影响。但是这个系统，上线后持续运行了四年几乎无故障。我们还是希望在交付时间能够接受的前提下，尽可能的养成匠人精神，无论对个人还是对系统而言，都是终身受益的。
|
|
|
|
|
|
另外，需要强调的是，匠心与交付也并不冲突。匠心不代表成本要从1变到10，花费超额的成本来成就匠心。而是要求我们在做事的过程中，将心注入，追求极致。否则，原本一天就能交付的工作，由于的“匠心”要额外花费十天才能完成，又会与公司目标冲突。
|
|
|
|
|
|
对如今的互联网行业来说，快速交付是一个非常重要的能力。快速交付不意味着质量上的妥协，很多时候，这是一个态度的问题。以炒菜为例，优秀的厨师与差劲的厨师，用在“炒”的时间和步骤其实不会相差太多，好与坏的区别取决于用不用心，而这“用心”其实包括前期的食材、工具的准备、平时的训练、对理念和目标的思考等，这才是更重要的。
|
|
|
|
|
|
而在技术方面，所谓的匠心也不是单纯指在写代码时吹毛求疵，关注注释有几种写法、括号应该怎么换行，而是写代码前，有没有用心思考与梳理，这才是差距所在。
|
|
|
|
|
|
**最后来看交付。** 技术人员往往更关注自己的技术，比如用了哪些新技术、算法有多牛、架构有多好，等等。但是我们希望，技术最终能与公司目标结合。比如算法很牛，那它对业务交付产生了多大的价值，是提升了转化率，还是优化了用户体验？
|
|
|
|
|
|
在简单和匠心之外，我们会更多强调，技术的最终目标是要完成交付，而不是为了炫技而做技术。因此，我们也会以交付来衡量技术人员的产出。
|
|
|
|
|
|
之所以把交付写进技术文化中，是因为文化可以自发的影响人。其实在互联网公司，所有程序员都知道要交付，因为不交付就无法完成KPI，最终无法完成目标。
|
|
|
|
|
|
但简单的把交付写进KPI，其实是一个被动的过程，而如果能把关注交付当做一种文化，它就会变为主动性，促使技术人自发地、更优雅地去思考结果与目标，也会更愿意思考自己的技术对公司产生了什么价值。
|
|
|
|
|
|
**极客时间：将技术文化落实到每个成员，具体会做哪些事情？**
|
|
|
|
|
|
**余沛：** 技术文化的打造是一个潜移默化的过程，具体到落实的话，可以通过鼓励符合文化的行为来进行引导。
|
|
|
|
|
|
以匠心为例，工程师写完代码，他认为已经合格了，完成了交付，而他的上级在帮他Review代码时，会非常认真，会去思考还有没有优化的空间，如果有，团队就开会讨论能够优化的部分，再给出较为全面的优化建议。而不是大家一看反正代码也能运行，就很容易的给你通过。
|
|
|
|
|
|
同样，对于交付也是如此，我们每一次内部评奖时，都会问候选人一个最终问题，即你的代码或架构的受益人是谁？他们获得了怎样的好处？
|
|
|
|
|
|
这样造成的结果是，以前评奖时，很多人都会列举自己做了哪些特别厉害的技术，而现在，他们会自发思考，我做的事情最终会交付怎样的成果，能对谁产生怎样的价值，这就是文化潜移默化的魅力所在。
|
|
|
|