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

更新日期: 2019-09-14阅读: 1.8k标签: 开发

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


前言

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

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


什么是业务?

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

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

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

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

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

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

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

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

下面总结几点我的理解:

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


为什么要了解业务?

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

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

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

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

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

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

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

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

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

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

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

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


如何去了解业务?

如何了解业务:

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

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

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

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

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


关于To B业务

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

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

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

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

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

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


总结

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

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

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

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

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

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

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

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

链接: https://www.fly63.com/article/detial/5307

软件开发教给我们的7个生活指南

我们在做软件开发时学到的很多思维、方法、工具、模型、算法……其实可以迁移到生活中使用,让我们生活得更美好哦。我这里暂举 7 个,以后有时间,慢慢补坑,争取补到 60 个。大家有兴趣的,可以留言补充你最有感觉的。

时间复杂度与空间复杂度分析

作为开发人员,我们都希望在完成功能的基础上让代码运行的更快、更省空间,那如何衡量编写的代码是否更有效率,这就需要我们学会如何分析代码时间复杂度和空间复杂度.

12 个概念,让 JavaScript 开发更加简单

JavaScript 是一门复杂的语言,不管处于什么样的水平,都有必要了解 JavaScript 的基本概念。本文介绍了 12 个非常重要的 JavaScript 概念,但绝对不是说掌握好 JavaScript 只需要知道这些就可以了。

js处理时间时区问题

服务器时间是东八区时间,页面会在全世界各地,页面 JS 功能需要对比服务器时间和用户本地时间,为兼容世界各地时间,需要将用户本地时间转换为东八区时间

敏捷开发

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

敏捷开发是如何被跑偏的

先说结论:据我观察,至少有60%的团队误用了敏捷软件过程,或者说至少60%的团队在进行伪敏捷开发。与大家通常的认知是相反的,敏捷过程并不是一个非常容易实践或者实施的过程规范。

敏捷开发中如何做质量管理?

敏捷是一个很流行的一个词语,但是在敏捷里面,包括很多团队也是刚开始用Scrum,怎么让质量成为敏捷的一个助力而不是拖累,这个是我主要想谈的。

写给开发人员:为什么朝九晚五不适合我们?

位我很尊敬的高级开发人员给我打来电话。他想找个朋友聊聊:因为担心自己只能得到可怜的 12% 加薪——而他所管理的其他初级开发人员,则有望获得 40% 的加薪。他还抱怨道

别再空谈敏捷开发了

现如今,“ 敏捷 ”可以是指任何东西。渐渐地,它就变得毫无意义了。很多企业已经对”敏捷“感到厌倦了,甚至有了抗拒性。更糟糕的是,就像孔子说的那样:跨学科研究、原则和实践是敏捷的未来。

前端开发人员最困扰的事情有哪些?

前端和后端开发之间的界线正在发生变化。有一些常见的错误会导致前端开发人员增加工作量、浪费时间,本文将介绍一些常见的错误以及如何避免这些错误。公司向他们的开发人员和程序员提出更多的要求

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!