一次开发方案决策的系统思考

本文案例已经过艺术加工,请忽略案例本身的真实性。
不久前,完成了一个项目,在制定开发方案时,出现两个方案的决策问题,我来分享了这里面的一些思考。

一、背景

现谈谈背景,我们负责了两条业务线的日常开发和维护工作,就好比淘宝和天猫这种模式,他们背后属于不同的业务部门,但都有一样的商品的购买流程。
就是这样的两条业务线,它们业务相互独立,但提供的业务功能是类似的,所以由一个团队负责,平时相安无事,哪边有需求,哪边放人。
我们就叫业务线A和B好了。

后来有一天,在业务线A花了大力气,投入两个月时间,开发了一个新的产品功能,代号“剁手”。

“剁手”项目一上线,好评如潮,业务线B就眼红了,跟开发团队说,我们也要“剁手”,你们把他们的功能包装下,快帮我们上了。

二、方案

现在,要出开发方案了。
出于软件开发的原则,尽可能让功能复用,不要重复造轮子,我们理想的设计方案自然是这样的。
将剁手功能剥离出来,做成可复用的模块,给两条业务线使用,也好维护。

但是,也有不同的声音,业务线A和业务线B背后的利益人不同,平时井水不犯河水,,不如直接复制一份过去。

所以,对于如下两方案,你会如何决策?如何说服不同的声音呢?

三、决策

不知道你是如何想的,我当时是用系统思考来决策的。
首先,我们现在的问题是:应该选方案一,还是方案二?
这两个方案各有利弊,它们构成的系统之间有不可调合的矛盾,无法做整合。所以我们可以基于系统思考的一个原则:跳出系统看系统。也就是跳出当前的问题,站在更高的层次来思考。
如何跳出呢?有一个方法:向上归类
话术是:X是一种什么?X属于什么?
就“剁手”这个项目而言,它既属于一个功能,又属于一条业务线。

这样,我们可以把要决策的问题重新表述:

  1. 把“剁手”当成一个通用的功能,提供给不同的业务线?
  2. 还是把“剁手”当成不同业务线上实现相同的功能?

这两种说法的区别是什么?
其实本质的问题在于:团队在组织定位是什么?
也就是:

  1. 我们是紧密的团队,给不同的业务线提供相同的功能服务?
  2. 还是我们是松散的团队,只是恰好两条业务线类似才合在了一起?

当我把这个问题抛出来,问团队的成员和管理层。
很快就得到了一个答案,我们其实是不同业务线恰好合在了一起,后面甚至会分开。
那么,答案是方案二,直接复制一份功能给业务线B。
这是一个完全不符合软件设计原则的方案,但却符合团队的组织定位,基于这个前提,我们必须这么做。

四、组织决定架构

在完成项目不久后,公司做出了组织架构调整,团队拆分,两条业务线分家,独立运行。
基于方案二的剁手项目没受任何影响,为各自的利益运行着。

从这个项目方案的决策中,我明白了一个道理,组织决定架构
很多时候,我们的开发方案,我们的软件架构,不是由纯粹的技术决定的,它往往是技术与多方利益相互妥协的结果。
这导致的另一个的现象是,在一个公司内部,不同团队会反复造相同的轮子,哪怕是已经有了,也要想自己再去造一个,无论出于什么目的,背后都是竞争与合作的博弈。

五、满意决策原则

在赫伯特·西蒙的《管理行为》一书中,谈到理性的决策模式是追求最优的方案,而人在做实际决策中,往往受各种因素的限制,其实做的是满意度的决策。
不要去寻求最优的方案,找到令人满意的方案就好。
在这次的项目中,最终的方案肯定不是最优方案,但无疑让涉及到的各利益方感到满意。
再回到我们的工作、学习和生活上,对于内心的诉求,我们是费劲心思、苦苦等待找最好的,还要找让自己的满意就行了呢?

Comments
Write a Comment