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

本文案例已经过艺术加工，请忽略案例本身的真实性。

不久前，完成了一个项目，在制定开发方案时，出现两个方案的决策问题，我来分享了这里面的一些思考。

一、背景

现谈谈背景，我们负责了两条业务线的日常开发和维护工作，就好比淘宝和天猫这种模式，他们背后属于不同的业务部门，但都有一样的商品的购买流程。

就是这样的两条业务线，它们业务相互独立，但提供的业务功能是类似的，所以由一个团队负责，平时相安无事，哪边有需求，哪边放人。

我们就叫业务线A和B好了。

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

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

二、方案

现在，要出开发方案了。出于软件开发的原则，尽可能让功能复用，不要重复造轮子，我们理想的设计方案自然是这样的。

将剁手功能剥离出来，做成可复用的模块，给两条业务线使用，也好维护。

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

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

三、决策

不知道你是如何想的，我当时是用系统思考来决策的。

首先，我们现在的问题是：应该选方案一，还是方案二？

这两个方案各有利弊，它们构成的系统之间有不可调合的矛盾，无法做整合。

所以我们可以基于系统思考的一个原则：跳出系统看系统。

也就是跳出当前的问题，站在更高的层次来思考。

如何跳出呢？有一个方法：向上归类。

话术是：X是一种什么？X属于什么？

就“剁手”这个项目而言，它既属于一个功能，又属于一条业务线。

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

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

这两种说法的区别是什么？

其实本质的问题在于：团队在组织定位是什么？

也就是：

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

当我把这个问题抛出来，问团队的成员和管理层。很快就得到了一个答案，我们其实是不同业务线恰好合在了一起，后面甚至会分开。

那么，答案是方案二，直接复制一份功能给业务线B。这是一个完全不符合软件设计原则的方案，但却符合团队的组织定位，基于这个前提，我们必须这么做。

四、组织决定架构

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

从这个项目方案的决策中，我明白了一个道理，组织决定架构。

很多时候，我们的开发方案，我们的软件架构，不是由纯粹的技术决定的，它往往是技术与多方利益相互妥协的结果。

这导致的另一个的现象是，在一个公司内部，不同团队会反复造相同的轮子，哪怕是已经有了，也要想自己再去造一个，无论出于什么目的，背后都是竞争与合作的博弈。

五、满意决策原则

在赫伯特·西蒙的《管理行为》一书中，谈到理性的决策模式是追求最优的方案，而人在做实际决策中，往往受各种因素的限制，其实做的是满意度的决策。

不要去寻求最优的方案，找到令人满意的方案就好。

在这次的项目中，最终的方案肯定不是最优方案，但无疑让涉及到的各利益方感到满意。

再回到我们的工作、学习和生活上，对于内心的诉求，我们是费劲心思、苦苦等待找最好的，还要找让自己的满意就行了呢？