兩人三腳的賽跑遊戲

你的系統只會發展成適應組織的模樣

    這陣子和主管聊天，討論到公司產品為何會走到現在的模樣。

    我們有兩套功能相似的產品線，只是目標客群有所差異。其中一套是從原本的產品複製出來後獨立發展的，為此，公司必須開始養兩倍的人力、兩個團隊各自維護與開發。常常發生同一個 bug 或是功能，兩邊要各做一次，而且做法還彼此不同。同一個需求，兩個團隊挑選的解決方案不一樣，導致公司內部出現許多相似卻不相同的程式庫。

    回想自己剛來的時候，公司跟我聊到這個議題，說希望能合併回一個產品線，我當真了。

    現在我明白，那只是聊天和單純抱怨 murmur 而已，並不是認真的。

    當公司的組織，兩條產品線底下，顧問、業務、客服都被拆分為兩群不同單位，兩邊各自接觸不同客戶，接收不同需求，彼此之間沒有一致的交流討論，那產品各走各的路，是再正常不過的，就是所謂的兄弟爬山，各自努力。

    就連蘋果這樣的大公司，剛推出 iPad 時，一開始跟 iPhone 共用 iOS 作業系統，但又要兼容兩邊的差異和特殊化，提高了交纏的複雜性和犧牲穩定性。最終也在 2019 年，將 iPadOS 從 iOS 切分出來，開始並行各走各的路，而現在 WatchOS，VisionOS，tvOS 如雨後春筍冒出。

    所以其實產品的拆分並不是問題，因為當初這樣做一定有他的好處，只是拿到好處後，又不甘願支付代價抱怨而已（多一倍的人力和開發量...etc）。

    其實這一切對我來說都歷歷在目，因為之前的公司也曾經做過一樣的事情，為了應付對岸大陸業務的快速發展，把原本台灣的產品複製出一份改給對岸使用，從此開始養兩倍以上的人力，在兩岸開發相同的功能、修相同的 bug。

    記得營運長當時罵：「當初到底哪個白癡 RD 做出這個決定的？」

    那時候兩邊的系統極度不穩，每週我都要出席事故檢討會議。發現兩岸的系統其實底層還有約 20% 左右的共用程式，而這個共用部分，就嘛對岸修改，台灣第二天上線死，反之亦然。

    因為組織上各自獨立運作，任何一邊改東西都不會管另一邊死活，也不會有兩邊聯合測試。所以既使我知道營運長對分割成兩套的決策反感，但我還是毅然決然地決定將這最後相連的 20% 徹底分割，兩岸各自維護，至少解決了 50% 以上的事故問題。

    當你想要奪得盡可能多的獎牌，所以派出兩名賽跑選手。會覺得讓這兩位選手各自盡全力奔跑，奪得獎牌的機會比較高？還是要他們用兩人三腳的方式，把腿綁一起去跟其他全力奔跑的選手競爭，贏的機會比較高？

    我想答案顯而易見。

    只要背後的主事者不要拿到甜頭後，又不願付代價，吐嘲：早知道派表現較好的那位出賽就好，不用花兩倍的薪水。

    主管跟我討論怎麼管理兩套產品在技術上的一致性，該制定什麼樣的規範，我的回覆是：「系統就是這樣長成組織規劃的模樣，反正兩邊的經營團隊就不同，這問題不是技術可以解的，而是組織和作業流程的問題。」

    現在的單位，就像是企圖要綁著兩個選手左右腳的那條繩子，不斷在研究怎麼樣讓繩子能夠綁得更緊。

    最近的任務和工作，總會讓我不禁懷疑：我們單位的存在、現在所做的任務，真的是正確的方向嗎？