业务,似乎与开发人员不是太相关,开发人员天生处于技术端。但是,一个只会开发的开发人员,很容易被代替,只有真正了解业务,才能真正了解需求,做出好的产品。
你一定经常听到“作为一名开发人员,一定要熟悉业务…blabla”类似的说法。但是当你本着“听人劝,吃饱饭”的想法,开始尝试去熟悉业务时,一些问题迎面而来:业务到底什么?能不能具体点?业务、产品、研发之间到底是什么关系?应该如何去熟悉业务?怎么样才算了解业务?To B业务的特点是什么?……
那么如何去解决这些问题呢?
我理解,业务是一个很实在的东西,就是办的什么事?怎么办事的?
记得我刚到公司实习,接触的第一个项目是某银行供应链金融智能风控。老大没有直接让我clone代码去写程序,而是拿出一个小本,一边给我讲供应链金融体系怎么回事,一边在本上给我画出了业务流程以及简单的产品架构。
那是我第一次知道了核心企业与小b、小r之间的业务及资金的关系,银行通过核心企的订单去管理上下游中小企业的资金流和物流,银行的盈利模式,我司应该从怎样的角度去建立风控模型等业务相关的知识。
了解这些“相关背景”,知道我要做什么,才能更好地知道下一步怎么做。
还是以智能风控系统做例子,假设一名技术人员小A负责开发其中一个功能模块:每天从行方指定sftp上获取当天的信贷数据,将其解析成指定格式的数据,进行一定的处理,并入库。
如果我们单纯开发,肯定很简单。但是在开发之前,我们要明确业务需求:
这些问题实际上是和开发没有什么关系的,但却是我们应该去了解的业务问题。
下面总结几点我的理解:
在明确了什么是业务问题后,很多同学可能会认为:“我是一名开发人员,我只需要按照要求去写代码就好了啊;即使后续有什么问题,那也不是我的锅啊。
其实这种想法没什么毛病,但是这样就可以满足了么?
首先我们要明确一个观点:不管是开发人员还是数据分析人员,都要熟悉业务。
对于技术人员来说,有两种大牛:一种是技术大拿,技术团队中的定海神针,可以不食人间烟火;另一种就是如何能够利用手中的技术去解决某一方面的业务问题,从而产生了什么价值。
懂业务就是懂需求,就是懂得换位思考。我们讲共情心,我们都不知道对方想要什么,怎么能做出满意的产品。技术是我们的手段,但不是目的。业务方想要的是各种数据分析结论的落地,是能够产生价值的工程产品。
如果我们不去了解业务,那么就要警惕变为“被动执行者”,在居士的《数据团队思考:数据驱动业务,比技术更重要的是思维的转变》一文中提到:
被动执行者完美地完成业务需求,但没有主动去发现和提出问题。被动执行者在数据相关的工作中,一般来讲主要是各种完成业务的报表、业务提数需求和一些业务方想法的验证。如果你一直处于这种角色,那么,请注意,公司是永远都不缺被动执行者的,你的工作可能很快会被外包同学替代。
这个世界,缺的是技术过硬又精通业务的工程师,缺的是真正能解决实际业务问题的人,缺的是复合型的人才。
了解业务,说白了就是对自己的团队的资源非常熟悉,并且洞悉和掌握了公司的流程,知道如何利用这些资源和流程来完成业务目标。
一个产品、一个项目,能否落地、如何落地、整体的判断,都依赖于对自身业务的了解。因此,开发人员要做的不仅仅是去满足业务的需求,而是要去了解业务的背景。参与到设计阶段,使技术可行性和产品需求更契合。
一方面降低了产品经理与开发之前的沟通成本;另一方面在开发之前尽可能地将各个方面考虑清楚,有助于把开发任务拆解的简明、清晰,既提高了开发效率,又避免了后续因为业务逻辑问题而对代码进行的修改和调试。
可以说尽可能的去了解业务,是一名开发人员的职业素养。
如何了解业务:
可以遵循“面-线-点”的方式,先从宏观上去了解行业以及公司的整体业务,然后是某个垂直领域,最后再深入到具体的业务场景。
首先要认清楚公司的业务模式、组织架构、部门角色以及KPI。在熟悉了基本信息之后,就要从自己所接触的业务框架和业务流程学起,这个时间段需要做的就多看,多问,多做。
在“做”这个过程中,我们可以进行“角色扮演”:
最后再简单地说一下To B的业务。
To B就是面向企业,To B产品本质是帮助企业提高生产效率的工具,企业消费,除了有可见的购买成本,还有不可见的更高昂的维护和迁移成本。
因此整个过程是是理性的、专业的、团队化决策的,每次采购,涉及的关键角色很多,至少有使用方、评估方、预算方、拍板方、签字方共同参与。不像个人的冲动消费,完全是个人决策,如在淘宝买一件衣服、安装一个APP。
To B产品还有一个非常重要的点,就是和企业客户的业务流程是高度相关的。
如果对目标客户的业务不了解,本来能匹配的需求就可能被忽略,本来能正确交付的产品就可能交付错误。对不同领域的客户,如果不明确目标需求,就会出现交付服务不匹配,客户问题没得到解决等问题。
因此To B公司,更需要去了解业务。
针对以上内容做一个总结。
最后还要说一句,本文只提供一些对业务重要性的认识及了解业务的方法论。在实际工作中,业务与本职工作的结合和取舍,还要自行把握。
坦白说,做这些并不能为你带来立竿见影的高处,更多的是一个积累的过程,只有厚积薄发才能水到渠成。
另外我们做一件事的时候,需要时刻提醒自己,要想清楚三个问题:
以上三个问题虽然简单,但确是简单有效的方法论(来自阿里某资深产品经理的),需要时刻牢记。
作者:Japson。某人工智能公司AI平台研发工程师,专注于AI工程化及场景落地。公众号:木东居士(ID:Data_Engineering)
来源:https://mp.weixin.qq.com/s/L1hCgTOs2IM92AkLQNPzfw
我们在做软件开发时学到的很多思维、方法、工具、模型、算法……其实可以迁移到生活中使用,让我们生活得更美好哦。我这里暂举 7 个,以后有时间,慢慢补坑,争取补到 60 个。大家有兴趣的,可以留言补充你最有感觉的。
作为开发人员,我们都希望在完成功能的基础上让代码运行的更快、更省空间,那如何衡量编写的代码是否更有效率,这就需要我们学会如何分析代码时间复杂度和空间复杂度.
JavaScript 是一门复杂的语言,不管处于什么样的水平,都有必要了解 JavaScript 的基本概念。本文介绍了 12 个非常重要的 JavaScript 概念,但绝对不是说掌握好 JavaScript 只需要知道这些就可以了。
服务器时间是东八区时间,页面会在全世界各地,页面 JS 功能需要对比服务器时间和用户本地时间,为兼容世界各地时间,需要将用户本地时间转换为东八区时间
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
先说结论:据我观察,至少有60%的团队误用了敏捷软件过程,或者说至少60%的团队在进行伪敏捷开发。与大家通常的认知是相反的,敏捷过程并不是一个非常容易实践或者实施的过程规范。
敏捷是一个很流行的一个词语,但是在敏捷里面,包括很多团队也是刚开始用Scrum,怎么让质量成为敏捷的一个助力而不是拖累,这个是我主要想谈的。
位我很尊敬的高级开发人员给我打来电话。他想找个朋友聊聊:因为担心自己只能得到可怜的 12% 加薪——而他所管理的其他初级开发人员,则有望获得 40% 的加薪。他还抱怨道
现如今,“ 敏捷 ”可以是指任何东西。渐渐地,它就变得毫无意义了。很多企业已经对”敏捷“感到厌倦了,甚至有了抗拒性。更糟糕的是,就像孔子说的那样:跨学科研究、原则和实践是敏捷的未来。
前端和后端开发之间的界线正在发生变化。有一些常见的错误会导致前端开发人员增加工作量、浪费时间,本文将介绍一些常见的错误以及如何避免这些错误。公司向他们的开发人员和程序员提出更多的要求
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!