提升领导力

一些话题 #

我的主管不是前端，作为 Leader 我该如何做？第一次看到这个标题时，第一反应这很像奇葩说题目，稍微改一下：我的主管不是前端，作为前端 Leader，我的发展是否受限？这个话题挺有意思的。

如何看待前端拆分至业务线 #

最近在讨论前端分拆问题，很多前端同学可能得直接向后端 TL 汇报。我和一些同学及 HR 有过沟通，觉得分分合合，都要看时机。

我在带团队过程中，做过两类事。一类事是把一些业务前端团队从 0 到 1 孵化出来，发展到大概十人时，有合适的 TL 带时，就会把团队输送到业务线去。同时也做过第二类事，就是在合适时候，把一些业务线的前端团队再合并起来。我觉得最佳的组织形态，就应该分分合合。分分合合之后，带来的好处会超乎大家想象。有时候分的好处比较大，比如前端分到业务线，前端绩效上很容易拿 3.75，基本上前端在业务线都会是个宝。一些业务线的前端，经常可以连续好几年拿高绩效，甚至都没机会拿 3.5+，因为全部都是 3.75 绩效。在业务线，前端的绩效更容易得到认可。

前端拆分到业务线，还有第二个好处：会更有利于前端招聘。前端合在一起时，要统一申请 HC 很痛苦。当前端分散到业务线时，招聘压力是给到了后端 TL，业务缺前端，后端 TL 得用自己的 HC 去招聘。前端散落在各个业务线时，往往会是前端人数发展最快的时候（有不少后端的 HC 会用来招聘前端）。合在一起的前端大团队，容易大锅饭，HC 申请很难。

前端拆分到业务线，还有一个好处，可以让前端跟后端的对话变得深入很多。一个后端开发，如果他带过前端团队，后续跟前端交流时，往往能感同深受，因为有过切肤之痛。不带前端，不少后端只会提需求，说缺前端缺资源就好。带了前端后，现在他得为前端同学去考虑很多：怎么招聘、如何发展、紧急缺人怎么办等等。这带来了很大好处，能使得前后端同学一起建立起更深入的对话通道。

但分散太久也不行，适当时也需要合一合。人是情感动物，缺少情感连接太久，从来没有在一起过，往往容易彼此不理解，容易造成山头林立。同时长期来看，分散对人员晋升成长也不利。

长期来看，还是建议能按 BG/BU 为单元，把前端团队合一合。同时借助前端委员会，把一些人才标准拉通，通过统一但不唯一的人才标准体系，去打通人才晋升通道。

总体来说，组织形态不用去太在意。分有分的好处，合也有合的好处，合适的时机，去做合适的组织调整就好。

Leadership 的三要素 #

回到今天想讲的话题，作为 Leader，最重要的不是向谁汇报，而是要尽可能提升自己的 Leadership 能力。我心目中，一个优秀的 Leader，需要具备三方面的能力：成事的能力、利他的能力，以及律己的能力。

这个话题很大，今天着重讲几个关键点。

定义问题 #

定义问题是成事要素里最重要的能力。无论你带五六个人还是几百个人，作为 Leader，最核心的能力之一是定义问题。团队的价值在哪，团队的绩效多好，就是看你能解决的问题有多大。要解决问题，首先重要的是要能识别发现问题，能定义清楚问题。

从业务侧定义 #

问题从哪来？作为前端，一个最常遇到的问题，就是业务缺人。比如业务线某项目突然很紧急，很缺人，该怎么办呢。当有业务向你提问题时，就是一个很好的时机，你就可以去定义清楚问题。

举一个我去年遇到的紧急缺人问题。要做新业务，要招大量运营小二。大家执行力很强，很快就招到了几千人。这几千人怎么去工作，需要建一个区域作业平台。这是一块全新业务，研发工作量很大，从后端到前端都很缺，而且缺口很大。前端一盘点，最少缺 20 个人。业务负责人打电话给我说：你必须一周内给我把这 20 个前端给整出来。我一听头大了，没有 HC 的时候苦恼，但一下子直接招聘 20 个前端，这得从哪里去找，那一周整个人都不好。好在体验技术部是合在一起的，可以有办法先内部匀动。于是我快速找了相关同学来商量，同时找各个业务方去协调，最终云动出来十几个同学。前端的战斗力很强，十几个同学就可以当 20 个前端用，最终把这个紧急缺人问题做了比较好的临时解决方案。

类似这种缺人问题，当你从业务角度去为业务考虑，去急业务之所急时，和业务方的信任感就会逐步建立起来。缺人问题有很多解决方案，有时候往往并不是技术问题，靠技术方案是解决不了的。上面这个例子，最终我把问题定义成前端团队的组织敏捷性。如何提高前端团队的组织敏捷性，这需要团队的全局观和快速执行力，要做好挺难。组织问题的解决难度，一点都不比技术问题容易。如果你能打造出一支拥有良好敏捷性的组织，可实现人员的健康弹性云动，那就太厉害了。我这块做得很一般，努力提升中。

除了缺人，还有一个经常遇到的问题，就是技术如何帮助业务创新。小程序，从 2017 年发展到现在三年多，看起来比较成熟。然而，实际去看各业务线，就会发现小程序技术上还有很多挑战点，甚至在拖业务后腿。

举个例子，最近业务方有提一个需求，希望在搜索结果页做服务直达（不需要打开小程序，就可以提前使用小程序的部分功能）。比如搜天气，搜索结果页就把天气给展示出来，搜充值，在搜索结果页就可以出来一个充值的可交互卡片，可以直接把充值完成。这是一个典型的业务需求，但小程序目前不具备这个能力。最终讨论下来，技术的方案，是要能把小程序变小，让小程序具备 widget 能力，通过 widget 形态，将小程序的部分功能呈现在搜索结果页或首页等地方。

这是一个典型的从业务问题出发，来定义技术问题的例子。业务问题是需要服务直达，定义出的技术问题是要把小程序变小，具备 widget 能力。把问题定义出来后，还会遇见排期等各种问题，这个时候你要切实去评估技术的可行性，与客户端团队一起把需求做合理评估，不能给业务方超出团队承载范围之外的承诺。有时候，也得坦然认怂，认怂并不是一件丢人的事。比如定义出小程序变小问题后，技术怎么实现，要联合客户端团队一起做，一排期，要花近半年时间才能实现。但业务经常是等不及的，这时还需要建立业务同理心，帮业务去想过渡方案。从业务需求到技术问题的拆解，技术可行性分析，包括临时方案怎么做等等，这些都是定义问题中需要具备的能力，是很实在的能力。

从团队侧定义 #

对公司来说，作为技术，有个显而易见的价值，就是疯狂提升研发效率，让业务能快速试错或快速试对。效率这件事，影响因素非常多。有个影响效率很大的问题点，就是一句话需求很多，同时需求定义不清晰，以及多方团队的协同效率很低。

对以上这类问题，我将其定义为上工程之痛。从需求到写代码之前称之为上工程，开始写代码之后称之为下工程。上工程的主要问题，就是需求的定义不高效不清晰。基于这个问题定义，我们开始做基于白雁和语雀的产研协同体系。很多人好奇，为什么我要去造白雁/语雀这样的产品，其实这些产品，都是来自于你平日里对工作痛点的愤怒，以及在这种愤怒下，你对问题的定义和解决方案。产品并不是产品，而是解决问题的载体。 对痛点的敏感和保持愤怒非常重要。一个不愤怒的产品经理，不会是一个好的产品经理。后续有机会再展开讲。

从技术侧定义 #

回到可能是我最擅长的技术侧。比如，要做架构升级/技术治理，要做一套新框架/新工具，等等。越是我们擅长的，往往越会被老板怼，会收到各种质疑不认可。

我可能幸运一点。主管一直比较懂技术，当我说要做技术架构升级等事情时，主管都还比较认可，愿意给时间让我去试。比如做 Ant Design，是因为之前的整个技术栈比较老比较散。Ant Design 可以至少在中后台这块的技术栈上，能够收敛统一。技术栈的收敛统一短期对业务是看不到价值的，但是长期的价值是一定能说清楚的。长期价值只要能跟主管说清楚，一般情况下还是可以争取。争取到认可，往往才是挑战的开始，因为业务很难给技术留出独立时间，大量技术侧的升级改造，是需要靠加班去做出来的。好在对很多技术同学来说，对技术的改造统一，往往会有极大热情，甚至晚上不睡觉都可以。

作为 Leader 最大的一个能力点，就是定义问题，非常非常关键。随着团队人越多，在定义问题这块花的时间也会越多。

定义目标 #

定义清楚问题后，要去解决问题。解决问题前，还有一个关键点，是要去定义清楚目标。这个目标不能用技术侧的语言表达（比如我想做架构升级、要多少 HC 等），要尽可能把目标转换成大家都能听懂的指标。

比如做xxx时，去年定了一个目标，是复杂月活应用要达到 300 个。这个目标对内讲，是可以的。但如果对外讲，那是看不懂的。达到 300 个，能为业务带来什么呢。所以对外沟通时，我会把目标翻译成：通过xxx的低代码研发，一年可以为公司节省 30 个前端。当你翻译成节省人力的目标后，你的主管不可能不理解，只是你要确确实实能去做到提效，并把计算逻辑说清楚（怎么得到节省 30 个前端的）。

大家经常会说管理四件事：定目标、追过程、拿结果、奖优罚劣。除了定目标，如何追过程也非常关键。在过程中，需要不断去看问题是不是真的定义清楚了，需要一边前进一边调整，最后把结果拿到。这一块很多人有分享过，这里不赘述。

谈谈晋升与成长 #

通过定义问题，并不断解决问题，累积几年，就能看清楚自己以及团队给公司的价值是什么。

我们给到公司的价值，就是帮助公司/客户解决了多少问题，解决了多大问题。同时这些问题，要跟你的业务方和主管有共识。一旦有共识，一般就会拿到一个比较好的绩效。然后就可以加薪，同样也就有机会晋升。我觉得怎么加薪怎么晋升，其实很简单，就是去看解决了多少问题，解决了多大问题。做到了，就有机会。

可能大家对我的个人历史会有误解，觉得我是靠写技术框架来晋升的。其实当时我的晋升主要是因为我解决了交易线的很多技术债务。当时我挺疯狂，把很多老代码都重构了。

做框架，初衷是为了解决详情页的多人研发和性能优化问题。当时一个 JS 文件有 4000 多行，疯狂时有一万多行。一个人写还是比较开心的，同时什么打包构建其实都不需要，一个文件直接压缩一下，就是性能最高的。但后来业务复杂度变高，很快加入了一个同学跟我一起维护。当第三个同学一起修改时，协作就有点崩溃了：每天都要解决代码冲突。后来关注到社区里的模块化开发趋势，于是去做了 框架 加载器，在当时一劳永逸地解决了多人研发协作问题。出发点就一个：我写代码时，不要影响别人；别人写代码时，也不要烦到我。

定义问题后，解法往往也就清楚了。我当时还做了很多其他事情，比如一些流程页，写得痛不欲生，各种分支流程太多了，有段时间，我睡觉都会梦到，太恐怖了。后来花了大力气重构，才终于能睡个安稳觉。

还有一个让人痛不欲生的业务，里面的逻辑看起来简单，但最初各种逻辑交错。举个最简单的，当时很多店铺里面都有客服小二，但这些客服小二都会取一些好听的名字，比如沉鱼落雁、闭月羞花。这需要前后端的代码一起配合，才能正确唤起对应的旺旺 ID。有很多业务逻辑在里面，你要去看各种代码包括后端代码，才能把整个逻辑给梳理清楚。

在做搜索结果页，往往有一排排数据，经常 20-50 个，甚至更多。这时会碰到参数拼接问题：一拼接，就很容易超过 IE 浏览器对 URL 最长长度的限制。这可怎么办？得在发请求时，切分成多个请求去发。后来有意思的是，这背后的挑战，成为了 框架 加载器的核心逻辑。

这背后的挑战是，并行异步发出多个请求后，在这些请求返回时，如何保证原来的执行顺序。这是 框架 模块加载的核心功能点：分析得到依赖列表后，并行去加载依赖文件，但返回时机是乱序不可测的，难点就是如何保证按原来的依赖顺序依次调用执行。这过程中，还需要考虑打包构建、拆包逻辑、性能的极致优化等等。当时真的着迷，甚至研究到少写几个变量，来追求压缩后的极致体积，以及不断观察内存和 CPU 占用，让运行性能最优等等。现在回想，依旧有很多乐趣。

后来自己的晋升，被评委们认可，很大原因并不是 Ant Design 等轮子，而是能定义清楚问题，同时能解决问题。其实在晋升场合里，就没怎么聊 框架 以及 Ant Design 等话题，评委也不太感兴趣（事实很残忍），语雀也没提过（只有一个评委问了一个问题）。我谈的最多的，是自己怎么看问题怎么解决问题。前端最大的问题，就是缺人，我是怎么解决的，啪啪啪跟他们讲一通。讲完后，大家认可，确实帮公司解决了不少问题，不少问题还挺难的。我后来当面试官，也是着重从问题出发，看候选人究竟解决了什么问题，由此来判断是否通过。

很快又是晋升季，想说说晋升的关键点：一定要回归专业，用专业的方式去定义问题和解决问题。刚才说的定义问题、定义目标、追过程、拿结果，这些都能体现专业度。专业这个词远远大于技术，技术只是专业的一小部分。比如你说你的 React 技术天下无敌，那又怎样呢？关键是用 React 解决了什么问题。我之前开玩笑说，其实我觉得很多后端开发的 Java 语言能力可能还不如我，但一点都不妨碍后端能一路往前晋升。后端的专业度，往往是在某个业务域，很多后端在业务架构能力上，远远强于前端。每个工种，最终看的都是领域专业度。

所以我觉得，大家真不要纠结技术这一块，除非你的专业领域，就是基础技术。选择了基础技术也挺好的，这是一条少有人走的路。比如，去做 Java 中间件的，或者云原生基础设施的，其实很少。大部分工程师，都是应用开发，核心是解决业务问题。

作为 Leader，最核心的就是要能成事。如果能够靠自己或靠团队，去解决大量问题，就不用担心什么。在成事过程中还有两个要素很重要，第一是利他，第二是律己。

学会利他 #

有段时间在推头狼文化，推了一堆的头狼，谁都想当头狼，一旦自己在战役里不是头狼，就有点不太想使劲。这样整个团队合作是有问题的。后来听到一个很有意思的说法，是勇做二号位。真正能把二号位做好，愿意和你合作的团队反而更多，能做成的事情也会更多。

勇做二号位是一种利他心态，这比争当一号位重要多了。前端等支撑性质的岗位，特别需要勇做二号位。

去年开始，我和其他同事，一直在推进内部开源。内部开源意味着产品并不属于某个团队，他是属于公司的，这样就可以阶段性地去换一号位，通过这种共赢的方式去让产品更长久。内部开源背后，也是一种利他心态。共同的利他，会让一些事情简单而美好。

还有一个最容易做的利他，就是分享。我有段时间很排斥分享，因为口齿不伶俐，会怯场。后来越来越意识到，担心都是多余的，最重要的是分享本身。当你在做分享时，无论输出多少，对听众可能都是会有收获，同时往往对自己的成长更大。

作为 Leader，还要学会倾听。倾听也是一种利他。听听你主管对你的诉求是什么，听听每个同学在想什么在担心什么。当你学会倾听的时候，整个世界都会感激你。

严于律己 #

作为 Leader，还有一个关键能力是律己。

别人愿意来追随你，你能够带领这个团队持续往前走，一方面是你能成事，业务和事情很吸引人；另一方面个人魅力也很重要，个人魅力往往来自一些基本素养。律己这块，我对自己的要求，是类似六脉神剑，整了一张图：

第一点：体能。带团队，避免不了 996 等加班情况，没有体能是很难做好 Leader 的。体能这块，保持精力是关键。我的做法是俯卧撑，或跑步。每个人都可以找到适合自己的体能锻炼方式。

第二点：情绪。当你在很愤怒/悲伤时，再怎么高效时间管理都是徒劳。要尝试去了解自己的情绪，能在情绪低落时，找到化解的方式。我曾有个同学，他一情绪低落，就背单词，一背单词，情绪立刻就好了。每个人都不一样，一定要找到适合自己的。特别是在工作压力越来越大时，情绪管理能力很关键。

第三点：原则。在体能和情绪的基础上，需要不断寻找到一些属于自己的原则。每个人的原则都不一样。比如我的一条原则，是真实不装。我花了很大精力，才能意识到自己在什么时候是装的。多用第三者视角去看自己，就会发现自己的一些潜意识要小心。一旦能意识到自己什么时候会装，就能比较容易做到不装。我还有一个原则是全情投入。睡觉就不玩手机，吃饭就开心吃饭，陪娃就全身心陪。要做到很难，我训练了自己好久，目前只能做到百分之七八十。可以找到很多自己内心认可的原则，并逐步去把这些原则做到，这样能提升自己的整个精神能量，在为人处世上也会发生比较大的改变。

第四点：思维习惯，很多时候你是被习惯驱使。习惯分为两种：思维习惯、行为习惯。举个简单例子：在沟通时，很多人会习惯说“但是”、“不是这样的”。但实际上这是你的一个思维习惯，你的第一反应是找退路或找借口。可以提升自己的觉察能力，一旦能觉察，在觉察和行动之间，就有巨大的选择自由（这也是自由的真正含义：觉察和行动间，藏着一个世界）。关于思维习惯推荐一本书《原则》，有讲到大量思维模式。

第五点：行为习惯。有些是很小很小的细节，比如在跟人沟通时，要正视他，要看到他的眼睛。看起来是很小的一个习惯，当你真的去把这个变成自己的习惯后，你会发现很多沟通都变简单了，很多人都很友善。这里我就不展开讲了，因为这个话题其实很大。

第六点：意义感。作为管理者，最重要的一个能力就是给自己给团队创造意义感。举个例子，体验技术部这个团队名字里，“体验”两字，就是一种意义感的承接。带团队，无论多大多小，到了一定阶段，一定要去想想这个团队存在的意义是啥。想清楚之后，同时能跟合作伙伴都达成共识，这个团队就会开始有魂。这话题非常大，时间有点晚，后续有机会再聊。

最后小结 #

回到主题：我的主管不是前端，我该如何突破。我的答案是：你要有“成事”的能力 —- 能发现问题，能把问题定义清楚，能定义清楚目标，能跟团队一起去解决问题，去拿到结果。这过程中，还能不断去利他，能寻求到合作，实现多方共赢。

最后回到自己，成为了 Leader，就要严于律己。这条路很孤独，你要不断去觉察情绪、不断去坚持一些原则等等，还要培养自己的思维和行为习惯，并尝试往上寻找意义感。

这个意义感我强调一下，不要刻意求之。很多时候，维持好体能、管理好情绪、做到一些原则，人就很不错了。如果还能养成一些良好习惯，人的一生就不会太差。当意义感缺失时，有下面两层作为支撑，埋头赶路，其实也挺开心的。我曾经有很长一段时间也是意义感缺失的，不知道自己活着是为啥。不要忘记对意义感的探寻就好，偶尔想清楚一些问题后，整个人生的意义感就会不经意之间冒出来。

说明：文章来源于互联网《支付宝前端团队分享》，感谢！