編輯導語：需求是做不完的，隨著時間的推移，用戶的需求會越來越多，產品經理只能不斷的更新迭代；大家都知道“重新做”是比較難完成的，但是對產品進行擴展是較簡單的；本文作者從產品角度分析如何提升產品的可擴展性，我們一起來看一下。

相信各位PM小伙伴都遇到過這種情況：一個已實現需求的小調整，開發卻向你反饋需要“重新做”的情況；排除開發同學抬杠的可能，我們可以從產品設計的概念上談談如何讓產品變得更易拓展。

本文不涉及具體業務，只是分享下思維方式，歡迎各位小伙伴評論區交流。

一、邏輯與特性

大家都知道隨著時間的推移，用戶的需求是不可能被完全滿足的，也就是大家常說的“需求是做不完”的。

舉個例子，某Saas產品原來是只支持本企業運營人員在PC端手動根據填寫的資質和申請為新用戶開賬號的，后來由于業務發展需要，開放了在公司官網的手機號自主注冊；上線不久后，公司Saas產品的代理商又要求為他們的客戶也開放一套手機號自主注冊的機制，又或者公司要求再開放郵箱自主注冊。

這種情況下，需求明顯是做不完的，而且似乎會有一些聯系，我們應該如何更從容地應對這些需求呢？

我們可以看看這個例子的業務抽象后到底是什么？

What：新用戶/憑借某些方式/得到賬號。

這是不是太抽象了呢？那我們再對“what”細分一下。

How：

• 我們可以從得到賬號的過程新用戶是主動或者被動分為“自主注冊”,“運營手動開通”或者其他；
• 我們也可以從得到賬號的位置分為“代理商渠道”,“官網渠道”或者其他；
• 我們還可以從用戶提交的資質分為“手機號”,“郵箱”或者其他。

這里What就是我們說的“邏輯”，而How就是我們寫文檔要寫的“特性”；事實上，可以看到“邏輯”是長期固定的，而“特性”與具體業務息息相關，也正是需求做不完的關鍵。

而找到了“邏輯”和“特性”后，我們要做的是固定“邏輯”，而將“特性”剝離；好的設計會讓你的迭代圍繞在“特性”部分；而由于“特性”往往只對應較小的模塊，甚至會有現成的實現方案，所以更容易掌控。

二、如何區分邏輯和特性

都說邏輯能力是產品同學的基礎能力，而對事物本質的洞見力以及抽象能力顯然就是邏輯能力的體現之一了。

我們常說藝術上的抽象是讓事物變得特別（unique），而作為PM，我們的抽象是通過識別本質而讓事物變得簡單。

邏輯和特性的區分也是一種抽象，下面我們看看區分邏輯和特性的工作流程。

1. 盡可能多地梳理業務中的需求

見多方能識廣，這個一個采樣的過程，你的樣本集能否代表業務全貌決定了你的抽象是否可靠。

舉個例子，如果只接觸了“公司運營為新用戶手動開賬號”這一種業務，那可能我的抽象會變成”公司運營手動操作某些事情”；這不能說不對，只是明顯對我們的思路會產生誤導，所以盡可能多地了解你的業務場景，是一個好的抽象的基礎。

2. 業務抽象

我們可以借鑒兩種常用的思維方式：過程抽象和角色抽象。

過程的抽象：重點在于梳理出通用流程中包含的幾個模塊或者步驟，比如在“新用戶/憑借某些方式/得到賬號”這一過程中，新用戶的注冊信息、新用戶的創建、用戶前端的展示等模塊都是必不可少的；看到這里的朋友其實也想到了，這一抽象方式在多個業務上的復用其實也就是對應著中臺的理論基礎。

角色的抽象：則需要我們先去考慮我們的整個系統到底有哪些角色參與，每個角色的信息和可能做的事情是什么，之后再對各個角色之間的關系進行拓展；這種抽象方式往往要求系統中參與的角色是立體的，比如如果我們從來沒有考慮過“代理商”這一角色，那我們所有基于“代理商”的需求自然而然會是空中樓閣。

通過業務抽象，其實我們的邏輯和特性已經呼之欲出了。

3. 定義邏輯和特性

相信經過上面的步驟，你已經能“想清楚”了，后面要做的就是描述出整個業務的工作軌跡；你會發現，如同魚骨圖一般，特性（魚刺）會很多，我們也會繼續增加，但是邏輯（魚脊柱）大多數都是固定的。

在這種思路的產品構建之下，比如我們如果要加一種注冊方式，其實只是在“新用戶的注冊信息”中增加了一個特性而已；這并不會影響到我們的基本邏輯，而且有的特性復用的概率高的時候我們也可以通過“組件化”來消除不必要的重復工作量。

在構建特性的過程，在規定邊界的同時，我們也可以加入自己對特性的理解和未來的可能迭代方向。

這篇文章沒有涉及具體的業務，只是筆者結合實際工作中的一些思考，和大家做一個分享；如果對讀者朋友有所啟發，深感榮幸，也歡迎大家指正批評。

本文由@幸失 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash ，基于 CC0 協議