业务痛点、个人成长以及未来发展的一些思考

·  阅读 659
业务痛点、个人成长以及未来发展的一些思考

今天我们不讲技术,给大家换换口味

聊聊我个人对:发掘业务痛点、个人成长以及未来发展的一些思考

本文索引

  • 发掘业务痛点、个人成长和未来发展的关系
  • 如何发掘业务痛点
  • 业务压力大怎么兼顾个人成长
  • 如何训练自己的综合能力

篇幅些点长,请耐心阅读

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这个问题千人千面,先说说我的想法:

  • 只会干“体力”活的
  • 学习能力差,不愿与时俱进的
  • 负能量满满的
  • 上进心不强的
  • 情商低的
  • 人际关系差的

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

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

(看看身边这样的人多么)

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

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

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

这个问题同样千人千面

之前听过一个培训,里面提到FE的发展方向(仍在技术领域),具体如下:

  • 技术类(广:架构师; 深:领域技术专家、科学家)
  • 管理类(技术管理者:经理,CTO;职业经理人:完整业务)
  • 创业类(创始人;技术合伙人,技术高管)
  • 顾问类(投资人:资本运作,投后服务;管理顾问:培训,团建)

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

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

  • 原生语言工具链
  • 全栈趋势
  • 发掘痛点,解决实际问题

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

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

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

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

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

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

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

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

  • 好奇心强的
  • 学习能力强的
  • 善于思考总结的
  • 综合能力强的
  • 情商高的

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

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

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

  • SMART(目标管理)
  • 随机应变
  • 坚持不懈
  • 敢于挑战
  • 直面挫折
  • 适时寻求帮助

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

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

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

说了这么多,是不是感觉有点跑题了,真是么?

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

(二)如何发掘业务痛点

  • 日常的需求讨论和建议
  • 流程优化(开发、协调、…)
  • 性能、体验优化
  • 小巧的技术方案提效(工具、系统)

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

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

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

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

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

怎么验证呢,很简单:

看看自己能不能画出完整的业务流程图(很简单么?)

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

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

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

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

image

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

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

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

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)思考内容(前文提到的)
复制代码

大原则:

  • 思考是练出来的,别让自己脑子锈住
  • 做事要讲逻辑
  • 给自己充电:多听课,多看书,多积累
  • 结合业务逐渐打磨自己的体系
  • 多跟业务沟通,练练嘴皮子,生活中也用得到

结语

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

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

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

感谢阅读

分类:
代码人生
标签:
收藏成功!
已添加到「」, 点击更改