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

本文案例已通过艺术加工，请忽略案例自己的真实性。

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

1、背景

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

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

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

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

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

2、方案

如今，要出开发方案了。出于软件开发的原则，尽量让功能复用，不要重复造轮子，咱们理想的设计方案天然是这样的。

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

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

因此，对于以下两方案，你会如何决策？如何说服不一样的声音呢？

3、决策

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

首先，咱们如今的问题是：应该选方案一，仍是方案二？

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

因此咱们能够基于系统思考的一个原则：跳出系统看系统。

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

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

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

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

这样，咱们能够把要决策的问题从新表述：

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

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

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

也就是：

1. 咱们是紧密的团队，给不一样的业务线提供相同的功能服务？
2. 仍是咱们是松散的团队，只是刚好两条业务线相似才合在了一块儿？

当我把这个问题抛出来，问团队的成员和管理层。很快就获得了一个答案，咱们实际上是不一样业务线刚好合在了一块儿，后面甚至会分开。

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

4、组织决定架构

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

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

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

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

5、满意决策原则

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

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

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

再回到咱们的工做、学习和生活上，对于心里的诉求，咱们是费劲心思、苦苦等待找最好的，还要找让本身的满意就好了呢？