初開：一次開發方案決策的系統思考

本文案例已通過藝術加工，請忽略案例自己的真實性。

不久前，完成了一個項目，在制定開發方案時，出現兩個方案的決策問題，我來分享了這裏面的一些思考。

1、背景

現談談背景，咱們負責了兩條業務線的平常開發和維護工做，就比如淘寶和天貓這種模式，他們背後屬於不一樣的業務部門，但都有同樣的商品的購買流程。

就是這樣的兩條業務線，它們業務相互獨立，但提供的業務功能是相似的，因此由一個團隊負責，平時相安無事，哪邊有需求，哪邊放人。

咱們就叫業務線A和B好了。

後來有一天，在業務線A花了大力氣，投入兩個月時間，開發了一個新的產品功能，代號「剁手」。

「剁手」項目一上線，好評如潮，業務線B就眼紅了，跟開發團隊說，咱們也要「剁手」，大家把他們的功能包裝下，快幫咱們上了。

2、方案

如今，要出開發方案了。出於軟件開發的原則，儘量讓功能複用，不要重複造輪子，咱們理想的設計方案天然是這樣的。

將剁手功能剝離出來，作成可複用的模塊，給兩條業務線使用，也好維護。

可是，也有不一樣的聲音，業務線A和業務線B背後的利益人不一樣，平時井水不犯河水，，不如直接複製一份過去。

因此，對於以下兩方案，你會如何決策？如何說服不一樣的聲音呢？

3、決策

不知道你是如何想的，我當時是用系統思考來決策的。

首先，咱們如今的問題是：應該選方案一，仍是方案二？

這兩個方案各有利弊，它們構成的系統之間有不可調合的矛盾，沒法作整合。

因此咱們能夠基於系統思考的一個原則：跳出系統看系統。

也就是跳出當前的問題，站在更高的層次來思考。

如何跳出呢？有一個方法：向上歸類。

話術是：X是一種什麼？X屬於什麼？

就「剁手」這個項目而言，它既屬於一個功能，又屬於一條業務線。

這樣，咱們能夠把要決策的問題從新表述：

1. 把「剁手」當成一個通用的功能，提供給不一樣的業務線？
2. 仍是把「剁手」當成不一樣業務線上實現相同的功能？

這兩種說法的區別是什麼？

其實本質的問題在於：團隊在組織定位是什麼？

也就是：

1. 咱們是緊密的團隊，給不一樣的業務線提供相同的功能服務？
2. 仍是咱們是鬆散的團隊，只是剛好兩條業務線相似才合在了一塊兒？

當我把這個問題拋出來，問團隊的成員和管理層。很快就獲得了一個答案，咱們實際上是不一樣業務線剛好合在了一塊兒，後面甚至會分開。

那麼，答案是方案二，直接複製一份功能給業務線B。這是一個徹底不符合軟件設計原則的方案，但卻符合團隊的組織定位，基於這個前提，咱們必須這麼作。

4、組織決定架構

在完成項目不久後，公司作出了組織架構調整，團隊拆分，兩條業務線分家，獨立運行。基於方案二的剁手項目沒受任何影響，爲各自的利益運行着。

從這個項目方案的決策中，我明白了一個道理，組織決定架構。

不少時候，咱們的開發方案，咱們的軟件架構，不是由純粹的技術決定的，它每每是技術與多方利益相互妥協的結果。

這致使的另外一個的現象是，在一個公司內部，不一樣團隊會反覆造相同的輪子，哪怕是已經有了，也要想本身再去造一個，不管出於什麼目的，背後都是競爭與合做的博弈。

5、滿意決策原則

在赫伯特·西蒙的《管理行爲》一書中，談到理性的決策模式是追求最優的方案，而人在作實際決策中，每每受各類因素的限制，其實作的是滿意度的決策。

不要去尋求最優的方案，找到使人滿意的方案就好。

在此次的項目中，最終的方案確定不是最優方案，但無疑讓涉及到的各利益方感到滿意。

再回到咱們的工做、學習和生活上，對於心裏的訴求，咱們是費勁心思、苦苦等待找最好的，還要找讓本身的滿意就好了呢？