技术领导力实战笔记_138_大咖对话_|_余沛：打造以最佳交付实践为目标的技术导向
你好，本周做客大咖对话的依然是同城翼龙副总裁研发中心负责人吕佩，其在二零一二年加入艺龙旅行网后，先后担任技术总监、首席架构师CTO,除了直接负责过一线的基础架构相关系统、分布式计算、OTA、垂直搜索引擎等工作外，同时推动了公司在技术方向上的全面转型。
技术委员会体系建立机管分离等管理类工作。
在加入艺龙之前，曾就职于百度，负责自动化运维相关系统建设。
今天，我们和他聊了聊CTO的使命与职责，以及技术、文化等话题，极刻时间问，在您看来，CTO的使命与具体职责是什么？又该如何衡量CTO的表现呢？雨佩回答CTU的使命与职责。
可以从两个不同的角度来看，一是自上向下，二是自下向上，一自上向下。
首先可以试着站在公司或CEO的角度来看待这个问题。
他们会有着怎样的期望，期望CTO达成怎样的使命？答案很简单，就是以最优性价比来交付业务以及产品的设计目标。
而方式也很简单，就是从质量和效率两个维度衡量CTO的业务交付能力。
二、自下而上除了完成公司老板的期待外，技术人员自己也是有追求的。
他们会希望自己自己的团队能为公司创造最大的价值，能通过技术手段摸索论证新的产品、业务，甚至商业模式，并投入实践，实现创收。
以AI为例，前两年AI在技术圈里比较火，但产品和运营人员可能并不清楚AI能给他们带来什么具体的帮助。
此时，技术人员应主动摸索论证并实践AI能为公司的产品、业务以及商业模式带来哪些效益。
自下向上的衡量也很简单，就是看由你驱动的技术和技术创新，在公司的业务中处于什么地位，起到什么作用，以及技术人员在公司内的存在感、荣誉感和归属感是否强烈。
这里我很想聊一下技术人员的存在感、荣誉感和归属感。
这些其实不在于你给他们多少钱，而在于他们的付出是否对公司的成长起到正面影响，公司又是否认可他们的付出。
如果答案都是确定的那他们自然会有归属感和荣誉感。
以翼龙为例，之前提到的酒店排序案例中，最早酒店的排序是由当地的运营人员决定的，因为他们更了解当地的酒店，知道怎么排序，对销量更好。
但从技术的角度来说，我们可以通过大数据进行重新排序。
当然模型刚出来的时候，大家会有些疑问，因为第一版排出来的结果的确比人工排序差。
但是我们的模型可以不断迭代，不断优化，最终出来的结果远远优于人工排序。
这时，技术人员自身会有很强烈的荣誉感，因为你的技术是实实在在的，在帮公司增长其他部门的同事也会对你有更多的认同感，真切认识到技术的价值，而不是技术。
人自己说自己做了多牛的技术，但却没人说得出这些技术到底对什么起到了帮助。
即刻直接问，作为CTO对于中层技术管理者的培养，您有哪些经验呢？于佩回答，首先很重要的一点是，技术团队要尽量扁平化，减少中间层级。
回到培养中层技术管理者可以从两方面出发，一是管理工具的合理利用。
二是技术文化的打造。
这两点有点相对技术，文化强，管理工具就可以相对弱一点。
反之，技术文化弱，我们就得通过很高的管理成本去压迫团队。
在具体的培养上，我会更倾向于让他成为能带头和一线同学一起往前冲的领头人。
而不是站在背后指边指挥的人，至少在技术领域，这样的做法会更好。
同时，我们会用CDR指标来衡量中层技术管理者以及高级别的技术人员。
所谓CDR指标，即code document review,要么能写code,要么能做真正的document,要么能帮助大家review代码，至少在某个方向较为突出。
总之，不能太脱离一线，我胜任翼龙CTO之后，虽说会做更多管理相关的事情，但依然有几个系统我会跟着一起去参与一些事情。
没有完全脱手技术，管理者亲身参与到团队的具体工作中，其实更能带动文化，把想打造的技术文化更好的传递下去。
另外，在CDR三个指标中，我很想强调一下，文档，我从来不认为文档是交付过程中的一个任务，代码是思考的产出，而文档就是思考的过程。
用建筑工程类比，就是你见过没有图纸就开始施工的工程吗？既然没有为什么，你就能允许不设计文档就开始写代码呢，还美其名曰快速交付，再怎么样求快也应该在写代码。
之前有一个良好的设计文档，写文档并不是为了产出一个文档，而是为了在写的过程中更好的思考，梳理代码的逻辑。
想清楚了再写，即使设计文档会花费一些时间，最终速度其实并不会比一上来闷头就写来的慢。
因为不论如何，思考代码逻辑这一步是无法避免的，区别，只是提前思考和在写的过程中再思考，后者还会引发更多的衍生问题。
当然，互联网领域竞争激烈，公司业务发展快速，产品模式迭代快速。
大家都在追求快时，如何能说服运营产品及技术人员，坚持速度与质量并行，很大程度上还是与文化挂钩。
即刻直接问您之前提到技术文化，那同城翼龙的技术文化是什么呢？又是如何打造落地的呢？于佩回答，我们的技术文化很简单，就是简单匠薪交付。
这三点先来看简单，简单有两个层面，一是做人简单，二是做事简单。
首先，技术人相对而言都比较简单，我们希望能将这种简单保持下去，不要将问题复杂化。
比如面对一个问题，大家就事论事，拿数据说话，不用，因为顾虑对方是上级或是其他部门、同事而难以启齿，以最直接有效的方法解决问题。
其次，将简单引用到做事儿中，我们内部有个原则，事情越复杂，出错的几率越大。
在技术上我们不赞成炫技，而是倾向于做减法。
比如为了实现某个功能，需要做一个架构，在初步的架构设计中需要十个组件。
这时我们一般会鼓励大家想办法做减法，将组件变成八个七个或者六个，尽量将它简化。
另外我们发现很多系统一旦运行三年以上就会出现很多问题。
通常这些问题不是因为新的数据量或新的业务引起的，而是因为之前系统中遗留的旧代码旧组件。
举个例子，几年前团购非常火爆，我们也在系统中加了很多与团购相关的代码。
如今，传统的团购模式几乎消失殆尽，遗留的代码已经没有价值，而互联网公司人员流动频繁。
如果你没有在一代代的架构优化中，及时把这些没用的部分清理掉，等过了n年之后再想去清理他们时已经没人弄得懂。
这些代码就会存在很大的风险，很有可能动一处就导致整个系统崩溃。
所以我们会提倡及时简化优化系统架构，再来看匠心简单和匠心不冲突。
就像苹果手机，虽然它的设计简单，但每个细节都非常用心。
我们口中糟糕的代码或糟糕的系统，并不是有一两处糟糕的地方导致的，而是因为在构建的过程中缺乏匠薪，导致整体都很糟糕。
在我看来，你可以把事情做少做简单，但质量要高，至少达到九十五分以上，否则就需要不停的返工。
基德还在翼龙带一线团队的时候，团队的一位成员设计某个功能出了第一版不合格，被我打回之后的第二版第三版依旧不合格，依旧被我打回重做这样来回反攻六七次才通过。
其实这只是一个小功能，但我希望能在不影响最终交付的前提下，帮助他养成匠人精神。
无论对他个人而言，还是对系统而言，都是终身受益的。
另外，需要强调的是，降薪与交付也并不冲突，降薪不代表成本，要从一变到十花费超额的成本来成就降薪，而是要求我们在做事儿的过程中将薪注入做到做好，否则原本一天就能交付的工作。
由于所谓的降薪要花费十天才能完成，就与公司目标冲突。
对如今的互联网行业来说，快速交付是一个非常重要的能力，但快速交付不意味着质量上的妥协。
很多时候，这是一个态度的问题。
以炒菜为例，优秀的厨师与差劲儿的厨师，炒菜的时间和步骤不会相差太多，菜的味道取决于用不用心。
而这用心，包括你炒菜前的食材、工具的准备，包括对以往炒菜经验的思考与总结等等，这才是更重要的。
而在技术上真正的降薪，不是你写代码的时候突然有降薪，而是你写代码之前有没有过真正的思考与梳理，这才是差距所在。
最后来看，交付技术人员往往更关注自己的技术，比如用了哪些新技术，算法有多牛，架构有多好等等。
但是我们希望技术能够与公司目标更好的结合。
比如这个算法很牛，那他对业务交付产生了多大的价值？是提升了转化率，还是优化了用户体验呢？在简单和匠心之外，我们会更多的强调技术的最终目标是要完成交付，而不是为了炫技而做技术。
因此，我们也会以交付来衡量技术人员的产出。
之所以把交付写进技术文化中，是因为文化可以自发的影响人。
其实在互联网公司所有程序员都知道要交付，因为不交付就无法完成KPI,最终无法完成目标。
但这样把交付写进KPI,大家是被动交付。
而如果把交付做成一种文化，它就会变为主动交付，促使技术人自发的更优雅的完成交付，也更在意自己最终交付的东西是否对公司产生价值。
即刻时间问，将技术文化落实到每个成员，具体会做哪些事情呢？女配回答，技术文化的打造是一个潜移默化的过程。
具体到落水的话，可以通过鼓励符合文化的行为来进行引导。
以匠薪为例，工程师写完代码，他认为已经合格了，完成了交付。
而他的上级在帮他review代码时会非常认真，会去思考还有没有优化的空间。
如果有团队就会做一起开会讨论，能够优化的部分，再给出较为全面的优化建议。
而不是大家一看，反正代码也能运行，就很容易的给你通过。
同样对于交付也是如此，我们每一次内部评奖时，都会问候选人一个最终问题，即你代码或架构的受益人是谁？他们获得了怎样的好处？这样造成的情况就是以前评奖的时候，很多人都会举例自己做了哪些特别厉害的技术。
而现在他们会很自然的去想，我做的事情，最终会交付一个怎样的成果，会对谁产生怎样的价值，这就是文化潜移默化的魅力所在。