B端產(chǎn)品設(shè)計(jì):從產(chǎn)品角度談“軟件模塊化設(shè)計(jì)”

1 評(píng)論 13003 瀏覽 87 收藏 15 分鐘

軟件模塊化設(shè)計(jì)是軟件工程領(lǐng)域的概念。本文結(jié)合筆者 ToB 產(chǎn)品設(shè)計(jì)的經(jīng)驗(yàn),從產(chǎn)品經(jīng)理的角度談?wù)勈裁词擒浖K化設(shè)計(jì),以及為何它被奉為產(chǎn)品設(shè)計(jì)的基本原則之一。

01 軟件模塊化設(shè)計(jì),“偷懶”利器

為了提升寫(xiě)作效率,幾乎任何一款編輯器都少不了“復(fù)制”“粘貼”這兩個(gè)功能,對(duì)于需要編輯冗長(zhǎng)代碼的軟件開(kāi)發(fā)人員更是如此。但程序猿們并不滿足于此,他們創(chuàng)建了一種開(kāi)源社區(qū),從而可以“復(fù)制”其他人共享的代碼,他們把這種共享的理念叫做“不要重復(fù)造輪子”。

業(yè)務(wù)方頻繁改動(dòng)需求令程序猿們很是頭疼,他們希望以最小的代碼改動(dòng)來(lái)實(shí)現(xiàn)業(yè)務(wù)方相要的效果;同時(shí),當(dāng)業(yè)務(wù)方提出新需求時(shí),盡量不去動(dòng)已經(jīng)寫(xiě)好的代碼……

基于以上實(shí)用性、高效率的工作需要,程序猿們創(chuàng)造一個(gè)“軟件模塊化設(shè)計(jì)”的概念:

把一個(gè)很大很復(fù)雜的系統(tǒng),按照功用性,劃分成若干個(gè)模塊,每個(gè)模塊完成一個(gè)確定的功能;然后在這些模塊之間建立相應(yīng)的聯(lián)系(接口),通過(guò)模塊間的互相協(xié)作,最終實(shí)現(xiàn)業(yè)務(wù)方提出的需求。

舉個(gè)例子,對(duì)不懂技術(shù)的業(yè)務(wù)方來(lái)說(shuō),上傳文件和上傳圖片是兩個(gè)完全不同的動(dòng)作,但對(duì)程序猿來(lái)說(shuō),這兩個(gè)動(dòng)作其實(shí)可以抽象成一個(gè)行為(或功能)——“上傳”。這時(shí),假如一個(gè)系統(tǒng)出現(xiàn)多處需要“上傳”功能的模塊,程序猿只需要把相應(yīng)的代碼復(fù)制過(guò)去,根據(jù)業(yè)務(wù)方需要做簡(jiǎn)單的修改即可,不必再重新編輯。

再比如一個(gè)商業(yè)分析模塊(BI),數(shù)據(jù)來(lái)源是財(cái)務(wù)系統(tǒng)和供應(yīng)鏈系統(tǒng),那么開(kāi)發(fā)人員在做BI模塊時(shí),只需要了解需要輸入什么數(shù)據(jù)、輸出什么類(lèi)型的圖表即可,完全不用考慮這些數(shù)據(jù)從哪來(lái),有什么意義。

以上就是“軟件模塊化設(shè)計(jì)”在軟件開(kāi)發(fā)領(lǐng)域最實(shí)用的兩個(gè)意義,除此之外,還具有使系統(tǒng)結(jié)構(gòu)清晰、代碼簡(jiǎn)潔、良好擴(kuò)展性、便于分離、適應(yīng)業(yè)務(wù)變化等優(yōu)點(diǎn)。

產(chǎn)品經(jīng)理距離“軟件模塊化設(shè)計(jì)”最近的時(shí)候就是畫(huà)原型圖!比如Axure中的“母版”功能、“動(dòng)態(tài)面板”、“框架”、頁(yè)面分級(jí)編組、圖層編組等等,我們可以仔細(xì)想想每次使用這些控件時(shí),都是出于什么目的:

  • 母版:一處改動(dòng),多處生效;
  • 動(dòng)態(tài)面板:封裝控件,便于拖動(dòng),交互效果互不干涉;
  • 框架:對(duì)需要變動(dòng)部分的內(nèi)容進(jìn)行定向修改,不影響其他;
  • 頁(yè)面分級(jí)編組:理清模塊、頁(yè)面間的層級(jí)關(guān)系;
  • 圖層編組:封裝控件,便于編輯管理。

02 模塊化設(shè)計(jì)對(duì)產(chǎn)品經(jīng)理的幫助

產(chǎn)品經(jīng)理在互聯(lián)網(wǎng)時(shí)代以前,主要?dú)w屬于市場(chǎng)營(yíng)銷(xiāo)部,職能是快速響應(yīng)市場(chǎng)需要,對(duì)產(chǎn)品盈虧負(fù)責(zé);軟件類(lèi)產(chǎn)品的設(shè)計(jì)工作直接由開(kāi)發(fā)部門(mén)負(fù)責(zé)。

進(jìn)入互聯(lián)網(wǎng)時(shí)代,尤其是移動(dòng)互聯(lián)網(wǎng),產(chǎn)品版本迭代速度加快,開(kāi)發(fā)部門(mén)越來(lái)越需要一個(gè)專(zhuān)門(mén)負(fù)責(zé)解讀用戶(hù)需求、研究用戶(hù)體驗(yàn),并將需求整理后傳遞給開(kāi)發(fā)人員的職能角色。產(chǎn)品經(jīng)理自此才逐漸成為互聯(lián)網(wǎng)行業(yè)的一個(gè)重要角色。

產(chǎn)品經(jīng)理與程序猿之間的這些淵源,決定了產(chǎn)品經(jīng)理需要了解一些類(lèi)似軟件架構(gòu)設(shè)計(jì)理念,或者是邏輯嚴(yán)謹(jǐn)?shù)乃伎挤绞?。一方面可以更友好、更?zhǔn)確地跟程序猿傳達(dá)設(shè)計(jì)要點(diǎn);另一方面也能夠幫助自己處理“具象的、數(shù)量繁多的、無(wú)邏輯的、瑣碎的”用戶(hù)需求。

軟件模塊化設(shè)計(jì)有兩個(gè)很重要的步驟——?dú)w類(lèi)和抽象,完成了這兩步才能確定最終要做哪些模塊、哪些功能。

比如說(shuō),單選題、多選題、判斷題同屬于客觀題,這叫歸類(lèi);單選題是“擁有4個(gè)選項(xiàng),答案唯一的題目”,多選題是“擁有4個(gè)選項(xiàng),以“且”關(guān)系連接的多答案題目”,判斷題是“擁有2個(gè)固定選項(xiàng),答案唯一的題目”,這叫抽象。

產(chǎn)品經(jīng)理在跟業(yè)務(wù)方溝通時(shí),經(jīng)常會(huì)遇到各種各樣的專(zhuān)業(yè)名詞、行業(yè)限定下的特殊場(chǎng)景,這些名詞在業(yè)務(wù)場(chǎng)景中可能代表著不同的含義,但是在軟件開(kāi)發(fā)中卻可以用固定的、已有的簡(jiǎn)單名詞來(lái)表述。

對(duì)需求做歸類(lèi)和抽象,不僅僅是為了跟程序猿溝通,更重要的是幫助產(chǎn)品經(jīng)理認(rèn)識(shí)到需求的實(shí)質(zhì),也使自己的設(shè)計(jì)工作“不要重復(fù)造輪子”。

對(duì)需求完成歸類(lèi)和抽象后,必然面對(duì)“如何聯(lián)系”這一問(wèn)題——模塊之間有無(wú)前后置關(guān)系,數(shù)據(jù)流向是怎樣的?

比如說(shuō),經(jīng)過(guò)歸類(lèi)抽象,我們決定開(kāi)發(fā)“題庫(kù)管理”“試卷管理”“教學(xué)管理”三個(gè)產(chǎn)品模塊;這時(shí)就需要思考這三個(gè)模塊之間的關(guān)系:

  • 沒(méi)有“題庫(kù)”,“試卷”不成立,但“教學(xué)”成立,所以“試卷”依賴(lài)“題庫(kù)”;
  • 沒(méi)有“試卷”,“題庫(kù)”“教學(xué)”均成立,所以“題庫(kù)”“教學(xué)”獨(dú)立;
  • 沒(méi)有“教學(xué)”,“題庫(kù)”“試卷”均成立……

經(jīng)過(guò)逐級(jí)演化,最終我們可以得出這三個(gè)模塊之間的關(guān)系圖譜。

經(jīng)過(guò)一系列歸類(lèi)、抽象和關(guān)系確定,我們可以得到一張UML用例圖、一張活動(dòng)圖,甚至狀態(tài)圖、時(shí)序圖和數(shù)據(jù)庫(kù)設(shè)計(jì);這些流程圖相當(dāng)于一張標(biāo)注過(guò)路線的產(chǎn)品地圖,有了路線圖就可以直接進(jìn)入產(chǎn)品設(shè)計(jì)階段了(UML圖可以使程序猿直接進(jìn)入開(kāi)發(fā)階段,不一定非得等到原型圖出來(lái))。

當(dāng)業(yè)務(wù)方提出需求變更時(shí),我們可以對(duì)照這些圖例:哪些需求是原有需求的變種,哪些需求是真正的新增,這些需求是否在預(yù)期的開(kāi)發(fā)路線上,是否能夠在系統(tǒng)中實(shí)現(xiàn),對(duì)系統(tǒng)的影響有多大……

總之,當(dāng)產(chǎn)品經(jīng)理對(duì)產(chǎn)品有了模塊化的概念化,會(huì)很輕松地應(yīng)對(duì)來(lái)自客戶(hù)的需求新增和變動(dòng)。

  • 在軟件工程領(lǐng)域,模塊化設(shè)計(jì)的初衷是:使軟件不至于隨著逐漸變大而變得不可控,最終要達(dá)到可控、可維護(hù)、可擴(kuò)展的目的。
  • 產(chǎn)品經(jīng)理學(xué)習(xí)模塊化設(shè)計(jì)的目的也是如此——使獲取到的需求可控、可維護(hù)、可擴(kuò)展,至少可以幫助我們快速評(píng)估出新需求在產(chǎn)品中所在的位置。

03 模塊化設(shè)計(jì)的5個(gè)顯著特征

前文通俗地還原了軟件模塊化設(shè)計(jì)的原貌,最后總結(jié)一下軟件模塊化設(shè)計(jì)的5個(gè)顯著特征:

1. 層次分明

可以簡(jiǎn)單理解為設(shè)計(jì)一個(gè)結(jié)構(gòu)合理的樹(shù)狀菜單。

2. 抽象與細(xì)分

抽象:只考慮要解決的問(wèn)題(用戶(hù)需求),不考慮實(shí)現(xiàn)方法;

細(xì)分:強(qiáng)調(diào)對(duì)需求的逐步分解,分解時(shí)僅較上一部分增加少量的細(xì)節(jié)。

用戶(hù)想要實(shí)現(xiàn)在線報(bào)銷(xiāo)的功能,那我們就給他做一個(gè)“報(bào)銷(xiāo)軟件”,這個(gè)“報(bào)銷(xiāo)軟件”就是抽象出來(lái)的實(shí)體;

接下來(lái)要對(duì)“報(bào)銷(xiāo)軟件”進(jìn)行第一次分解:報(bào)銷(xiāo)信息填寫(xiě)、發(fā)票識(shí)別與驗(yàn)真、審批;

第二次分解“發(fā)票識(shí)別與驗(yàn)真”:發(fā)票信息錄入、發(fā)票真?zhèn)涡则?yàn)證、發(fā)票是否已用驗(yàn)證;

第三次分解“發(fā)票是否已用驗(yàn)證”:歷史已用發(fā)票查詢(xún)、歷史已用發(fā)票編號(hào)對(duì)比……

3. 組成獨(dú)立

在軟件工程領(lǐng)域也被成為“信息隱蔽”,意思是在設(shè)計(jì)和確定模塊時(shí),使一個(gè)模塊內(nèi)包含信息(流程或數(shù)據(jù)),對(duì)于不需要這些信息的其他模塊來(lái)說(shuō)是不能訪問(wèn)的。

也就是說(shuō),除了必要的接口,盡量減少模塊間、分系統(tǒng)、子系統(tǒng)間的邏輯依賴(lài),這樣在后期維護(hù)升級(jí)時(shí),就可以避免干涉其他不相關(guān)的部分。

例:

“報(bào)銷(xiāo)單”包含單據(jù)編號(hào)、單據(jù)類(lèi)型、單據(jù)金額、提交人、提交日期等信息,但“財(cái)務(wù)分析”模塊只需要用到單據(jù)金額、提交日期兩項(xiàng)數(shù)據(jù),那么就只允許“財(cái)務(wù)分析”模塊通過(guò)接口調(diào)用的方式訪問(wèn)這兩項(xiàng)數(shù)據(jù),其他數(shù)據(jù)一概不能訪問(wèn)。

4. 面向數(shù)據(jù)結(jié)構(gòu)(面向接口)

軟件系統(tǒng)一般由邏輯(算法)和信息兩部分構(gòu)成,信息又分為內(nèi)容和數(shù)據(jù);邏輯是構(gòu)建軟件功能的骨架,內(nèi)容和數(shù)據(jù)是血肉,其中以數(shù)據(jù)尤為重要。

假如要實(shí)現(xiàn)軟件模塊化且模塊之間相互獨(dú)立,必須要先拋棄邏輯(實(shí)現(xiàn)方法),因?yàn)橛羞壿嬀痛磉@兩個(gè)模塊誰(shuí)也離不開(kāi)誰(shuí),就不能稱(chēng)之為獨(dú)立。

如果這兩個(gè)模塊必須要關(guān)聯(lián)在一起,但又不允許它們?cè)谶壿嬌匣ハ喔缮?,那?strong>最好的辦法就是為它們內(nèi)部包含的數(shù)據(jù)進(jìn)行抽象化,形成標(biāo)準(zhǔn)化接口,以數(shù)據(jù)調(diào)用的形式實(shí)現(xiàn)兩個(gè)模塊間的互相協(xié)作。

5. 高內(nèi)聚,低耦合

這里要解釋一下,其實(shí)“高內(nèi)聚,低耦合”才是軟件開(kāi)發(fā)的內(nèi)在要求,“模塊化設(shè)計(jì)”只是實(shí)現(xiàn)“高內(nèi)聚,低耦合”的其中一種方法。

  • “高內(nèi)聚”最精準(zhǔn)的體現(xiàn)是“面向?qū)ο箝_(kāi)發(fā)”,它的意思是從功能角度來(lái)衡量模塊間的聯(lián)系,也就是說(shuō)一個(gè)好的內(nèi)聚模塊應(yīng)當(dāng)只做一件事;
  • “低耦合”的精準(zhǔn)體現(xiàn)是“面向接口開(kāi)發(fā)”,意思是從軟件結(jié)構(gòu)角度衡量各個(gè)模塊之間的聯(lián)系,耦合強(qiáng)弱取決于模塊間接口的復(fù)雜程度、進(jìn)入或訪問(wèn)一個(gè)模塊需要調(diào)用的接口數(shù)量和次數(shù);極端的低耦合是不需要任何接口,但一般很少見(jiàn)。

“高內(nèi)聚,低耦合”是判斷軟件設(shè)計(jì)好壞很重要的一個(gè)標(biāo)準(zhǔn),關(guān)于如何達(dá)到這一要求,本文不作重點(diǎn)介紹,大家可以自己查查資料簡(jiǎn)單了解一下。

04 兼顧考慮用戶(hù)體驗(yàn)和市場(chǎng)需求

模塊化設(shè)計(jì)并不只是為了提高軟件開(kāi)發(fā)效率、適應(yīng)快速變化,它在一定程度上也代表了最優(yōu)的用戶(hù)體驗(yàn)和市場(chǎng)需要。下面舉幾個(gè)例子:

  • UE設(shè)計(jì)中有一個(gè)“就近原則”,就是對(duì)相關(guān)控件進(jìn)行直觀分組,創(chuàng)建一個(gè)更少混亂、更有組織的布局,使用戶(hù)在一個(gè)區(qū)域只進(jìn)行一類(lèi)操作。
  • 頁(yè)面設(shè)計(jì)中的樹(shù)狀菜單和“面包屑”元素,代表著分層分級(jí);
  • 每個(gè)頁(yè)面只進(jìn)行固定的、少量的幾個(gè)相關(guān)性較強(qiáng)的功能操作,比每個(gè)頁(yè)面進(jìn)行很多個(gè)操作學(xué)習(xí)成本更低,更容易上手使用;
  • B端客戶(hù)的定制化需要相對(duì)比較高,而ToB產(chǎn)品往往都做得又大又全,有的客戶(hù)可能僅僅只需要部分功能模塊,這時(shí)就需要為拆分后的功能模塊進(jìn)行單獨(dú)定價(jià),最終報(bào)價(jià)按照客戶(hù)選用的模塊進(jìn)行匯總。
  • 采用模塊化設(shè)計(jì)的軟件產(chǎn)品,可以結(jié)合客戶(hù)行業(yè)特點(diǎn)或公司產(chǎn)品規(guī)劃,針對(duì)性地對(duì)某個(gè)模塊進(jìn)行優(yōu)化升級(jí),使之單獨(dú)成為一款產(chǎn)品參與市場(chǎng)競(jìng)爭(zhēng),并且不會(huì)對(duì)原系統(tǒng)造成影響。

 

作者:產(chǎn)品路漫漫;微信公眾號(hào):產(chǎn)品路漫漫

本文由 @產(chǎn)品路漫漫 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來(lái)自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 非常好

    來(lái)自北京 回復(fù)