业务痛点、个⼈成长以及未来发展的⼀些思考
今天我们不讲技术，给⼤家换换⼝味
聊聊我个⼈对发掘业务痛点、个⼈成长以及未来发展的⼀些思考
本⽂索引
发掘业务痛点、个⼈成长和未来发展的关系
如何发掘业务痛点
业务压⼒⼤怎么兼顾个⼈成长
如何训练⾃⼰的综合能⼒
四个章节是循序渐进的，建议顺序阅读。篇幅有些长，请耐⼼读完
（⼀）发掘业务痛点、个⼈成长和未来发展的关系
先问个问题：发掘业务痛点和个⼈成长这两点冲突么？
我猜，⼤部分⼈会回答“不冲突”
理想情况：解决业务痛点的技术⽅案，同时满⾜新技术的探索，最终业务痛点解决了，个⼈技术能⼒提升了，皆⼤欢喜
但⾻感的现实却是：这样的需求基本可遇不可求，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）珍惜每次（业务）周会抛出的问题和槽点
周会上产品运营同学的吐槽，其实就是⼀个很好的切⼊点

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。