成长&业务更匹配，实现更大的发展空间

哈喽，我是树酱，今天分享一篇来自转转团队成员陈龙在前端领域中结合业务及未来发展的思考总结。包括发掘业务痛点、业务压力大如何兼顾个人成长、如何训练自己的综合能力等等

（一）发掘业务痛点、个人成长和未来发展的关系

先问个问题：发掘业务痛点和个人成长这两点冲突么？

我猜，大部分人会回答“不冲突”

理想情况：解决业务痛点的技术方案，同时满足新技术的探索，最终业务痛点解决了，个人技术能力提升了，皆大欢喜

但骨感的现实却是：这样的需求基本可遇不可求，FE大部分工作依旧是简单重复的体力活，做页面，码代码。

相信多数程序员的心声是：“想做有挑战的需求，但没人给我提”

那可能有人会说，业务痛点应该是产品该干的事，技术嘛，你提需求我给你实现就好了

这句话本身没毛病，术业有专攻，尤其让一个技术去思考业务痛点，会花费更多的时间，而且结果未知

常见的现象：技术同学处心积虑，思考了一个产品方案提给PM，不是石沉大海，就是被判为“不靠谱”

由此技术就更不愿投时间在业务思考上，有时间我宁愿多看看技术文章，做做demo

尤其工作没几年的同学，主要精力基本在技术沉淀上，在业务思考的时间确实较少

这本身并没有什么问题，不同阶段不同侧重点。但对于有一定经验和技术深度的同学，我建议可以往这方面多投入些精力，理由后面会谈到

问题2: 开发人员只做好需求就够了么

通常的回答：“当然不是，我们还要额外做很多事情，比如个人成长，业务沟通，资源协调，团队管理 ...”

确实，如果程序员只会写需求，并且在保质保量的前提下，那也顶多算60分

这种工作方式，短期糊口没问题，长期就不一定了， 而且这类程序员通常占大多数，等到30-35岁，可能就是职业生涯的终点了

问题3: 未来哪类人可能优先被淘汰

这个问题千人千面，先说说我的想法：

• 只会干“体力”活的

• 学习能力差，不愿与时俱进的

• 负能量满满的

• 上进心不强的

• 情商低的

• 人际关系差的

这里面并没有提到技术能力，因为技术能力是好奇心和学习能力的结果体现

工作几年后，曾经的技术激情慢慢退却，开始习惯不断重复的工作，新东西也学不动了，关键现有的知识应付工作足够用

（看看身边这样的人多么）

负能量，情商和人际关系，就属于能否良好融入团队了

基本上，未来优先被淘汰的属于：底层能力差的同学

问题4: 未来哪类人可能会走更远

这个问题同样千人千面

之前听过一个培训，里面提到FE的发展方向（仍在技术领域），具体如下：

• 技术类（广度：架构师；深度：领域技术专家、科学家）

• 管理类（技术管理者：经理，CTO；职业经理人：完整业务）

• 创业类（创始人；技术合伙人，技术高管）

• 顾问类（投资人：资本运作，投后服务；管理顾问：培训，团建）

大家可以根据个人特点，参考一下

另外，在一次尤雨溪的直播连线中，有人问到前端行业未来发展，他提到了三个方向：

• 原生语言工具链

• 全栈趋势

• 发掘痛点，解决实际问题

前两点侧重点在技术深度挖掘，基本属于纯技术领域。

我本身并不是学霸风格，相比于技术控，能切实帮业务解决问题会更让我有成就感。

（另一个成就感来源就是能带出一批牛人，这不是今天重点，就此略过）

所以就我个人来讲，更倾向于走：业务侧的技术管理路线 （有点像 技术经理和管理顾问的结合）

毕竟程序员到后面，拼的就是附加值了

道理很简单：一个工作10年的技术和一个工作两三年的比。你的工资可能是他的几倍，但你的开发效率可不一定能高多少， 那30岁的你最大的价值是什么，难道只有写需求么？

所以到时候，你是属于公司资产，还是公司成本呢？

OK，再回到这个问题本身，同样给出我的个人想看法：

• 好奇心强的

• 学习能力强的

• 善于思考总结的

• 综合能力强的

• 情商高的

上面同样都没有直接提到技术能力。

我个人认为，如果你未来走偏业务的技术路线的话，能让我们走的更远的，并非单纯的技术能力，而是通用能力。

我之前始终没能精炼出到底有哪些能力，直到有一次听课， 里面提到美国summit学校的育人标准，跟我潜意识的想法不谋而合

• SMART（目标管理）

• 随机应变

• 坚持不懈

• 敢于挑战

• 直面挫折

• 适时寻求帮助

为什么还是没有学习能力？

因为学习能力作为最简单的能力，人人都具备。但上面提到的，都需要长期培养。

虽然这是一个中学的育人标准，但却能够让人终身受益，即便未来不再从事技术这个行业，它也能很好的帮到我们

说了这么多，是不是感觉有点跑题了，真是么？

行，那我们先直接切入，其他的稍后再聊

（二）如何发掘业务痛点

• 日常的需求讨论和建议

• 流程优化（开发、协调、…）

• 性能、体验优化

• 小巧的技术方案提效（工具、系统）

这些是我们最常见的，有人也叫“业务参与感”，但其实是比较初级的， 因为这些基本不用对业务有太深的理解，只要具备一定的技术素养就可以做到， 这离业务痛点还比较远

那么除了上面提到的，想深入业务还需要具备什么素质呢？

1）业务全貌及详细流程的了解

这点很多人会比较自信，认为小意思

但实际情况可能连自己都不清楚

怎么验证呢，很简单：

看看自己能不能画出完整的业务流程图（很简单么？）

比如：下单流程；仓储/供给流程；下单流程；回收流程；质检流程 ....

每个人负责的业务特点不同，属于自己的“流程图”也不尽相同， 看看能不能完整画出来，能详细到什么程度

因为业务痛点可能就隐藏在无数的细节当中，你要不知道，永远都发觉不了

下面是我整理的某个业务流程图（就是个示意，也没打算让大家看清~） 

里面关键逻辑，后续流转，哪一步可能有坑，画出来才会了解更多

而且这个流程依旧很简单，很多内部逻辑都没有标出，但随着流程图的不断的细化，完整的业务也就呈现了（这是个不断迭代的过程）

之前的教训：自认为很懂业务，其实都是皮毛。

2）给产品提建议要在充分思考之后

程序员有个通病：突然有个想法后（也为了更好的参与业务），直接提给PM，让PM进行后续思考，但实际PM稍加思索，就直接定性：不靠谱

同样，你做为技术，突然一个PM跑来，告诉你这个需求的技术方案应该xxxx这么实现，有时，你一听就觉得“什么玩意儿，不懂技术还瞎出主意”

道理是一样的

如果同样的事情发生几次后，这方面的信任度就会大幅降低，你的建议也会越来越不受重视，同样，你也越来越没有动力提了，恶性循环就这样形成了。

所以，有了想法后，自己要想清整个流程，包括背后的逻辑都要想清楚。

比如：你提的建议，预期收益是什么，有没有调研，有没有历史数据，最终的流程怎样，是否有可参考的例子，大改动量有多大，可能涉及部门等

看着好麻烦，感觉这些事情都是产品该干的活

是的，但我想说的： 一旦你有灵感想提给产品，请把整个流程想清楚，最起码你的方案要能够说服自己，且逻辑能够闭环。

业务思维就是通过这些点点滴滴不断提升的

3）明确当下业务核心目标

这非常重要，因为它可以保证你的努力不会打水漂

举个我的例子：

之前殚精竭虑，想了一整套可能提升业务订单的方案，像前面提到的，预期收益、目标人群，所处时期节点，初期规划，后续切入点，行业调研、落地方案、涉及流程和相关部门业务，改造成本，预期风险等等能做的都做了

各方面，我自认为考虑很周到，我甚至写了一个非常长的文档（因为那段时间连做梦都在想产品方案），然后非常自信的在周会上提了出来。

而当时的业务核心目标是：优化整体UE模型

啥意思，当时业务每卖一单，公司需要补贴3-5块钱。而全业务都在努力把收入和成本打平，工作重心都在优化供给和履约成本上。

而这个时候，我却提了个让业务亏更多钱的方案，结果可想而知。

4）业务健康指标及数据波动跟踪

通常技术都不太关心业务数据，或者只关心核心的几个，如：DAU，发布率，引流，转化率等等

这些确实很重要，但这些数据只反映了一个结果，那么造成这个结果的原因都有哪些呢？

比如，用户发布率低，入口流量多少，发布流程复杂度，每一步的折损多少，哪几步折损率最高，然后再分析可能的原因，

其实就是深入细节～

5）拆掉思维的墙

5.1 不要给自己的工作范围设限

作为技术，职责边界不要划分的过于清晰，比如：

• xxx事不应该由我来做

• xxx事是PM的事情

• xxx事应该server做

解决业务痛点和做需求差别较大，这个时候可以不用明确划分边界

可能就是这些事情，能让FE去接触平时没触碰过的领域，最关键的：业务真的需要

比如之前业务说：需要做爬虫

按常规想法，这事应该由server处理，但我们确实做了

而且通过这次爬虫的开发，使我们解锁了很多新技能：运维相关知识、node应用、多线程、 防风控、puppeteer、数据库

倒不是说这些技术有多高大上，但确实因为这个方案落地：

• 让我们切实帮业务解决了实际问题

• 新技术有深度应用，并且落地

• 有了新的成长和团队沉淀，为后续培训积累了很好的素材

• 收获业务的信任，同时也收获了技术影响力

5.2 思考角度多维度

比如提效，提效都包含哪些？开发提效，用户操作提效，协作模式提效，流程提效

其他的呢？

• 帮pm快速收集并组织关键数据，给pm数据决策提效

• 开发小工具，pm完成例行体力活，腾出更多时间去思考业务，这算不算

• 团队状态的感知和调整算不算

提效不单单指技术侧，而是需要放眼整个团队，任何一点的提效都算

这一点其实挺难的，需要经常性刻意去锻炼，才会慢慢有感觉

6）珍惜每次（业务）周会抛出的问题和槽点

周会上产品运营同学的吐槽，其实就是一个很好的切入点

细细思考，哪些可以用技术解决，这算是一种偷懒的方法

7）主动去找产品沟通

没事找产品运营多聊聊，可以从中获知很多业务细节，包括困扰他们的问题

可能有些问题，对技术来讲就是手到擒来的事情，但你不聊确实很难知道，因为常规的产品需求都排不完，这些个人化的小问题也很难抛出来。

主动找产品沟通，即能增进产研之间的感情，同时也能更深入的了解业务，遇到的问题以及未来的动向。

但这点，一般开发人员都不愿意去做，相比跟产品运营聊这些东西，不如安静的写会代码，而且，作为开发的我们，永远都有做不完的需求，哪有那么多“没事时间”

这个确实需要个人突破，要不然你永远都会陷在无休止的需求当中。

摆正心态

公司没有义务对你的个人成长负责
道理很简单，公司是花钱请你做事的，至于你的个人成长，与我无关。
员工的第一要务本身也是做事，而不是成长。

我说的比较露骨，但确实是实情
所以，不要把没时间学习、成长慢归咎于公司太忙。
你这是在为自己急流勇退找借口
因为任何一家公司基本都这样。
这个心态一定要摆正！！！
如果能碰到氛围好又注重个人成长的环境，也请你好好珍惜。

那怎么在高强度业务需求的同时兼顾个人成长，后面会提到。

为什么花这么多篇幅讲如何深入业务，我认为：

• 走技术和业务结合的路线必须对业务要有很好的理解

• 业务能让技术更有价值

对于业务

• 实际问题解决了

• 团队氛围更融洽了

对于个人

• 解锁更多领域，且有机会深入细节（深度+广度）

• 有更多的支持，能够实际落地

• 个人(团队)口碑，更快的职业发展

技术成长其实很简单，没接触过的、有更深入研究的、更优方案产出的都算技术成长， 它也是伴随方案落地的附属品

罗列一些我们团队的过往经验

• 框架转换工具 -> 命令行 + ast + ts

• 自动埋点收集方案 -> 命令行 + jsdoc + webpack插件 + ract + eggjs + mongo

• 机器人抓取数据 -> eggjs + puppeteer + 代理池

• 解决游戏安全中心解绑痛点 -> electron + vue3

• 自动加购工具 -> node多进程和进程通信 + puppeteer + pkg

• 马良系统 -> sketch插件开发 + 数据算法 + react + eggjs + mongo + vue

• 小程序onShow方案 -> webview和小程序通信机制及周边

• …

我始终认为，如果你具备一定的技术沉淀，当遇到问题时，你一定有办法解决它，即便它并不是最优解。

而如何发现业务痛点，才是关键。这也是很多人都有的问题：希望别人找出痛点，然后自己出方案解决

职业前中期，这种方式没问题，因为我们也不太具备业务思考的能力， 现在太多的程序员：

• 为了技术产出而造轮子，为了技术尝鲜而造轮子，不管轮子能不能用，也不管业务到底有多忙

• 为了学习新技术而写demo，但使用程度仅限demo

第一种被认为浪费资源，也是业务方比较反感的，第二种个人学习没有深度

尽可能的结合，才是有效方案。

所以，我个人认为，发掘业务痛点需要的是：综合能力，也就是前面提到的summit育人标准

说了这么多，很多人会说最缺的还是时间，那么下面就处于业务高压下没有精力的同学一些建议。希望你们在快节奏的同时尽量能够兼顾个人成长

（三）业务压力大如何兼顾个人成长

1）直面焦虑

通常在高压下，大部分程序员都会有焦虑的心态，程序员不怕需求多，只要安排得当是能够处理的，就怕扎堆倒排期。

根据经验，焦虑通常来自几方面：

• 倒排期的需求，一眼望不到边

• 产研关系紧张，被不断质疑和催促

• 时间越紧张越改需求

• 开发过程中被频繁打断，急躁贯彻始终

• 个人成长的事情，完全没时间弄

• 规划的公共建设，同样完全没时间

• 对未来的迷茫

而程序员又有自己的执拗：尽快完成需求，然后专心做自己的事情

一看到未来相当长时间内都是这个状态，谁能不焦虑。

有的团队，夸张到产品对排期的把控程度甚至超过开发人员，你的排期就像写在脸上一样，上午几点能提测，什么时候能介入下一个需求，产品门儿清。

所以分析完焦虑点，你就需要针对问题做出相应调整

不要天真的认为换工作能解决问题，没准换完还不如现在呢。

2）适当增加排期

增加排期buffer，可以直接缓和这种心态。

如果确实是阶段性的业务上升期，个人成长给业务让步是可以接受的，但长期的话，就需要一些“公事公办”的心态了。

毕竟个人成长确实需要精力投入。公司没义务对你的成长负责，但你要对自己负责，自己不找时间，那永远都没有。

如果你每天都工作到很晚，那抽出半小时到一小时肯定是没问题的，而且对需求节点基本产生不了什么影响。

只是很多人认为这个时间太短，做不了什么事，宁愿去做需求。

另外，增加排期面临最大的问题，就是来自产品的质疑，说白了就是信任问题

前面提到，如何深入业务的一些方法，尤其跟产品的沟通，会很好的与业务团队建立链接和信任感，因为他们知道你在非常努力的帮助他们。信任感一旦建立，业务是不会对你的排期产生任何质疑的。

这样，你既有了好的业务口碑，同时也挤出时间做个人提升。而你的成长还能去反哺业务，这就形成了良性循环。

所以增加排期buffer背后反应的：

• 是心态的调整：快节奏下，时间是一点点积累出来的，想化零为整，客观条件不具备，那就想办法适应化整为零

• 解决产研信任问题：这是一套组合拳才能产生的效果

3）碎片学习的体系化积累

这部分是针对将时间化整为零的配套建议。

通过笔记来完成，好记性不如烂笔头。

我用的是印象笔记，找个顺手的工具很重要。

建立专题笔记本，把每天学习的内容，作为一条独立的笔记，放到笔记本中， 这样积累多了就成体系化了

而且整理单条笔记时正好对学习内容的回顾，也不用担心看完就忘，一条条笔记也能见证你学习的过程

4）以单周或双周为单位做个人总结

这个总结很有必要，内容可以是多维度的

• 业务：数据跟踪，痛点思考，规划和建议，业务沟...

• 技术：遇到的问题，方案思考，学习，个人成长...

• 管理：沟通，团队规划，人员培养，组织架构，团队稳定性...

• ...

经常性总结思考同时会帮你解决一个大问题：那就是对未来的迷茫

5）把控业务节奏

这部分可能会争议，也属于管理问题。

有些管理者认为作为技术不应该控制业务节奏。最起码技术团队的状态不应该成为阻碍业务发展的因素。

我很认同这个观点。但团队当下的状态同样重要，比如：团队稳定性，成员心理状态。如果团队已经长时间高强度运转，而且部分同学已经有消极的状态时，就有必要做出调整了。

万一干到一半出现离职状况岂不更糟，比起这样我宁愿阶段性牺牲业务节奏。

当然，把控业务节奏是最后的选择，只有在无计可施的情况再去协调

在此之前可以采用：

• 组内协调资源消化需求（不同业务线的资源灵活调配，通常同部门下的业务线，跨部门也不现实，这属于同级间的协调）

• 跨部门协调资源（需要向上级申请了）

• 申请hc，尤其让业务驱动，通常会更有效

• 技术方案优化

• 业务的mvp版本协商（俗称砍需求）

• ...

即便这样依旧完不成的话，那就需要找业务协商，该降降节奏了。

我坚持认为，无论是个人问题还是管理问题，只要你不做出改变，那你和你的团队始终都会维持现状甚至更糟，

能解决眼前问题，就是随意应变的体现么

ok 继续前面的综合能力的话题

（四）如何训练自己的综合能力

技术学习，大家基本都具备，通常离不开：看文章，写demo，研究问题，个人规划等等，因为不是重点，这里就不展开了

我着重聊下技术外的东西，我自己的方法：

1）采用固定流程跟进业务

每周研读产品周报，明确本周重点，观察数据变化
每周分析一个业务问题（可以是任何问题）
业务周会，尽量主动提个有效建议（可以很小）
即便提不出来，也没关系，重要的是需要不断训练自己的找问题的能力

2）软素质学习和积累

快餐类的，如：樊登读书
系统类的，如：极客时间，喜马拉雅等等
每种学习方式有自己的特点，
对于职场心理学、管理类、创业类、人文社科等初期我建议用快餐式学习
系统学习个人根据实际需要

听听这些能让程序员思维大幅提升
有学习，就得有积累，有用的东西需要积累下来，不管和别人交流还是分享，都用得到
慢慢也会发现，自己沟通的内容也会越来越有营养

3）团队分享

分享，很多人比较抵触，一个是确实没时间，另一个也是怕做ppt，怕讲不好
做过分享的同学都有同感：分享前的一周收获颇丰
分享可以锻炼自己的归纳总结，准备的同时，还能了解到很多边边角角的知识点
而且分享可以锻炼演讲能力

很现实的例子：职级评审，平时做了很多东西，被公认的大牛，但在关键时刻却说不出来

4）充分利用周报

周报除了写本周工作内容外，额外附上：

1）个人学习（文章、技术、业务），对自己也是个敦促
2）思考内容（前文提到的）

大原则：

• 思考是练出来的，别让自己脑子锈住

• 做事要讲逻辑

• 给自己充电：多听课，多看书，多积累

• 结合业务逐渐打磨自己的体系

• 多跟业务沟通，练练嘴皮子，生活动中也用得到

结语

我相信，懂业务的技术型（管理）人才未来会有非常广阔的空间。当然，其他技术路线也各具特色，只是我个人可能更喜欢这种

公司发展靠业务，技术助力业务，业务驱动技术。对业务的积极思考，可以让个人成长更有目标感，同时也可以让个人成长有机的融入业务中去。相互促进，会让人更接地气，同时有更快的个人发展。

当然，这些是我的个人想法，如果觉得偏激，也请见谅， 未来是不确定的，只能慢慢蹚出一条适合自己的路

---

请你喝杯🍵 记得三连哦～

1.阅读完记得给🌲 酱点个赞哦，有👍 有动力

2.关注公众号前端那些趣事，陪你聊聊前端的趣事

3.文章收录在Github frontendThings 感谢Star✨