本文案例已经过艺术加工，请忽略案例本身的真实性。
不久前，完成了一个项目，在制定开发方案时，出现两个方案的决策问题，我来分享了这里面的一些思考。
背景
现谈谈背景，我们负责了两条业务线的日常开发和维护工作，就好比淘宝和天猫这种模式，他们背后属于不同的业务部门，但都有一样的商品的购买流程。
就是这样的两条业务线，它们业务相互独立，但提供的业务功能是类似的，所以由一个团队负责，平时相安无事，哪边有需求，哪边放人。
我们就叫业务线A和B好了。
后来有一天，在业务线��A花了大力气，投入两个月时间，开发了一个新的产品功能，代号“剁手”。
“剁手”项目一上线，好评如潮，业务线B就眼红了，跟开发团队说，我们也要“剁手”，你们把他们的功能包装下，快帮我们上了。
方案
现在，要出开发方案了。
出于软件开发的原则，尽可能让功能复用，不要重复造轮子，我们理想的设计方案自然是这样的。
将剁手功能剥离出来，做成可复用的模块，给两条业务线使用，也好维护。
但是，也有不同的声音，业务线A和业务线B背后的利益人不同，平时井水不犯河水，，不如直接复制一份过去。
所以，对于如下两方案，你会如何决策？如何说服不同的声音呢？
决策
不知道你是如何想的，我当时是用系统思考来决策的。
首先，我们现在的问题是：应该选方案一，还是方案二？
这两个方案各有利弊，它们构成的系统之间有不可调合的矛盾，无法做整合。所以我们可以基于系统思考的一个原则：跳出系统看系统。也就是跳出当前的问题，站在更高的层次来思考。
如何跳出呢？有一个方法：向上归类。
话术是：X是一种什么？X属于什么？
就“剁手”这个项目而言，它既属于一个功能，又属于一条业务线。
这样，我们可以把要决策的问题重新表述：
- 把“剁手”当成一个通用的功能，提供给不同的业务线？
- 还是把“剁手”当成不同业务线上实现相同的功能？
这两种说法的区别是什么？
其实本质的问题在于：团队在组织定位是什么？
也就是： - 我们是紧密的团队，给不同的业务线提供相同的功能服务？
-
还是我们是松散的团队，只是恰好两条业务线类似才合在了一起？
当我把这个问题抛出来，问团队的成员和管理层。
很快就得到了一个答案，我们其实是不同业务线恰好合在了一起，后面甚至会分开。
那么，答案是方案二，直接复制一份功能给业务线B。
这是一个完全不符合软件设计原则的方案，但却符合团队的组织定位，基于这个前提，我们必须这么做。
image
组织决定架构
在完成项目不久后，公司做出了组织架构调整，团队拆分，两条业务线分家，独立运行。
基于方案二的剁手项目没受任何影响，为各自的利益运行着。
从这个项目方案的决策中，我明白了一个道理，组织决定架构。
很多时候，我们的开发方案，我们的软件架构，不是由纯粹的技术决定的，它往往是技术与多方利益相互妥协的结果。
这导致的另一个的现象是，在一个公司内部，不同团队会反复造相同的轮子，哪怕是已经有了，也要想自己再去造一个，无论出于什么目的，背后都是竞争与合作的博弈。
满意决策原则
在赫伯特·西蒙的《管理行为》一书中，谈到理性的决策模式是追求最优的方案，而人在做实际决策中，往往受各种因素的限制，其实做的是满意度的决策。
不要去寻求最优的方案，找到令人满意的方案就好。
在这次的项目中，最终的方案肯定不是最优方案，但无疑让涉及到的各利益方感到满意。
再回到我们的工作、学习和生活上，对于自己的欲望，我们是费劲心思、苦苦等待找最好的，还要找让自己的满意就行了呢？
