技术与业务同行：做业务的技术人

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

1. 团队刚接手新业务，业务高速发展，需求爆炸，历史代码的日常维护成本高，前端人员基本被拖着跑在地上摩擦摩擦；

2. 前端的基建和开发效率提上来了，维护成本也降低了，逐渐了解业务，和业务对话，给出基于数据和技术视角的输入；

3. 主动寻求通过技术给业务的增值方式，思考技术如何赋能业务的增长。

• 业务理解 

• 业务支撑

• 业务对话

• 业务赋能

• 从业务里长出来的技术 

• 锋线前端的技术产出

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

• 软技能 

• 时间管理

• 项目管理

• 分享与交流

1. 前端同学对于业务不熟悉，基本上在项目需求已确定的尾声去参加视觉评审现场定功能和给排期，没有办法判断需求背后的业务逻辑跟业务大节奏是否匹配、需求本身是否能够达成业务目标、有没有更好的实现方式，不知道。基本是在follow和接需求；

2. 维护成本高。前期每天有花一定的时间在各种线上问题的解决上，忙于救火，这里有个bug UI错位了，那里没数据空窗了，前端同学每天过得非常“充实”；

3. 对需求的响应速度较慢。业务的技术栈稍微老了些，边写代码边查API，查不到直接看源码找，效率有点吃力，跟别的业务的技术体系不同，难复用和沉淀，偶尔在大促里还得因为技术栈的问题重写一遍别人写过的代码，有点像在一座孤岛，都在自己玩。

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

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

1. 日常工作再忙，抽时间出来review，分析一下自己的时间去哪了、问题在哪；

2. 时间管理，梳理自己手上的事情，按紧急和重要程度划分，别慌，合理安排自己的时间；如果需求过来的时机比较随意，可以拉上合作方沟通，推动定期的需求排期会（双周、月会），让整体节奏更规律和合理；

3. 发现问题，我们就可以出协同或者技术的解决方案了，但解决方案不是一次性的，也不要自己玩，希望可以联合横向的前端同学体系化地解决这一类问题。

• 大市场 

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

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

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

• 业务线 

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

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

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

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

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

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

1. 刚刚接手新的业务，可以邀请业务方老板或者资深的运营/产品同学，给你讲讲这块业务的过去现在未来、愿景、财年规划，以及对技术同学的期望；

2. 花时间读合作方（运营、产品、研发）的周报，了解现在在发生什么，是不是离目标越来越近了；

3. 了解业务目标、落地策略、衡量目标的数据口径，关注数据，关注目前做的项目是否为了达成目标而战，如果不是，提出你的想法和建议；

4. 出差，近距离接触你的用户，会很有体感（尤其被当面吐槽你做的页面有多烂的时候）；

5. 尽量在项目需求成型前参与讨论，了解业务方对这个方案背后的真实需求，越往后介入，会离真实需求越远、越被动，最终就只剩执行了。

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

1. 不断地输入、观察，业务的真实需求是什么？站在业务方的角度思考，业务遇到的痛点、挑战在哪里？

2. 基于“我”的职能和个人特质，我可以为此做些什么？

3. 和老板、团队同学、业务方对焦，确认“我想做的”是不是“大家想要的”？

4. 考虑投入产出比，给技术产出先找好业务的阵地（试验田），有没有可以借力的地方，不要重复造轮子。快速验证这个方向的正确性后，再逐渐多加投入、丰满技术设计。不要自己YY、默默地做完，做出来没有业务场景埋单。

• 在各个角色中有联接的优势，向前联接运营、产品、设计，向后联接服务端、算法、测试，在了解业务需求的同时，了解各方的技术解决方案；

• 横向服务多条业务线，可以抽象出不同业务线的需求间的异同，产出体系化的解决方案；

• 离用户最近，在用户数据采集的关键链路。

锋线前端的潜在发力点：

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

• 某个技术领域的深耕。

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

4. blah blah

• 为什么要做？（有什么业务价值？有什么技术价值？）
• 为什么是现在做？
• 为什么是你做？

• ROI（投入产出比）怎么样？

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

1. 对于业务来说，在现阶段，怎样的技术能力和解决方案能够解决业务的痛点、创造更大的业务价值？

2. 针对上一个问题的痛点，我可以做些什么？

3. 一个人或一种角色（前端）能够做好吗？如果不能，怎么联动更多的角色（运营、产品、设计师、服务端、算法、端、测试），一起把事情做好？

4. 确定你想做的事情，方案想好，快速在业务中落地，再不断完善；

5. 你觉得是对的事情，坚持做。尽管一开始老板觉得不对，坚持做出来之后，验证了有业务价值，你就是对的。（不要教你什么话都听不进去，哎，自己领悟吧）

i) 技术视野

我该知道的事：技术视野

• 关注日常业界新技术。不一定要深入了解，但对新技术保持好奇心，大概了解它是做什么的，如果在工作中遇到匹配的落地环境，可以考虑写个demo看看是不是有价值。

• 关注集团和业界的解决方案。在业务中发现问题，做解决方案的时候，我们很容易陷入自己的设计中，一脑子地想把所有东西都自己做出来，但投入会非常大，产出的价值是否一样大呢？不知道。大部分情况下，你想做的，能搜到的，前人踩的坑，或者已有的成熟的解决方案，只要你去沟通去接触，就可以轻松地接进来，为什么要花大量的时间去造轮子呢？可以借力的地方，就去借力吧，把时间剩下来，做你的解决方案中更核心更有价值的事情。

• 在解决方案或者领域中，是否可以跟集团的方案联动、合力共建，大家向一个地方发力，把基础能力下沉，再在各个BU中做上层的定制？

ii) 技术深度

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

• 体系化 / 系统化 

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

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

• 全链路 

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

• 单点技术挑战 

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

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

我该知道的事：ROI

1. 当前业务背景下，为什么要做？

2. 现在必须做吗？

3. 为什么是你做？

4. 怎么做？（体系化、全链路、单点技术挑战）

5. 有什么业务和技术结果？能否被复用？

6. 未来规划（能否跟BU或集团的方案联动、共建）

时间都去哪了？

我该知道的事：时间管理

1. 梳理以及合理安排手上项目的排期（开发时间、介入时间、重要程度、紧急程度），如果有并行项目也是一样的；
2. 每周一有个小计划，写上这周我要完成什么；
3. 每天早上想想今天我要完成什么，优先级如何；

4. 日常的会议邀请和项目排期按时间表有序地进行，特殊的插入项目或会议视情况调整。

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

• 项目立项、需求评审 

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

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

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

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

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

• 项目开发 

• PM（Project Manager）

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

• 多人开发项目 

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

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

• 站会 

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

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

• 联调 

• 前置联调流程 

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

• 测试、发布 

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

• 整体发布计划

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

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

3. 分享和交流的方式：输出文章、线下分享、与其他团队或跨BU的交流。