第448期｜技术人在职业成长不同阶段的能力诉求
你好，这里是卖桃者说。
上一期，我们跟你分享了余沛老师关于“技术Leader需要具备的素质与能力”这个话题的思考。
余沛目前担任同程旅游副总裁，负责集团整体的研发工作。他2012年加入艺龙旅行网后，从技术总监一路做到首席架构师、CTO，同程与艺龙合并后，又出任新公司副总裁，对技术人成长有着自己的实践与经验。
在我们成长的不同阶段，对于能力模型的要求是不一样的，程序员也不例外。在这次交流中，余沛老师也跟我们分享了他对技术人不同阶段的认知和期望，希望能对你有所启发。
对于程序员阶段
首先是程序员阶段，在余沛看来，一个优秀的程序员，起码要具备以下三个方面的能力。
第一，要做好交付。技术人员往往更关注自己的技术，比如用了哪些新技术、算法有多牛、架构有多好等等。但在余沛看来，技术更大的价值，还是在于最终能够跟公司目标有更好的结合，比如这个算法很牛，那它对业务交付产生了多大的价值，是提升了转化率，还是优化了用户体验？
因此，他会更多地跟研发团队强调，技术的最终目标是要完成交付，而不是为了炫技而做技术。他也会以交付来衡量技术人员的产出，甚至把这一点写进了公司的技术文化，因为文化可以自发地影响人。
其实在互联网公司，所有程序员都知道要交付，因为不交付就无法完成KPI，最终无法完成目标。但受限于KPI是一个被动的过程，技术人更多的，还是要培养自己自发地、主动地去思考结果与目标的习惯，习惯于思考自己做的事情对公司会产生什么样的价值。这是一种思维上的转变。
第二，要把事情做简单。做技术的同学都应该清楚：事情越复杂，出错的几率越大。在技术上，余沛并不赞成求多、炫技，而是更倾向于做减法。比如，为了实现某个功能需要做一个架构，在初步的架构设计中需要十个组件，这时，他一般会鼓励大家想办法做减法，将组件变成8个、7个，或者6个，尽量将它简化。
另外，即使是今天看起来很好、很适用的技术系统，也要随着时间的推移，去持续地做减法，及时简化、优化系统架构。就跟衣橱里的衣服一样，换季不合身了就要敢于淘汰。
第三，要具备匠心。匠心和简单并不冲突，就像苹果的产品，虽然它的设计理念趋向简单，但在很多细节上都能感受得到它非常的用心。
有时检视一些不太好的系统，你会发现它们并不是单纯的只有一两处糟糕的实现，而是从整体到细节都没有用心，到处都很糟糕。在余沛看来，一个优秀的工程师，做一个优秀的设计，至少达到95分以上，否则后期返工、维护的成本就会很高。
他举了个例子，之前做一个基础组件系统的研发的时候，出了第一版设计，不合格，被评审打回，之后的第二版、第三版依旧不合格，依旧被打回重做，这样来回返工六七次才通过。看起来似乎对交付有一些影响，但后来这个系统一次上线就持续运行了四年，期间几乎无故障。还是希望能在交付时间接受的前提下，尽可能地养成匠人精神，这样无论是对个人还是对系统而言，都是终身受益的。
另外，需要强调的是，匠心与交付也并不冲突。匠心不代表成本要从1变成10，花费超额的成本来成就匠心，而是要求我们在做事的过程中，将心注入，追求极致。否则，原本一天就能交付的工作，由于“匠心”要额外花费十天才能完成，反而会与公司目标冲突。
对如今的互联网行业来说，快速交付是一个非常重要的能力。但是，快速交付并不意味着质量上的妥协，很多时候，这是一个态度的问题。以炒菜为例，优秀的厨师与差劲的厨师，用在“炒”这个动作上的时间和步骤其实不会相差太多，好与坏的区别取决于用不用心。而这“用心”其实是包括你前期食材、工具的准备、平时的训练、对理念和目标的思考等等，这些才是更重要的。
而在技术上，所谓的匠心也不是单纯的指在写代码的时候吹毛求疵，关注注释有几种写法、括号应该怎么换行等，而是写代码之前，有没有过真正的思考与梳理，这才是差距所在。
对于中层管理者阶段
再来看中层管理者阶段，余沛表示，对于中层管理者，他会更倾向于让中层管理者成为能带头和一线同学一起往前冲的领头人，而不是站在背后拿着指挥棒的纯管理。至少在技术领域，他也相信一线的工程师更愿意跟随有使命感、以身作则、能力服众的Leader。同时，在实践中会尽量检视，避免中层管理者过早地脱离一线，成为“拿指挥棒站在后面的人”。
比如，他曾经定下了一个叫“CDR”的指标来度量中层技术管理者和高级别的技术专家。所谓CDR指标，即Code、Document、Review。中间的管理人员，不能太脱离一线，虽然他们身具团队培养管理、项目管控、应急指挥等管理职能，但仍然要在这三个指标上有对应的完成度。
要么仍然能和团队一起完成部分的核心代码，要是不写一线代码也可以，那么就要看重要系统的设计文档有多少的参与度，或者帮助团队成员做了多少的Code Review、提交了多少有意义的Comment。总之，至少要在CDR中的某个方面有明显贡献，不能太脱离一线。
包括余沛本身，即使现在大部分的精力都跟管理相关，但依然会不定期参与到部分系统的讨论、评审中去，不敢完全脱手。技术管理者坚持不脱技术岗，其实更能带动技术文化并将之更好地传递下去。
另外，在CDR三个指标中，需要特别强调一下Document的重要性。文档从来不是交付过程中的一个任务，与之相反，需要被提倡的是：代码是思考的产出，而文档就是思考的过程。
你可能见过很多工程师，不做设计直接Coding，然后边写边思考边改，还觉得写文档麻烦，浪费时间。其实用建筑工程来做对比就能想明白，你见过没有图纸就开始施工的工程吗？肯定没有。那为什么就能允许不做设计、不落地文档就开始写代码呢？还要美其名曰“快速交付”。
再怎么样求快，也应该在写代码之前有一个良好的设计过程。文档并不是为了产出一个file，而是利用写的过程中去思考、梳理逻辑，想清楚了再动手写代码。撰写文档看似会在前期花费一些时间，但写完后转成Coding的过程能够一气呵成，最终速度其实并不会比一上来闷头就Coding，发现不对又删了改、改了删来得慢。
对于CTO阶段
对于想再进一步，从中层管理者向CTO进阶的技术人，余沛给出了两点建议。
第一点，一定要更加深入、也更加广泛地参与并了解公司的核心业务，跟随公司的核心业务一起成长。在横向的维度上思考业务，在纵向的维度上思考用何种合理的技术解决方案，这样才能对公司的整体技术方向作出完善的规划。
最好是亲身到一线核心业务里走一趟，站在外面看跟站在里面亲身体验一遍是完全不同的感受。假如你是空降过来的，也务必要说服老板、创造条件把自己先放进核心业务里去看看，哪怕这个核心业务原来并不由技术主导。在这个过程中，再用自己的技术专业眼光，帮助公司重新审视业务。
比如某个工作一直由运营负责，他们会遵循他们一贯的思维方式和做事习惯，没有人从更高的角度来重新审视的话，他们是不会意识到还可以用其他手段来改进流程、提高效率的，也无法跳脱出以往的习惯。而你尝试去了解之后，很有可能发现技术可以在某个点上帮助到他们，让他们事半功倍。
第二点，尽快将自己的目标从原先较为单一的技术类目标，或者项目进度完成指标，转变成公司的业务目标，力争把技术与业务这两条线聚合到一起。这是非常重要的，因为只有你把这两条线聚合到一起，你才会更多地站在公司、业务的角度，越来越多地从资源分配和收益等角度去思考问题、判断现状。否则，如果长期只单纯关注技术，就会忽略背后需要的投入与产出、成本与收益等问题，无法顾全公司大局。
最后，余沛强调，技术团队中单项能力最强的其实不一定是CTO，相反，如果CTO成了公司里技术最牛的，其他人都不如他，离了他运维也不行了、安全也不行、架构也不行了，那才是最危险的。CTO这个职位需要做的，一是把控好技术方向，清楚认知公司业务在哪些方向需要用到什么样的技术；二是帮助公司培养具体领域技术最牛的人才，这才是CTO最本质的职责。
因此，技术管理者要成长为CTO的关键点，首先还是在于观念的转变，要打下扎实的技术功底和相当广阔的技术视野，还得锻炼提升自己对于业务的理解能力、对于成本的控制能力、对于团队的建设能力，以及协调与沟通的能力。简而言之，就是不仅要能够帮助公司利用最优的成本解决掉问题，也能够让研发工程师们过得有存在感、荣誉感和归属感，还得让外面的优秀人才源源不断地跳进来。
好，以上就是余沛对于技术人职业成长不同阶段所需能力的认知和期望，希望他的思考能对你有所启发。
另外也在这里做个小调查，你现在正处于职业成长的哪个阶段呢？在你的认知中，这个阶段所必需的能力有哪些，你当前欠缺的又是哪些方面的能力呢？欢迎在评论区多多留言分享你的思考。
卖桃者说，明天见。
（策划：成敏；编辑：夏天）