10bet不想谈业务的开发不是好开发?

来源:http://www.chinese-glasses.com 作者:Web前端 人气:157 发布时间:2020-04-29
摘要:作者:Japson。某人工智能公司AI平台研发工程师,专注于AI工程化及场景落地。公众号:木东居士(ID:Data_Engineering)来源: 《软件方法》上——业务建模和需求 可以遵循“面-线-点”

作者:Japson。某人工智能公司AI平台研发工程师,专注于AI工程化及场景落地。公众号:木东居士(ID:Data_Engineering)来源:

《软件方法》上——业务建模和需求

可以遵循“面-线-点”的方式,先从宏观上去了解行业以及公司的整体业务,然后是某个垂直领域,最后再深入到具体的业务场景。

这本书我理解为是从软件开发人员的角度出发,主要聚焦在两方面的技能:需求和设计。鼓励开发人员不要仅仅停留在编码工作,可以试着从纯粹的技术思维转变到业务思维,在做设计之前进行业务建模,才能在激烈的竞争中获得优势。

技术和产品服务于业务,业务方就是需求方;产品梳理业务结构,将业务转变为可行性需求;通过技术输出为工程产品,从而实现我们的核心价值。开发和产品设计需要遵循一个规则——这个规则就是业务,我们依照这个规则,对业务不断地深挖、不断地细化;这样才能优化出符合业务需要的产品,从而去支撑业务、改善业务、推动业务。业务领域的知识包括:我们对行业领域的思考、对业务模式的熟悉、对业务模块的理解等;是一个积累的过程,业务不是“坐而论道”,而是要在实际项目中实践,“真听真看真感受”。为什么要了解业务?


你一定经常听到“作为一名开发人员,一定要熟悉业务…blabla”类似的说法。但是当你本着“听人劝,吃饱饭”的想法,开始尝试去熟悉业务时,一些问题迎面而来:业务到底什么?能不能具体点?业务、产品、研发之间到底是什么关系?应该如何去熟悉业务?怎么样才算了解业务?To B业务的特点是什么?……

利润=需求-设计

作者在第一章先抛出了一个新颖的公式“利润=需求-设计”。可以怎么理解呢?传统的销售利润的公式是“利润=收入-成本”。而在软件开发中,需求工作解决的就是“产品好卖”的问题,要卖出好价钱;而设计工作则致力于解决“降低成本”的问题,软件的制造成本要低。这样最终软件产品才能有高的利润。

这个公式是为了让开发人员明白,需求和设计在开发中其实扮演者不同的角色,所以一定要分开。同时也是明确了业务建模和需求的重要性。

如果需求和设计不分,利润就会缩水。

把需求直接映射为设计,只会产生重复代码。

人体需要许多功能,但功能并不能对应内部子系统的设计。比如人体需要跑步、跳舞、搬运等功能,而做设计时,最终的产物是将人体设计成呼吸子系统、消化子系统等等来支持这些功能。如果把需求直接变成设计,那跑步的呼吸系统和跳舞的呼吸系统就是重复代码了。

相反,也不能直接从设计推导需求。

比如,一个搬运工有心肝脾肺,他找工作的时候也不可能说“老板,我有心管理功能,请我吧”。

总之,拿到需求之后,要先经过分析再做设计。开发人员之间经常提到的“编码的艺术”,不是在讲编码的技能,其实就是分析的技能。

以上三个问题虽然简单,但确是简单有效的方法论(来自阿里某资深产品经理的),需要时刻牢记。

业务建模

第一步,选定要改进的组织,明确目标人群,这里的组织就是我们要研究的对象。我们要做一个银行业务受理系统,这个时候我们要进行业务建模了,需要研究的组织是谁?——银行。

第二步,寻找业务执行者。业务执行者就是在组织之外和组织进行交互的人群或者其他组织。银行的业务执行者是谁?——储户,企业、人民银行等等。

什么是用例呢?

用例就是业务执行者和组织交互达到的,组织能够提供的价值。要注意这里的价值,很重要。怎样才算是有价值的?就是要达到执行者的期望和组织的承诺的平衡点。比如,患者是执行者,组织是医院,而挂号并不能算为一个用例。因为患者到医院挂号后,他所期望的服务不能就此结束了,这并不是他对医院的期望,而且,也不是医院对患者的承诺。

什么是业务流程?

业务流程就是业务用例的实现。先去明确业务用例对改进业务流程有非常大的帮助——先归纳组织对外提供什么价值,再思考如何更好地优化组织内部流程来实现这些价值。这就是一种很好的思路。

怎么去识别业务用例?

主要还是从业务执行者的角度出发,思考业务执行者和组织打交道的目的,基本上能将所有的用例找出。另外一种方式也可以补漏,观察组织内部的活动,一直问为什么,再向外推到组织外部的某个业务执行者。

为什么要思考业务用例?

业务用例不是思考系统提供什么“功能”,而是购买了这个软件或系统后,对于组织本来就有的“功能”会带来一点点帮助。比如,银行的“存款”业务,是银行本来就有的功能。有了存款办理系统后,能够提升存款的办理速度、准确度,客户满意度,所以,还有什么理由不买这个系统呢。


总之,思考用例的过程,就是发现价值的过程。如果我们能不断通过用例思维来思考一个组织或者系统的需求,就能训练出越来越强大的发现价值的能力。所以,其实不论是什么职业什么行业,都很需要这种思维能力,因为,发现价值的能力是终身受益的。

其实这种想法没什么毛病,但是这样就可以满足了么?

愿景

让开发人员介绍现在手头上正在开发的项目时,他们通常会说,这个系统有哪些功能巴拉巴拉。当被问到为什么要做这个系统时,却不知道怎么回答了。也就是说,在他们的意识里,这只是一个可以工作的软件,可是我们真正要回答的是,这是一个可以卖的软件吗?卖给谁?卖点在哪里?这,就是两种不同的思维。

这一点其实我现在作为业务分析人员也有一样的弊病,所以,一定要尽快将思维转变过来。

转变的第一步,就是要不断的问自己这个项目或产品的愿景是什么?也就是,为什么要开发这个项目?第二步,产品的涉众是谁?影响到谁的利益?

一个软件产品的需求是永远做不完的,上万条的需求要先做哪些是需要排序的,而排序就是由以上两点因素决定。

前言

10bet 1

To B产品还有一个非常重要的点,就是和企业客户的业务流程是高度相关的。

刚开始读这本书时,我很惊讶,程序员都已经在学习业务建模了,而我作为业务分析人员如果都不懂业务建模,真是自行惭秽。

记得我刚到公司实习,接触的第一个项目是某银行供应链金融智能风控。老大没有直接让我clone代码去写程序,而是拿出一个小本,一边给我讲供应链金融体系怎么回事,一边在本上给我画出了业务流程以及简单的产品架构。

虽然本书可能是写给开发人员看的,但从我的角度,这本书实在是有很多“干货”,帮助我理清了很多之前觉得模糊的概念。

坦白说,做这些并不能为你带来立竿见影的高处,更多的是一个积累的过程,只有厚积薄发才能水到渠成。

接下来慢慢梳理一下这些概念,进入业务建模的思维模式。

最后再简单地说一下To B的业务。

因此整个过程是是理性的、专业的、团队化决策的,每次采购,涉及的关键角色很多,至少有使用方、评估方、预算方、拍板方、签字方共同参与。不像个人的冲动消费,完全是个人决策,如在淘宝买一件衣服、安装一个APP。

这些问题实际上是和开发没有什么关系的,但却是我们应该去了解的业务问题。

对于技术人员来说,有两种大牛:一种是技术大拿,技术团队中的定海神针,可以不食人间烟火;另一种就是如何能够利用手中的技术去解决某一方面的业务问题,从而产生了什么价值。

我理解,业务是一个很实在的东西,就是办的什么事?怎么办事的?

下面总结几点我的理解:

那么如何去解决这些问题呢?

什么是业务?我的理解是:业务是产品和服务实现价值的目标,是在设计和研发阶段需要遵循的准则,是价值的量化体现。为什么要了解业务?摆脱“被动执行者”,可以从更高的层面去看待问题。如何了解业务?多看多问多做。

多看:多看公司内部文档,包括需求文档、产品白皮书、原型图、产品帮助文档、使用手册、成功案例等等与公司业务相关的文档。多问:用正确的提问方法,在恰当的时机,找相关的人去问合适的问题。关于以上四个形容词,可以自行理解。多做:自己在看和问的时候有所产出。比如,看文档或系统时,去梳理整体业务流程,动手画出大致地系统流程图来,也可以是系统框架,系统功能模块等;将问的问题与自己的感悟相结合,做总结;多使用公司的产品,多跑业务流程,去分析流程后的业务细节,通过数据、代码、动作去理解。

业务,似乎与开发人员不是太相关,开发人员天生处于技术端。但是,一个只会开发的开发人员,很容易被代替,只有真正了解业务,才能真正了解需求,做出好的产品。

针对以上内容做一个总结。

一方面降低了产品经理与开发之前的沟通成本;另一方面在开发之前尽可能地将各个方面考虑清楚,有助于把开发任务拆解的简明、清晰,既提高了开发效率,又避免了后续因为业务逻辑问题而对代码进行的修改和调试。

最后还要说一句,本文只提供一些对业务重要性的认识及了解业务的方法论。在实际工作中,业务与本职工作的结合和取舍,还要自行把握。

可以说尽可能的去了解业务,是一名开发人员的职业素养。

如何了解业务:

本文由10bet发布于Web前端,转载请注明出处:10bet不想谈业务的开发不是好开发?

关键词:

最火资讯