算法是不是產(chǎn)品經(jīng)理該考慮的？作者答曰：是。

知乎上有個問題如下：

經(jīng)常被研發(fā)同事問倒，這個功能應(yīng)該怎么做呢？算法問題應(yīng)該是實現(xiàn)層面的問題了，不知道各位在實際過程中的經(jīng)驗是怎么樣的。其實職能本來沒有一個特別清晰的界定，但是一定有最效率的方式。這么說太虛了，舉個例子，比如，產(chǎn)品需要根據(jù)用戶添加“喜歡”的內(nèi)容向用戶推送用戶喜歡的內(nèi)容，就是一個“猜”的功能，那么這個猜出來的內(nèi)容是怎么算出來的，這個算法。

我的回答是：

去年在點我達，我接手了調(diào)度模塊的設(shè)計，有幾個月時間一直在搭建產(chǎn)品框架和協(xié)作流程。在此之前，調(diào)度的產(chǎn)品、算法以及除了開發(fā)的方方面面，都只由一個同事負責(zé)。

與此同時，公司成立了算法研究院，請來了機器學(xué)習(xí)相關(guān)的博士，負責(zé)以調(diào)度為主的各項算法的設(shè)計。

于是原本從接受需求、設(shè)計功能，到研究算法、跟進實施的步驟，拆分成了兩塊：我?guī)У恼{(diào)度產(chǎn)品組負責(zé)調(diào)度產(chǎn)品，而研究員團隊負責(zé)調(diào)度算法。

現(xiàn)在的協(xié)作流程大概是這樣的：

1. 需求方提出需求

例如，運營的同事認為，鮮花訂單的派單形式要有新的產(chǎn)品和算法支撐。這里講一下背景。我們的即時物流平臺會有外賣、商超、快遞、鮮花等一系列類型的訂單，其中外賣訂單是比較核心的，我們做的也比較久，因此很多產(chǎn)品模塊包括調(diào)度的設(shè)計，都是適應(yīng)外賣場景的。當(dāng)時鮮花則是相對新的業(yè)務(wù)。

2. 產(chǎn)品經(jīng)理承接需求，并抽象

我們小組的同事小 C 接到了這個需求，于是跟運營的同事多次溝通討論需求背景，以及跟相關(guān)的其他同事（比如銷售、商務(wù)的同事，以及騎手）確認實際場景。最終，抽象出算法問題。

比如，以下就是典型的算法問題描述：

在時效要求不高（以天為單位，而外賣是 1 小時內(nèi)送達）、起點集聚終點分散（外賣的起點終點都是分散的）、每個騎手可攜帶鮮花訂單數(shù)量為 n （外賣的上限 m < n）的前提下，應(yīng)該如何基于外賣調(diào)度邏輯來設(shè)計鮮花調(diào)度邏輯。

3. 算法研究員承接算法需求，解決算法課題

算法研究員常博接受了算法需求，于是會把產(chǎn)品經(jīng)理的描述再抽象一層，變成約束條件下的最優(yōu)派單策略。以這些可量化的指標，就可以搭建起算法模型，依據(jù)已有的歷史數(shù)據(jù)，來跑出最合理的算法策略以及相關(guān)的參數(shù)設(shè)置。當(dāng)然，在此過程中，不免會與小 C 和運營的同事持續(xù)溝通，有許多策略涉及的因素，比如在產(chǎn)品邏輯中的耦合性、比如在具體業(yè)務(wù)場景中的合理性，都要做大量探討。

像下圖就是典型的算法描述（是我們已棄用的一個算法）：

4. 產(chǎn)品經(jīng)理整合算法模型成為產(chǎn)品功能

此后，小 C 會考慮模型的細節(jié)，然后就跟把引擎裝入發(fā)動機一樣，設(shè)計出模型相關(guān)的配套產(chǎn)品功能。真正的需求文檔會是算法文檔長度的幾倍甚至十幾倍。后續(xù)就會跟技術(shù)協(xié)作，跟進研發(fā)。過程中也是會跟常博經(jīng)常溝通，但在此階段負責(zé)人始終是小 C。

這種協(xié)作模式可以算是一種可參考的模板。我們運行了半年多，一直沒有問題，而且雙方的協(xié)作極少有模糊地帶。

那么回到題主的問題?？赡墁F(xiàn)在沒有專職的算法研究員，那么產(chǎn)品和研發(fā)直接協(xié)作該怎么辦？

就推送喜歡的內(nèi)容這個需求來說，首先，需求的目的、背景是產(chǎn)品經(jīng)理要搞清楚的。推薦這些內(nèi)容，是為了什么？淺顯的目的是為了讓用戶點擊，那背后相關(guān)的需求是什么？是現(xiàn)在用戶活躍度比較低、是用戶發(fā)掘優(yōu)質(zhì)內(nèi)容的路徑過長，還是并不清楚老板說好像大家都有那就做吧？

其次，最關(guān)鍵的，需求的實現(xiàn)方式是產(chǎn)品經(jīng)理要搞清楚的。需求和算法是兩個層面的事情，作為產(chǎn)品經(jīng)理不能丟給研發(fā)說「做個推薦」就行了。顯然，推薦不是一種具體的算法課題。就好像告訴研發(fā)說「做個個人中心頁面」一樣不具體，這個頁面應(yīng)該有什么、要達到什么效果，跟其他功能的邏輯關(guān)系……都是產(chǎn)品經(jīng)理要考慮的。

就推薦來說，是基于什么數(shù)據(jù)做推薦呢？用戶的歷史瀏覽、用戶的已有關(guān)注、用戶的資料畫像，還是用戶的社交關(guān)系？即使作為產(chǎn)品經(jīng)理，你不清楚基于規(guī)則、基于內(nèi)容和協(xié)同過濾都是什么概念，你也要知道推薦不是憑空做的，是要根據(jù)具體的數(shù)據(jù)做分析的。

一個合理的梳理結(jié)果就像前文提到的，應(yīng)該是類似于：「基于用戶已有關(guān)注對象的類型和這些對象發(fā)布內(nèi)容的特征，來推薦更多同類的關(guān)注」或者「基于用戶目前的社交關(guān)系和相關(guān)的互動情況，推薦更多他可能喜歡的用戶」。

再之后，是跟研發(fā)搞清楚，所給出數(shù)據(jù)的意義（比如相關(guān)因素的權(quán)重），以及溝通邏輯上的合理性。比如，拿基于社交關(guān)系的推薦來說，用戶 A 給用戶 B 經(jīng)常點贊意味著什么？用戶 A 跟用戶 C 每周有 15 次互動意味著什么？用戶 A 拉黑了用戶 D 意味著什么？這些不是算法課題！這些是產(chǎn)品經(jīng)理應(yīng)該以自己對用戶或主觀或客觀的感知，得出的功能判斷。

然后是建模。在這里確實有一個模糊地帶，如果是非常懶的研發(fā)，不愿意自己研究算法課題、自己建模，是有點尷尬。在職責(zé)劃分上，坦率地說有計算機背景的研發(fā)做建模和算法研究會更合理一些。但如果是我，我會很開心有往前多走一步的機會。如果把這件事做好，就相當(dāng)于多了一項不錯的核心競爭力（可以想象未來懂算法、懂機器學(xué)習(xí)的產(chǎn)品經(jīng)理會越來越吃香），也許會大大有利于你在公司甚至未來市場上的競爭力。

即使是你并不想有這項核心競爭力，在爭執(zhí)不下的場景中，我也建議你暫時把這個任務(wù)做起來。畢竟產(chǎn)品經(jīng)理是要為產(chǎn)品的方方面面負（tian）責(zé)（keng）的，產(chǎn)品因為任何問題沒有如期完成，產(chǎn)品經(jīng)理都跑不了。

接下來就是根據(jù)建模的結(jié)果，梳理功能了。推薦當(dāng)然不是簡單的建模而已，具體什么時間節(jié)點收集用戶信息？在什么功能模塊下推送給用戶？推送的數(shù)量有沒有限制？展示交互和界面都是怎樣的？這也都是產(chǎn)品經(jīng)理要整理好的。

最后，具體用什么樣的代碼、什么樣的系統(tǒng)框架來實現(xiàn)，那就是研發(fā)的事情了。

大致來看，就是這樣的：

從題主的描述看，其實有點像省掉了「需求抽象」和「功能設(shè)計」的步驟，認為這純粹是個算法課題，需求來了就硬生生扔給研發(fā)，等待產(chǎn)品出爐了。我覺得這是不太合理的。

前文提到了，在點我達初期，實際上所有實現(xiàn)之前的步驟，都是由我一位同事完成的。這也是我推薦的方式。

歇歇。

#專欄作家#

劉飛，微信公眾號：劉言飛語，人人都是產(chǎn)品經(jīng)理專欄作家?；ヂ?lián)網(wǎng)產(chǎn)品經(jīng)理，先后在錘子科技、嘟嘟美甲和點我吧任產(chǎn)品經(jīng)理，知乎產(chǎn)品經(jīng)理領(lǐng)域最佳回答者之一。豆瓣閱讀《最好的時代》作者。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，不得轉(zhuǎn)載。