其他分享
首页 > 其他分享> > 业务开发扯淡

业务开发扯淡

作者:互联网

书接上一回,业务架构扯淡,今天我们聊聊业务开发。
做技术的人,心中总会有技术偏执,多少会有写中间件的倾向,做基础架构,做开源项目,以技术改变世界,或者起码改变身边,产生自己的影响力。能做到的同志可能不少,但是回顾现实,很多时候,我们更多的时候是在做业务开发。这很尴尬不是吗?面试的时候,聊天的时候,提到业务开发,聊天对象心里面产生的第一个感觉是否就是很无语的增删改查?很不幸,这事我也没办法,正如很多广东人至今认为出了广东就是北方,北方冬天下雪,小学语文课都这么教,没毛病。
我们能做的,只能是做到更专业的自己,更高的交付,那么下面我尝试从几个方面扯淡。

大环境(初始化上下文)

很悲剧,2020年并不友好,开局一场疫情,外贸奔溃,互联网,实业一片凉凉,身为开发的我们,承受的是更少的资源,更快的发布节奏,整个行业都在玩优化,没办法,我们只能跟着优化自己。

项目

如何正确的做事情,这事应该不用扯,老生常谈,项目无非就是范围,资源,质量,进度这几个要素之间博弈后的结果。身为开发,我们基本影响不到资源(2020只会更少),我们能影响的因素:范围,质量,进度。

范围(业务)

假设在进度,质量,资源不变的情况下,决定我们最终交付的成果的,相当大的因素是项目开始时,圈定的范围,每个排期确定的发布内容。这很好理解,但是我想表达的是,开发不应该只是埋头接受。当环境压力大起来的时候,我们应该主动参与决策,而非仅仅被动撸代码,要参与,承担范围(即发布内容)重要程度,优先级的review。

有很多原因逼迫我们干这事。比方说,产品同学会有自己的强迫症,可能会觉得多展示一个信息,会让用户更舒服;A产品提了自己需求,B产品也来了;老板紧急需求;诸如此类,这些需求带来的效益是多少?纷乱复杂的多个需求下来怎么玩?这里有几个事得做:

  1. 全局思维:
    请放到公司层面思考业务。把我们负责(或者即将开发)的系统套进公司的业务链条中去思考。我们负责的系统,占据什么样的位置,和其他系统怎么交互,如何影响和干预最终的结果(让公司挣钱)。本次开发的功能,是核心业务功能,还是非核心?是否可以通过替代方案或者临时运维。

  2. 理解业务
    对业务的理解也应当抽象,如同设计,比如说,这个业务的信息流是怎样的,业务流程是怎样的(资金流,物流,交互等),业务本质上就是商业逻辑的系统化方案。我们可以参考jvm怎么优化代码的,先构造出一个图,区分控制流和数据流,算法一匹配,完事,业务梳理也是这个思路,殊途同归。有了这样的抽象思维和对细节实现的把控(产品同学通常不熟悉细节,并且对数据流的把控不如开发),下次圈范围pk的时候,飞龙骑脸是必须的。

  3. 28原则
    按照最经典的,重要程度/紧急程度区分四个界限,画个图,把堆积的需求列一列,再配合对业务的理解(请注意,公司视角),相信排期出来的,永远2.8原则里面2的部分会全部在排期中,8的部分会包含一部分,剩下一部分通过运维或者沟通,小步快跑,积极调整。(这里再附送一个个人心得,80%不重要的功能,只要拖上一两个版本,很快业务可能忘掉,不用谢)

  4. 和产品沟通
    最后,我们开始和产品沟通,结果只有两个:

质量

质量大致上分为,可维护性,扩展性。这里的细节和见解太多,只阐述个人认为的在高强度进度压力下的最低标准:代码要做到结构化,可读性,足够的日志

在此之上,可以根据排期紧急程度酌情提高要求,比如单元测试覆盖率。单元测试很重要,也很费时间,高质量的单元测试,对比设计,撸代码的时间占比大概要去到1:1:1。可测试性,个人认为在中等压力下面应该纳入最低标准。可测试性也是代码质量最重要的标准之一,也是提高个人设计水平的重要工具。

进度

进度没啥好说,加班呗。。

进度对个人而言,往细里说,是工作方式,时间安排,相信各位老司机各有各的开车习惯,这里推荐一种方式,把工作内容做简单归类:思考清单,执行清单,休息清单

总结

现实就是我们压力越来越大,年纪也越来越大,只好保证自己在有限的时间里都在做最重要的事情,并且调整自己的工作方式尽量做到更好。

by da01.chen

标签:代码,业务,扯淡,开发,进度,清单,我们
来源: https://blog.csdn.net/vipshop_fin_dev/article/details/105941118