文章未作者結(jié)合自身實際經(jīng)驗總結(jié)，希望能夠給產(chǎn)品路上的各位PM帶來一些幫助。

項目簡介

最近在國內(nèi)某家人氣互聯(lián)網(wǎng)金融平臺的資產(chǎn)端做一些產(chǎn)品工作，公司相對傳統(tǒng)一些，放貸以線下渠道為主。最近公司想鋪設(shè)線上進件渠道，公司整體在這方面經(jīng)驗不多，所以我來打這個排頭兵。這個APP（下稱產(chǎn)品A）從7月份立項開始，快速進入開發(fā)，8月因故延期，9月上線后幾天就遭受了大多數(shù)現(xiàn)金貸產(chǎn)品都會遇到的問題——被大量羊毛騙貸群體沖擊，因而暫時關(guān)閉了進件。后與某著名貸款超市B合作，接通后發(fā)現(xiàn)對方推過來的客戶質(zhì)量極差，遂暫停合作。此文寫在APP 1.1 版本上線之際，是我對這個產(chǎn)品一個較為全面的復(fù)盤。

關(guān)于復(fù)盤

產(chǎn)品復(fù)盤的重要性不言而喻，復(fù)盤形式有很多種，條件允許情況下，我認(rèn)為應(yīng)該以團隊為單位進行復(fù)盤。無奈我目前所在的公司這方面氛圍差一些，所以我是從個人和公司的角度，進行了一些總結(jié)。因為我只是做了一些脫敏處理，一些細節(jié)只有內(nèi)部人員才清楚，所以希望讀者主要關(guān)注產(chǎn)品的思路和經(jīng)驗總結(jié)，感謝閱讀。

下為正文：

• 項目：某現(xiàn)金貸A
• 項目時長：2017-7立項 至 2017-10暫停

產(chǎn)品設(shè)計階段：

問題一、立項時沒有定義好問題和場景：

產(chǎn)品A所要解決的問題體現(xiàn)在兩個方面：

1. 對用戶來說，這個產(chǎn)品要解決的問題是現(xiàn)金貸借貸中，下款難，審核慢，期限太長的問題（做的短期）。
2. 對于公司來說，這個產(chǎn)品要解決的問題在于提供一個線上自主進件的渠道，作為整個公司產(chǎn)品向線上轉(zhuǎn)化的一個補充，同時也是短期現(xiàn)金貸產(chǎn)品線的一個分支。

兩者之間是有關(guān)聯(lián)的，通過解決用戶的問題而解決公司的問題。然而在產(chǎn)品的立項階段，對于用戶這邊，并沒有定義的很清楚，所謂的下款慢、下款難、流程繁瑣的問題是我在1.0上線后才總結(jié)出來的，并且隨后才設(shè)計了對核心流程進行迭代的計劃。這讓我們在產(chǎn)品初期沒有把握到特別清晰的一個方向，做了一些和這件事無關(guān)的工作。相應(yīng)的，我們對典型用戶和典型場景定義的也不夠。讓我們輕視了羊毛黨這個破壞性很強的用戶群體，這也是造成項目暫停的主要原因。

改進點：

1. 立項時定義好產(chǎn)品的目的、典型用戶、典型場景，做好這些工作，可以使產(chǎn)品路徑變得清晰，減少很多困擾和無用功。

問題二、產(chǎn)品文檔不夠完整清晰

開發(fā)前從接到任務(wù)（周三）到評審需求（周一）一共只給了我四天的產(chǎn)品規(guī)劃時間，間接導(dǎo)致設(shè)計文檔比較不達標(biāo)。

PRD存在一些問題：

1. 流程圖不夠清晰，
2. 狀態(tài)機沒有全部列出，
3. 有些細則沒有寫清楚。

設(shè)計稿存在一些問題：

1. 不夠完整，缺失部分頁面
2. 沒有設(shè)計規(guī)范，給開發(fā)留下比較大的空間
3. 時間壓得緊，甚至是一邊出稿一邊開發(fā)，也就沒有返工的余地
4. 沒有頁面流轉(zhuǎn)

和許多互金公司一樣，我們的開發(fā)人員分布在兩個城市，對于這種兩地聯(lián)合開發(fā)的模式，產(chǎn)品文檔尤為重要。因為這部分的問題，客戶端出現(xiàn)了比較多自由發(fā)揮的地方，花了一些時間去統(tǒng)一，最后成品細節(jié)也比較粗糙。

改進點：

1. 業(yè)務(wù)壓力大，也要爭取時間，磨刀不誤砍柴工，
2. 我已經(jīng)更新了自己的PRD模板，
3. 要讓設(shè)計師出設(shè)計規(guī)范。

開發(fā)至上線階段：

問題一、需求變更

開發(fā)過程中存在三次需求變更：

1. 白名單：白名單是包括在最初的方案里的，初衷是為了限制前期用戶范圍。隨著討論的推移，這個功能慢慢被廢棄了，但兵荒馬亂中我沒有及時發(fā)現(xiàn)這點，形成了返工。
2. 返修需求則是業(yè)務(wù)沒有考慮清楚，直接沿用了之前的流程，后來風(fēng)控負責(zé)人提出了質(zhì)疑，認(rèn)為返修會暴露風(fēng)控規(guī)則。其實返修這個需求，在線下渠道里，是給銷售讓步的一個需求，線上自主進件里自然就不需要了。一個風(fēng)控需求，來源卻是銷售，如果不熟悉系統(tǒng)，多做求證的話，確實難以觸及。
3. 做到一半時，風(fēng)控部門和領(lǐng)導(dǎo)們開會，把貸中模型更換了，但相關(guān)信息沒有同步到我這邊，直到項目末期我才從別的事情問出這個變化來，但是按照既定排期已經(jīng)無法更改。

改進點：

1. 需求同步問題：需要做到兩點：一是在線文檔更新，第二要對項目內(nèi)成員全員通知。第一點很簡單，主要要更新及時，并且文檔要標(biāo)出更新了哪里。第二點這次沒有達到，就算在QQ群里說了好幾次，都會被開發(fā)人員忽略掉，要面對面通知才行。目前我想到的一個方法專門建一個通知群，里面不進行任何討論，也不能進行任何回復(fù)，可以做成群主禁言的QQ群那種形式，在上面進行通知，以免消息被討論淹沒。
2. 所有涉及產(chǎn)品的信息都要同步到PM這里來，不是領(lǐng)導(dǎo)開會的時候定一下，程序自己就會改過來的，我們公司可能在這方面經(jīng)驗還不夠。

問題二、項目進度不準(zhǔn)確

項目出現(xiàn)了一次延期，原因是捆綁了其他業(yè)務(wù)需求，結(jié)果另一個項目延期了。項目疊加提高了項目的交叉風(fēng)險，原本每個項目成功率80%，捆綁后變成80*80=64%，實際上捆綁還會帶來額外的代碼合并風(fēng)險。

在項目排期的時候，所需時間是根據(jù)開發(fā)和測試進度估計的，后來領(lǐng)導(dǎo)一問，測試進度馬上壓縮了大半，說明測試時間存在彈性比較大，造成項目進度估計不準(zhǔn)確。

改進點：

1. 避免大項目捆綁上線。
2. 產(chǎn)品、開發(fā)、測試統(tǒng)一估計緩沖區(qū)，避免重復(fù)估計。

問題三、因設(shè)計產(chǎn)生的bug

1. 在測試階段發(fā)現(xiàn)，有兩個功能產(chǎn)生的bug最多，分別是返修和信息緩存。造成這兩個功能bug多的原因是這兩個功能都在業(yè)務(wù)主流程中，且邏輯較為復(fù)雜，涉及狀態(tài)多。
2. 發(fā)布之后出現(xiàn)了一個比較嚴(yán)重的bug：上線發(fā)布時，運維人員配置規(guī)則鏈錯誤，導(dǎo)致進來的用戶走成了舊的規(guī)則鏈。第二天風(fēng)控反饋后才發(fā)現(xiàn)。然而這個問題只有風(fēng)控那邊才會發(fā)現(xiàn)。
3. 北京貸后方面也產(chǎn)生了兩個比較嚴(yán)重的問題：

• 貸后放款時沒有扣下x%的手續(xù)費：本次產(chǎn)品中x%的手續(xù)費是新增規(guī)則，貸后需要部署新規(guī)則，對此我和貸后產(chǎn)品有反復(fù)確認(rèn)過，但貸后最終上線時還是沒有上這個功能。對此我覺得有兩點可以有改進的余地，第一是今后新產(chǎn)品上線時，可以進行全流程測試，其中資金問題走財務(wù)報銷，這需要北京方面配合。第二是對于關(guān)鍵風(fēng)險點，如果條件允許，可以做風(fēng)險備案。
• 產(chǎn)品A沒有走會簽流程，所以貸后各方面沒有被通知到。會簽流程只有運營部的人知道，屬于運營部的工作漏洞，但會嚴(yán)重影響產(chǎn)品的正常使用。

改進點：

1. 盡量簡化產(chǎn)品邏輯，尤其是在產(chǎn)品初期，復(fù)雜的功能應(yīng)盡量做的簡潔，不僅利于開發(fā)，也利于體驗。
2. 在條件允許的情況下，應(yīng)該避免PRD出現(xiàn)模棱兩可的情況。
3. 發(fā)布驗證的時候，風(fēng)控最好能在線，盡量要求三方做驗證，因為有些問題我們發(fā)現(xiàn)不了。
4. 對于這種貸款產(chǎn)品，盡量能驗完全流程，把放款也驗了，公司提供一下報銷。
5. 盡可能地熟悉公司的一些產(chǎn)品上線制度。
6. 對于一些不靠譜的業(yè)務(wù)部門，如果不能換人，產(chǎn)品需要負擔(dān)起一些更多的確認(rèn)工作。

上線后運營階段：

問題一、羊毛黨數(shù)量超出估計

上線后用戶量超出了我們的估計，產(chǎn)生了以下問題：

1. 第三方查詢接口成本太高，用戶量劇增后造成總成本過高。
2. 因為低估了用戶量，在一期中沒有把機審的功能做上去，結(jié)果造成審批人手嚴(yán)重不足。
3. 用戶質(zhì)量極差，通過率極低，造成以上兩點資源無謂損耗，以至關(guān)閉了項目。

改進點：

1. 其實這種問題我不是第一次遇到，只是沒想到騙貸產(chǎn)業(yè)經(jīng)過兩年發(fā)展了這么多，光光是來嘗試進件我們就承受不了。之前友商給的信息是上線后最高每天300單左右，但產(chǎn)品A單ios每天都有1000單，后來即使關(guān)閉了，第一個月也有兩萬的ios安裝量，騙貸群體龐大。對于這種比較大的風(fēng)險，可以提前準(zhǔn)備好“開關(guān)”，或采用類似于“灰度發(fā)布”的形式，逐步開放。
2. 很重要的一點，當(dāng)業(yè)務(wù)方不熟悉市場，零經(jīng)驗，比較怠惰的時候，我身為比他們有經(jīng)驗的PM，應(yīng)該主動去調(diào)研一下市場，由我來估計相應(yīng)的風(fēng)險，并且向業(yè)務(wù)方說明某些需求的必要性，爭取延期。
3. 成本核算很重要。

問題二、產(chǎn)品運營分工比較奇特

公司因為線上經(jīng)驗太少，運營比較缺乏線上運營的意識，所以有些線上運營的工作其實是我這邊在做。

1. 一些運營文案上的內(nèi)容，最好還是要讓相應(yīng)的策劃人員來做。
2. 渠道推廣的頁面設(shè)計、文案，最好是由運營來規(guī)劃。
3. 應(yīng)用市場的推廣應(yīng)交與ASO人員。應(yīng)用的分發(fā)并不是單純的往市場上一放那么簡單，雖然我通過分發(fā)應(yīng)用，親身了解了其中的一些小99。但從公司層面來看，我們公司有5款以上的APP，竟然沒有半個有ASO經(jīng)驗的人，效率確實比較低，效果也不太好。

改進點：

1. 公司如果要發(fā)展線上業(yè)務(wù)，不是出兩款線上產(chǎn)品這么簡單的，需要的是整個架構(gòu)、人員、意識的轉(zhuǎn)變。
2. PM應(yīng)該盡可能聚焦在產(chǎn)品工作上，先把產(chǎn)品做好了，再考慮去學(xué)習(xí)了解其他事。

問題三、合作方不給力

合作方B是國內(nèi)某知名貸款超市，產(chǎn)品A接的第一個渠道，采用的形式是API對接，B的用戶在其APP進件后推給我們，后發(fā)現(xiàn)接入效果并不好暫停。對接過程中有以下問題：

1. 對典型用戶和典型場景沒有清晰的描述，這也是后來造成問題的關(guān)鍵。對于B的用戶，沒有分析它的成份，輕信對方所說的客戶質(zhì)量。結(jié)果一運行，客戶質(zhì)量都差得很，根本沒法用。
2. 我們可以通過B后臺控制進件量，但開發(fā)過程中我們（包括技術(shù)總監(jiān)）都忽略了一個問題，B的客戶進件的速度非常快，平均每秒能有5單左右，峰值可以達到20單/秒，加上每單的大小又在2M以上，對我們的帶寬有不小的壓力。這個問題直到上線之后才發(fā)現(xiàn)。
3. 對接這種大公司，對方根本不會給你定制，全部都是按照他的規(guī)則對接，如果開發(fā)前沒有排除所有問題，開發(fā)到一半發(fā)現(xiàn)問題，就會很麻煩。這點我在一開始有意識到，但是有幾個問題還是沒有估計到，比如第2點說的阻塞帶寬。
4. 商務(wù)上并沒有走的很清楚，其中一條是：B推過來的用戶，如果超時了我們沒收到，他照樣要收錢。這是對我們非常不利的條款，但是直到上線后，我和對方產(chǎn)品溝通時才得知這一點，而業(yè)務(wù)完全不知道。而且B疑似是腳本自動給我們推客戶，所以進來的很快，然后都很差。
5. 開發(fā)過程中，發(fā)現(xiàn)對方放在網(wǎng)上的文檔中心有部分信息是過時的，提高了我們的開發(fā)難度。

改進點：

1. 跟A一樣的問題，也是跟A一樣的結(jié)果，立項的時候要對典型用戶和典型場景做詳細描述。在對接三方時，可以考慮向?qū)Ψ揭恍?shù)據(jù)來跑模型，確定對方的客戶確實能達到通過率。而不是對方說可以就可以，風(fēng)控口頭說可以10%，就能10%，事實上竟然沒有半個客戶能通過我們的風(fēng)控審核。
2. 對接渠道時要考慮流量壓力和用戶行為模式，尤其是那些定制不了的大客戶。
3. 設(shè)計階段要確認(rèn)對方的接口文檔是最新的。

問題四、無法快速迭代

在產(chǎn)品立項時，計劃是先上一個MVP版本，然后以很高的頻率去做迭代。然而上線后由于種種問題項目暫緩、沒有專門的開發(fā)人員、被渠道占用資源，導(dǎo)致迭代變得極其緩慢，兩個月只出了一個版本，下一個版本還要等半年，這種迭代速度對于一個初創(chuàng)產(chǎn)品來說，可以說是廢了。

改進點：

1. 公司如果要做一款產(chǎn)品，最好能分配專門的研發(fā)人員，就算是一個人也可以，不然產(chǎn)品遇到問題后無法迭代，就等于一個廢品，做一個廢一個。如果開發(fā)人員不夠，就不要輕易立項，浪費精力。把有限的開發(fā)聚焦在好的資源上，而不是為了做而做。
2. 雖然有人說項目制過時了，但是對于一般的企業(yè)來說，還是項目制比較易于執(zhí)行。
3. PM一定要有主動權(quán)，能夠把握住產(chǎn)品的節(jié)奏，聚焦于三件事以內(nèi)。如果產(chǎn)品上線初期，就到處拉資源推廣，延緩了產(chǎn)品的正常迭代，那如果拉來的資源不頂用呢？產(chǎn)品本身又沒有進步，兩頭落空。這個問題非常廣泛地存在于中等公司的初創(chuàng)項目中，必須注意。

本文由 @深藍色蕭邦?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自PEXELS,基于CC0協(xié)議