作者：硅谷堂mp ? 來源：搜狐

當我們提到一些常見的功能時，可以一筆帶過，簡單的描述一下就可以了，比如，對于微信登錄，手機號注冊。

那如果我們提到的是一些比較復雜的，具備一定創造性功能的時候，又該如何呢？

比如：

APP推薦分享功能，老用戶A將APP下載分享頁，分享到朋友圈，或微信好友，微博，新用戶B,C,D通過分享下載APP裝機并注冊，老用戶A獲得積分或其他獎勵。

類似問題，會成為產品經理的一道分水嶺，于我們而言，不只是想一些好的東西，還要有辦法將他實現，這需要我們對技術有一定的基礎認知。

常規的技術實現邏輯

幾乎所有的互聯網產品均會包含這四個環節，數據庫，后端，接口，前端。

但在某些產品里，可能會增加環節，或者用另一個方法來代替上圖的某個節點，也可以減少一些環節。

“數據庫”的存在就可以被“日志”來代替。

一款無需網絡支撐的“計算器”則只需要前端的功能支撐。

對于產品經理而言，我們有義務將一個idea轉化成可用代碼實現的方案，實際上這個轉化過程正是產品經理重要技能的一環。

不僅僅是想到需求，還要確保需求可被實現。

對于互聯網產品而言，一個idea一般都會牽扯到這4個環節，我們以登錄為例。

這是一個簡易的泳道圖，我們可以這樣來解讀這幅登錄的泳道圖。

用戶在前端執行了登錄的操作

前端通過接口，將用戶輸入的帳號和密碼上傳到后端

后端將這些信息與數據庫的用戶信息表進行匹配

后端將匹配結果通過接口返回給前端

前端根據后端返回的信息來確定下一步是成功還是失敗。

擴展

我們所說的異常保護，就是在上述的過程中，每一個環節都有可能出現錯誤，

我們無法將所有的錯誤都進行預設，通常會將異常做分類。

沒有返回以及返回的信息，不是“對”，也不是“錯”

一個登錄功能，除了我們所看見的登錄成功，登錄失敗，還會有請求失敗，請求錯誤這兩個“功能需求”。

對于登錄這類比較常規并且固定的功能，產品不需要過細的思考，但在一些個性化比較強的需求處理時，我們就需要將他盡可能的貼近實現方案。

復雜需求

案例:

APP推薦分享功能，老用戶A將APP下載分享頁，分享到朋友圈，或微信好友，微博，新用戶B,C,D通過分享下載APP裝機并注冊，老用戶A獲得積分或其他獎勵。

這個是基于分享的泳道圖，他能滿足我們分享的需求，但顯然，這不能完成案例中的復雜邏輯。我們來看看另外一副泳道圖.

這個圖補充了B用戶在微信打開被分享出來的鏈接所對應的操作，但是這任然是不夠的。

我們再來看看案例：

老用戶A將APP下載分享頁，分享到朋友圈，或微信好友，微博，新用戶B,C,D通過分享下載APP裝機并注冊，老用戶A獲得積分或其他獎勵。

我們還有幾個問題沒解決

我們如何知道B用戶打開的是A用戶分享出來的網頁呢？

我們怎么知道訪問的人，下載的人，注冊的人是同一個人呢？（條件是B下載裝機并注冊，A才獲得積分）

第一個問題很好解決，A用戶分享出去時，將用戶的profile信息一起傳給后端就可以記錄下，“誰分享的”

同時，在B用戶訪問時，我們也去記錄下訪問人的信息.

微信提供了這樣的支撐能力，在用戶訪問一個H5鏈接時，我們可以獲得訪問用戶的微信ipen ID，這樣就能知道誰訪問了。

走到這一步，我們已經能夠將這個案例實現大部分了。

A用戶將下載頁分享到微信，B用戶訪問了A分享的下載頁，并做了下載動作。

第二個問題怎么辦呢？

我們怎么知道訪問的人，下載的人，注冊的人是同一個人呢？（條件是B下載裝機并注冊，A才獲得積分）

（文章里已經用了較多的泳道圖了，后面就不再貼圖啦，大家可以自己畫一畫）

我們在微信環境所記錄的訪問ID ，是以微信提供的Open ID 作為唯一標識的。

第二個問題實際上是我們沒有辦法將Open ID 與用戶注冊時生成的User ID進行關聯。

我們無法知道一個新注冊的用戶，是從哪里下載的。

然后

我很喜歡一句電影臺詞：如果不是喜劇結尾，那是因為電影還未完結。

我們設計到這里，已經能夠發現問題了，那就能夠找到問題的解決方案。

解決問題，產品經理應該是專業級的。

解決方案（參考）

我們要做的是將注冊ID與訪問用戶的openID進行關聯，中間欠缺一個可鏈接的橋梁。

于是，我們可以建設另一個橋梁，來起到替代作用。

可以在下載頁做一個活動，

每次用戶訪問這個頁面時顯示一個處理后的參數，這個參數是根據計算得到的，就像微信的open ID 一樣。

訪問者ID加上分享者ID再加上一些其他的參數，生成一個新的參數，具備唯一性，我們可以將其稱為幸運ID。

B用戶只要在注冊過程中，甚至注冊以后的正常使用過程中，輸入這個幸運ID，就能建立起這道橋梁。

這樣我們就可以完整的實現案例的場景了。

1.通過記錄分享者的user ID， 我們可以知道某個H5是A分享出去的

2.通過記錄訪問者的open ID ,我們可以知道是B打開了A分享的網頁

3.通過幸運ID，我們能知道B用戶是通過A分享出來的網頁下載并注冊的。

現在的問題在于，如何讓用戶輸入“幸運ID”

這個問題是不是變得簡單了？

我們只是需要尋找一個能夠讓用戶輸入“幸運ID”的動機就好啦。

比如，

輸入幸運ID，看看哪些朋友也在用

輸入幸運ID，領取紅包

輸入幸運ID，可以抽獎

結局

這并不是唯一的解決辦法，實際上很多需求都可以用不同的實現方法來解決。

案例中的問題，我也沒有將其完全描述出來，相信還剩下許多細節問題，留給大家思考。

工作過程中，我們經常會遇到非常棒的想法，但卻無法將他實現出來，研發會向我們反饋“技術無法實現”。

據我了解，很多時候的“技術無法實現”是指無法實現這個方案，往往，我們換一個方案就可以實現了。

這就需要我們具備一定的技術認知，能夠考慮到技術如何實現，他的思路邏輯是怎么樣的。

案例中有一個小的細節，我們通過微信的open ID 來知道訪問者是誰，

如果沒有這個open ID,那么這套方案就是“無法實現”的。

小故事

PM：

我想知道有多少人在QQ訪問了我們的網頁

研發：

這做不到，我只能幫你查查被打開了多少次，我不知道是“誰”訪問了網頁，因為他沒有登錄。

（沒有記錄“人”，就沒辦法知道“多少人”訪問）

PM：

哦 好吧。

PM：

我們可以用QQ的第三方登錄嗎，這樣用戶在QQ訪問時，QQ就會把用戶的信息傳給我們。

研發:

這樣就沒問題了，但你需要提一個需求，以前的數據就沒辦法了，這個需求實現以后，就可以統計了。

PM：

好吧我去提個需求。

新需求：用戶在QQ訪問網頁時，需要使用QQ提供的一鍵登錄。

（解決了想知道多少人訪問的“需要”）

我是小硅，文中的案例來源于一位朋友在QQ群的提問，我正在四處收集問題。

如果你在工作過程中遇到了各種各樣的問題，來硅谷堂公眾號告訴我們吧。

作者： 枯葉

來源： 枯葉咖啡館

本文已獲授權，如需轉載請聯系原出處

END