|
|
|
|
|
# 07 | 对程序员来说，自由价更高
|
|
|
|
|
|
|
|
|
|
|
|
**极客时间：**饿了么的技术文化是什么？
|
|
|
|
|
|
|
|
|
|
|
|
**张雪峰：**用一个词来总结就是自由。自由到就是同学不爽，我可以让他换岗之类。但后面我很难做到了，因为没有那么多岗位可以让你随便调，要么就是让另一个岗位挪，要么就是我造出岗位，但这其实是一个很大的风险，因人设岗是可以的，要看什么人，你也不能经常用这种招数，绝大部分情况下，你还是要守正。
|
|
|
|
|
|
|
|
|
|
|
|
刚开始我可以让同学们吐槽，因为你迁就了这个同学，让他做了自己感兴趣的，有可能他到一个新团队，别人可能跟他配合不好，所以这个也需要平衡。刚开始我基本上尽可能满足同学们的诉求。
|
|
|
|
|
|
|
|
|
|
|
|
对程序员来说，自由真的是价更高，你要给他一定自由度。
|
|
|
|
|
|
|
|
|
|
|
|
**极客时间：**除了“技术自由度”，还有别的关键词吗？
|
|
|
|
|
|
|
|
|
|
|
|
**张雪峰：**饿了么以前其实是有六个字来代表企业精神的，叫极致、激情、创新。因为我们本身推崇的就是极客文化，刚开始完全按这个来的，因为我们CEO Mark他特别Geek，他特别推崇扎克伯格，特别推崇键盘改变世界这种理念，所以我们都受他的影响。
|
|
|
|
|
|
|
|
|
|
|
|
技术团队我们当时也总结过一些词，我印象最深的就是开放、自由，我认为开放、自由，这就是我给程序员最大的两个词。
|
|
|
|
|
|
|
|
|
|
|
|
**极客时间：**前面我们聊收购百度外卖的时候有说过工程师的技术素养问题，工程师的基础能力是基本的，除此之外，大家肯定也要有一些其他的软技能，你觉得比较重要的软技能都有哪些?比如沟通能力算不算？
|
|
|
|
|
|
|
|
|
|
|
|
**张雪峰：**沟通这个词比较泛，举个例子，比如说最简单的Presentation的能力，不管你晋升述职还是跟老板汇报，PPT是绕不过去的，虽然很多人讨厌这种方式，但你绕不过去，因为你要让别人知道你的想法，不可能上来都是Demo、代码，这不行的。一是写PPT，二是把它讲出来。
|
|
|
|
|
|
|
|
|
|
|
|
大部分的工程师都是受Linus Torvalds（林纳斯·托瓦兹，Linux之父）的影响，在不想沟通或者自己不擅长沟通、表达、分享的时候，就扔出来那句话，“Talk is cheap,Show me the code”。其实，这句话有他的语境，你看Linus的表达能力是很好的。所以，我和团队说，“Talk is important”。
|
|
|
|
|
|
|
|
|
|
|
|
加入阿里后，我也参加过几场晋升述职，去担任评委，人家PPT几乎没有写得烂的，水准都很高，但是讲得有差异。演讲的技巧非常重要，而且其实这项能力在外企是特别重要，因为在外企还要用不同的语言跟别人去沟通。
|
|
|
|
|
|
|
|
|
|
|
|
另外，写Email也是个技能，我有时候写Email都要反复措辞的，要发给谁，抄送给谁，还有密抄给谁，这种都需要小心的，这方面我统称为Presentation。你说的人与人沟通那属于情商，Presentation Skill是你要让对方明白，同时你要看懂对方要表达的意思。
|
|
|
|
|
|
|
|
|
|
|
|
但也有些人走火入魔，比如PPT一搞就搞100页，那个也不行，还是需要抽象能力。一般来说，程序员抽象能力都还可以的。
|
|
|
|
|
|
|
|
|
|
|
|
我再讲个小故事，饿了么曾经有一个小伙子，那哥们特别神奇，我很看好他，他晋升述职不用PPT，一上来就说，我本来准备了一个PPT，后来想想没必要，我就跟大家讲一讲，然后就开始脱稿讲。
|
|
|
|
|
|
|
|
|
|
|
|
当时上海的评委只有一票投反对，因为他确实讲得不错，不需要PPT他能讲清楚。但这次晋升答辩北京团队清一色全部投否决票，因为这是百度体系不能容忍的方式，你这是对评委的不尊重。最后结果是我求情让他过了，这个其实不太好，但因为我对他有些偏爱。我只是举个例子说做演讲这个事情。
|
|
|
|
|
|
|
|
|
|
|
|
**极客时间：**对一个人偏爱，会不会让其他人觉得不公平呢？你怎么看这事呢？
|
|
|
|
|
|
|
|
|
|
|
|
**张雪峰：**肯定会有不公平议论，说实话，饿了么让我偏爱的同学比较多，有我一直在孜孜不倦准备的 CTO backup（接班人），还有就是让很多同学有“苦”说不出的我最偏爱团队 CI（Core Infrastructure）。
|
|
|
|
|
|
|
|
|
|
|
|
没办法，人都有自己偏好，纯上帝视角、无利益相关几乎没人能做到，更不要说持续做到，对我来说，尽量在偏好和公平之间取得一定平衡。比如：我虽然偏爱 CI 团队，但出了故障或 CI 被吐槽、投诉，我一般也是先追杀 CI（兰建刚/徐盎/刘焱等同学苦张雪峰久矣），被我挑战最严厉的一般也是 CI 团队，即使主责或 Root cause 不在 CI 团队。
|
|
|
|
|
|
|
|
|
|
|
|
又比如：我虽然偏爱石佳宁（中台技术团队负责人，二代 CTO 首选）、黄晓路（全局架构组负责人）、许红涛（商户开放平台技术负责人，三代 CTO 首选）等同学，但佳宁、晓路他们也是我在部门例会或各种群里 Challenge 最多的几位同学。
|
|
|
|
|
|
|
|
|
|
|
|
**极客时间：**你觉得技术团队的价值体现在哪里？
|
|
|
|
|
|
|
|
|
|
|
|
**张雪峰：**我后来到阿里，行癫（阿里云总裁、前阿里巴巴集团CTO）跟我们开会说过几次，他说技术团队的价值是什么？我们脱口而出驱动业务，他说不可能，我今天明确跟你们说，不可能。
|
|
|
|
|
|
|
|
|
|
|
|
在他看来，技术只有两个核心价值。第一就是对于验证成功或接近成熟的业务，你要帮它做Scale，快速做规模化，不要线性。比如从1-10用了10天，那你从10-100应该只用两天或一天。
|
|
|
|
|
|
|
|
|
|
|
|
线性就是用工程师堆业务逻辑嘛，业务逻辑就是需要人的，虽然很多人说讨厌CRUD，但也没办法，业务逻辑人工智能是搞不定的。反而中间件是很容易做规模化，非线性的东西是难度高，但一本万利。中间件一开始投入很大，比如投入100多人，这些人都很贵，公司可能说凭什么要投资他们，又看不出交付了多少业务需求。但这样考虑是不对的，一旦上线，价值非常大。
|
|
|
|
|
|
|
|
|
|
|
|
第二，就是技术团队要帮业务团队快速试错。这个我是在饿了么深有体会的，Mark就总是说，你要上线了，我才知道公司这个业务行不行，能不能活下来，哪有时间让你搞什么架构。饿了么2009年第一版快速上线，绝对归功于 No Architecture，汪渊（Raymond）居功至伟。我曾和他聊过这事，如果当初饿了么找我做第一版，我绝对迅速搞（拖）垮公司，最简产品、唯快不破 vs. 完美架构、技术洁癖之间很难调和。饿了么那时候最重要的是速度，你也不要管什么战略不战略的，你就给我最快速度上线、试错。
|
|
|
|
|
|
|
|
|
|
|
|
饿了么创业就是靠试错试出来的，快速创新完全是基于快速试错的，现在对这个理念我是绝对的拥趸。那种瞬间虎躯一震、如有神助、不用试错就一炮打响的成功业务，用凤毛麟角来描述都算夸张了。
|
|
|
|
|
|
|
|
|
|
|
|
**极客时间：**“技术驱动业务”这句话在技术圈太常说了，很多人也是这么认知的，你现在对这个观点的看法呢？
|
|
|
|
|
|
|
|
|
|
|
|
**张雪峰：**就像我刚才说的，行癫的视野是非常开阔的，我很佩服他，他说你今后不要再跟我说妄图去驱动业务，只有一种情况，像Google这样靠技术驱动纯线上业务的，才有资格去说驱动业务（今后如果无人车实现商业规模化，或许也算一种）。阿里又不是纯线上的，我们还有很多销售人员要去谈合作的，技术主要还是推进业务实现。
|
|
|
|
|
|
|
|
|
|
|
|
所以现在一看到技术驱动业务的文章，我确实也不怎么会去看，除非你做的就是技术产品，比如数据库之类的基础软件产品。所以他总结的这两条技术团队的核心价值还是很淳朴的。
|
|
|
|
|
|
|
|
|
|
|
|
**极客时间：**前面聊了很多，能感觉到你很在意同学们的职业成长，希望给大家自由度，或者说希望大家都能好好思考自己的职业生涯。
|
|
|
|
|
|
|
|
|
|
|
|
**张雪峰：**肯定，我希望大家尽可能喜欢自己做的事，在这个层面，我也有挺多反思。比如说，其实我们前端团队经历过动荡的。
|
|
|
|
|
|
|
|
|
|
|
|
有一段时间，我们所有的前端都是归Sofish（原饿了么前端负责人）一个人管的，C端、B端、物流都要做，但是后来出了问题。有人就说，这些做前端的家伙，整天去搞开源（其实有失偏颇），搞最新的那些东西，搞他们自己喜欢的那些东西。但对业务来说，我们希望进度再快一点，也希望他们能和我们一起加班，哪怕你在那磨洋工呢？人就是这个心理，不患寡而患不均。
|
|
|
|
|
|
|
|
|
|
|
|
因为我跟你一个团队，都是搞技术的，你说产品经理不加班还可以理解，咱们都搞技术，你不加班，是不是你工作量不饱和？Leader会去质疑你的成员，平级（Peer）也会质疑的。
|
|
|
|
|
|
|
|
|
|
|
|
但Sofish他不管这些，后来我说你面儿上也得过得去，让同学们在那边加加班。其实联调几乎都是后端的锅，前端他们做的质量确实非常好。Sofish就说，我干嘛要让他们非要待到8点以后？后来他这个团队是被我摁着加班的。
|
|
|
|
|
|
|
|
|
|
|
|
后来摁不住了，我就跟他说算了，你把你做物流的前端切出去，切到了物流的研发团队，就汇报给那边。我们早期其实除了C端，都是这样的，就是每一个产品的研发包括前端和后端都是在一个团队。后来是因为Sofish做得真的很棒，所以我希望他把所有前端都管起来。这个事儿可能我当时也有点认知偏差，其实这里面是有矛盾的。
|
|
|
|
|
|
|
|
|
|
|
|
比如对前端来说，你汇报给业务的研发团队，这样做业务交付，效率是最高的。但是对于个人成长，对自身的技术追求来说，其实是比较糟糕的，因为你没有同道中人啊，你跟后端没法交流。
|
|
|
|
|
|
|
|
|
|
|
|
如果前端大家都坐在一起，就会很有共同语言。平时还能搞一些技术分享会，那如果你去了业务团队，你位子要搬，就可能缺少这样的条件。当然这不是绝对，只是我的看法，有些团队前端跟后端在一起也非常好，他们内部也会搞一些小技术创新什么的。
|
|
|
|
|
|
|
|
|
|
|
|
但有些团队他们就感觉很失落，尤其物流团队的前端切出去之后，他们业务的交付速度是快了，但同学的职业生涯可能会有遗憾。就是我认为技术的职业生涯和你做交付的效率其实是有天然的冲突的。你很难做到让他技术有很大收获，又让他交付速度很快，因为交付速度很快证明你很难有时间学习，更何况大家不坐在一起。所以在这件事上我们走了一些弯路。
|
|
|
|
|
|
|
|
|
|
|
|
另外，Sofish他其实是比较纯粹的技术人，他的主要精力还是放在对前端技术的不断追求上面，比如说性能、框架、工具。因为前端有很多的东西需要做，比如他们用的框架、工具，很多是他们自己做的。反过来，他们对业务的关注可能就有点不够。
|
|
|
|
|
|
|
|
|
|
|
|
有时候我感觉，“拔苗”是可以拔的，但有些“拔苗”其实非常违背同学们本意。虽然没出什么大事，但下面大家的冲突并不少、吐槽更多，后来我就做了调整。所以，组织架构调整很难的，像阿里这么成熟的组织体系还经常调组织架构呢。
|
|
|
|
|
|
|
