中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

項(xiàng)目簡介

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

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

產(chǎn)品復(fù)盤的重要性不言而喻，復(fù)盤形式有很多種，條件允許情況下，我認(rèn)為應(yīng)該以團(tuán)隊(duì)為單位進(jìn)行復(fù)盤。無奈我目前所在的公司這方面氛圍差一些，所以我是從個(gè)人和公司的角度，進(jìn)行了一些總結(jié)。因?yàn)槲抑皇亲隽艘恍┟撁籼幚恚恍┘?xì)節(jié)只有內(nèi)部人員才清楚，所以希望讀者主要關(guān)注產(chǎn)品的思路和經(jīng)驗(yàn)總結(jié)，感謝閱讀。

下為正文：

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

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

問題一、立項(xiàng)時(shí)沒有定義好問題和場景：

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

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

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

改進(jìn)點(diǎn)：

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

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

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

PRD存在一些問題：

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

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

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

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

改進(jìn)點(diǎn)：

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

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

問題一、需求變更

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

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

改進(jìn)點(diǎn)：

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

問題二、項(xiàng)目進(jìn)度不準(zhǔn)確

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

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

改進(jìn)點(diǎn)：

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

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

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

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

改進(jìn)點(diǎn)：

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

上線后運(yùn)營階段：

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

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

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

改進(jìn)點(diǎn)：

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

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

公司因?yàn)榫€上經(jīng)驗(yàn)太少，運(yùn)營比較缺乏線上運(yùn)營的意識，所以有些線上運(yùn)營的工作其實(shí)是我這邊在做。

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

改進(jìn)點(diǎn)：

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

問題三、合作方不給力

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

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

改進(jìn)點(diǎn)：

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

問題四、無法快速迭代

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

改進(jìn)點(diǎn)：

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

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

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