如何挖掘系统的业务价值

最新推荐文章于 2022-09-14 00:06:14 发布

春哥大魔王

最新推荐文章于 2022-09-14 00:06:14 发布

阅读量440

点赞数

文章标签：大数据编程语言人工智能 java 数据分析

本文链接：https://blog.csdn.net/peter7_zhang/article/details/112690783

版权

写在前面

技术是服务于业务的，一个系统的发展应该是以业务为导向的，如果可以很好的挖掘一个系统的业务价值，并用这个价值作为牵引，引领系统走上一个新台阶，应该是一个正常/正确的决定。

重研发投入的两个业务发展阶段

对于研发人员来说投入较大研发成本的系统发展阶段应该有两个：

爆发阶段：某个业务从零到一或是爆发增长，需要搭建一个完全新的系统去承接某个针对性的领域业务，比如橙心从零到一发展起来，很多系统会拔地而起；
平稳阶段：这个阶段代表着业务已经过去爆发式增长的阶段，进入了存量阶段，这个“存量”代表着业务的平稳（新需求来了系统的改动不太大），数据规模增长放缓，不太需要解决大规模数据量、请求量带来的挑战，这个阶段可能会将研发资源投入到“重构”当中，或是重构单一的一个业务系统让他更好用，或是整合几个类似的业务系统变为某个领域的平台系统，支持更好的品类，业务自闭环，降低沟通成本，附以配置化提高人效；

对于这两个阶段的技术问题都是比较确定的，都可以给专项的解，但是在“上价值”的时候对于很多研发人员可能是挑战最大的，特别是对系统重构的同学来说，花了很大的经历投入了研发，但是却不好展示其价值与收益，就像一个姑娘，读四书五经、琴棋书画，让自己变得更好了更善良了，但是价值却很难说得出来。

对于爆发阶段系统的价值其实相对比较容易说，毕竟这个阶段拔地而起的大多项目都有一个服务的大目标，而且很多价值其实可以从运营、产品同学身上找到，经过挖掘沉淀到自己系统所负责的域内就可以了。

但是系统重构更多是来源于研发同学的体感，这种体感包括支持新业务迭代太费劲了，成本巨高。或是系统稳定性太差了，隔三差五出case，一分析发现是架构设计不合理导致。研发人员为了更好的支持新业务快速交付，并提高系统维护的扩展能力，提高系统稳定与可靠做了相应的重构，而这种重构很多时候比从零到一搭建一个系统挑战更大，因为大家习惯把重构叫“在奔跑的火车上造轮子”，而从零到一搭建系统时，这个火车起码还没有奔跑起来。

怎么挖掘系统重构的业务价值

其实我也不知道。

但是我相信肯定有一些针对这个问题相关的方法论的，只不过我还没接触过或是没有消化到，这里当然需要高P的同学们可以各抒己见了，让我们学习学习。

1.思考现状

既然决定重构了，除了某些同学有代码洁癖外，肯定还是有很多客观的外部因素的，比如一个系统里面承接的业务线越来越多，每条线都有自己的业务迭代节奏，而人少活多，就有迫切的效率需求，如何提效呢？我们决定重构。

那么如何重构呢？这里就变成了技术同学的难题了，但是也是我们擅长的。比如我们考虑到每次新业务线的接入对系统的改动都是彻头彻尾的，那么如何提效呢？可以将一些系统基础能力下沉变成标准化的能力，这样新业务改动范围缩小，研发效率会有所提升。

或是之前系统存在稳定性问题，严重影响了使用体验，产生资损，我们经过分析之后发现某些核心数据在高可用保障上存在缺失（或是设计不可以），于是我们针对性做了优化和重构，在事前事中事后都有所保障，此后类似的问题并未再次出现。

上面两个例子是围绕于“需求交付效率”与“资损场景高可用保障”关键词挖掘重构的价值，之前和一些高P聊过类似的价值挖掘，对方会提出下一个问题：

需求交付效率和资损场景高可用保障是所有系统都可能遇到的问题，那么为什么是你这个系统现在需要解决的呢？

当时确实没有预想类似的问题，只能回答：这两点是当时系统最痛的点，系统稳定性与资损高可用是基本盘，如果这两者做不好，上层建筑无从谈起，先打好基本功，从这两点出发。

后来我想了下，这个问题的背后是，你的系统现阶段的目标是什么，你所做的事情是否服务于这个目标。

以我目前的想法来说，可能依然给不出一个趋近完美的方案，只能在转换下话术把语言重新组织吧。

2.对于未来的思考

前面的价值挖掘围绕于现状，系统当前的痛点，系统现阶段要解决的问题。还有一个视角是基于未来，就是我的系统未来究竟要变成什么样子，当然也需要说下为什么要变成那个样子。

我们有了一个未来的样子也就是理想态之后，与现阶段系统进行对比，输出演化路径，围绕于这个演化路径来就可以了。

还是那句话有了演化路径之后，拆解成技术方案并落地，对于研发人员来说都不是问题，又回到了哪个问题了？价值是什么。

如果以这个视角来挖掘价值，这个价值需要足够站得稳，如果理想态的价值都不被认可的话，路径当中所有的投入都会被认为是没有价值的。难。

那么如何挖掘理想态价值呢？很多时候研发人员是不擅长的，需要和产品、老板多聊，你会发现很多事情，和老板聊完之后确实就可以上价值了。

比如我们现阶段系统支持的业务A，B，C，未来还会接业务D，每个业务都有不同的服务场景与类别，未来系统承接多业务线是必然趋势，所以将一些基础和业务能力平台化/中台化，提高企业级的复用能力是目前看起来适应于系统未来发展的演进方向，于是我们提出了某个理想态的架构。所以不论现状遇到的问题还是未来，系统平台化/中台化都是一个顺势而为的决定。

而对应的业务价值，理想态交付之后再做相应的整理吧。