本文结合了作者的工作经验提出了一些建议，希望每一位技术同学都可以找到适合自己的成长方向和路径。

做业务就好比打仗，团队是我们的归属。

在团队中，我们既要通力协作，又要定义问题，既要业务先赢，又要技术成长。

越来越多的前端将投身业务研发，要有更好的发展，业务理解力非常关键。

在阿里的这6年，我的工作主要是对接各个1688批发/分销/严选业务，搭建业务的买家导购场景、营销会场、买卖家工作台以及小二管理的中后台应用，有段时间搞搞前端工程建设。

和大部分锋线前端同学一样，刚开始的时候，我对自己的发展方向、成长路径也会迷茫。

我是个业务前端，忙于业务的各种会议、项目和答疑，时间都去哪了？天天搬砖，技术该怎么成长？

做业务和做技术冲突吗？一方面，1688的业务在高速增长，技术要为业务保驾护航，帮助业务高效高质量地把需求落地，多走一步，给业务输出更多技术角度的建议。另外一方面，技术在此中的价值又是不是真如“我”所想，没时间干别的（包括对现状对问题的思考），天天忙于搬砖，跳不出这个“资源”的循环？答案明显不是的，也许只是打开这个世界的方式不对。

业务先赢，技术的成长可以长在业务的挑战和痛点之上，实现业务和技术的共赢。

在这段时间里，经历过技术和业务合作的三种模式（阶段）：

1. 团队刚接手新业务，业务高速发展，需求爆炸，历史代码的日常维护成本高，前端人员基本被拖着跑在地上摩擦摩擦；
2. 前端的基建和开发效率提上来了，维护成本也降低了，逐渐了解业务，和业务对话，给出基于数据和技术视角的输入；
3. 主动寻求通过技术给业务的增值方式，思考技术如何赋能业务的增长。

下面给大家带来一些不成熟的小建议，抛砖引玉，欢迎同学们在评论区留言，希望每一位技术同学都可以找到适合自己的成长方向和路径，遇到更好的自己。

文章大纲

• 业务理解

• 业务支撑

• 业务对话

• 业务赋能

• 从业务里长出来的技术

• 锋线前端的技术产出

• 技术视野、技术深度、投入产出比

• 软技能

• 时间管理

• 项目管理

• 分享与交流

  一、业务理解

为什么技术要懂业务？很简单，故事是这样的。

不了解业务，你可能听不懂业务方要什么，甚至连需求的业务逻辑都搞不清，这种情况的合作模式只有一种，需求下来了，你接住，然后给排期。

不了解业务，没办法跟业务方对话，很难有技术对业务的输出。也许，这个需求的设计不合理，你不知道；这个需求有更好的实现方案，你不知道；这个需求可以通过现成的关联产品方案解决，省时省人力，你也不知道。

不了解业务，会让你离用户的真实需求很远，你越难发现其中的一些痛点和挑战，没法真正提出你的思考和解决方案，去解决用户的难题。

回想过去的两年，我经历过的在业务中的3个不同的前端同学成长阶段，恰巧，可以在这三个阶段（业务支撑、业务对话和业务赋能）举些例子。

1.1 业务支撑

团队刚刚开始接手这块业务，业务在疯狂地扩张，冲在前面飞快地跑，冲呀~~~ 前端各种应接不暇，一条业务线有5个前端同学在支持，但还是很吃力，有种在后面被拽着跑的感觉。

我总结了一下，原因有3点：

1. 前端同学对于业务不熟悉，基本上在项目需求已确定的尾声去参加视觉评审现场定功能和给排期，没有办法判断需求背后的业务逻辑跟业务大节奏是否匹配、需求本身是否能够达成业务目标、有没有更好的实现方式，不知道。基本是在follow和接需求；
2. 维护成本高。前期每天有花一定的时间在各种线上问题的解决上，忙于救火，这里有个bug UI错位了，那里没数据空窗了，前端同学每天过得非常“充实”；
3. 对需求的响应速度较慢。业务的技术栈稍微老了些，边写代码边查API，查不到直接看源码找，效率有点吃力，跟别的业务的技术体系不同，难复用和沉淀，偶尔在大促里还得因为技术栈的问题重写一遍别人写过的代码，有点像在一座孤岛，都在自己玩。

咳咳，看到这里，同学们会不会有点熟悉的感觉，这是不是你们工作的现状，或者曾经遇到过的？

发出一个灵魂拷问：

在业务开发中，遇到让你不舒服或者难过的点，你有没有为了解决它们做过什么事情？

回到一开始的聊的话题“业务前端没有成长空间”，如果忙到连思考的时间都没有，对可见的问题熟视无睹，什么没做、没做深做透把问题给解决了，那就不要再说没有成长空间了哟。

我该知道的事：再忙，也要抽时间思考

1. 日常工作再忙，抽时间出来review，分析一下自己的时间去哪了、问题在哪；
2. 时间管理，梳理自己手上的事情，按紧急和重要程度划分，别慌，合理安排自己的时间；如果需求过来的时机比较随意，可以拉上合作方沟通，推动定期的需求排期会（双周、月会），让整体节奏更规律和合理；
3. 发现问题，我们就可以出协同或者技术的解决方案了，但解决方案不是一次性的，也不要自己玩，希望可以联合横向的前端同学体系化地解决这一类问题。
   

   1.2 业务对话

再来一轮灵魂拷问，你了解你对接的业务吗？以我在1688的经历为例。

• 大市场

• 1688平台是做什么？产品大图了解一下？

• 用户是谁？买卖双方过来，平台靠什么让他们把线下交易搬到1688上？

• 平台的商业模式？靠什么吸引流量，谁埋单，盈利模式是怎样的？

• 业务线

• 用户是谁？流量怎么分层？占比多少？分别在业务中是怎样的定位？

• 我们做的页面是什么东西？导购场景是干嘛的？为业务带来什么价值？要创造更多的价值，我们可以做什么？

• 为什么要搞大促？大促的目标怎么定的？玩法有哪些，想到达到什么目标，指标口径和目标数字是多少？

• 业务的核心指标是什么？KPI目标是什么，这些数字背后的含义是什么？要达成这些目标，业务策略是什么？

• 今年业务的运营重点方向在哪？整体落地节奏如何？前端团队在各个阶段的人员安排如何？技术提供什么为之保驾护航，哪些是已有的能力，哪些需要新造或者借力？新造的解决方案，技术设计和落地节奏如何？这些方案能否被别的团队甚至BU复用？

（等等等等……

没有做过电商，入职前3个月，我根本不知道一个前端该了解这些。（逃

我参与2017年的96大促（第一届商人节），做业务大促组件的支持。前端同学要关注业务数据的嘛，我去了解了一下大促的目标（GMV、买家数），到傍晚达成GMV目标之后，敲鼓庆功，我也很开心地跟着yeah一下~ 然而，大促日均20w买家数代表什么，当时的我并不了解，只知道20w是个数字目标，不知道背后有多少运营同学的招商圈品困难、海景房吸引供应商带动线下买家到线上成交、爆发前蓄水等等的动作，更不知道前端在里面除了支持前端组件的开发、会场的质量保障、答疑，还可以做什么。

跟TL沟通过我的情况，不了解业务的背景和目标，看不清当前的action在业务的规划里是哪一环，希望达成的目标是什么。总的来说，没什么业务sense。

何以解忧？唯有通过各个渠道吸收更多的输入，用时间把对业务的了解堆起来。只有在你对业务规划和现状了解的情况下，才能基于技术的角度，给业务输出更多的专业的建议，发挥更多技术的价值。

我该知道的事：了解业务需要什么，在正确的方向用技术创造更多价值

1. 刚刚接手新的业务，可以邀请业务方老板或者资深的运营/产品同学，给你讲讲这块业务的过去现在未来、愿景、财年规划，以及对技术同学的期望；
2. 花时间读合作方（运营、产品、研发）的周报，了解现在在发生什么，是不是离目标越来越近了；
3. 了解业务目标、落地策略、衡量目标的数据口径，关注数据，关注目前做的项目是否为了达成目标而战，如果不是，提出你的想法和建议；
4. 出差，近距离接触你的用户，会很有体感（尤其被当面吐槽你做的页面有多烂的时候）；
5. 尽量在项目需求成型前参与讨论，了解业务方对这个方案背后的真实需求，越往后介入，会离真实需求越远、越被动，最终就只剩执行了。
   

   1.3 业务赋能

经历了第一、第二个阶段，在运营和产品的业务规划过程中，在前端的角度，针对目前业务面临的挑战，给到更多技术角度的输出（如全站核心链路流量梳理和转化率可视化、发现新的流量渠道等），以及制定出相应的业务技术规划。

从一开始的需求接不过来、被业务拖着跑，到后来跟业务对话，在技术角度有更多的见解和输出，一起把业务做好。在这两个阶段，我做的事情都在规划以内，跟着业务的节奏走，正常地达成目标。

回到我的职能和业务背景。我主要做业务线的导购场景，导购场景的本质是接住流量并把买家转化成交易，核心链路包括流量从哪里来、来了以后展示什么商品、商品命中他们的需求后转化成下单和成交。场景的转化效能，成了业务增长的核心，但场景该怎么定义效能才能更好呢？心智明确的场景靠运营的经验来定义，但对外开源引流的新通路场景，运营同学也不知道该怎么定义。

下一个阶段，我能不能做一些超出预期的事情，提供解决方案去验证一些业务方没有做规划但数据证明效果很好的东西，技术赋能业务，发现更多未知的领域，创造更多的业务价值呢？

于是，我想做CBU场景的A/B Test解决方案，从一开始的纯前端方案、到后来跟蚂蚁金服达尔文平台合作在业务中落地，最后和CBU无线端团队合作场景魔方项目，打造出CBU的基础实验解决方案Evolution，详情在这里就不叙述了。

我该知道的事：跳出常规，技术为业务、商业探索做更多的事情

1. 不断地输入、观察，业务的真实需求是什么？站在业务方的角度思考，业务遇到的痛点、挑战在哪里？
2. 基于“我”的职能和个人特质，我可以为此做些什么？
3. 和老板、团队同学、业务方对焦，确认“我想做的”是不是“大家想要的”？
4. 考虑投入产出比，给技术产出先找好业务的阵地（试验田），有没有可以借力的地方，不要重复造轮子。快速验证这个方向的正确性后，再逐渐多加投入、丰满技术设计。不要自己YY、默默地做完，做出来没有业务场景埋单。
   

   二、从业务里长出来的技术

2.1 锋线前端的技术产出

简单总结了一下，作为锋线前端，我们有哪些优势以及有哪些潜在的发力点。纯属个人观点，欢迎大家继续补充和提建议哈。

锋线前端的优势：

• 在各个角色中有联接的优势，向前联接运营、产品、设计，向后联接服务端、算法、测试，在了解业务需求的同时，了解各方的技术解决方案；
• 横向服务多条业务线，可以抽象出不同业务线的需求间的异同，产出体系化的解决方案；
• 离用户最近，在用户数据采集的关键链路。

锋线前端的潜在发力点：

• 联接（已有能力和解决方案的聚合，产品化体系化地解决某个业务痛点）；
• 端（如web端、客户端、IoT等）；
• 线上产品的匠心打磨（如语雀编辑器）；
• 某个技术领域的深耕。

下面开始进入回忆故事线，觉得太长的同学可以跳过哈。

经历了第一个阶段的需求管理和研发提效，前端团队的整体开发节奏趋于规律，哎哟，有点成绩和效果，这个会上瘾，接下来想继续搞，随着对业务的认识增加，渐渐地会对业务产生一些“不成熟的小建议”。（下面是个人认为比较常见的、接地气的虚拟场景）

1. 这里技术体系太老了，为了进一步提升开发效率，我们想要搞技术重构
2. 前后端联调有点费劲，我们想搞个联调数据中台，提升联调效率
3. 那里展现速度太慢了，我们要搞性能优化
4. blah blah

一般会遭到老板或者业务方无情的拒绝，问得我一脸懵逼。

• 为什么要做？（有什么业务价值？有什么技术价值？）
• 为什么是现在做？
• 为什么是你做？
• ROI（投入产出比）怎么样？

我想起一年前，搞完组件的开发提效后，我跟老板说，我想做前端测试方向，搞组件质量，保障组件的线上质量。结果当然是被当场拍死，我也有不服气哈，质量方向没有价值么，为什么不让我做？经过了多番沟通后，我有点明白问题出在哪里。我提出要做的事情，有价值但不是必须做的，没有结合目前业务需要什么。也就是说，我想做的技术是个人和纯技术角度yy的，没有基于业务的现状和痛点去考虑技术方案，不接地气，投入产出比不高。后来结合业务当时的痛点（无法快速对比产品迭代的转化提升、开源场景的低成本试错和探索），产出基础的A/B实验解决方案，先从搭建场景切入，在业务场景中落地验证实验对业务的价值。

说实话，我要做A/B Test一开始提出来，也是要被老板拍死的，A/B Test出来那么多年了，解决方案那么多，为什么我还要去做？呃……恕我直言，是有很多实验方案啊，但是传统A/B成本有多高，大家心里没点数么？以前一提到在业务场景中做A/B，合作方会跟我说，做A/B挺好的，有价值，还有时间做A/B，你们挺闲呀~ （捂脸）当时并没有做A/B的自由，有部分设计师、产品和运营同学想试错，但是技术没有提供这样的土壤。

我知道，这个方向是对的，有价值的，只需要快速在业务场景验证，去证明。所以，我坚持了自己的想法，做低成本的实验解决方案。

以前产品经理（PD）要做个蒙层透明度的A/B实验，研发肯定会直接拍死，不给做，排期、研发成本（基础分桶逻辑还要跑实验数据）太高。大家可能不知道，近期1688主客首页，针对直播组件就做了这么个实验，就改黑色蒙层的透明度（亮度），端开发同学开个支持透明度改变的配置，搭建平台上使用实验插件，简单配置流量，实验数据自动回流。最终亮度较高的方案胜出，UV CTR提升了1%，1%代表什么，这是个百万UV级别的页面，做个实验，多了几万的UV点击，ROI那么高的迭代优化方案通过实验轻松发现。

在这个阶段，我该知道的事

1. 对于业务来说，在现阶段，怎样的技术能力和解决方案能够解决业务的痛点、创造更大的业务价值？
2. 针对上一个问题的痛点，我可以做些什么？
3. 一个人或一种角色（前端）能够做好吗？如果不能，怎么联动更多的角色（运营、产品、设计师、服务端、算法、端、测试），一起把事情做好？
4. 确定你想做的事情，方案想好，快速在业务中落地，再不断完善；
5. 你觉得是对的事情，坚持做。尽管一开始老板觉得不对，坚持做出来之后，验证了有业务价值，你就是对的。（不要教你什么话都听不进去，哎，自己领悟吧）
   

   2.2 技术视野、技术深度、投入产出比

针对这part，我也没有太深的认识，只有一些浅薄的个人理解，跟大家分享。（结合在圆桌中大佬的解答）

i) 技术视野

我该知道的事：技术视野

• 关注日常业界新技术。不一定要深入了解，但对新技术保持好奇心，大概了解它是做什么的，如果在工作中遇到匹配的落地环境，可以考虑写个demo看看是不是有价值。
• 关注集团和业界的解决方案。在业务中发现问题，做解决方案的时候，我们很容易陷入自己的设计中，一脑子地想把所有东西都自己做出来，但投入会非常大，产出的价值是否一样大呢？不知道。大部分情况下，你想做的，能搜到的，前人踩的坑，或者已有的成熟的解决方案，只要你去沟通去接触，就可以轻松地接进来，为什么要花大量的时间去造轮子呢？可以借力的地方，就去借力吧，把时间剩下来，做你的解决方案中更核心更有价值的事情。
• 在解决方案或者领域中，是否可以跟集团的方案联动、合力共建，大家向一个地方发力，把基础能力下沉，再在各个BU中做上层的定制？

ii) 技术深度

一聊到“技术深度”，我很自然地会认为是在某项技术上挖得很深，或者解决了一个业界公认难度很高的技术难题。但原来这是“技术深度”的其中一部分。

我该知道的事：技术深度的体现

• 体系化 / 系统化

• 体系化思维是认识事物的一种方式，在面对问题的时候，能够针对复杂的问题，列出关键的要素和解决方法，将散乱无序的问题，变得逻辑清晰，有章可循。

• 在问题的定位和解决的体现，从表象到本质，拆解出造成问题背后的原因，针对性地去解决本质的原因，而非治标不治本，有解决方案有节奏地解决。

• 全链路

• 除了前端的部分，向前向后的技术栈，还能挖多深。

• 单点技术挑战

• 在某个技术挑战上，你的思考和解决方案是怎样的。秀肌肉的时候来了~

iii) 投入产出比（ROI）

一开始，我以为投入产出比的意思，就像理财的概念一样，在项目中投入了多少人多少时间，回报是后续可以减少多少人多少时间。后来发现，还有另一层含义。

当我们聊起ROI，首先要解答的问题其实是这个决策的正确性，我们做任何的决策的时候，都存在“机会成本”。

我有20块钱，买了4只鸡翅。20块也可以买一碟干炒牛河，但我的钱都用来买鸡翅了。这碟干炒牛河就是我的机会成本，牛河会不会更好吃？

述职答辩时，更多是想知道在落地/执行之前，你对ROI是否有足够的思考，还是不考虑投入产出地想到什么做什么。

我该知道的事：ROI

1. 当前业务背景下，为什么要做？
2. 现在必须做吗？
3. 为什么是你做？
4. 怎么做？（体系化、全链路、单点技术挑战）
5. 有什么业务和技术结果？能否被复用？
6. 未来规划（能否跟BU或集团的方案联动、共建）
   

   三、软技能

一些看似与工作无关，但又密切相关的点。

3.1 时间管理

时间都去哪了？

这大概是在不同阶段的我们，都会遇到的问题，每天都有做不完的项目、开不完的会，还有一些杂七杂八的事情。

没有太好的建议，我用最笨的方式，类似日常的记账，用一个月的时间，记录我每天的时间花在哪了，好好想想哪一个环节可以合理安排，解放一下自己的时间。

我该知道的事：时间管理

1. 梳理以及合理安排手上项目的排期（开发时间、介入时间、重要程度、紧急程度），如果有并行项目也是一样的；
2. 每周一有个小计划，写上这周我要完成什么；
3. 每天早上想想今天我要完成什么，优先级如何；
4. 日常的会议邀请和项目排期按时间表有序地进行，特殊的插入项目或会议视情况调整。
   

   3.2 项目管理

有一天，我们要肩负起项目PM的责任，做项目管理。

一般的项目流程是这样的：

idea / 需求 – 需求沟通 – 立项 – 需求评审 – 视觉评审 – 技术调研与设计评审 – 项目K.O / 排期 – 开发 – 联调 – （TC评审 / 冒烟） – 测试 – （功能预演） – 上线 – 上线效果数据评估 – 迭代

我没有上过项目管理的课，工作过程中经过了一些实战，纯属个人理解。

做好项目各个合作方的协同，针对以上流程产出整体项目节奏的时间表（细化到人、事、时间）和milestone。实施过程中，提前把风险抛出和解决，把控好项目的节奏，保证项目的正常进行与交付。

我该知道的事：项目管理

• 项目立项、需求评审

• 了解项目背景，项目背后的业务逻辑，抓到真实的需求

• 需求与视觉稿比对，确认他们的匹配度与设计合理性（在时间紧的项目，给出最低成本的方案的建议）

• 接口定义设计、前端技术调研&技术设计、K.O.

• 在开发之前，做好技术设计是第一步，设计之后你会很清晰要做什么、怎么做、风险点在哪

• 降低后续的返工、漏功能、前后端对不上增加联调的开发和时间成本

• 项目开发

• PM（Project Manager）

• PM责任重大，除了肩负开发工作，发现、记录、解决过程中遇到的问题，定整体项目节奏和定期同步项目进度、项目周报。

• 多人开发项目

• 在技术设计过程中，梳理出基础/公用模块，避免重复开发，共享信息，保证信息透明

• 分工一定要明确，否则可能会产生人多手乱，1+1<2的效果

• 站会

• 每天早上5-10分钟的站会，同步昨天进展、今天计划、整体进度是否有delay、有没有风险。这是成本低、效率高的沟通方式，保证项目组的同学们都了解进度和风险。

• 有突发的、严重的问题，当场提出、讨论、定解决方案，不拖延

• 联调

• 前置联调流程

• 目前项目组利用dummy进行前端定义的数据接口mock，在开发过程中，前置联调的工作，降低后续真实数据的联调风险

• 测试、发布

• TC评审可以前置，再check一遍测试准入的核心链路，避免提测前才发现主链路跑不通，再临时补功能

• 整体发布计划

  3.3 分享与交流

谈到“分享”，以前的我会觉得，我应该要有一个牛逼的技术方案，通过文章或者线下的方式，向大家输出我的产出。

后来有了一些新的理解。分享，不仅仅是输出，是双向的，我们在分享之前，先要讲给自己听，有助于梳理自己的思路，分享过程中，大家会有疑问或反馈，不一定是你在解答问题，很有可能由思想的碰撞给你带来新的思路。

我该知道的事：分享与交流

1. 分享不是单向的，是双向的交流，既可以梳理自己的思考、向外输出，也可以通过思维碰撞，带来新的思路；
2. 不一定要有完美方案才能分享，可以是阶段汇报，让更多人知道你在做什么，说不定能吸引潜在的用户和合作方；
3. 分享和交流的方式：输出文章、线下分享、与其他团队或跨BU的交流。