如何完成業務產品的架構設計?

0 評論 996 瀏覽 4 收藏 5 分鐘

大多數產品經理都只負責了需求和原型部分,很少有涉及到產品架構的概念和意識。本文分享了4層結構完成業務產品架構設計的思路,供各位參考。

內部培訓過許多產品同學,也認識一下外部的產品同學,普遍存在一個問題:比較多的同學是在面向問題進行產品設計,很少有同學能夠擁有業務產品的架構設計能力。這就造成一個問題,大多數的產品經理頂多算是一個需求管理者或者原型設計者。

面向問題進行設計,必然會導致絕大多數的同學會第一時間去尋找問題的答案,比如詢問用戶想要什么要的效果、競品是怎么解決這個問題的,這樣的結果會逐步讓自身的軟件產品陷入繁雜的邏輯設計和產品價值的喪失。到后期必然會出現,牽連太多,改不動的局面,更有甚至會出現性能下降、易用性降低的嚴重問題。

那么如何跳出面向問題設計?

想要跳出面向問題設計,問題進行提升,抽象到更高的維度進行產品設計,這樣就能保證既解決了問題,又能夠將產品功能限定在有限的約束集中。本文將以面向用戶的解決方案為出發點,談一下業務產品的架構設計,以期共勉。

4層結構完成業務產品架構設計

隨著客戶業務的演進,對于軟件產品來講,用戶的需求將是無窮無盡的,如果面向問題設計,那么對于客戶來講,就是一個需求一個需求的價值,只是滿足了客戶對于軟件產品使用的問題,卻沒有從根本上為客戶提供價值的提升。

所有的產品都應該給客戶帶來價值,那么到底是產品的什么為客戶帶來價值呢?筆者認為:面向客戶業務問題的解決方案,是產品提供價值的核心,本文基于解決方案提出4層結構來完成業務產品架構設計。

層級0(L0):解決方案-立足于客戶價值,為客戶能夠買單提供基礎;

層級1(L1):業務模塊-獨立的微服務,可以理解為支持解決方案的最小業務支撐單位;

層級2(L2):頁面和邏輯-每一個獨立的業務模塊,必然提供的一項業務能力,業務能力的表達是通過頁面和邏輯進行呈現的,每一個頁面又拆解為不同的頁面區塊(每個區塊是基于模塊最小的功能呈現)

層級3(L3):功能點和接口-既然是能力,必然包括涉及的功能點和接口能力,實現業務功能和跨解決方案的數據交互能力。

4層的產品架構設計,從解決方案出發,既立足于客戶價值的輸出,也可以將業務產品框定在有限的約束集中,為產品的發展和迭代打下堅實的基礎。

本文僅供參考,后續在為各位補充4層產品架構的詳細設計思路;

本文由@張三豐 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!