本文案例已經過藝術加工，請忽略案例本身的真實性。
不久前，完成了一個項目，在制定開發方案時，出現兩個方案的決策問題，我來分享了這里面的一些思考。
一、背景
現談談背景，我們負責了兩條業務線的日常開發和維護工作，就好比淘寶和天貓這種模式，他們背后屬於不同的業務部門，但都有一樣的商品的購買流程。
就是這樣的兩條業務線，它們業務相互獨立，但提供的業務功能是類似的，所以由一個團隊負責，平時相安無事，哪邊有需求，哪邊放人。
我們就叫業務線A和B好了。
二、方案
現在，要出開發方案了。出於軟件開發的原則，盡可能讓功能復用，不要重復造輪子，我們理想的設計方案自然是這樣的。
將剁手功能剝離出來，做成可復用的模塊，給兩條業務線使用，也好維護。
三、決策
不知道你是如何想的，我當時是用系統思考來決策的。
首先，我們現在的問題是：應該選方案一，還是方案二？
這兩個方案各有利弊，它們構成的系統之間有不可調合的矛盾，無法做整合。
所以我們可以基於系統思考的一個原則：跳出系統看系統。
也就是跳出當前的問題，站在更高的層次來思考。
如何跳出呢？有一個方法：向上歸類。
話術是：X是一種什么？X屬於什么？
就“剁手”這個項目而言，它既屬於一個功能，又屬於一條業務線。
- 把“剁手”當成一個通用的功能，提供給不同的業務線？
- 還是把“剁手”當成不同業務線上實現相同的功能？
這兩種說法的區別是什么？
其實本質的問題在於：團隊在組織定位是什么？
也就是：
- 我們是緊密的團隊，給不同的業務線提供相同的功能服務？
- 還是我們是松散的團隊，只是恰好兩條業務線類似才合在了一起？
當我把這個問題拋出來，問團隊的成員和管理層。很快就得到了一個答案，我們其實是不同業務線恰好合在了一起，后面甚至會分開。
那么，答案是方案二，直接復制一份功能給業務線B。這是一個完全不符合軟件設計原則的方案，但卻符合團隊的組織定位，基於這個前提，我們必須這么做。
四、組織決定架構
在完成項目不久后，公司做出了組織架構調整，團隊拆分，兩條業務線分家，獨立運行。基於方案二的剁手項目沒受任何影響，為各自的利益運行着。
五、滿意決策原則
在赫伯特·西蒙的《管理行為》一書中，談到理性的決策模式是追求最優的方案，而人在做實際決策中，往往受各種因素的限制，其實做的是滿意度的決策。