研发人员如何才能在做业务的过程中自我增值?

简介: 如何才能在做业务的过程中不再是资源一样被消耗而是像资产一样自我增值?如何成长?如何高效率地成长?如何让自己的成长走在环境要求的前面?基于以上这些问题,本文将依次阐述以下内容:先从“人的本质”入手(第二章节),接着探讨“人的成长”的本质(第三章节),最后再探讨业务和技术的一般规律及应对策略(第四、第五章节)。需要注意的是,以下内容受限于个人能力和经验有限,在描述规律的过程中,可能会存在维度的缺失;或者当前描述的规律所涉及的维度并不是某些读者认知中的重点,因为事物不同的维度在不同角色和级别的人的认知中重要程度不同。

1 背景

如何才能在做业务的过程中不再是资源一样被消耗而是像资产一样自我增值?如何成长?如何高效率地成长?如何让自己的成长走在环境要求的前面?

基于以上这些问题,本文将依次阐述以下内容:

先从“人的本质”入手(第二章节),接着探讨“人的成长”的本质(第三章节),最后再探讨业务和技术的一般规律及应对策略(第四、第五章节)。

需要注意的是,以下内容受限于个人能力和经验有限,在描述规律的过程中,可能会存在维度的缺失;或者当前描述的规律所涉及的维度并不是某些读者认知中的重点,因为事物不同的维度在不同角色和级别的人的认知中重要程度不同。

2 人的本质

在哲学层面上,讨论“人的成长”实际上是探讨“人”这一客观事物在特定维度上的某种积极的发展趋势。因此,在谈论“人的成长的本质”之前,我们需要先搞清楚“人的本质”究竟是什么,接着才能对“成长是人的些维度的什么样的变化趋势”得出合理的结论

“人的本质是人自身,是人的需要,是自由的有意识的劳动。人的本质不是单个人所固有的抽象物,在其现实性上,它是一切社会关系的总和。”

人的本质可以分为两个维度,一个是人的物质性,一个是人的社会性。

人的所有的行为,不是在满足自己的需求,就是在满足别人的需求。满足自己的需求的过程,可以粗略总结为实现个人价值的过程;而满足别人的需求,就是通过劳动(即实践)创造价值并完成价值的交换的过程。

3 “人的成长”的本质

由认知提升所指导的实践过程所创造的价值的提升,是人的成长的本质。

3.1 人的价值,是判定人是否成长的唯一指标

马克思主义哲学把人的价值区分为个人价值和社会价值。个人价值是通过实践满足个人需求产生的,而社会价值则是通过实践满足他人需求产生的。“人的价值”的评估分为两个维度:自我评价,与个人价值相关;外界评价,与社会价值相关。两者共同构成了人的价值评估,缺一不可。个人价值的评估取决于价值创造过程和自我认知,而社会价值的评估则取决于价值流转过程和群体对个体的认知。

这为“如何从各个方面提升人的价值和评价”提供了理论基础并指明了提升途径:在客观方面,我们需要改进价值创造过程和价值流转过程;在主观方面,我们既要提高自我认知,也要通过科学、合理的方法提升他人对我们的认知。通过客观和主观两个方面的共同努力,实现“人的价值”评估结果的提升。

3.2 "认知提升”是个人成长的前提

认知提升是个人成长的前提,它强调了在一般情况下,认知变化是个人实践结果变化的前提。

认知没有提升,实践过程和产出的价值变化通常不大,因此产出的价值在面对个人评价和外界评价时,也不会产生质的变化。

即便有特殊情况,个人认知没有提升但是实践产生的价值变大,那也要实事求是地进行分析价值组成,一般也都是由其他外界因素影响带来的价值增量,与个人本身无关。

建立这样的认知有助于个人合理评估自身价值和了解所处的情况。职场中很多人没有这个概念,把平台、额外的资源带来的价值增量误以为是个人创造的,表面上看起来每年工资、职务都在上升但是忽略了个人认知的提升,导致的结果就是在某个时间点发生职业生涯变动时,就会发现个人和N年前的自己相比毫无变化,而所处的就业环境已经对自己非常不友好了。

这其实就是大家常说的:需要在成长的路上褪去平台带来的光环来看待自己,抛开各方干扰真正静下来审视自己才能突破。

3.3 人的价值,是判定人是否成长的唯一指标

“人的价值”的评价包括自我评价(个人价值)和外界评价(社会价值)两个维度。这两个维度共同构成了人的价值评价,缺一不可。个人价值的评价取决于价值创造过程和自我认知,而社会价值的评价取决于价值流转过程和群体对个体的认知。

当我们讨论一个人的价值时,需要综合这两个维度的评价结果。如果一个人没有创造个人价值,他无法判断自己的价值大小,也就无法从内在本质上认同自己是否成长。同样,如果一个人没有创造社会价值,那么他所生活的社会群体无法感知他的存在,也就无法客观地评判他是否成长。

3.4 实践创造的“价值的提升”,是“人成长的本质”对外呈现出的现象

“成长”是指客观事物的某个属性在一定时间内发生有利于其生存和发展的变化或呈现出这样的趋势。对于个人来说,成长体现为“人的价值”的提升。在追求成长的过程中,确立合理的标准和采用科学合理的评判方法至关重要。

首先,要确立评判标准。我们应该明确自己想要在哪些方面取得成长,设定明确的目标,并确保这些目标与实际情况相符。这样才能避免盲目追求成长或陷入过度完美主义的困境。很多人觉得自己有成长,细问起来今年的自己和去年的自己有何区别,却无法说清楚——这就是因为个人对自己想要成长的维度不确定,对成长的标准没有设定,对是否有成长也没有科学合理的判断方法,一切都是在凭感觉下结论,这些问题会让成长过程变缓慢甚至没有成长,最终导致法应对环境的要求。还有些人已经是人中龙凤,每天做事也殚精竭虑,但是总觉得自己不够好,总觉得实际结果不及理想预期,一味的长期坚持完美主义,就导致个人精神健康和生理健康都受到非常负面的影响——这也是因为个人价值判断标准设置不合理,究其根源在于认知出了问题导致的。

其次,要建立科学合理的评判方法。这意味着要平衡自我评价与外界评价,避免过度自信或自卑。要学会接受和处理外界的评价,但也要进行自我评估,确保自己的价值判断是客观的。很多人骄傲自大,就是没有合理综合环境对他的评价,在认知上过高地评估了自己创造的价值,可以多和周围的人沟通对齐来解决;很多人周围的人说他不好,就会产生非常大的负面情绪继而产生自我内耗而无法把事情做好,本质上也是因为过重的、不分对错地看待外界评价,而没有做好个人自我评价的结果。

最后,不论是设定合理的标准还是建立科学合理的评判方法,都要始终关注个人价值的本质。综合客观地评估个人价值,既不过分依赖自己的主观判断,也不完全受制于他人的评价。这样,我们才能在面对困难时坚持自己的理想,同时在遇到“不可为之事”时时接受他人的建议,实现真正的成长。

3.5 “人的成长”的现象与假象

“在某个环境中,在某个维度下,在一定时间尺度上,个人对自己的实践所产生的结果与过去相比更加认可,个人所在的群体也对个人所创造的价值更加认可,就是成长的现象。”

有人想成长,读了很多书,知识储备变大,专业技能提升,代码写得很优雅,把程序当艺术品,却对公司业务没有任何实际帮助,在公司眼中这种成长是不是成长?(这种情况下,个人需要思考如何将所学应用于实际工作,以提升自己在公司中的价值,或者换一个能发挥作用体现出个人价值的公司)

有人借力平台,平台需要什么就做什么,随着业务发展乘风破浪,收入年年攀升,脱离公司的环境再看,究竟有没有成长?(他们的成长是否依然存在,取决于他们是否具备独立思考、解决问题的能力以及是否能够在不同环境中实现价值。)

有人趁着年轻打拼多年所获颇丰,人到中年后却突然佛系起来,他是否是成长了?(他们的成长取决于如何看待这种转变。如果他们能够在不同阶段发现自己的价值,并在过去的经历中汲取经验和智慧,那么这样的转变可以被看作是一种成长。)

这些问题我给出了自己的答案,但他们其实都没有正确答案,只有当事人自己知道自己想什么,知道自己做了什么,而究竟做怎么样,不仅需要交给周围环境来检验,还需要交给时间来检验才能有所定论。所以最终我们再从具体现象回归到哲学,人的成长的现象最终究竟是真是假,还是要看其所为(客观事实),也要看其本心(主观认知)。

4 业务的发展规律及应对策略

4.1 业务的发展规律

业务的生命周期如下图所示:

img

看图时,需要注意以下内容:

图中的曲线仅用于定性分析,非定量分析的精确图表,因此生命周期中各阶段的长度、和业务规模、利润规模的比例关系也都是示意型的,而非精确的比例关系。不同的业务,生命周期长短可能不同,各阶段持续的时间也不同,业务方期望各阶段持续时间长短也不同,需要具体问题具体分析。不同的业务,利润出现的时间和业务生命周期的阶段对应关系不同,利润规模和生命周期各阶段对应关系也不同,需要具体问题具体分析。

在此基础上,我们简单用语言讲清楚业务发展过程是怎样的:

4.1.1 启动期

启动期可以粗略分为立项期和验证期。

立项期主要关注业务定位和规划,需要结合组织战略、价值观和大环境的要求来制业务计划。这一阶段通常由业务侧产品经理(PD)或运营发起。

验证期则在立项通过后开始,主要目标是通过快速实现产品原型,验证业务模式的可行性。并且目标客户群体的客户代表是愿意为这种产品付费的。这个阶段一般会投入大量的研发人员来做对应的信息系统来支撑业务的运行。研发团队在验证期通常需要深度参与项目,并在此阶段成为主要角色。

4.1.2 发展期

在启动期完成价值证明之后,业务进入发展期,此时的重点是将经过单个客户验证的业务模式快速扩展到更多客户场景,实现业务规模的快速增长。在这个阶段,研发团队需要处理系统完备性问题,以适应更多客户的需求和新的共性场景。

然而,发展期的主角不再是研发团队。研发团队的角色逐渐从主要行动者转变为基础参与者,其他团队如运营、产品经理、销售、客服等团队将共同协作,成为当前阶段的主角。因此,研发团队在支持客户业务需求的同时,还需承担业务上下游协作角色的需求的信息化任务,这一点往往是研发人员可能会忽视的点。

4.1.3平台期

在业务规模增长达到上限并逐步趋于平缓的阶段,企业开始关注利润的最大化,降本提效成为主旋律。这个阶段可能会出现较多矛盾和问题,本质上源于之前业务阶段留下的隐患。对于研发人员而言,寻找既能满足长期利益又能兼顾短期利益的方案至关重要,但长期利益应始终是主要原则。

在业务进入平台期后,整个业务进入成熟周期。组织和流程逐步完善,形成支撑业务平稳发展的体系。然而,这也可能导致组织僵化,对市场和客户变化的感知敏感度下降,以及决策延迟或阻滞。如果不做调整和干预,业务进入衰退期是必然的。

在这个阶段,业务和技术都不是解决问题的关键,而是组织本身。

4.1.4 衰退期

业务进入衰退期,个人需要考虑的一个问题就是,业务经历完整的生命周期而消亡是自然规律,那么对应的技术是否也需要随着业务的消亡而消亡?如果技术和业务耦合度太高,那么业务消亡自然会牵连技术。

4.1.5 消亡期

如果业务进入消亡期没啥好说的,及时转身止损,投入合理的资源善后即可。

4.2从整个业务发展的规律来看,个人需要具备哪些能力

从业务发展规律来看,研发人员能力大多数和做业务相关,同时和宏观的技术架构及落地把控能力相关,具体如下:

  • 分析业务本质的能力,即能看清业务内部主要矛盾次要矛盾,能根据业务内部和外部环境的相互关联和相互影响来判断业务未来的发展趋势。
  • 利益平衡能力,能够理解各参与方的核心利益诉求,将商业模式与技术系统相结合,平衡各方的利益。
  • 在业务初期,能够根据业务需求和发展趋势,设计具有前瞻性和扩展性的系统架构,同时在初期就关注技术生产力的长线投入。
  • 在业务中期,能够全方位构建业务支撑体系,解决方案化并跨业务复用,利用技术生产力推动业务发展。
  • 在业务末期,能够完成技术沉淀,孵化新的技术产品,为组织带来新的业务增长点。

5 技术的演进规律及应对策略

5.1 业务研发过程中的技术的规律

受业务复杂度和业务生命周期的影响,业务研发过程中的技术整体呈现模型复杂、支持维度多的特征,因此“复杂业务模型的领域设计”、“横跨多个业务生命周期的技术架构演进”、“多维度全方位支撑、保障、驱动业务发展”是三个明显的特点。

从单个业务生命周期来看,业务研发过程涉及到的技术从单一维度向多维度演变;随着业务逐步进入成熟期,应用从单体应用向微服务转化;技术的发展趋势,从简单“把业务跑起来”,逐步形成全方位支撑业务发展的技术解决方案,这是业务研发过程中的一般规律。

如果一个研发团队同时负责多个业务,那么在做业务的过程中,逐步会形成一些多个业务都会复用到的业务服务,这些业务服务领域相对独立,功能通用,各种业务都需要用到,最终逐步形成业务中间件。这个过程本质上就是业务研发过程中,技术“从单维度应用演变为多维度的解决方案”的基础上,继续从“单业务用演变为多业务复用”的过程。

再进一步,如果一个技术一号位先后负责多个业务,那么某个业务本身的领域知识不再那么重要,“如何在没有任何业务背景和经验的前提下完成复杂业务领域建模”变成了技术一号位需要重点构建的核心能力之一。因此业务研发过程中,关于业务建模的方法论是众多技术中的一个非常重要的维度,特别是对于支撑多个不同业务的人而言,该维度的能力是核心能力,是区别于技术研发人员的核心差异点之一。当然由于业务研发过程和技术研发过程会有转换,所以不同情况下的核心维度会发生变化,需要具体问题具体分析。

以上提到的规律是和组织的生命周期相关的,组织稳定,就能沿着单个业务发展的生命周期完成技术从单维度应用到多维度应用的积累;组织有能力承接多个业务,那么就会自然而然地走上解决方案复用的道路,而解决方案的复用带来的好处就是生产力提升以后反哺业务,能够加速业务的某些阶段的发展。

但是值得注意的是,不同于技术产品,很少有团队能走业务研发过程中的技术演进过程。往往是成熟业务的团队才可能走完整个过程。

5.2 如何利用规律或打破规律

5.2.1 提到的技术规律对一般的研发同学有什么启示

  • 认识到生产力形成的过程是和团队的生命周期相关的,成熟的团队生产力相对较高,技术沉淀更深入,但是由于多次的由主到次的迭代,所以一个成熟团队,需要投入精力的领域往往在技术体系上的粒度较细,面较窄,整体更深入;而新成立的团队往往生产力的积累上比成熟团队差,但是面更广。因此一般的研发人员在挑选团队的时候,要看自己当前处于什么样的阶段,是处于积累期,还是处于已有一定积累,需要在广度上做扩展:前者适合去成熟团队,后者适合去新兴团队。
  • 当然,也要认识到业务生命周期和团队生命周期之间的关系。成熟的团队做的业务往往是比较稳定的,换言之,已经稳定的业务一般是由一个比较成熟的团队来支撑的。即使这类型的团队开展了新的业务方向,但是基本盘依然是成熟业务,因此团队稳定性高。但是在这种团队中,一般情况下新加入的员工做的都是比较边缘的事情,因为核心的主要的事情已经有人在做了,并且已经做到了一定的成熟度。新兴团队做的业务往往是新立项做的,不论业务在战略上有多重要,都无法改变它不是当前时间段的主干业务的现实,所以业务能否做成、团队能否稳定存在是一个需要考虑的问题。因此一般的研发人员在挑选团队的时候,也要考虑团队的稳定性,如果觉得稳定性最重要的,那就去核心业务部门,这样的团队相对而言比较稳定,但是要注意做的事情可能是比较细碎比较边缘的;如果是认为施展个人才华更重要,那就选择去新兴团队做新的业务,机会多,虽然开始事情比较杂,但是都是业务的重点,唯一需要考虑的就是团队的稳定性,即业务可能失败而团队被调整。
  • 认识到技术研发过程和业务研发过程的客观转换规律。一般比较成熟的技术团队,技术研发过程已经逐步经过多次迭代,在技术先进性和技术深度上已经完成了阶段性的目标,在成本和支撑的业务场景没有骤变的情况下,大概率不会继续投入,而会逐步将重心调整到整个技术的对外输出上,因此会变成以业务研发过程为主;一般比较成熟的业务团队,业务研发过程逐步完成了对应阶段的业务使命,而继续发展下去生产力就会变成制约业务继续增长的瓶颈,所以除了业务能力建设以外,还会投入更多资源进行技术能力的建设,因此团队主要研发过程会从业务研发过程转变为技术研发过程。因此一般的研发人员在挑选团队的时候,要结合自己究竟想做业务还是想做技术,然后根据目标团队当前的实际情况来看该团队究竟处于哪个研发过程中,而不是只看团队是否是技术团队或业务团队。非常实际的例子就是,在技术团队中,有大量的研发人员做的都是业务功能的开发,而和技术团队真正的核心技术领域关系并不大;在业务团队中,有一些研发人员做的事情并不是真正的客户业务需求,而是在做相关领域的技术深度建设。所以在转岗的时候,不要看团队的类型是什么,而是要看团队当前处于哪种研发过程中。

5.2.2 从技术的发展规律来看,如何选择广度或是深度

目前来看,技术已经出现了很多大领域的划分,从单纯的编程语言到基于编程语言构建的技术栈,再到大数据、算法这类专业技术域,再到各个场景业务领域的基础技术如电商、广告、社交等,并且随着整个技术体系的发展,越来越多的细分领域的投入也在逐步饱和,整个技术栈的深度和广度都已经到了单个研发个体无法完全掌握的程度。所以对于很多初级技术人员首先面临的问题就是:我该怎么选我的成长路径。

究竟是先深度还是先广度,一般情况下,我们都是讲先把基础打好,这是前提,也是未来深度究竟能多深、广度究竟可以多广的决定性因素。那么基础究竟打到什么程度?我个人的感觉和是:一定要在某个技术领域达到专家的程度,然后再去考虑究竟是横向扩充广度,还是纵向发展深度。这些是个人内在的要求。

另外一个方面就是,技术人员所在的团队类型也和发展模式有关,如果是业务研发团队,技术的广度是必然的要求;如果是技术研发团队,那么技术的深度也是必然的要求。这些是外界环境的要求。

在回答究竟是深度优先还是广度优先的时候,要结合个人内在的驱动力和外在团队的要求,眼光放长远去选择即可。

5.2.3 从技术的发展规律来看,如何在做业务的过程中有突破

做业务的时候,绝大多数人都是在不停地处理业务需求,并且往往陷入恶性循环:需求越做越多,越做越急,却最终越做越慢。本质原因是把业务发展和技术发展作为二元对立的过程来看的,做业务需求的时候就认为要赶快做完,PD、运营没有留出做技术的时间所以就不做了;而在有时间做技术的时候却又一心想把各种高大上的东西用起来,满足个人的技术成长欲望、消除自己在技术上积累缓慢的焦虑。但是事实上,做业务开发和做个人技术成长是一个统一的过程。

所以说,想在做业务的过程中有突破,第一件事情就是要在认知上改变过去业务需求和技术发展对立的错误观念,要在思想上把做业务需求和做技术统一起来,而不是对立起来。

6 最后

道路是曲折的,前途是光明的。我们自己要充分认识到成长的艰难和曲折,同时更要认识到掌握合理科学的成长方法论并且实践之后,那么个人的成长是必然的。希望每个渴望成长的人不要遇到困难就轻言放弃。

7 参考资料

阿里巴巴中间件

阿里开发者

8 作者简介

鑫茂,深圳,Java开发工程师。

希望通过文章,结识更多同道中人。

相关文章
|
5月前
产品运营方法论问题之运营策略不变如何解决
产品运营方法论问题之运营策略不变如何解决
|
7月前
|
消息中间件 监控 前端开发
研发人员如何做好日常工作的稳定性保障
本文介绍了一些研发人员如何做好稳定性建设的工作事项
241 0
|
7月前
|
监控 数据可视化 前端开发
高效设计企业营销系统的3种方案实践复盘
高效设计企业营销系统的3种方案实践复盘
146 2
|
7月前
|
前端开发 数据库 云计算
技术运营的工作是什么?
技术运营的工作是什么?
435 0
|
安全 测试技术
如何打造一个“无需激励”自运转的技术团队?
如何打造一个“无需激励”自运转的技术团队?
84 0
|
运维 数据挖掘
《云上大型赛事保障白皮书》——第七章 保障阵型与流程管理——7.2 云上大型赛事流程管理——7.2.1 基于业务影响的流程分级(下)
《云上大型赛事保障白皮书》——第七章 保障阵型与流程管理——7.2 云上大型赛事流程管理——7.2.1 基于业务影响的流程分级(下)
139 0
《云上大型赛事保障白皮书》——第七章 保障阵型与流程管理——7.2 云上大型赛事流程管理——7.2.1 基于业务影响的流程分级(上)
《云上大型赛事保障白皮书》——第七章 保障阵型与流程管理——7.2 云上大型赛事流程管理——7.2.1 基于业务影响的流程分级(上)
110 0
|
大数据 开发者
阿里速度! SRE团队全力保障多地健康码顺利上线
2020年初,新冠肺炎疫情爆发。春节后,企业要复产,百姓要复工,政府需尽快保障各项工作有序开展。如何精准防控,统筹疫情期间的各项工作,有序稳健恢复经济社会秩序,成为当务之急。对此,阿里巴巴快速反应,除各种物资支持、政策响应外,还配合多地政府开发健康码,充分运用大数据手段助力疫情防控和复工复产,实现数字化防疫,让政府相关人员更快速、更清晰、更精准地进行防控管理决策。
阿里速度! SRE团队全力保障多地健康码顺利上线
|
存储 SQL 供应链
软件需求人员-如何提升需求分析和业务方案的能力
  今天我准备再写一篇软件需求人员能力提升方面的文章,也就是把这个问题进一步谈透。对于IT行业来说,前面谈到更多的是招聘软件开发或架构设计人员不容易,特别是架构人员也难以培养。而对于软件需求人员也是同样的道理。   软件需求不同于用户需求或原始需求,对于业务需求往往你无需任何的IT技术背景就能够提出你的需求和问题,而对于软件需求则涉及到业务需求分析,分解,形成完整的业务解决方案,复杂的还是涉及到业务建模,最终才形成软件需求。   因此软件需求人员实际是衔接业务用户和内部技术团队的关键桥梁,软件需求和业务建模做得好,技术实现本身也更加高效。同样,一个软件系统最终实现出来灵活,可复用,那么首先
636 0
|
传感器 物联网 测试技术
如何让您的业务和团队为IIoT计划做好准备
当使用IIoT对公司进行数字化转型时,比技术本身更重要的是每天实施和使用新系统的人员。本文讨论如何与员工进行预先沟通并利用公司内部和外部的正确技能,这是成功实现IIoT计划的关键要素。
345 0
如何让您的业务和团队为IIoT计划做好准备
下一篇
DataWorks