阿里大佬：技术人的3个段位，你在哪段?

做业务就好比打仗，团队是我们的归属。在团队中，我们既要通力协作，又要定义问题，既要业务先赢，又要技术成长。

图片来自 Pexels

越来越多的前端投身业务研发中。想要有更好的发展，业务理解力非常关键。阿里巴巴前端技术专家悟寻将他在阿里的成长思考，送给在业务中深耕细作的你。

我将我经历过的或者正在经历的状态，分成三个阶段进行总结：

• 求生存
• 谋发展
• 修体系

阶段一：埋头苦干求生存

作为一个服务一线业务的前端同学，支撑好业务占据我们 50%-60% 左右的 KPI，纵观行业前端本身很容易成为整个业务的资源瓶颈，而身为业务的前端我相信一定经历过疲于奔命，经常线上救火的事情。

我入职后的前一年主要做进口业务：天猫国际，一个包含平台和自营的业务。当时的进口业务还处于野蛮生长，竞争激烈的阶段。

经常面临一年两大改，日常需求不断，期间还要应付一年的 5 个 S 级的大促和一些小促。

我记得最忙的时候是 2017 年双十一，面临着自营和平台两块业务的大迭代，同时还需要面临双十一大促各种需求，每天除了做业务几乎没有什么思考和总结的过程。

而经过那次之后我也深刻体会到对于需求管理和时间管理如何避免线上起火的重要性。

这里我结合自身和团队的经验梳理了如何打破这种状态方法，也欢迎各位补充。

需求管理

首先需求是做不完的，所以要有取舍，集中人力和精力做核心的业务需求，才能发挥最大的价值。

如果你所在团队目前处于各种零散的需求纷至而来导致无法应对的情况，则有必要进行相应的需求管理措施。

①需求双周排期会

比如拉上老板，PD 和业务方的开发一起，每两周(时间可自定义)坐到一起对焦这两周的项目进展和接下来所有需求，并且确定好优先级。

哪些是应该安排资源进行开发，哪些应该进行取舍，让更多的精力和人力 Focus 在业务的重要事情上。

当然比如业务方靠谱或者有大的规划，则一般会对财年的目标进行战役级别的拆解，并且梳理出业务今年必须要要拿下的几场战役，那么技术同学就可以根据战役来排兵布阵了。

业务和技术同学也有明确的统一的战线和目标，比如我们目前就是以各种战役为主，日常需求穿插为辅。

②如何拒绝一句话需求

在需求双周排期会中基本能搞定 80% 的核心需求和优先级，但在平时还是会存在一些业务方/PD 会找你提一些没有经过梳理和思考的一两句话的需求。

比如：这个商品坑我想从一排一换成一排二的，或者想这个地方的 Icon 或者营销标我觉得字体不好看想修改下等等这样的诉求。

那面对这样的诉求，在左耳朵耗子的专栏中和小胡子哥的博客都有提到如何拒绝一句话需求的方法。

结合我自己的经验觉得有如下三个递进的方法来解决：

• 多问几个为什么：比如你这个需求背后的目的和价值是什么?做了之后有什么预期的收益，为什么这么做就可以达到这个收益。

你可以不直接问业务方，但是你也需要问自己，业务方的这个目标和做这个需求的路径是否可以匹配得上，如果实现路径存在逻辑漏洞或者不是最佳的则这个需求也就没有做的必要性。

• 给出替代方案：经过上面的步骤，其实你会发现你已经过滤了一批无效的一句话需求，而有些需求可能是有一定的存在价值，但是可能业务方提到的点并不是有效的方案或者说成本太大的方案。

这时你就需要思考替代方案，尽量通过现有方案或者小成本的方式来满足业务方，间接的达到“拒绝”的效果。

• 不能直接说不，但可以有条件的说是：当你确定这个需求是 ok 的，但你确实暂时抽不出时间来搞定这个事情的时候，这时关键在于我们不能直接拒绝业务方，长此以往会影响到后续的合作关系。

这种情况你可以说，这个需求我接受，但是我可能需要较长一些的缓冲时间或者砍一些需求(部分满足)，又或者必须要按时上的话，不能保证项目的上线后的效果、质量等，让业务方来做部分的取舍。

提升开发效率和质量

当然作为技术人员，需求管理只是一方面，还需要从自身的角度出发，提升开发效率和质量，这个我相信大家都深有体会，尽量不要做低质量的重复事情。

比如通过统一开发技术体系和封装相应的可复用的组件和提效工具等来释放自己和团队同学的生产力，千万不要因为太忙而放弃思考和做这些事情，这样只会欠下更多的技术债。

当然这里也有个误区，并不是鼓励大家造轮子，身为业务团队的同学，尽量把眼光能放到行业或者集团内借助现有的技术方案快速的定制来满足自己的业务诉求。

比如之前我们借助之前舒文团队的魔系列产品定制了海外自己的魔石模块来满足海外营销场景的需求开发，现在基本上大促类似坑位模块都得到了比较好的解决。

再者就是质量问题，需要抽空对线上经常出现问题的产品和代码进行梳理和方案的重新设计。

在做国际时，我一般是利用周末的时间来做这种事情，进行部分的重构来达到这种问题的彻底解决，避免三更半夜出现“连环夺命 call”。剩下的方式和手段就是增加开发环节质量保证和必要线上监控了。

关注上线效果并及时总结

有的时候我们认为项目提测上线后就完成了，这是一个不好的习惯，长此以往自己也就在合作方当中沦落为一个项目资源的角色，处于被动的状态。

其实仔细分析下多关注上线之后的业务数据和效果并分析总结，有如下好处：

• 提高自己对业务的理解能力，你在关注业务数据的同时，也就会更多地从业务的角度来看到这个功能所带来的价值是否符合预期。

当出现不符合预期的时候，可以和业务方一起进行数据漏斗的分析从而找到问题所在，避免我们的劳动成果成为一次性的工作。

• 总结的同时可以帮助自己梳理这个项目中自己哪些地方做的不足，或者相关推进中存在什么问题，以及后面怎么改进，提高了下次项目中的迭代效率和质量。

比如这个项目是否存在需求理解不到位存在返工，或者沟通 & 联调低效，环境不稳定，自己设计的方案是否合理等问题，后续要怎么解决。

• 也可以从数据和总结中判断出什么样的需求是靠谱的，什么样的业务方是靠谱的，频繁争取资源上线效果又不好的业务方，下次再有需求过来则需要多增加一个心眼和思考的过程。

小结：以上就是我在应对业务需求井喷所总结的一些经验，总体来说就是虽然业务占据我们大部分的 KPI，但不能在业务中迷失了自己，需要给自己安排总结和反思的时间，做到主动掌握节奏的支撑业务。

阶段二：四顾茫然谋发展

当然做到主动掌握节奏支撑业务还是不够的，如何让自己在做业务的同时能获得更好的沉淀和成长呢，下面说说我经历的第二个阶段，我把它称为四顾茫然谋发展。

这个阶段你会发现你虽然能较好地支撑了业务和有一定的时间来思考了，但是作为业务前端有个困境就是似乎不知道往哪些方向来发力来提升自己，特别是在每次制定规划和写 KPI 时，总会出现除了业务不知道该做啥的困境。

在我看来身处在业务团队的前端可以试着从两个角度去探索和思考：

业务赋能角度

业务赋能其实是需要我们紧贴业务规划，制定技术规划和方案。

这里建议从财年开始后就需要陆续和老板，还有自己对口的业务 PD 还有业务去聊，找一些线索和输入，了解业务方今年的 KPI 重点是什么，预计的拆解和实现路径是什么?

再结合自己的和团队情况，想想自己能做哪些事情来帮助业务实现其 KPI，其实这并非是一个简单的事情，我自己也在慢慢的锻炼和训练着自己。

目前有两点感受可以谈下：

①抓住本质从点及面，通盘考虑：很多时候，我们收到的痛点和业务需求都是单点的，这时我们不能着眼于眼前的单点问题，而需要通盘来考虑。

比如 SEO 的页面对性能非常敏感，经常会收到一些业务方来反馈，说目前我们的 SEO 有这个地方，那个地方需要优化下，而单点解决这些问题可能对业务带来的收益并不大，对自己的技能也没有什么成长。

这时候如果通盘考虑这个命题，其实会发现做 SEO 页面的优化，其实目的是为了提升 SEO 页面的收录和排名。

而提升 SEO 页面的收录和排名不仅有前端性能优化这一个路径，而是还有一些其他的路径：比如优化关键词和长尾词，采用 Google 的 AMP 技术改造 SEO 页面，优化爬虫爬取页面的耗时提升爬取率等等。

这样就能把点的问题转化为面的问题，才能制定更有效和全面的抓手来赋能业务。

②既要解决眼前痛点，也要长远谋划：很多时候我们不能仅满足于眼前的 KPI，还需要了解业务方长远的想法和可以预见的规划。

比如我们目前正在做一个集团非常重要的项目，这个项目时间非常紧张(前端需要 300 多个人日, 且只有 48 个工作日，一度成为项目的风险点)，业务和技术的第一要务就是按时上线。

这时如果按着常理，规划的目标肯定围绕着如何按时上线的事情，而可以预见的未来，可能还需要基于这个模式落地到其他的站点。

所以这里在规划和需要做的事情又增加了如何做到技术方案的可以复制性，做到未来能新开站点如何做到缩短前端人力的问题，帮助业务能做到海外站点快速规模化，这就是第二个维度的事情了。

而当我把这个项目的所有可能的近的问题和远的问题都挖掘一遍，那我们要做的事情其实就是海外分站前端整体解决方案。

所以这需要我们不断的挖掘问题和定义问题，然后再找到对策，这样才能找到更好的的赋能业务抓手。

技术体验角度

技术体验角度相对前端同学来说比较熟悉，而身在业务团队，前端这块也可以做比较多的事情，比如研发效能的提升，性能体验优化，新技术试点和落地，与端的融合等等。

如果想重点投入在这方向里面有几个点，我觉得是需要重点关注的：

①避免重复造轮子：当你需要制定一个产品化的方案或者工具和框架的时候，最好先放眼集团内部和行业，进行一番调研，看看业界和其他同事是怎么解决这个问题的。

尽量站在别人的肩膀上做出创新或者参与共建，避免小团队内造出重复和质量低的轮子。

这里建议可以多关注集团前端委员会的规划和动态，多关注集团内外的分享，当发现有感兴趣和共同有需要面对的问题和场景时，参与共建和共享。

②方案的深度和广度：这个比较好理解，比如就拿前端的性能优化来说，目前我们已经不怎么谈资源压缩，Combo 请求之类常规操作了，而是进入了和客户端深入结合的深水区进行优化(深度)。

如之前天猫的 Webbased 方案，而之前我在做海外性能优化 Global Lite 方案的时候也是从全链路的角度来规划和思考的(广度)。

所以规划方案的深度和广度，决定了这个方案的收益面，而提升深度和广度的方向或者说技巧我觉得可以是：

• 一是多跨出一步，以上下游和合作方的角色来思考，和其他团队的角色深度合作，探讨可能的方案。
• 二是以终局的思维来思考，比如这个事情最后应该是要做成什么样的，然后和现实做 Match 考虑落地方案。

③关注方案的 ROI：这里涉及到你规划的方案，如果完整实施下来的成本和收益的问题，这个会最终衡量你做这个事情或者方向的价值。

那如何衡量成本和收益呢，成本可以考虑从两个角度来说，一个是平时我们理解的成本, 比如投入了多少人日，花费了多少经费等，还可以从另一个经济学的机会成本来考虑，即放弃了的最大代价。

收益其实比如提高了多少人效，提升了多少业务数据，提升了多少性能等，建议采用对比的方式来凸显。

④引进来和走出去：引进来的意思是尽量基于现有的方案和能力来进一步创新或者定制，走出去是将成果和方案能反哺出去。

比如将方案覆盖到集团其他行业和 BU，解决类似场景的问题，或者开源，申请专利和多参与集团内外的分享交流等等。

小结：关于思考业务赋能和做技术规划，其实是一个非常值得不断探讨和锻炼过程，建议平时多和老板和团队内高 P 沟通并交流。

一般他们会比较有经验，可以在思考的深度和格局给出非常多的建议，有的时候这种交流会有一种醍醐灌顶的感觉。

阶段三：千锤百炼修体系

有的时候当我们找到一个觉得可以深耕的方向和机会的时候，脑子里面也许就已经有了大致的思路和方案，这时候可能会迫不及待的就想要开工，陷入了各种技术方案的细节之中。

这样的坏处在于可能会导致我们做着做着偏离了主航道，导致最后的产出不理想。

这里我们需要有一套理论和方法来保证对问题理解是准确的，完整的和足够高度的。

这个块有没有方法和套路呢，答案是：有!那就是养成结构化思考和做事方式。

结构化的思维

①建立核心目标：当我们在面对一个问题和挑战(挑战即机会)的时候，需要明确我们做这个事情的核心目标是什么，建立问题的核心目标。

举个简单的例子，比如在开发中遇到了项目编译慢的问题, 目标可以定义为解决项目编译问题，但是我们也可以升华一层为提升整个开发流程的效能。

这时的核心目标就是对整个开发流程进行提效。进一步升华的目的是为了提升整个事情的价值和解决问题的覆盖面。

②进行目标拆解：这里可以根据不同的场景选择不同的逻辑顺序(时间/结构/程度)来进行拆解。

比如开发提效这个目标我们就可以按开发的时间顺序来进行拆解，比如：本地开发和调试→联调→预发验证→发布上线等。

这里面需要关注的点就是需要做到拆解的完备和独立，拆解出来的子项能够做到相互独立和完整：

• 时间顺序：中心执行的步骤、流程等。
• 结构顺序：中心的空间、地理位置、内部外部条件等。
• 程度顺序：中心的轻重缓急、重要性等。

③子项的清理：事业是无限的，人力总是有穷、认知高度总是不够(from 承风)，所以这里需要做到取舍并不是所有的子项都是值得在现阶段做或者需要花费较大成本去做的。需要抓住其中的核心子项，也就是核心抓手。

小结：这里我建议大家可以直接阅读下《金字塔原理》一书(我自己也在学习中)和一些职业发展的其他书籍，补充自己除了技术方面之外一些思考和项目管理和人际沟通等方面的知识。

当然书和文章都是理论知识，还是需要在工作当中千锤百炼的去修炼这种思考和做事的方式，才能体现出它的价值。

这块我目前也在不断的在工作中尝试中，等后续如果有较多的体会和经验了再来分享。

最后

以上就是我在这几年摸爬滚打出的一些经验，借此机会也在这里感谢下我的老板和帮助过我的朋友，你们一直都是我学习和参考的榜样。

【编辑推荐】

点赞 2