做业务就好比打仗，团队是我们的归属。在团队中，我们既要通力协作，又要定义问题；既要业务先赢，又要技术成长。越来越多的前端投身业务研发中。想要有更好的发展，业务理解力非常关键。阿里巴巴前端技术专家悟寻将他在阿里的成长思考，送给在业务中深耕细作的你。

前言

我将我经历过的或者正在经历的状态，分成三个阶段进行总结：求生存，谋发展，修体系。

阶段一：埋头苦干求生存

一名服务一线业务的前端同学，有 50-60% 左右的 KPI 是支撑好业务。纵观前端行业，这很容易成为整个业务的资源瓶颈，而身为业务的前端，我相信一定经历过疲于奔命，经常做线上救火的事情。我入职后的前一年主要做进口业务——天猫国际，一个包含平台和自营的业务。当时，进口业务还处于野蛮生长，竞争激烈的阶段。经常面临一年两大改，日常需求不断，期间还要应付一年的 5 个 S 级的大促和一些小促，我记得最忙的时候是 17 年双十一，面临着自营和平台两块业务的大迭代，同时还需要解决双十一大促各种需求，每天除了做业务几乎没有什么思考和总结的过程。而经过那次之后，我也深刻体会到对于需求管理和时间管理 & 如何避免线上起火的重要性。这里我结合自身和团队的经验梳理了如何打破这种状态方法，也欢迎各位补充。

需求管理

首先需求是做不完的，所以要有取舍，集中人力和精力做核心的业务需求，才能发挥最大的价值，如果你所在团队目前处于各种零散的需求纷至而来，导致无法应节的情况，那么有必要进行相应的需求管理措施：

1.需求双周排期会

比如拉上老板，PD、业务方和开发一起，每两周 (时间可自定义) 坐到一起聚焦这两周的项目进展和接下来所有需求，并且确定好优先级，哪些是应该安排资源进行开发，哪些应该进行取舍，让更多的精力和人力 focus 在业务的重要事情上。当然，比如业务方靠谱或者有大的规划，则一般会对财年的目标进行战役级别的拆解，并且梳理出业务今年必须要拿下的几场战役，那么技术同学就可以根据战役来排兵布阵，业务和技术同学也有明确的统一的战线和目标。目前，我们就是以各种战役为主，日常需求穿插为辅。

2.如何拒绝一句话需求

在需求双周排期会中，基本能确定 80% 的核心需求和优先级，但是在平时仍然会存在一些业务方或 PD 找你，提一些没有经过梳理和思考的一两句话的需求，比如这个这个商品坑我想从一排一换成一排二的，或者因为某个地方的营销标不好看，所以想要修改等等类似的诉求。那面对这样的诉求，在左耳朵耗子的极客专栏中 & 小胡子哥的博客都有提到如何拒绝一句话需求的方法，结合我自己的经验觉得有如下三个递进的方法来解决：

第一，多问几个为什么。比如你这个需求背后的目的和价值是什么？做了之后有什么预期的收益？为什么这么做就可以达到这个收益？你可以不直接问业务方，但是你也需要问自己，业务方的这个目标和做这个需求的路径是否可以匹配得上，如果实现路径存在逻辑漏洞或者不是最佳的方案，这个需求也就没有做的必要性。

第二，给出替代方案。经过上面的步骤，你会发现自己已经过滤了一批无效的一句话需求，而有些需求可能是有一定的存在价值，但是可能业务方提到的点并不是有效的方案或者是成本太大的方案。这时，你就需要思考替代方案，尽量通过现有方案，或者小成本的方式，间接的达到“拒绝”的效果。

第三，不能直接说不，但可以有条件的说，你确定这个需求是 ok 的，但是你确实暂时抽不出时间来搞定这个事情。这时，你不能直接拒绝业务方的需求，因为长此以往会影响后续的合作关系。那么当面临这种情况时，你可以说，这个需求我接受，但是我可能需要较长一些的缓冲时间或者砍一些需求 (部分满足)，又或者必须要按时上的话，不能保证项目的上线后的效果、质量等，让业务方来做部分的取舍。

提升开发效率 & 质量

当然，作为技术人员，需求管理只是一方面，还需要从自身的角度出发，提升开发效率和质量。我相信大家一定都深有体会，尽量不要做低质量、重复的事情，比如可以通过统一开发技术体系和封装相应可复用的组件、提效工具等来释放自己和团队同学的生产力，千万不要因为太忙而放弃思考和做这些事情，这样只会欠下更多的技术债。

这里也有个误区，并不是鼓励大家造轮子，身为业务团队的同学，尽量把眼光能放到行业，或者集团内借助现有的技术方案快速的定制来满足自己的业务诉求，比如我们曾经借助过舒文团队的魔系列产品，定制了海外自己的魔石模块，以此满足海外营销场景的需求开发，现在基本上大促中类似坑位模块都得到了比较好的解决。

再者就是质量问题，需要抽空对线上经常出现问题的产品和代码进行梳理和方案的重新设计。在做国际时，我一般是利用周末的时间来做这种事情，进行部分的重构来达到类似问题的彻底解决，避免三更半夜出现“连环夺命 call”。剩下的方式和手段就是增加开发环节质量保证和必要线上监控了。

关注上线效果 & 及时总结

有时候，我们认为项目提测上线后就完成了，这是一个不好的习惯，长此以往自己也就在合作方当中沦落为一个项目资源的角色，处于被动的状态。其实，如果你能仔细分析或多关注上线之后的业务数据、效果和分析总结，会产生以下好处：

1.提高自己对业务的理解能力

在关注业务数据的同时，你会更多地从业务的角度来看到这个功能所带来的价值是否符合预期。当出现不符合预期时，你可以和业务方一起进行数据漏斗的分析，从而找到问题所在，避免我们的劳动成果成为一次性的工作。

2.避免下次出现相同错误

总结的同时，还可以帮助自己梳理在这个项目中有哪些地方做的不足，或者相关推进中，存在什么问题以及后面怎么改进，提高了下次项目中的迭代效率和质量。比如这个项目是否存在因为需求理解不到位，从而返工的情况，或者因为沟通、联调低效，导致环境不稳定，亦或者因为自己设计的方案不合理，导致出现问题等情况。

3.总结业务方问题

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

小结

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

阶段二：四顾茫然谋发展

当然，做到主动掌握节奏支撑业务还是不够的，我们还需要做到在做业务的同时，能够获得更好的沉淀和成长。接下来，我将说说自身经历的第二个阶段，我把它称为“四顾茫然谋发展”。

这个阶段，你会发现虽然能较好地支撑了业务和有一定的时间来思考了，但是作为业务前端一直会被似乎不知道往哪些方向来发力来提升自己的困境所困扰，特别是在每次制定规划和写 KPI 时，总会出现除了业务不知道该做啥的请款。在我看来，身处在业务团队的前端可以试着从两个角度去探索和思考：

业务赋能角度

业务赋能其实是需要我们紧贴业务规划，制定技术规划和方案。这里建议从财年开始后，你需要陆续和老板及自己对口的业务 PD 去聊，找一些线索和输入，了解业务方今年的 KPI 重点是什么，预计的拆解和实现路径是什么，再结合自己的和团队情况，想想自己能做哪些事情来帮助业务实现其 KPI。事实上，这并非是一件简单的事情，我也在慢慢的培养和训练自己，目前有两点感受可以谈下：

1.抓住本质从点及面，通盘考虑

很多时候，我们收到的痛点和业务需求都是单点的。这时，我们不能着眼于眼前的单点问题，而需要通盘来考虑，比如 SEO 的页面对性能非常敏感，经常会收到一些业务方来反馈说，目前我们的 SEO 有这个地方需要优化下，而单点解决这些问题可能对业务带来的收益并不大，对自己的技能也没有什么成长。此时，如果你能通盘考虑这个命题，其实会发现做 SEO 页面的优化，目的是为了提升 SEO 页面的收录和排名。而提升 SEO 页面的收录和排名不仅有前端性能优化这一个路径，而是还有一些其他的路径，比如优化关键词、长尾词，采用 Google 的 AMP 技术改造 SEO 页面，优化爬虫爬取页面的耗时提升爬取率等等。这样就能把点的问题转化为面的问题，才能制定更有效和全面的抓手来赋能业务。

2.既要解决眼前痛点，也要长远谋划

很多时候我们不能仅满足于眼前的 KPI，还需要了解业务方长远的想法和可以预见的规划。比如，我们目前正在做一个集团非常重要的项目，这个项目时间非常紧张 (前端需要 300 多个人日，且只有 48 个工作日，一度成为项目的风险点)，业务和技术的第一要务就是按时上线。这时，如果按着常理，规划的目标肯定围绕着如何按时上线的问题，而可以预见的未来，可能还需要基于这个模式落地到其他的站点，所以这里规划和需要做的事情又增加了，如何做到技术方案的可以复制性，做到未来能新开站点和缩短前端人力，帮助业务能做到海外站点快速规模化，这就是第二个维度的事情了。当我把这个项目中所有可能的问题都挖掘一遍，那我们要做的事情就是海外分站前端整体解决方案。因此，我们需要不断的挖掘问题和定义问题，然后再找到对策，这样才能找到更好的赋能业务抓手。

技术体验角度

相对前端同学来说，技术体验角度是比较熟悉，而身在业务团队，前端这块也可以做比较多的事情，比如研发效能的提升、性能体验优化、新技术试点和落地、与端的融合等等。如果想重点投入在这方向里，有几个点我觉得是需要重点关注的：

1.避免重复造轮子

当你需要制定一个产品化的方案或者工具和框架时，最好先放眼集团内部和行业，进行一番调研，看看业界和其他同事是怎么解决这个问题的。尽量站在别人的肩膀上做出创新或者参与共建，避免小团队内造出重复和质量低的轮子。我建议，可以多关注集团前端委员会的规划和动态，多关注集团内外的分享，当发现有感兴趣和共同有需要面对的问题和场景时，参与共建和共享。

2.方案的深度和广度

这是一个比较好理解的问题，以前端性能优化举例，目前我们已经不怎么谈资源压缩和 Combo 请求之类常规操作了，而是进入和客户端深入结合的深水区进行优化 (深度)。比如天猫的 Webbased 方案，在这之前，我做海外性能优化 Global Lite 方案时也是从全链路的角度来规划和思考的 (广度)。因此，规划方案的深度和广度决定了这个方案的收益面，而提升深度和广度的方向或者技巧方面，我觉得一是多跨出一步，以上下游和合作方的角色来思考，和其他团队、角色深度合作，探讨可能的方案；二是以终局的思维来思考，比如这个事情最后应该是要做成什么样的，然后和现实做 match 考虑落地方案。

3.关注方案的 ROI

这里其实涉及的是你规划的方案，如果完整实施下来的成本和收益的问题，这个会最终衡量你做这个事情或者方向的价值。那么我们如何衡量成本和收益呢？成本可以考虑从两个角度来说，一是平时我们理解的成本, 比如投入了多少人日，花费了多少经费等；二是从另一个经济学的机会成本来考虑，即放弃了的最大代价，比如提高了多少人效，提升了多少业务数据，提升了多少性能等，建议采用对比的方式来凸显。

4.引进来和走出去

引进来的意思是，尽量基于现有的方案和能力来进一步创新或者定制；走出去其实是将成果和方案能反哺出去，比如将方案覆盖到集团其他行业和 BU，解决类似场景的问题，或者开源、申请专利、多多参与集团内外的分享交流等等。

小结

关于思考业务赋能和做技术规划，其实是一个非常值得不断探讨和锻炼过程，建议平时多和老板、团队内高 P 沟通和交流。一般来说，他们会比较有经验，可以在思考的深度和格局给出非常多的建议，这种交流会有一种醍醐灌顶的感觉。

阶段三：千锤百炼修体系

当我们找到一个觉得可以深耕的方向和机会时，往往脑子里面也许就已经有了大致的思路和方案，这时可能会迫不及待的就想要开工，陷入了各种技术方案的细节之中。这样的坏处在于，容易让我们偏离了主航道，导致最后产出的效果不理想。因此，我们需要有一套理论和方法来保证对问题理解是准确的。那么这个块有没有方法和套路呢？有！那就是养成结构化思考和做事方式。

###结构化的思维

1.建立核心目标

当在面对一个问题和挑战 (挑战即机会) 时，我们需要明确做这个事情的核心目标是什么，建立问题的核心目标。举个简单的例子，在开发中，你遇到了项目编译慢的问题, 目标可以定义为解决项目编译问题，但是我们也可以升华一层为，提升整个开发流程的效能。这时，核心目标就是对整个开发流程进行提效。再进一步升华，目的就变成了提升整个事情的价值和解决问题的覆盖面。

2.进行目标拆解

这里可以根据不同的场景，选择不同的逻辑顺序 (时间 / 结构 / 程度) 进行拆解。比如，开发提效目标，我们可以按开发的时间顺序进行拆解，本地开发、调试 -> 联调 -> 预发验证 ->发布上线等。这里需要关注的点是，我们需要做到拆解的完备和独立，拆解出来的子项能够做到相互独立和完整。

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

3.子项的清理

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

小结

我建议大家可以直接阅读《金字塔原理》一书 (我自己也在学习中) 和一些职业发展的相关书籍，补充自己除了技术方面之外，一些思考和项目管理、人际沟通等方面的知识。当然，书和文章都是理论知识，我们还需要在工作当中去修炼这种思考和做事的方式，才能体现出它的价值。目前，我正在不断地在工作中进行尝试，后续如果有较多的体会和经验，我会再来分享。

本文由阿里技术（ali_tech）授权转载，关注 TGO 鲲鹏会公众号（ID：tgo-kunpenghui）了解技术管理的各样招式。

TGO鲲鹏会，是极客邦科技旗下高端技术人聚集和交流的组织，旨在组建全球最具影响力的科技领导者社交网络，线上线下相结合，为会员提供专享服务。目前，TGO鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800+ 名，60% 为 CTO、技术 VP、技术合伙人。

会员覆盖了 BATJ 等互联网巨头公司技术领导者，同时，阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀，成为 TGO 鲲鹏会荣誉导师。

创作场景

从求生存到修体系，我在阿里找到了技术人的成长模式