1. Platform

Platform相對(duì)于產(chǎn)品而言，它是橫向的。Platform是服務(wù)與匯總多方角色的一個(gè)完整產(chǎn)品線，它橫跨多個(gè)縱向產(chǎn)品并為這些產(chǎn)品提供‘公共的’服務(wù)，Platform服務(wù)并支持點(diǎn)融的多個(gè)產(chǎn)品或點(diǎn)融所有的產(chǎn)品。比如，用戶運(yùn)營(yíng)中心是一個(gè)Platform，它既可以給投資端產(chǎn)品提供服務(wù)，又可以給借款端產(chǎn)品提供服務(wù)；安全反欺詐平臺(tái)是一個(gè)Platform，它為點(diǎn)融所有產(chǎn)品提供公共接口，產(chǎn)品可以通過(guò)調(diào)用這些公共服務(wù)來(lái)解決人機(jī)識(shí)別，黑客惡意注冊(cè)，登陸等安全問(wèn)題。

Platform關(guān)注‘轉(zhuǎn)化’及‘復(fù)用’的能力，它希望越來(lái)越多的第三方采用它所提供的服務(wù)，從而最大化使用平臺(tái)的產(chǎn)品數(shù)量和不同的業(yè)務(wù)類型?？梢詫latform理解為一系列的基礎(chǔ)構(gòu)造，而這些基礎(chǔ)構(gòu)造的目標(biāo)是使多個(gè)產(chǎn)品能夠在同一種技術(shù)框架下進(jìn)行搭建。Platform將功能標(biāo)準(zhǔn)化，抽象化，依靠提供標(biāo)準(zhǔn)化的服務(wù)，從而提升Product產(chǎn)品化及開發(fā)的效率，同時(shí)，它也是MVP產(chǎn)品可以快速上線的強(qiáng)大后盾。

Platform的功能一般比較通用，不和任何產(chǎn)品線緊耦合。它所服務(wù)的對(duì)象是眾多不同的產(chǎn)品或內(nèi)部團(tuán)隊(duì)，通常不會(huì)直接面對(duì)C端用戶。這些使用Platform所提供服務(wù)的用戶和產(chǎn)品對(duì)于Platform本身而言，是沒(méi)有優(yōu)先級(jí)和重要等級(jí)之分的，同時(shí)，Platform的設(shè)計(jì)也沒(méi)有業(yè)務(wù)偏向性。

Platform和Product均可Saas化，并有可能賣給第三方。在點(diǎn)融，我們一般會(huì)優(yōu)先考慮Saas化縱向的產(chǎn)品，可以選擇性的整合部分平臺(tái)化的模塊作為VAS，從而增加縱向產(chǎn)品的競(jìng)爭(zhēng)力。

Platform和Product的關(guān)系圖如下：

A．如何判斷

如果對(duì)以下大部分問(wèn)題的回答是肯定的，那么您所致力開發(fā)的項(xiàng)目就是一個(gè)Platform：

i. 您的項(xiàng)目當(dāng)前是不是服務(wù)于多個(gè)點(diǎn)融產(chǎn)品或者未來(lái)6個(gè)月內(nèi)會(huì)服務(wù)于多個(gè)（≥2個(gè)）點(diǎn)融產(chǎn)品？

比如：這個(gè)平臺(tái)是服務(wù)于投資端和借款端多個(gè)不同產(chǎn)品的嗎？

ii. 如果有一個(gè)點(diǎn)融自我組建或者收購(gòu)的新團(tuán)隊(duì)/部門，您所提供的服務(wù)是否能夠讓他們使用？

iii. 您的框架是否支持不同的多種應(yīng)用和產(chǎn)品在上面進(jìn)行搭建和提供支持？

iv. 這個(gè)項(xiàng)目的目標(biāo)是不是為了提升Product產(chǎn)品化的效率？

B． 需要遵循的規(guī)則

i. MRD Review: 必須進(jìn)行，且為Blocking Review；

參考流程：MRD Review Process

ii. Architecture Review: 必須進(jìn)行，且為Blocking Review；

參考流程：Arch Review Process

iii. 職責(zé)分配：必須有較高職級(jí)（如Director）的人作為owner，必須要有不同的角色分別承擔(dān)：Approver, Block reviewer和Non-Block reviewer的角色；

iv. 每三個(gè)月Product Committee 與 Arch Committee對(duì)所有的Platforms進(jìn)行一次評(píng)審來(lái)確認(rèn)該P(yáng)latform是否值得進(jìn)行繼續(xù)開發(fā)投資；

C．不建議做的事

i.Platform上不建議做Hack的解決方案，在設(shè)計(jì)之初就要考慮到與其他產(chǎn)品/用戶的整合和對(duì)接，項(xiàng)目產(chǎn)出常為模塊化的接口及標(biāo)準(zhǔn)；

ii. 不建議做與某個(gè)業(yè)務(wù)強(qiáng)耦合的功能；

D． Platform舉例

i. 市值最高的10家公司中有5家就是或有平臺(tái)業(yè)務(wù)，比如：Apple, Microsoft, Google, Amazon, Facebook。Amazon是一個(gè)線上零售的平臺(tái)，一開始Amazon只賣書，隨著時(shí)間的推移，Amazon擴(kuò)展并銷售了各種各樣的產(chǎn)品和服務(wù)，成為一個(gè)Platform；

ii. 對(duì)外平臺(tái)舉例：

點(diǎn)融網(wǎng)dianrong.com本身就是一個(gè)服務(wù)于借與貸的平臺(tái)；

Chained Finance是為供應(yīng)鏈上下游的供應(yīng)商和經(jīng)銷商提供金融服務(wù)的平臺(tái)；

iii. 對(duì)內(nèi)平臺(tái)舉例：

用戶運(yùn)營(yíng)，數(shù)據(jù)倉(cāng)庫(kù)，會(huì)員體系這些都屬于對(duì)內(nèi)的Platform；

除此之外，Design Bible 也是一個(gè)Platform。

2. ?Product

Product相對(duì)于平臺(tái)而言，它是縱向的。Product通過(guò)滿足特定用戶的需求來(lái)創(chuàng)造價(jià)值，其用戶對(duì)象十分清晰。比如一個(gè)客戶關(guān)系管理產(chǎn)品的用戶就是客戶服務(wù)部門，點(diǎn)融理財(cái)APP的用戶就是C端的投資用戶，魔借APP的用戶就是線上小額借款用戶。Product只服務(wù)于某一類核心客戶，可能會(huì)有外部其他的潛在用戶，當(dāng)PM看到有這群用戶的機(jī)會(huì)時(shí)，可以考慮做產(chǎn)品Saas化來(lái)滿足潛在用戶的需求。

從業(yè)務(wù)的角度去看，Product是一個(gè)獨(dú)立運(yùn)行的業(yè)務(wù)（Standalone Business），而且Product是有能力成為一個(gè)單獨(dú)的BU或者是分公司的。

Product從一開始設(shè)計(jì)的時(shí)候就伴隨著預(yù)先定義好的業(yè)務(wù)邏輯，而這些預(yù)定義的業(yè)務(wù)邏輯將Product的范圍限制在一定的界限之內(nèi)。在做產(chǎn)品設(shè)計(jì)的時(shí)候，PM首先應(yīng)該去調(diào)查公司已有哪些平臺(tái)可以幫助產(chǎn)品進(jìn)行快速搭建（通俗的說(shuō)，就是先要尋找已經(jīng)可用的輪子），為了推動(dòng)業(yè)務(wù)快速向前發(fā)展，可以允許Product使用Hack的方式快速實(shí)現(xiàn)目前沒(méi)有的功能，因?yàn)槠渑c業(yè)務(wù)的強(qiáng)相關(guān)性，它所關(guān)注的是業(yè)務(wù)走向而不是誰(shuí)會(huì)來(lái)調(diào)用我的產(chǎn)品。比如，當(dāng)某個(gè)產(chǎn)品需要使用標(biāo)簽的時(shí)候，可以將功能做在自己的產(chǎn)品里滿足需求即可，但是產(chǎn)品里要做一個(gè)公司級(jí)別的標(biāo)簽系統(tǒng)，并不是一件靠譜的事。

A．如何判斷

如果對(duì)以下大部分問(wèn)題的回答是肯定的，那么您所致力開發(fā)的項(xiàng)目就是一個(gè)Product：

i. 這個(gè)產(chǎn)品如果單獨(dú)在市場(chǎng)上賣的話，有沒(méi)有機(jī)會(huì)？

ii. 這個(gè)產(chǎn)品是不是服務(wù)于一類特定用戶的？

iii. 產(chǎn)品本身有沒(méi)有可行的商業(yè)模式？

iv. 產(chǎn)品中實(shí)現(xiàn)的功能是不是強(qiáng)依賴于業(yè)務(wù)，若非常依賴于業(yè)務(wù)，則是Product，比如：產(chǎn)品如果脫離了某項(xiàng)業(yè)務(wù)就無(wú)法生存；

B． 需要遵循的規(guī)則

i.MRD Review: 必須進(jìn)行，且為Blocking Review；

參考流程：MRD Review Process

ii.Architecture Review: 當(dāng)產(chǎn)品處于POC/MVP階段時(shí)，建議進(jìn)行架構(gòu)評(píng)審，為Non-blocking review；當(dāng)產(chǎn)品進(jìn)入成長(zhǎng)階段之后，必須進(jìn)行架構(gòu)評(píng)審，為blocking review；

參考流程：Arch Review Process

iii.Investment Thesis: 應(yīng)當(dāng)包含；

參考流程：Investment Thesis

iv.職責(zé)分配: owner為產(chǎn)品經(jīng)理；

v.每三個(gè)月Product Committee對(duì)所有的Products進(jìn)行一次review看是否值得對(duì)某個(gè)產(chǎn)品進(jìn)行繼續(xù)開發(fā)投資；

C．不建議做的事

i.不推薦在產(chǎn)品中做平臺(tái)化的東西，例如借款產(chǎn)品中不應(yīng)該去開發(fā)與“用戶生命周期”相關(guān)的功能，這些功能應(yīng)當(dāng)在Platform中的用戶運(yùn)營(yíng)里進(jìn)行開發(fā)；

ii.產(chǎn)品加入的功能越來(lái)越多的時(shí)候Product可以向Platform發(fā)展，但是產(chǎn)品不應(yīng)該是平臺(tái)化的發(fā)起者，需要做平臺(tái)化的項(xiàng)目就要遵循平臺(tái)的立項(xiàng)流程并指派合適的Owner；

iii.杜絕產(chǎn)品經(jīng)理不調(diào)研公司已有的技術(shù)平臺(tái)和模塊，按個(gè)人喜好和想象搭建產(chǎn)品；

D． Product舉例

i.每個(gè)汽車公司都擁有多個(gè)設(shè)計(jì)制造的平臺(tái)，比如：底盤設(shè)計(jì)，軸傳動(dòng)，轉(zhuǎn)向操舵等，而不同型號(hào)的汽車就是基于這些平臺(tái)所搭建出來(lái)的產(chǎn)品；

ii.點(diǎn)融借貸，MCA等，這些都屬于Product；

iii. 聚合支付服務(wù)也是一個(gè)Product，服務(wù)于點(diǎn)融的核心業(yè)務(wù)；

iv.CRM也屬于Product，為用戶運(yùn)營(yíng)的一部分，其對(duì)內(nèi)服務(wù)于銷售和客服，如果Saas化，將能服務(wù)于金融企業(yè)，銀行等外部客戶。

3.?? Feature

Feature是令Product有別于其他產(chǎn)品和競(jìng)爭(zhēng)對(duì)手的重要特征之一，它是Product的重要組成部分，也就是說(shuō)，一個(gè)產(chǎn)品由多個(gè)Features組成。Feature主要是指功能性的單元或組件，客戶/用戶和開發(fā)者可以通過(guò)Feature來(lái)進(jìn)行溝通，我們也可以利用Feature來(lái)審視和提高產(chǎn)品被重復(fù)消費(fèi)的意識(shí)。比如TTZ 1.0是一個(gè)Feature，它拆散所有的資產(chǎn)包并分配到不同的團(tuán)中，構(gòu)成了產(chǎn)品有別于其他產(chǎn)品的特性；現(xiàn)金貸中實(shí)時(shí)全自動(dòng)線上審批，極速（僅需3分鐘）借款申請(qǐng)?bào)w驗(yàn)等屬于Feature，它們構(gòu)成了產(chǎn)品的賣點(diǎn)。

Feature一般包括產(chǎn)品的功能性與非功能性特征（functional/non-functional Features），非主體特征（outlier Features），交叉性特征（cross-cutting Features）及由于時(shí)間壓力帶來(lái)的不成熟的特征（immature Features）等。

A．如何判斷

有時(shí)候我們很清晰的知道“這是一個(gè)產(chǎn)品的Feature”，但更多情況下，尤其是當(dāng)我們?cè)谧霎a(chǎn)品的MVP的時(shí)候，往往只是做了一個(gè)解決簡(jiǎn)單問(wèn)題的Feature。Feature更多的是具體的動(dòng)作/功能，而包含眾多Features的產(chǎn)品，解決的則是特定用戶的場(chǎng)景化問(wèn)題。

如果對(duì)以下問(wèn)題的回答是肯定的，那么您所致力開發(fā)的項(xiàng)目就是一個(gè)Feature：

i. 這個(gè)Feature是不是產(chǎn)品所具備的眾多特征（nice-to-have, must-to-have）之一？

ii. 這個(gè)Feature是不是高度聚焦的？它是不是與產(chǎn)品現(xiàn)有的其他功能完全不同，但是它又是和其他的Feature一起組成了這個(gè)產(chǎn)品？

B． 需要遵循的規(guī)則

i.MRD Review: 推薦進(jìn)行，為Non-blocking Review；

參考：MRD Review Process

ii.1 Pager立項(xiàng)流程：需要進(jìn)行，且為Blocking Review;

參考流程：1 Pager Review Process

iii.Architecture Review: 推薦進(jìn)行，為Non-blocking Review；

參考流程：Arch Review Process

C．不建議做的事

i. 防止功能蔓延（Feature Creep）；

D． Feature舉例

i.TTZ 2.0對(duì)于TTZ 1.5來(lái)說(shuō)，它是一個(gè)Feature而不是Improvement, 依賴于RiverRun這個(gè)平臺(tái), 服務(wù)于點(diǎn)融的核心業(yè)務(wù)；

ii. 小融包，節(jié)節(jié)發(fā)，企業(yè)團(tuán)，社區(qū)，商城，點(diǎn)融幣都屬于Feature；

iii.好的Feature與不好的Feature:

Good Feature

Bad Feature

受用戶歡迎

用戶抱怨

受開發(fā)者歡迎

重復(fù)的特性

充分實(shí)施的，思慮周全的

變通方案，Hack

準(zhǔn)確無(wú)誤的

缺陷特性

測(cè)試充分的

無(wú)法測(cè)試或者很難進(jìn)行測(cè)試的

滿足架構(gòu)設(shè)計(jì)要求的

選擇性Feature

獨(dú)特的功能性

極易變動(dòng)的，不穩(wěn)定的

4. ?Improvement

Improvement是指對(duì)產(chǎn)品的改善，產(chǎn)品是否實(shí)施了這一項(xiàng)Improvement，不會(huì)影響產(chǎn)品功能的主要業(yè)務(wù)目的，但是Improvement在用戶體驗(yàn)，使用方便，穩(wěn)定性，性能等方面的提升，可以更好的實(shí)現(xiàn)產(chǎn)品的目標(biāo)。Improvement的引入不會(huì)帶來(lái)新的business goal，但是Feature會(huì)。

比如點(diǎn)融理財(cái)界面改版是是一項(xiàng)Improvement，而TTZ 2.0對(duì)于TTZ 1.5來(lái)說(shuō)，是一個(gè)Feature而不是一項(xiàng)Improvement，因?yàn)閮烧咭獙?shí)現(xiàn)的業(yè)務(wù)目標(biāo)不一樣，設(shè)計(jì)和實(shí)現(xiàn)也不相同，并且TTZ 2.0為整個(gè)產(chǎn)品創(chuàng)造了新的賣點(diǎn)，而TTZ 1.5的目的是為了團(tuán)產(chǎn)品的合規(guī)化，所以TTZ1.5是Improvement，TTZ 2.0是Feature；總而言之，Improvement不會(huì)增加產(chǎn)品本身的賣點(diǎn)，但是它可以增強(qiáng)用戶體驗(yàn)，提高轉(zhuǎn)化率。

A．如何判斷

Improvement針對(duì)的是已有的功能，是在已有功能的基礎(chǔ)上所做的優(yōu)化，包括：用戶體驗(yàn)，性能等，這是一個(gè)持續(xù)的過(guò)程。

如果對(duì)以下問(wèn)題的回答是肯定的，那么您所致力開發(fā)的項(xiàng)目就是一個(gè)Improvement：

i.這項(xiàng)改進(jìn)是不是在現(xiàn)有的產(chǎn)品功能上所做的優(yōu)化？

ii.您的目標(biāo)是不是為了提升用戶體驗(yàn)？或者是為了提升產(chǎn)品性能/產(chǎn)品質(zhì)量？

B． 需要遵循的規(guī)則

i.MRD Review: 推薦進(jìn)行，為Non-blocking Review；

參考：MRD Review Process

ii.1 Pager立項(xiàng)流程：推薦進(jìn)行，為Non-blocking Review；

參考流程：1 Pager Review Process

iii.Architecture Review: 推薦進(jìn)行，為Non-blocking Review；

參考流程：Arch Review Process

C.不建議做的事

i.防止范圍蔓延，杜絕開發(fā)者憑經(jīng)驗(yàn)喜好將Improvement擴(kuò)大為對(duì)一個(gè)Feature的重構(gòu)；

D.Improvement舉例

i.點(diǎn)融理財(cái)界面改版Lender 4.0是一個(gè)Improvement；

ii.注冊(cè)時(shí)由數(shù)字驗(yàn)證碼改為極驗(yàn)。

5.?Bug/Defect

Bug/Defect是指軟件產(chǎn)品中存在的缺陷。當(dāng)軟件的功能實(shí)現(xiàn)沒(méi)有滿足產(chǎn)品的需求，或者沒(méi)有滿足用戶的期望時(shí)，這時(shí)產(chǎn)生的問(wèn)題就是缺陷；換言之，缺陷是指代碼或數(shù)據(jù)庫(kù)層，或代碼邏輯實(shí)現(xiàn)所引發(fā)的功能故障，或者是不符合用戶預(yù)期的結(jié)果。

軟件的缺陷可以從以下幾個(gè)角度進(jìn)行分類：

優(yōu)先級(jí) Priority

嚴(yán)重等級(jí) Severity

用戶發(fā)現(xiàn)缺陷的機(jī)率 Probability

質(zhì)量維度，包括Accessibility，Compatibility，Concurrency，Efficiency，F(xiàn)unctionality，Install-ability，Localizability，Maintainability，Performance，Portability，Reliability，Scalability，Security，Testability，Usability

相關(guān)的模塊/組件

缺陷發(fā)現(xiàn)的階段

缺陷引入的階段

A.如何判斷

i.缺陷可以發(fā)生在軟件開發(fā)生命周期的任何一個(gè)階段，缺陷的識(shí)別可以由參與項(xiàng)目的任何人員完成，例如：產(chǎn)品經(jīng)理，系統(tǒng)維護(hù)人員、開發(fā)人員、測(cè)試人員、界面設(shè)計(jì)師、用戶等；

ii.對(duì)于缺陷的修復(fù)是指修正不符合設(shè)計(jì)規(guī)格的結(jié)果，而Feature request則是給產(chǎn)品添加新的功能；

iii.缺陷是引起客戶對(duì)產(chǎn)品‘不滿’的主要起因，而Feature request則是提升產(chǎn)品吸引力的方法及手段；

B.需要遵循的規(guī)則

i.Defect/Bug在創(chuàng)建時(shí)應(yīng)遵循Priority & Security的定義；

參考流程：優(yōu)先級(jí)Priority和嚴(yán)重等級(jí)Severity的定義

ii.所有Bugfix，代碼一定要進(jìn)行review；

參考流程：Code Review Guidelines

C.不建議做的事

i.防止為了修復(fù)缺陷而引起的范圍蔓延，杜絕開發(fā)人員憑經(jīng)驗(yàn)喜好將一個(gè)Bug fix擴(kuò)大為做代碼優(yōu)化甚至擴(kuò)大為做一個(gè)Improvement；

D. Defect舉例

i.團(tuán)投資記錄無(wú)法顯示給投資用戶；

ii.散標(biāo)無(wú)法進(jìn)行投資；

iii.為賬戶充值點(diǎn)擊確認(rèn)支付后手機(jī)應(yīng)用退出；

iv.新貴貸提交審核后，在審核系統(tǒng)中無(wú)相關(guān)貸款信息；

v.用戶輸入的還款金額等于應(yīng)還款金額時(shí)，無(wú)法進(jìn)行還款操作，并且APP報(bào)錯(cuò)“不可超過(guò)當(dāng)前結(jié)清應(yīng)還金額，請(qǐng)重新操作”；

vi.社區(qū)模塊由于新版本的上線加載速度由300ms 延長(zhǎng)至 3s。

本文作者：安娜（點(diǎn)融黑幫），資深項(xiàng)目經(jīng)理。