產品設計的分而治之與整合

我們有一個收銀系統，它涵蓋了收銀記賬、商品管理、員工管理、會員管理、 以及顧客端的營銷功能，也就是說可以滿足一個線下店鋪所有經營所需，現在要設計一個預約功能模塊，該怎麼做呢？

很多人傾向於與原來的業務徹底割裂，實現一套獨立的服務項目增刪改查邏輯，以及一套獨立的預約單管理邏輯。

原因很簡單，系統本身已經足夠複雜了，新的業務模塊與原來的業務融合太深，容易出問題。

說白了，這就是害怕。

當然，還有的人找出其他的理由，認為模塊獨立的話，客戶操作更簡單，不必為了一個事情到別的地方進行設置，這樣體驗更好。

我認為這個理由是比較牽強的。

一個系統為什麼會好用？或者說，為什麼會有「系統」的存在？

就是因為系統中各種元素可以復用，你設置過員工，就不必再為預約服務的服務者再創建一個新的概念。

來一個模塊，就新建一堆概念，用戶的操作反而是繁瑣的。

可能會有一些新的客戶，他不需要用到那麼多的功能，他就只用其中一個功能模塊，所以他不希望理解那麼多基礎概念。但是，這樣的客戶是你應該爭取的嗎？

所以一切問題，都是定位問題。

定位的問題，是整個公司的問題，但路走到一半，你必須沿著原來的路走下去。

模塊獨立，聽起來是所謂避免耦合，是分而治之。

事實相反，它反而在業務層面，做的結果卻是高度耦合。

回到預約模塊的問題。

它要實現如下的流程：用戶查找技師（員工）或項目（商品）-->填寫預約單-->支付/提交-->完成預約-->收到服務提醒-->到店享受服務（可能會進行更多的商品的消費）。

如前所述，技師應該是由員工這個元素擴展而來。

而服務項目應該是由商品的元素擴展而來（當然也可以新建一個對象）。

這些問題還不大。

最後一步，到店享受服務，有一種做法是把這個過程放到預約這個模塊中管理，理由是完整簡單。

說白了就是害怕。

一個高耦合的系統，害怕各種連接，但又不得不進行各種連接，它把各種業務相同的部分重複去做處理，所有的程序員企圖各自為戰，實際上又不得不進行混亂的合作。

實際上最後一步，它應該是歸屬於商品消費/收銀的一部分，預約就是預約，帶支付的預約關心的是預約人有沒有交訂金，交了訂金，你人基本上一定會來，用訂金來消滅不確定性，簡化管理，使用預約的商家，他不是把預約當成微商城來用，他做的不是一鎚子買賣，商品消費靠的是線下的轉化。現實中，預約一個鐘的服務，可能會加一個鍾，用到的商品可能也會增加.

你人不來，那麼就訂金不退，這是預約收費的關鍵邏輯。

但是有人偏不這麼做，非要把商品的消費囊括到預約本身的正式流程中。

在他們看來，預約支付成功，並不代表預約本身的訂單完成，他們要把訂金和最後尾款都收到 ，才能把訂單完結。

這就會導致業務的複雜度大幅提升，狀態管理模糊。

正確的邏輯是：預約支付成功，就應該有一個訂單完成了。服務有沒有完成，那是另外一回事，因為服務本身具備極大的複雜度和不可預知性。

你有現成的商品消費/收銀功能模塊不調，卻非要把閹割版的收銀邏輯寫到預約里，結果不但會導致業務本身功能不全，還會帶來後續大量統計問題。