復(fù)雜產(chǎn)品設(shè)計的邊界感
本文將探討產(chǎn)品經(jīng)理如何處理模塊間的交互問題,確保數(shù)據(jù)流動性和功能的合理性。通過實際案例分析,我們將深入了解如何在尊重各模塊定位的基礎(chǔ)上,優(yōu)化產(chǎn)品設(shè)計和數(shù)據(jù)服務(wù),以及如何與上下游模塊進(jìn)行有效對接。
“我負(fù)責(zé)哪些產(chǎn)品功能”、“我可以為上下游提供哪些數(shù)據(jù)服務(wù)”、“我需要上下游提供哪些數(shù)據(jù)服務(wù)”、“我應(yīng)該如何與上下游交互對接”等等產(chǎn)品問題不由自主的會在大腦中出現(xiàn),都是作為產(chǎn)品經(jīng)理的我們在日常工作中經(jīng)常會向自己或相關(guān)產(chǎn)品經(jīng)理問到的問題。
特別是,當(dāng)我們需要與自己所負(fù)責(zé)的產(chǎn)品系統(tǒng)/模塊存在數(shù)據(jù)信息交互的上下游系統(tǒng)/模塊產(chǎn)品經(jīng)理argue新的改造產(chǎn)品功能應(yīng)該如何設(shè)計、應(yīng)該在自己還是對方的系統(tǒng)/模塊范圍內(nèi)實現(xiàn)時,對接的雙方都會窮盡所有說辭來試圖說服對方接受自己所提出的產(chǎn)品功能設(shè)計建議。
那么作為產(chǎn)品經(jīng)理的我們應(yīng)該如何去應(yīng)對,如何去協(xié)調(diào)雙方給出最合理的產(chǎn)品設(shè)計解決方案?根據(jù)過往工作經(jīng)歷,建議按照“以我為主,關(guān)注邊界”的原則來思考。
在實際業(yè)務(wù)中正常運轉(zhuǎn)、體現(xiàn)相應(yīng)產(chǎn)品價值的每個產(chǎn)品系統(tǒng)/模塊都有其定位和在支撐業(yè)務(wù)順利進(jìn)行中所應(yīng)該肩負(fù)的應(yīng)處理的業(yè)務(wù)階段范圍,供應(yīng)鏈產(chǎn)品是由很多不同功能的產(chǎn)品系統(tǒng)/模塊組成,并且在物流、信息流、資金流等三方面數(shù)據(jù)層面提供支撐,作為供應(yīng)鏈軟件產(chǎn)品的組成部分,每個產(chǎn)品系統(tǒng)/模塊所起到的作用各有不同。
例如:采購訂單管理模塊:定位在響應(yīng)來自各種不同來源采購訂單創(chuàng)建訴求,對生成的采購訂單進(jìn)行狀態(tài)管理,并將生成的采購訂單作為基礎(chǔ)憑證被其他上下游系統(tǒng)/模塊來調(diào)用、流轉(zhuǎn),以實現(xiàn)業(yè)務(wù)方商品采購全生命周期管理。
那么按照采購訂單管理模塊的定位,雖然在創(chuàng)建采購訂單時需要用到供應(yīng)商數(shù)據(jù)、合同數(shù)據(jù)、商品主數(shù)據(jù)、庫存數(shù)據(jù)等數(shù)據(jù)信息,生成的采購訂單在到貨后生成的結(jié)算單等相關(guān)數(shù)據(jù),甚至退貨、退款過程中數(shù)據(jù)等的管理都不應(yīng)在采購訂單管理模塊的產(chǎn)品功能邏輯范疇,根本原因是這些數(shù)據(jù)信息的管理與采購訂單管理模塊的定位不符,采購訂單管理模塊只定位在采購訂單信息流源頭數(shù)據(jù)的生成及管理。
類似地,商品主數(shù)據(jù)管理模塊:定位在商品主數(shù)據(jù)的創(chuàng)建及管理,商品主數(shù)據(jù)模塊作為一個基礎(chǔ)、通用被調(diào)用產(chǎn)品模塊,被調(diào)用后生成采購訂單的產(chǎn)品邏輯、資金結(jié)算的產(chǎn)品邏輯、退貨逆向的產(chǎn)品邏輯等數(shù)據(jù)信息管理都不應(yīng)在商品主數(shù)據(jù)管理模塊的產(chǎn)品功能邏輯范疇。
產(chǎn)品定位是核心,也是與上下游系統(tǒng)/模塊產(chǎn)品經(jīng)理argue的依據(jù)重心。
從產(chǎn)品專業(yè)性來分析,作為存在相互關(guān)聯(lián)的上下游系統(tǒng)/模塊產(chǎn)品功能,不同的產(chǎn)品系統(tǒng)/模塊分屬于由不同的的產(chǎn)品經(jīng)理、不同的產(chǎn)品團(tuán)隊甚至不同的公司主體分別負(fù)責(zé)。
我們負(fù)責(zé)的僅是其中某個環(huán)節(jié)并由相應(yīng)產(chǎn)品系統(tǒng)/模塊體現(xiàn)。咱們最了解的也只是自己所負(fù)責(zé)的產(chǎn)品系統(tǒng)/模塊情況:例如,咱們所負(fù)責(zé)產(chǎn)品系統(tǒng)/模塊定位、產(chǎn)品功能邏輯、業(yè)務(wù)和研發(fā)資源配置、與上下游哪些系統(tǒng)/模塊對接、可以為上下游系統(tǒng)/模塊提供的數(shù)據(jù)清單以及可支持的數(shù)據(jù)信息交互方式等等。
在實際工作中也不可能允許給予充足的時間和機會去建立對與上下游發(fā)生交互的所有系統(tǒng)/模塊功能有十分深入的理解。對于上下游產(chǎn)品系統(tǒng)/模塊所包含的內(nèi)在產(chǎn)品功能邏輯及其他相關(guān)情況等不很了解,甚至是黑盒狀態(tài)。(如圖1)
圖1 系統(tǒng)/模塊間相互交互關(guān)系
那么,當(dāng)搭建新的產(chǎn)品功能并需要與上下游系統(tǒng)/模塊發(fā)生交互對接時,我們應(yīng)該從對內(nèi)、對外兩方面入手:
- 對內(nèi)“以我為主”以自己所負(fù)責(zé)的產(chǎn)品系統(tǒng)/模塊的定位為主,基于“我”去推導(dǎo)出來所需要、所能夠提供的數(shù)據(jù)信息。站在自己所負(fù)責(zé)產(chǎn)品系統(tǒng)/模塊定位角度,確認(rèn)產(chǎn)品系統(tǒng)/模塊內(nèi)部應(yīng)新增/改造的產(chǎn)品功能邏輯,非自己范圍內(nèi)需求應(yīng)堅決拒絕,并據(jù)理力爭,確保新增/改造的產(chǎn)品功能復(fù)合產(chǎn)品系統(tǒng)/模塊定位要求。避免所負(fù)責(zé)產(chǎn)品系統(tǒng)/模塊功能范圍的無限延展,失去產(chǎn)品核心。避免產(chǎn)品系統(tǒng)/模塊功能的耦合性及可擴(kuò)展性都向壞的方向發(fā)展。
- 對外“關(guān)注邊界”,對于上下游系統(tǒng)/模塊內(nèi)在的產(chǎn)品功能邏輯,由于沒有精力和機會知道全貌,我們不應(yīng)該猜測對方產(chǎn)品系統(tǒng)/模塊的內(nèi)部情況,而是將關(guān)注點聚焦在產(chǎn)品系統(tǒng)/模塊對接的工作面,即邊界上。上下游系統(tǒng)/模塊對咱們而言是完全的黑盒,在與上下游產(chǎn)品系統(tǒng)/模塊產(chǎn)品經(jīng)理交流過程中擺正自己的位置:咱們是需求方,對接方是為咱們提供解決方案的產(chǎn)品設(shè)計方,咱們需要做的是明確、無誤地提出自己的數(shù)據(jù)對接需求,明確需要的數(shù)據(jù)屬性、需傳遞的字段清單、需支持的數(shù)據(jù)交互方式、需實現(xiàn)的數(shù)據(jù)交互頻次等等層面信息。
至于這些需求如何實現(xiàn)、是否有更好的支持方式,都應(yīng)交給需對接的產(chǎn)品經(jīng)理來統(tǒng)籌考慮。(如圖2)
圖2 系統(tǒng)/模塊間的交互邊界
每個產(chǎn)品經(jīng)理都具備自己獨特的產(chǎn)品專業(yè)性,尊重別人的專業(yè)性也是對自己的一種尊重。復(fù)雜產(chǎn)品設(shè)計是一門藝術(shù),這門藝術(shù)不僅適用于與其他產(chǎn)品經(jīng)理協(xié)作過程中,也適用于自己負(fù)責(zé)多個相互關(guān)聯(lián)的產(chǎn)品系統(tǒng)/模塊時。
同時,如果有余力通過多種途徑去多多了解上下游系統(tǒng)/模塊的內(nèi)部邏輯等相關(guān)情況也是值得的,從產(chǎn)品經(jīng)理職業(yè)發(fā)展路徑來看,將來更需要的是“T”型人才,即在所能夠掌握的范圍足夠廣的情況下能夠在某個或多個產(chǎn)品方向建立的自己獨特的理解。
保持好奇心,提升對復(fù)雜產(chǎn)品設(shè)計的邊界感能夠助力你我在產(chǎn)品設(shè)計的道路上走的更順、更遠(yuǎn)。
本文由@踐行知行合一 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于 CC0 協(xié)議
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
- 目前還沒評論,等你發(fā)揮!