两位前阿里 P10 的成长经历，让我学到这几点

大家好，我是 shixin

最近看完了专栏《超级访谈：对话毕玄》，这个专栏和年初看的《超级访谈：对话汤峥嵘》类似，都是对阿里 P10（程序员金字塔顶端大佬）的访谈，介绍了他们的成长经历和人生感悟，让我受益颇多。这篇文章里我将对这两个专栏的内容做一个对比总结。

本文主要包括这些内容：

1. 阿里 P10 大概是什么概念
2. 两位 P10 大佬的成长经历
3. 两位 P10 大佬关于常见话题的见解

• 成长心得
• 职业发展

阿里 P10 是什么概念

可能很多人对阿里 P10 是什么概念还不清楚，这一节我们来简单了解下。

P 序列是阿里内部评价研发等职能人员的级别体系。

一般来说刚毕业是 P4（本科） 或者 P5（研究生）；工作三年左右达到要求者可以升至 P6 高级工程师；工作五年左右、技术达到一定深度可以升至 P7 技术专家，这个阶段确定性还是很强的，一般只要投入一定的努力就可以实现。

再往上走就不单单是个人努力这么简单，天时（大环境和业务所属赛道前景）、地利（业务发展情况）、人和（个人能力和领导）缺一不可，运气不好可能一辈子都没机会再往上升，因此 P7 是大部分程序员的职级天花板。据统计，阿里停留在 P7 级别的开发约有万人。

如果足够优秀并且幸运，可以负责较大业务的一端技术（比如 Android/iOS/前端/后端），就能达到 P8 技术主管级别。据统计，阿里 P8 级别的开发约有五千人。

再往上，不仅具备某一端的技术能力和管理能力，还具备跨端沟通协作和商业思维，可以为业务整体技术保驾护航，就达到了 P9 总监级别。据统计，阿里 P9 级别的开发约一千余人。

再往上走就到了我们今天要学习的两位大佬的级别：P10 研究员/资深总监。P10 不仅在公司内很有话语权，同时在行业内也有很大的影响力。据统计，P10 在阿里大概只有五百人。

通过以上数据我们可以看到，在二十多万员工的阿里集团中只有几百人可以达到 P10 级别，几乎可以算的上千里挑一、人中龙凤。他们的身上一定有很多优秀的习惯和个人素质值得我们学习。

两位 P10 大佬的成长经历

相信不少人和我一样，对这些高段位大佬的成长经历有很强的好奇心，想知道他们是如何达到这一步的，这期间有什么关键的选择。这一节我们来看下他们的成长经历，通过了解前辈是如何成长的，可以帮助我们站在更高的角度审视自己。

汤峥嵘的成长经历

首先来看下汤峥嵘前辈成长的关键节点和值得我们参考的点。

关键节点一：到美国留学

汤峥嵘在读书时就很优秀，90 年代在清华读书，大学期间选择退学去美国留学，在美国半工半读的经历，让他逐渐学会自己做选择、对结果负责。

汤峥嵘提到，在大学时他知道中国的计算机水平比美国差的很远，于是选择去更发达的美国去看看。当时（九十年代）国内的互联网刚起步，在美国学习、工作会比在国内机会更多。

中国互联网大事记

值得我们参考的：

汤峥嵘之所以能够去国外留学，一方面是因为他知道国外计算机更好，另一方面是因为他有很强的“选择更先进的环境“的思维，即使换个环境会面临很多不确定和孤独，但他更关注确定的一面。这一点值得我们学习。

有时候我们只知道低头做事，却不知道环境对结果的影响，同样的力气，在平地上走和在自动人行道上走，明显后者速度更快。

在成长阶段，去更发达的环境里会让我们事半功倍，比如去更好的学校、更大的公司、更发达的国家/城市。环境的影响虽然短期内可能没有那么明显，但假以时日，差异便会凸显出来。

那如何知道“什么是更好的“呢？这其实有点“马太效应”，所处的环境越好，有效信息密度越大，知道的好东西、好方向更多，于是“富人“越富。

过去已然无法改变，我们能做的就是在日常生活里，主动去参与一些有价值的活动、项目，在其中认识更多的人，从而获取更多有效的信息，并且调整自己的行动。

关键节点二：美国工作十年

1995 年硕士毕业后，汤峥嵘选择留在美国工作。前六年在匹兹堡，后四年在硅谷。

在找第一份工作时，汤峥嵘投了两百份简历，并且每份都做了个性化修改。他把这种行为叫“过度努力”，就是把 60 分就可以的事做到八九十分。

第一份工作中他很快就做到了技术主管的职位，究其原因主要是亮点：

1. 通过“过度努力”的精神做好接手的所有任务，让领导逐渐对他简历信任
2. 比如在地图上展示不同地区的需求，如何绘制不规则的地图在那时候网上还没有现成的例子可以参考。他花了些“笨功夫“把 50 个多边形都标记出来，然后逐一绘制出来，演示结果让老板很满意
3. 经常看别人的代码，看到写的不好的就顺手改了，改完之后就变成他来维护，后来到 80% 代码都是他一个人在维护

在匹兹堡工作时，业务发展经历了快速发展（招了很多人）、钱烧完（裁员）、被收购（又招人）多个阶段，由于汤对业务和代码的熟悉程度，始终没有影响到他的工作。

第一份工作让他明白：做技术编程能力是第一位的，只要有能力，公司倒了都不怕。

后来汤峥嵘去硅谷工作了四年，在那里换了好多家小公司。相较于第一份工作中的踏实做事成长，在硅谷他遇到职业发展的迷茫：是做管理还是往技术上发展。最终由于没有适合的工作，决定回国加入淘宝。

值得我们参考的：

首先值得学习的一点是“利用优势打出价值”。

我们需要知道自己当下在什么方面是比普通人有优势的，趁着自己优势还在，选择能够发扬优势的方向，而不是丢掉优势和别人同起点竞争。

汤峥嵘毕业后的第一份工作年薪四万美金，在当时这是相当高的，要知道同一时期的北京平均年薪只有 8144元。

北京历年平均工资

在 1995 年，美国 GDP 大约是中国的十倍，能够在更发达的国家做互联网，这就是汤当时的优势。如果他毕业时选择回国工作，就相当于丢掉了优势，浪费了一把好牌。

中国、美国历年GDP数据比较

另外一个值得学习的点是“过度努力”思维。

汤峥嵘说“做所有事总是喜欢多做一点，我才放心”，这其实是他个人素质的外在表现，说明他是一个有高标准的人，事事力求做到较好，不随便，用常说的话就是“很靠谱”。

在读书时，我们的努力程度可以通过成绩和排名看出来，因此有时候会迫于外界压力逼着自己做一些事。但工作以后，很少有人会直接告诉你，你做的事可以得几分。在标准变得模糊后，事情要做到什么程度，就完全看做事者的内在要求。

对公司来说，肯定希望员工都尽职尽责把事情做到更好。在招聘的时候之所以优先选择学历更好的人，一部分原因也是因为能够上好学校的人，往往对自己要求比较高，做事有高标准。

对个人来说，我们需要积累一个个成功案例，让别人可以快速的知道自己是靠谱的。因此在面临“随便一点还是认真一点“时，尽可能的认真一点吧！

关键节点三：八年阿里时光

2003 年看到吴炯（阿里第一任 CTO）在清华 Email 群组发的招聘广告，由于当时处于职业发展的迷茫期，看到国内互联网的氛围越来越好，汤峥嵘决定参加面试，最终也通过了。

在保留一年 offer 后，2004 年汤峥嵘决定回国加入淘宝，作为主架构师，负责架构迁移工作。在当年 10 月转到支付宝部门负责技术，带领 Sun 外包开发项目。后来做了六年 B2B 业务，前三年负责国际网站的技术，三年后任日本阿里巴巴 CTO。

阿里大事记

加入阿里后，汤峥嵘的职业发展不再迷茫，走上了管理路线。

在阿里的几年里他逐渐认识并接受了阿里文化，在专栏里分享了很多关于管理的话题，后面的部分我们会具体查看。

值得我们参考的：

首先一点是获取高质量信息。

汤峥嵘能够看到淘宝的招聘广告，源自他的清华 Email ，这本质上就是高质量信息渠道。这让我开始反思自己平时关注的信息，有多少信息是对以后有价值的，信息来源是否是高质量的。现在我获取信息主要来自公众号、新闻网站、书籍、付费课程网站、技术网站，很多是二手信息，并且还局限在某一技术领域，少了些更高层面的信息，比如国内外互联网行业发展等。

还有一点是有意识的积累信心。

汤峥嵘认为阿里给他最大的价值是让他积累了很多信心：“一个人往前走，你的信心是怎么来的很重要，我想就是因为我过去做成功的几件小事情，然后复用这个经验，或者凭借这些成功给我的信心，不断向前”。

当我们做成一件事后，即使这件事很小，心里也会有微小而充实的幸福感。这个时候，我们最好有意识地记录下这件事的因与果，在大脑中不断强化选择和结果的映射，这样在后面遇到类似的事情后，可以最快的做出选择。

比如前段时间在公司内的黑客马拉松获奖后，我及时复盘并记录下偶然背后的必然，这样后面遇到类似的比赛，我就会多一些经验。

关键节点四：加入途牛和 VIPABC

2013 年汤峥嵘离开阿里，加入了途牛担任 CTO。之所以选择途牛，是因为他觉得途牛创始人比较年轻（80后），对移动互联网的机会更有敏感度。汤峥嵘选择的时间点很好，一年后途牛就在纳斯达克上市了。

途牛 2013 年前后大事记

在途牛任职期间公司高速增长，技术团队从 200 人扩张到 1500 人。作为 CTO，汤有很大的发挥空间。他的核心任务：

1. 一个是能够理解老板要做什么事情，甚至能够站在他的角度去思考
2. 另一个就是要快速组建团队

在这个过程中，除了思考如何招到这么多优秀的人、能在队伍快速增长的时候保持好队形（招培育留），还需要不断地根据业务发展调整技术架构和组织架构。

离开途牛后，汤峥嵘加入了 VIPABC，在专栏里他聊了很多关于 2018 年裁员的事情。

为什么公司要裁员？一方面是公司为了应对市场变化防御性调整，另一方面也是由于每个主管的淘汰惰性（没有压力不会主动淘汰人），需要公司层面出压力逼着去劣存优。

当外部环境要求企业快速扩张的时候，管理者要冷静思考招什么样的人，怎么搭组织结构。企业快速扩张起来以后，一定要花足够精力去管理团队，并且不断灌输危机感，告诉大家随时会裁员。当真的遇到需要收缩的时候，同样要冷静思考让哪些人离开。

关于招人和裁人，他总结了这几点：

1. 招人的标准要高

• 面试的时候盯着一些细节去问
• 经历里选几件重要的事问技术细节，看是自己做的，还是只是参与下甚至其他人的项目
• 把项目里遇到的真实问题抛给他，看他如何解决
• 根据进来后的表现，优化自己的面试问题和判断方式
• 看重的特质：聪明、可以沉下心搞技术、有责任心

1. 淘汰的标准要让团队清晰

• 技术能力是首位
• 在项目管理这块，我希望他们能让我提前预知风险，有什么问题预感到不妙，要提前让我知道，不要拖到最后一刻

值得我们参考的：

作为程序员，我们在换工作或者加入新项目组时，很多时候可能只考虑了项目盈利情况、工资和职责，汤峥嵘给了一个更高层面的思考内容：考虑“要加入的领域在这段时间内，技术能否发挥重要价值”。

在回顾途牛那段时间的快速增长时，汤峥嵘说到：“我们做出来的东西能产生商业价值，因为它确实改变了原来旅游业的商业模式”，比如发明新模式“目的地成团”，改变原有的出发地成团模式，提升成团概率。

如果在这个行业里，技术做的只不过是线下转线上，并没有带来实质性的改变，那发展空间可能就不大。

“互联网应该是解决长尾资源的问题，假如这个资源多出来了，互联网可以帮你卖掉，但是如果本身就是个稀缺资源，就不适合放在互联网上，互联网恰恰是要卖那些不太好卖的东西”。

毕玄的成长经历

上一节我们了解了汤峥嵘的成长经历，相较于汤的高起点（清华、美国留学），毕玄的起点更接近普通人。在阿里工作十四年中，毕玄主导实现了三个非常牛的技术项目。这一节我们来看下他的成长经历。

关键节点一：小公司里脱颖而出

毕玄大学专业是生物。虽然不是计算机本专业，但他从大二开始就为外面的公司写商业网站，这让他有了行业经验，让后面入行多了些优势。

2002 年毕业后，进入一家做政府项目的公司。一开始由于不会 VB(Visual Basic)，做项目实施（现在叫交付工程师）。半年后组里缺程序员，经理出了道编程题，答出的可以转岗。毕玄在截至日期前解决了问题，成功转为程序员。

在小厂的第五年，他花半年写了 OSGi（Open Service Gateway Initiative，开放服务网关协议，基于插件体系，拓展能力强，Eclipse 就是一个例子） 的 OpenDoc，由于当时 OSGi 在国内关注度很大，但是相关文章比较少，他的文章获得了比较大的关注，因此被称为“国内 OSGi 第一人”。

值得我们参考的：

毕玄在淘宝多年工作中做了很多高价值的项目，其中很多都是转方向以后做的，技术方向的判断力着实让人佩服。

回过头来看他锋芒初露时，我们会发现他之所以能够在 OSGi 领域有知名度，是因为他在国内对 OSGi 还没那么了解时就已经对 OSGi 很熟悉，并且花时间撰写了开放文档。这种学习一手知识、紧跟国外的技术趋势并及时引进国内的思维值得我们学习。

关键节点二：加入淘宝，负责 HSF

2007 年年底，毕玄加入淘宝。加入淘宝是通过熟人内推，而熟人就是通过 OSGi 文章认识他。

虽然面试回答的不怎么样，但当时淘宝招聘要求没有那么高，只要有一个点是非常专业的就可以，毕玄的专业点就是 OSGi。

进淘宝后他负责 HSF(High-speed Service Framework，分布式 RPC 服务框架) 的设计和实现，现在 HSF 每天还都承担着百亿次以上的服务调用。这个复杂的项目让毕玄认识到：

1. 负责流量越大的系统，就越需要对整个系统的所有环节都要非常非常清楚
2. 以前可能认为十万分之一的问题不会出现，但在一个大型系统里，它是必然会出现的

反思当时的技术选型时，毕玄认为 HSF 使用 OSGi 是错误的选择：

1. 程序员技术选型容易主观，梦想用一个很先进的技术去做一件事情
2. 技术选型，关键是反思选择把原来的东西改造新的，对当时这家公司来讲，对客户、用户来讲，意味着什么？到底有没有帮助？是不是一个很好的长期发展选择？
3. 商业是一个妥协的问题
4. 面试很多 P8 升 P9 的架构师，问的核心话题都是你在这一轮架构设计里面做过什么选择和平衡
5. 越高级别的人，越需要回答的问题是你为什么要干这件事情，而不是你怎么干这件事情，以及怎么解决里面各种各样的技术难题，这些是偏执行层面的

值得我们参考的：

在淘宝面试时，虽然毕玄很多问题没答上来、算法问题也没写出来，最终还是由于深入了解 OSGi 被录取。

今天很多公司的面试其实也是这样，除了考察基本技能，更重要的是确定面试者是否有某个方向很擅长。只要有一个方向掌握的很好，那就说明他具备深入学习的态度和方法，工作里遇到问题需要学习新知识时应该也不会花太多时间。

当我们为了换更好工作而学习时，什么都学不如找一个有价值的方向深入了解。

关键节点三：转岗做淘宝私有云 T4

在 HSF 比较成熟后，毕玄又去做了 NoSQL 数据库 HBase 的改进和落地。HBase 推广落地一段时间后，觉得自己对团队帮助不大，又开始迷茫自己到底该干点啥。

2011 年他从《Web 容量规划的艺术》中找到灵感，决定去做容量成本优化的事。找运维同事拉了份数据发现机器的利用率有很大提升空间，于是转岗去负责淘宝私有云 T4 的设计和落地。

虽然毕玄对 T4 的相关技术也不是很了解，但他知道目标和价值，于是找了很多专业的人组成一个虚拟团队。因为大家对目标理解完全一致并且认可，因此愿意花时间在这个项目中，最终真的做成了。

复盘这个项目时，毕玄做了这些总结：

1. 一家公司到了一定的规模，你想做的事情肯定也会有另外的人感兴趣，就看你能不能找到这样一帮人并且组织起来做成

• 关键看你做了什么事情对这家公司好，都是看结果
• 技术人员如果对你有信任，并且他也相信这个事情是有价值的，其实大家是愿意用业余时间去干的

1. 对技术 Leader 来讲，其实判断是对是错不重要，因为对方向的判断是很主观的，没到那个时候很难说谁对谁错。但最怕你没有判断，外面怎么样，你觉得就是怎么样，那这就不要干了
2. 带了一个很大的虚拟团队去做一个很大的事情，也拿到了一个相对不错的结果，但比起对我的影响，对其他人的影响是小很多的，这个状况我不是很喜欢。对一家公司来讲，以战养兵是最重要的。

值得我们参考的：

最近几年，降本增效成了各个公司的普遍口号。让人敬佩的是，毕玄从 2011 年就开始关注企业的运维成本，在互联网业务高速发展的当时能够关注这点，足以证明他的先见性。

对于企业来说，需要攻守双管齐下。除了关注业务拓展、收入增加，我们也可以向毕玄学习，多关注公司的支出成本，从日常的资源使用出发，思考如何降低成本提高效率。

关键节点四：转岗运维，做异地多活改造

2013 年毕玄决定从研发转到运维，之所以转变，是为了从全局了解公司的技术运维情况。正好当时要做淘宝异地多活，于是花了几年时间做了广为外界所熟知的淘宝异地多活改造。

在当时做异地多活的难点是全世界完全没有可参考方案，花了半年多才逐步把方案试出来。毕玄感慨道：“技术圈子的人，见过猪跑太重要了”。做这种大的架构，一般是先有一个系统全貌，然后有解决的思路，就可以大概知道需要哪些人来做。然后去找各领域的人，告诉他我的思路是这个，你看这个系统里怎么改能做成这样。

异地多活项目，涉及的人太多，必须要先提一个思路，然后大家开始探讨，最重要的是，参与的各方都要获得利益。

运维这段经历，一方面让大家觉得他是能做整个大系统架构的人，另一方面也拓宽了他的知识面，让他知道了一个系统真正的全貌。做系统设计，不可能忽视下面的基础设施完全当它是个黑盒。研发作为一个系统的掌控者，这些应该要掌握的。

值得我们参考的：

做异地多活后毕玄刚好做 P10 晋升面试，有人问他这些人都不向你汇报，为什么要听你的？他说最关键的就一点：“因为我还掌握着所有人的机器“。

话糙理不糙，在做内部的架构升级或者优化时，如何推动业务改造、使用，是个让人头疼的话题。很多时候业务方都会忙着做需求，对于依赖的基础功能漠不关心。

毕玄的经历告诉我们，要想真的推动改革，必须把控核心资源，通过资源限制才能强推落地。

关键节点五：做统一调度和研发效能

2016 年毕玄开始带系统软件事业部跟研发效能部，一开始大概三四百人，后面有五六百人。

当时的两个目标（本质都是成本）：

1. 做好统一调度

• 离线业务和在线业务使用同一个机器池，提高利用率
• 可以用一个指标直接体现：公司所有服务器全天的平均利用率
• 大部分公司应该都小于 10%，阿里 16 年开始做的时候是 8%，Google 发表论文的时候大概是 50%
• 现在阿里这个团队还在做，去年做到了 30% 左右，天花板是 60%

1. 解决研发效能团队的定位问题

• 研发工具链条特别长：写代码、编译、打包、测试
• 代码编写：IDE 的改进，代码智能化 （GitHub Copilot）
• 编译：Google Bazel
• 希望短期能不能稍微集中力量做出一两个亮点，只要有一两个亮点就足以证明这个团队对公司的整体研发效能是有价值的

第一个目标最终实现的比较好，从 2016 年到 2018 年，大概跑到了 1 万台机器，相当于在线有 1 万台可以给离线用，那一年离线少采购了 5000 多台机器，1 台假设 10 万，一年省了 5 个亿。

第二个目标做的比较艰难，本质上是因为研发效率无法直接量化，公司层面只会看到最后的人员增长。研发效率提升是个复杂的问题，因为它其实是个协作问题：

1. 第一个问题：协作开发模式

• 公司有这么多种类型的业务，要高度抽象出一个很好的协作模式，太难了

1. 第二个问题：环境干扰问题

• 测试环境不稳定，测试效率如果很低，意味着最终上线的周期肯定会被拉长

为什么很多公司想提升研发效能？

1. 大厂到了后面人效比是下降的
2. 每年都会觉得业务增长是这样，但研发人员怎么还在不断增长
3. 公司层面只看最后的人员增长

值得我们参考的：

做技术选型的时候，如果开源界已经有一个很成功的东西，自己又没有什么很颠覆性的思想，还是拥抱开源比较好，没必要挑战。

关键节点六：创业担任 CEO

毕玄在 2022 年创立贝联珠贯公司，担任创始人和 CEO，主要做资源调度产品。对于现在很多公司而言，人员和 IT 资产是最主要的两块成本投入。他们选择的赛道是提升 IT 资产利用效率，降低成本。

谈到创业方向的选择，他给了三个建议：

1. 选一个自己相对有优势的领域

• 第一次创业的人，八成只能做自己擅长的，其他的概率非常低

1. 从商业模式上来讲具不具备盈利的可能性

• 盈利，最重要的是你对客户的价值是什么

1. 可以被产品化和规模化

• 边际效应

谈到 CEO 的工作内容，他说 CEO 就是一个打杂的，公司什么事没人干就是 CEO 干，如果有人干，你最好就不要干了。

虽然梦想很重要，但盈利是第一要事：

1. 现在的融资环境，至少要一年半以上，我们都是按照18 个月准备的
2. 办公司当然要赚钱，但选择还是需要的
3. 在资金还够用的情况下，短期有些钱如果对公司业务发展没什么意义，就不要赚好了（个人也是，时间要紧）
4. 提升金钱支出敏感度

• 很多大厂出来创业的人，钱都不知道花哪去了

1. 有了很好很健康的现金流，再考虑一些梦想

• 阿里云能做为什么？就是有淘宝，能持续产生健康的现金流

对于 ToB 业务要想盈亏平衡需要积累多久，他认为至少需要三年以上：

1. 第一年，种子客户培养

• 相对乌托邦阶段，蒙头做一个自己觉得对这个世界很有价值的产品
• 拿了融资尤其，一你不缺钱，二业务增长也不是你这个阶段最重要的目标
• 等见到真正的客户让他付钱的时候，你可能就发现原来根本不是这样
• 太高调在中国真不是好事，卷得非常厉害的，抄袭也非常严重

1. 第二年，基于种子客户的赛道做规模化复制
2. 第三年，扩到一个更大的领域，不限赛道通用的

两位 P10 大佬关于常见话题的见解

上一节我们了解了汤峥嵘和毕玄的成长经历，从关键节点中学到很多。除了成长经历，专栏中还有很多话题的讨论，这里我摘录几个感兴趣的话题，看看大佬们的见解，主要包括：

1. 如何更快地成长
2. 如何换更好的工作/做对选择
3. 该怎样做技术
4. 如何做好管理

如何更快地成长

关于个人成长，汤峥嵘有这些建议：

1. 向优秀的人靠近

• 每个人在一个阶段到达天花板的时候，就需要有人能带你看到上一层的风景，多和贵人请教（贵人就是把你拉到上面让你看一眼的人）
• 要想成为优秀的人，就得有意识地向优秀的人靠近，同时接受他们指出你身上的缺点

1. 过度努力：

• 核心是积极争取，不计较得失，也不让自己后悔
• 现在很流行选择大于努力的理论，但我更相信努力。因为只有努力是自己可以控制的，选择、机遇、贵人、天分等都是自己无法控制的。

1. 像老板一样思考

• 当我把自己想象成老板的时候，我在提可选方案时会跟老板说：如果我是你，我会选择其中哪个方案。这相当于我给了自己一次机会跟老板交流，如果老板比较厉害的话，还可以给我指点，我不就学到了吗
• 独立承担责任：核心是自己有思考、做决定，接受任何后果，不把期望值放到其他人身上
• 当你觉得你是这件事的主人的时候，你会冒着非常大的风险去管理这个事情，去做选择。你可能会搞砸，失败了你没啥大损失，成功了有大收获的

1. 笑对问题

• 当你看到的问题越多，那就说明你的机会越多。对纯技术人来说，你就是要去解决公司里最难的问题，这就是你的捷径
• 普通人可能没有机会解决难题，牛人天天都在解决难题。给我们问题，就是在给我们机会

1. 晋升

• 在公司人缘好，认识的人多，而且做的事情委员会的人都了解，可能在晋升的时候就会占便宜，另一个人和技术委员会的人不熟，只用一个小时的汇报时间说服评委，总是有点难度

1. 无论是对商业、产品还是技术类的知识，你都要有一个系统化的积累过程，这样才能进步和成长

毕玄的建议：

1. 对自己负责

• 每家公司不对个人成长负任何责任，反正你没成长，公司大不了换一个人
• 但你自己应该有追求，用到的所有东西都应该去了解它背后是怎么回事，否则很容易被淘汰

1. 检验自己的水平

• 有一个很简单的方法：能分享多少
• 你讲多久能把自己讲空掉，就是你能力的极限
• 很多人用中文随便能讲两个小时，一换成用英文讲，10 分钟就讲完了，这其实就是你的英语水平

1. 很多新招来的人，都想一上来就铺天盖地做一件很大的事，真的想多了

• 你先从一件很小的事证明你就是比别人做得好，然后慢慢的别人对你有了信任，那你机会多了去

如何换更好的工作/做对选择

汤峥嵘：

1. 我绝大部分过去的选择都不是因为对前面的企业不满意，而是说在比较两个机会的时候，考虑下一个机会是否明显可以给我更大的提升
2. 要了解自己，你自己是什么样的人，喜欢什么样的环境，在去大公司或者小公司之前，把公司情况、团队情况、你自己的情况统统考虑进去，再做选择，而不是盲目地认为公司大小对个人就有决定性影响，还是要关注具体的人
3. 每一次换公司我都遵循一条主线，那就是：这个公司做的业务或者这个领域在这段时间内，能否通过技术进行比较大的变革，是的话我觉得投入就有价值

• 反例：挂号业务，不过是让医疗体系的技术往前赶一赶，没有让行业产生变革

1. 我是有意回避一些我认为悲观的东西，我觉得当你看到太多负面东西，或多或少就会在你脑海里沉淀下来，对你做判断会有影响

毕玄：

1. 正确的做事和做正确的事

• 公司大了以后，不同部门的职责不一样，有些时候基础部门会出于自己的考虑，拒绝业务部门的要求（正确的做事）。其实这个时候更应该做的事，围绕业务目标，给出规避或者解决的办法（做正确的事），否则业务不好谁都不好

1. 高级别的人换工作最大的风险：别人会对你的期待太高

• 如果去另外一家大公司，多数给的职位能比现在更高，大家对你的期待是完全不一样的，比如同样的事，我在阿里做要三年，别人就可能希望你在一年内带来很革命性的变化
• 工程就是工程，工程落地的节奏是很难压缩的，加速肯定会有风险

1. 没有平台，你有能力也没用

• 平台不够大，碰到的问题就不是世界级，可能别人早就碰到并且已经解决掉了，那你就不可能做很创新性的

关于该怎样做技术

汤峥嵘：

1. 做技术的还得听业务的需求，但是牛人可能就会在做业务需求的时候，发现技术有颠覆性的苗头，这个时候就可以跳出来说，本来这个技术是为这个需求去做的，但是我打算拿这个技术干别的
2. 阿里有行癫这样非常牛的人，他在一开始就把架构搭得很清楚了，在执行业务时候也很清楚

• 他指挥得好，中台搭建的速度就快
• 但如果公司的架构没做好，各个部门各自为政，这个大中台的转换就不会这么顺利。

1. 很多做技术的人特别喜欢定规则，他们自认为规则很好，但是这些规则常常反过来变成束缚了
2. 业务人员说今天要把刀，技术人就得今天扔个刀给他

• 技术人先不要想做一把多厉害杀伤力多强的刀，业务的人可能也不 Care 这个，他们就是想要把能用的刀，能大概砍几下就行了

1. 关于出问题

• 只要做东西就容易出 Bug，所以必须得在效率和错误率之间找到平衡
• 优秀的技术团队要能比用户先知道系统问题
  • 我们用真实的一小批用户试错，等到大规模用户来临前，我已经把 Bug 修好了

毕玄：

1. 程序员的价值关键体现在作品上，作品里很重要的一点是对业务、技术趋势的判断
2. 判断新技术是否有价值

• 围绕痛点去想，技术现在有没有可能把这个痛点往前推进一代产生很大的改变，你的新东西要解得更好，而不是小修小补
  • 比如大数据的演进，围绕算更快的诉求：Hadoop 解决能算出来，但有点慢；Spark 解决的是我通过架构改造，让你整个具备了算更快的能力；Flink 就更快，因为已经实时化了
• 第一步想清楚用户的问题是什么，第二步想具体怎么去解这个问题

1. 关于技术影响力

• 千万不要为了做影响力而做影响力，只看你对公司业务的影响
• 影响力是很容易培养的，你有了结果，也有贡献，做的方法也具备引领性，剩下的只要炒作包装一下就可以

1. 技术难度，不能光定义成纯技术侧的东西，其实还有很多是复杂性问题、抽象问题

• 做业务技术的人，他不是没有技术难度，他的技术难度在业务复杂度，能不能抽象成一个非常简单的东西，去支撑非常复杂的业务

1. 什么是架构师

• 根据需求设计解决方案，判断出每个系统要解决好的几个问题，有时候也负责核心代码的编写
• 第一是目的，第二是目标（目标即指标，如何考核你做到了），第三是系统组织设计
  • 第一要非常清楚知道你做的这个事情的意义，从意义出发思考解决方案，不局限手段，做取舍
  • 对未来项目技术发展趋势有判断，尽量支持拓展
  • 处理团队分工问题
• 越大的架构师越是个框架，是个方向性指导，定义了一个目的，最后确保这么多人协作不会走偏
• 必须说清楚我的总体思路是什么，然后你这部分最重要的是要做好什么
• 技术上的架构师是我必须要设立一些指标，可以确保你们上线了我也能看
  • 如果不能量化，应该是这个架构师没有想得很清楚
• 解决思路有很多种，你为什么选择这种？你的思路是不是最好的？如果不是最好的，你要知道最好是什么
• 取舍：到底哪几个地方是一定要解决的，哪些在当前阶段是不重要的
  • 先落地，优先选择从工程落地上效率最高的，即使不够优雅
  • 逐步优化，最重要的是快速证明可行
• 架构最大的问题是如果解决思路有问题，最后的返工可能非常吓人
  • 如果你不知道这个世界上已经有的、最好的解决方法到底有哪些，你就会觉得自己的解决特别牛，但其实可能是别人玩剩的
  • 见过猪跑是很重要的
  • 架构师，对视野的要求非常高
  • 必须主动天花板的发展情况
    • 先找你的领域含金量最高的学术会议，看论文
    • 中国计算机学会推荐的计算机顶级会议目录：https://www.ccf.org.cn/c/2019-04-25/663625.shtml
• 面试判断的核心就是看你对自己项目背后技术的理解程度，包括这个项目的问题、你的解法、业界对这个问题的解法、最后你为什么选择了这个方法而没有选择业界的方法

1. 技术最重要的是带来了什么

• 技术好，那你到底用什么来证明呢？
  • 你做的东西，对这家公司的整个业务发展是否有所作用？
• 对技术人来讲，只在乎你过往做了什么，你做了一个东西还能被很多人用，就是最牛的

关于如何做好管理

汤峥嵘：

1. 如果你真想做好 CTO，首先确保自己的技术不能差。千万不要放弃自己对技术的追求和对技术的研究，不能变成一个纯管理岗位，千万不要放弃在公司里一些小的技术上的沟通，那个是让你保持技术敏感的一个很重要的途径
2. CTO 的责任

• 我要把这些人都带起来，让他们成为发动机，他们只要能力强了，他们成为每个部门的 CTO 了，我就轻松了。我花了蛮多时间，跟他们做各种沟通的
• 管理的责任之一就是要把你下面技术很牛的人，介绍给别人，要不然他上不去是你的责任。
• 如何培养人
  • 首先选对要培养的人，特质：聪明、单纯、有责任心
  • 给他一个比水平略微高一点的任务
  • 适当的时候给一些暗示，告诉大方向，但又要让他觉得是自己努力做的，有满足感
  • 多聊天，鼓励、激励（激将）
• CTO 要花很多精力去跟业务人明确问题，然后协调解决问题
• 管理的人太少也不是好事，当 CTO 离一线越来越远的时候，会真的看不见问题的。因为下属给你展示的基本上都是经过包装的真相

1. 技术人转管理可能第一步遇到的问题，就是由管事到管人的转变，这几乎是两种不同的方法。

• 技术的好坏是黑白分明的，但人和事不是

1. 做管理者，一个很重要的核心是把上级的刚性的、标准的需求，变成一个柔性的、可执行的方案，这才是管理的本质。

• 中层的管理者是连接作用，他要把向上的不确定性转为向下的确定性。因为管理者越往上走，他承受的不确定性越大

1. 管理的一个重要部分是让团队的价值观匹配

• 做管理，就是要你来给这些人打分，你决定了他们的去留、工资，你就有这么大的责任。
• 在此以前总想追求一个完美的管理方案，想谁也不得罪，应该我打出的分所有人都叫好，老板也说好，员工也说好，后来你发现这根本不存在
• 你要把你不喜欢的和你喜欢的人的画像画出来，告诉大家，你鼓励什么和不鼓励什么

毕玄：

1. 建立管理认知：如果你想对这个公司有更大的贡献，就必须带领更大的团队
2. Leader 的几件事：把方向定好（长期、短期），阵型布好（组织形态，闭环还是依赖外部），位置放好（每块的一号位），另外是事情的跟进，还有一点整个团队的成长，就是人才培养问题

• 落实环节需要对团队很了解，需要花精力去了解他们，看到一个更立体的人
• 人才培养很重要，通常来说，只要团队的成员都成长了，事情就做成了
  • 人才的资产负债表，团队人才是在亏损还是盈利（职业发展向上就是盈利、向下就是亏损）
• 公司变大之后，业务多元化，要横向扩张，面临的问题就需要一个厚的人才梯队池来解决，如果不特意培养就没有了，公司就会断岗

1. 人数少的时候，管理比较简单，只需要知道他们的能力状况和在做的事情
2. 如何对成员了解更多

• 三个问题增加了解
  • 离开阿里巴巴的时候，你会找一份什么工作？（确认职业规划，根据他的规划可以更好的安排工作）
  • 过去一年你觉得对你职业生涯是加分、减分还是持平，能不能写进简历？（确认目前工作安排是否有价值，如有否定的回答，需要考虑是否给的方向、空间有问题）
  • 对团队的看法，有没有什么问题（如果对问题有思考和想法，可以结合发展潜力和职业规划安排工作）
• 经常聊，会发现有些人其实有潜质去承担更大的事情
  • 不同级别的人，无非是看问题的角度不一样
  • 好的领导会和下面讲为什么做这个决定，考虑点是什么

1. Leader 最重要的是思考方向

• 经常问手下的 leader，理想中你的团队阵型是什么样的，几个人、分别放什么级别
  • 考察他的规划和境界，是否会限制下面的人
  • 一个 Leader 要做好，核心是先要对整个团队的方向有思考，你有自己的观点很重要
  • 可以跟我观点相悖，这都不重要，但关键你想过，并且有逻辑，那我觉得就可以了
• 其他所有技能都是可以弥补的，但对方向的感知这个技能是很难被弥补的，否则只能做执行
  • 对技术 Leader 来讲，其实判断是对是错不重要，因为对方向的判断是很主观的，没到那个时候很难说谁对谁错。但最怕你没有判断，外面怎么样，你觉得就是怎么样，那这就不要干了
• 结合团队和自己的位置，往上看
  • 站在公司的角度，越高的层级，要考虑的就会越贴近公司的核心
• 越大的 Leader，肯定是越难被影响
  • 你会觉得他很偏执，建立在自己很强的相信上，否则他很难走到这个位置。这其实没错，如果他太容易被影响，这样的 Leader 也太可怕了
  • 当 Leader 最好不要太急做决定
  • （我就有些容易被说服，没有完整的自我逻辑闭环）

1. 心态

• 打造开放透明的环境，做决策时告知决策的原因，同时接受挑战
• 杜绝这种心态：Leader 一定要什么都懂；被问到不会的问题，会没有面子损失权威
  • 在被挑战后，即使不会，直说没有想到这点，不想太多
  • 在到新岗位上，不要因为在乎自己的权威，就必须强装的比其他人都懂，外行指挥内行
• 保持这种心态：Leader 是帮下属解决问题的（如果解决不了，可以直说，不必耽误大家时间）

总结

好了，这篇文章到这里就结束了。

本篇文章介绍了阿里 P10 的大概概念，回顾了两位 P10 前辈成长过程中的关键节点，然后针对一些年轻人关注的话题记录了两位前辈的感悟。

通过两位前辈的分享，我们可以对如何成长为阿里 P10 有更多的认识。

成长最快的方式是从前辈身上学习，相信在将来的某天，他们的话语会给我们带来启发。