不想谈业务的开发不是好开发

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

前言

你一定经常听到“作为一名开发人员,一定要熟悉ↅ业务…blabla”类似的说法。但是当你本着“听人劝,吃饱饭”的想法,开始尝试去じ熟悉业务时,一些问题迎面而来:ж

业务到底什么?能不能具体点?业务、产品、研发之间到底是什么关系?应ⓞ该如何去熟悉业务?怎么样才算了解业务?To B业务的特点是什么?……

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

什么是业务?

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

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

那是我第一次知道了核心企业与小b、小r之间的业务及资金的关系,银行通过核心企的订单去管理上下游中小企业的资金流和物流,银行▬的盈利模式,我司应该从怎样的角度去建立风控模型等业务相关的知识。

了解这些“相关背景”,知道我要做什么,才能更好地知道下一步怎么做。

还是以智能风控系统做例子,假设一名技术人员小A负┗责开发其中一个功能模块:每天从行方指定sftp上获取当天的信贷数据,将其解析成指定格式的数据,进行一定的处理,并入库。

如果我们单纯开发,肯定很简单。但是在开发之前,我们要明确业务需求:

数据属性是什么?是业务平台的订单数据、期初数据还是授信数据? 每种数据是什≮≯么含义,有什么用途?是实时数۩据还是银行当日的跑批数据?实时数据的响应时间要求是多少?银行一般晚上几点跑批?几点进行对接? 数据如何存储,如何设计表结构设计为全表还是拉链表? 那些数据是需要Ф更新,那些数据是需要存储,方便月终对账的行方对账的逻辑是什么? 如何设计表结构才方便对账以后出报表的时候,怎么才方便取数?

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

下面总结几点我的理解:

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

为什么要了解业务?

在明确了什么是业务问题后,很多同学可能会认为:“我是一名开发人员,我只需要按照要求۞۞去写代码⊥就好了啊;即使后续有什么问题,那也不是我的锅啊。

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

首先我们要明确一个观点:不管是开发人员还是数据分析人员,都要熟悉业务。

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

懂业务就是懂需求,就是懂得换位思考。我们讲共情心,我们都不知道对方Θ想要什么,怎么能做出满意的产品◎。技术是我们的手段,但不是目的。业务方想要的是各种数据分析结论的落地,是能够产生价值的工程产品。

如果我们不去了解业务,那么就要۩๑警惕变为“被动执行者”,在居士的《数据团队思考:数据驱动业务,比技术更重要的是思维的转变ξ》一文中提到:

被动执行者完美地完成业务需求,但没有主动去发现和提出问题。被动执行者在数据相关的工作中,一般来讲主要是各种完成业务的报表、业务提数需求和一些业务方想法的验证。如果你一直处于这种角色,那么,请注意,公司是永远都不Ч缺被动执行者的,你的工作可能很快会被外包同学替代。

这个世界,缺的是技术过硬又精通业务的工程师,缺的是真正能解决实际业务问题的人,缺的是复合型的人才。

了解业务,说白了就是对自己的团队的资源非常熟悉,并且洞悉和掌握了公司的流程,知道如何利用这些资源К和流程来完成业务目标。

一个产品、一个项目,能否落地、如何落地、整体的判断,都依赖于对自身业务的了解。因此,开发人员要做的不仅仅是去满足业务的需求,而是要去了解业务的背景。参与到设计阶段,使技术可行性和产品需求更契合。

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

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

如何去了解业务?

如何了解业务:

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

首先要认清楚公司的业务模式、组织架构、部门角色以及KPI。在熟悉了基本信息之后,就要从自己所接触的业务框架和业务流程学起,这个时间段需要做的就多看,多问,多做。

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

在“做”这∝个过程中,我们可以进行“角色扮演”:

把自己当作用户,去熟悉使用过程; 把自己当作是测试,审核需求及流程完整度; 把自己当作产品,理解产品设计; 把自己☞当≌作开发,去深挖业务细节; 把自己当ю作架构,学习其架构设计等等。

关于To B业务

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

To B就是面向企业,To B产品本质是帮助企业提高生产效率的工具,▂▃▅▆█企业消费,除了有可见的购买成本,还有不可见的更高昂的维护和迁移成本。

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

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

如果对目标客户的业务不了解,本来能匹配的需求就可能被忽略,本来能正确交付的产品就可能交付错误。对不同领域的客户,如果不明确目标需求,就会出现交付服务不匹配,客户问题没得到解决等问题◣。

因此To B公司,更需要去了解业务。

总结

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

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

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

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

另外我们做一件事的时$候,需要时刻提醒自己,要想清楚三个问题:ⓛ

弄清楚,为什么做这件▊事?做这件事的价值是什么๑? 去思考,如何做这件事? 完成后的产出是什么?明确衡量标准。

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

 

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

来源:https://mp.weixin.qq.com/s/L1h⊿CgTOs2IM92AkLQNPzfw

本文由 @木东居士 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 ±CC0 协议

 
®关于本站文章™ | 若非注明原创,默认 均为网友分享文章,如有侵权,请联系我们™
㊣ 本文永久链接: 不想谈业务的开发不是好开发