什么叫做以业务角度出发探讨问题?

thumbnail

去年的 11 月,一个同事离职前,指出我当时存在的最大的问题就是:思考问题只从技术角度出发,从来不以业务角度出发思考问题。这一评价引起了我深深的思考,直到过去的半年间我真正接手并负责一个项目的时候,才真正想明白这句话的含义。

从业务角度探讨问题真的很难吗?

实际上,这种思维方式一点都不神秘,甚至是一种被真正技术流的程序员所不屑的一种思维方式。简单一点来说,一句话就可以概括:从公司的角度出发,去思考日常生活中会遇到的各种各样的业务问题。

绝大多数的程序员,作为行业中的技术专家,基本都不屑于如此思考问题。软件开发本身就是一个严谨的课题,其中的每一环都应当经过深思熟虑,每个环节都应当是,或者说理应是最优解才对。这样开发出来的系统,才是每个程序员理想中的完美系统。

但是在实施的过程中,很多情况下会被各种现实因素所制约。非常明显的两个因素就是:团队技术能力、项目工期。这两个因素都会对系统的实施产生影响。

例如团队技术能力低的话,很容易会出现:纸面上的设计是一套,但是真正在项目中实现的时候想不到相应的实现方案,而采用了另一套实现起来简单,但是对系统长远期维护不利的设计。最终在交付的时候就会产生货不对版的问题。

另外,项目工期被压缩的很短的话,也会对整个系统产生一定程度的影响。例如:一个很复杂的功能,领导要求一个月内就必须出成果。这会直接导致很多高级技术实现无法采用,最终会交付一个勉强能用的版本。虽然之后可以通过快速迭代的方法迅速改进这个版本,但是,由于工期被压的过短,项目的设计很可能会是不完善的。这会导致未来的某一天,迟早需要对整套设计推倒重来,以极高的代价来满足后续的相关需求。

而所谓的从业务角度出发,也就是为公司业务需求、公司现状和软件开发间寻找一个极佳的平衡点。优秀的软件设计师,在项目开始的时候就能够预先想到其余两点对软件开发可能会造成的影响,并在一开始就指出潜藏的阻碍项,在业务开发前就想办法规避,抑或者说提前在这几个点间进行平衡,最终交付一套对公司,以及对客户满意的系统。而这套系统可能并不是完美的。

为什么绝大多数程序员做不到这一点?

很多人在宣扬这一套理论的时候,都会刻意隐藏做到这一点的前提:具备充足的背景信息,以及充分被上级领导所信任。

首先来看第一点:具备充分的背景信息。这里的背景信息,指的是整个公司今年整体的大战略、目前你所执行的项目在公司内 / 在行业内的定位、你所执行的项目目前具备多少资源、以及你所执行的项目需要面对的客户群体。大多数人可能在第一步就 gg 了,因为很多人的想法都是:我每天把自己的代码写好,把 bug 改好也就够了,思考这么多有什么用呢?而且这些信息,很多情况下是从你的直属领导处所获得的,一般情况下领导也不会给你透露这么多关键信息,如果你转头跑路把消息卖了就不好了(逃)。

其次第二点:被上级领导所信任。大多数的前端职业生涯规划文章都会教你这一点:要在工作中做一个靠谱先生。换个思路来想这句话,就是要让你身边的人觉得你这个人很踏实。一旦人员基数多了,上级领导自然也会被你身边的人所影响,改变对你的看法。做到这一点后,第一点也就迎刃而解了,在拥有充分背景信息的情况下,站在业务角度思考问题根本就不是什么难事。毕竟你已经清楚整个部门希望你的系统达到什么预期效果,按照这个期望来规划整体开发流程是轻而易举的。

对于程序员来说,这种思考方式真的重要吗?

如果从升职加薪的角度来说的话,这套思路当然是必要的。毕竟这样能使你在有限资源的情况下,做出符合部门预期的产品。而部门的考核也是从这一点出发进行评判的。毫不夸张地说,从业务角度思考问题,会使你的项目在公司内的周期变得更长,也会使你的地位在部门内得到飞速上升。

但是我并不建议初级程序员过早的学习这一套思考方式,因为这套思考方式从另一个角度来说的话,算是对于现实生活的妥协。另一个原因是,一旦你涉足这条路,需要你思考的点会直线上升,也就是说,你不能再像以往那样纯粹的在某个技术点上进行深入探究,而是需要从全局入手去思考问题。

而一个初级程序员,职业生涯的前 2-3 年就是一个在为自己打基础的时段。这个时段下过早的涉足过于形而上的思考方式,对于个人的技术能力并不会起到什么帮助,相反的还会分散你在技术方面的专注力。甚至你的开发时间也会被工作中的各种琐事所压缩,直接导致技术能力的停滞。

什么时候需要学习这套思路呢?当你获得权限,去独立担任一个项目的负责人的时候,才是你应当思考这个问题的时候。这时候你会对整个项目负起主人翁的责任,到这个时候再从业务角度出发去思考问题也不迟。

小结

写在 Lowcode 项目上线的前夜,作为一个被强行推出来的技术负责人,这半年间为了项目存活,不断的思考项目在公司内的立足点,也算做到了从业务角度出发思考问题。然而当我做到这一点的时候,却发现我已经变成了过去我最讨厌的那种,为项目缺陷不断寻找各种借口的人。仅以此文缅怀我规划 Lowcode 前的初心,时刻不忘追求极致的技术。

© 2020 — Douglas/rss
友情连接/卡拉搜索