一樱调、產(chǎn)品經(jīng)理要不要懂技術(shù)祖娘？

大家通常提到的產(chǎn)品經(jīng)理油啤，除了常規(guī)意義上全權(quán)負(fù)責(zé)產(chǎn)品的產(chǎn)品經(jīng)理之外锥忿，還有產(chǎn)品設(shè)計師在岂、用戶體驗(yàn)產(chǎn)品經(jīng)理嘴瓤，以及后臺產(chǎn)品經(jīng)理场梆、需求分析師等很多種摹芙。不同的公司日月，產(chǎn)品經(jīng)理負(fù)責(zé)的事務(wù)也各不相同袱瓮。

從行業(yè)角度，也可以分為技術(shù)型產(chǎn)品的 PM爱咬、設(shè)計型產(chǎn)品的 PM尺借、運(yùn)營導(dǎo)向產(chǎn)品的 PM。再細(xì)一點(diǎn)劃分精拟，還可以分出電商產(chǎn)品的 PM燎斩、社交產(chǎn)品的PM或者搜索產(chǎn)品的 PM等虱歪。在某招聘網(wǎng)站上，產(chǎn)品經(jīng)理的常見分類就有很多種栅表，如圖7-1所示笋鄙。每種產(chǎn)品對應(yīng)的產(chǎn)品經(jīng)理所需要的技術(shù)知識有所不同。百度搜索的產(chǎn)品經(jīng)理不可能對搜索算法不敏感怪瓶。而在產(chǎn)品實(shí)現(xiàn)并不困難的情況下萧落，或者說在非技術(shù)因素更重的產(chǎn)品中，可能就不太需要了解太多技術(shù)背景洗贰。

image.png

我們在寫簡歷的時候都知道有一種寫法是把技能描述成“精通”找岖、“掌握”、“了解”等敛滋，其實(shí)這樣寫沒有意義宣增，因?yàn)楦窘忉尣磺宄銓寄艿恼莆粘潭取Ｈ绻f精通PS矛缨，到底是精通到可以手繪出蒙娜麗莎爹脾，還是精通到可以給女朋友修個照片而已呢？我們需要的是實(shí)際的描述箕昭。

同理灵妨，“懂”這個詞也可以解釋成很多行為。知道Java和C++的區(qū)別算不算懂落竹？可以設(shè)計數(shù)據(jù)結(jié)構(gòu)和一些算法算不算懂泌霍？能夠自己馬上實(shí)現(xiàn)所有代碼算不算懂？最淺層次的“懂”述召，是任何產(chǎn)品經(jīng)理都應(yīng)該達(dá)到的朱转。很多產(chǎn)品經(jīng)理居然都不知道自己產(chǎn)品的后臺是用什么語言寫的，也不知道 API是什么意思积暖，更不知道產(chǎn)品包含的所有數(shù)據(jù)是怎樣流通的藤为。而比較高層次的“懂”，到底是不是需要懂得讀代碼夺刑、寫代碼缅疟，則要看實(shí)際情況了。

“技術(shù)”到底是什么呢遍愿？大多數(shù)人只會把技術(shù)理解成代碼存淫，是在編輯器里一行一行敲出來的東西，以為敲得越快代表寫得越好沼填。但其實(shí)還有很多純技術(shù)的工作并不是單純地實(shí)現(xiàn)軟件桅咆。我的理解是，任何產(chǎn)品工作中接觸到的技術(shù)都應(yīng)該算作產(chǎn)品經(jīng)理“有可能”需要了解和學(xué)習(xí)的技術(shù)坞笙。包括算法岩饼、技術(shù)邏輯刽脖、數(shù)據(jù)結(jié)構(gòu)、架構(gòu)忌愚、整體框架等曲管，只說代碼實(shí)現(xiàn)反而是比較次要的。

總的來說硕糊，產(chǎn)品經(jīng)理一定要懂技術(shù)院水，具體懂到什么程度要看“需要”。不同的產(chǎn)品經(jīng)理負(fù)責(zé)的事情不同简十，接觸到的技術(shù)也不同檬某，所以要清楚哪些事情是需要了解的。比如之前在做安卓操作系統(tǒng)的時候螟蝙，我們會對原生系統(tǒng)提供的一些可復(fù)用的模塊很熟悉恢恼，這樣我們會設(shè)計出成本更低的方案；在做上門美甲及現(xiàn)在的眾包物流時胰默，我們會跟開發(fā)的同事一起設(shè)計訂單邏輯和數(shù)據(jù)結(jié)構(gòu)场斑，因?yàn)檫@些既跟具體實(shí)現(xiàn)的方法有關(guān)系，也跟用戶對產(chǎn)品的使用效率有關(guān)系牵署。

這些可以算作技術(shù)漏隐，卻并不是日常生活里理解的“用C語言寫一個排序”那樣的技術(shù)。比較讓人頭疼的是奴迅，很多人問“產(chǎn)品經(jīng)理是不是需要懂技術(shù)”的問題時青责，腦海里想的是“下個星期要不要報個Java學(xué)習(xí)班或者買本《7天學(xué)會安卓開發(fā)》”，這樣的想法是很荒謬的取具。

二脖隶、好的文檔到底是什么樣的？

不同公司的產(chǎn)品文檔差別很大暇检。草創(chuàng)階段公司的文檔就是幾頁紙产阱，標(biāo)注著整體的邏輯、描述功能細(xì)節(jié)占哟。而在諸如BAT這樣的大廠的主產(chǎn)品心墅，一個小的產(chǎn)品改動可能就要經(jīng)歷BRD、MRD和PRD榨乎。我們?nèi)ピu判到底哪種格式正確，就好像討論哪種口紅顏色最好看一樣瘫筐，沒有意義蜜暑。口紅要看涂在誰的唇上策肝，如同文檔要看用在怎樣的項(xiàng)目中肛捍。

了解過很多產(chǎn)品經(jīng)理的文檔格式隐绵，也使用過很多不同的文檔格式，但想對“好的”產(chǎn)品文檔下個定義拙毫，還真的很難依许。一個檢驗(yàn)方法：能夠減少甚至免除在開發(fā)過程中技術(shù)人員跟產(chǎn)品經(jīng)理溝通的文檔就是好的文檔。

這是基于文檔的根本意義的檢驗(yàn)缀蹄。嚴(yán)格來說峭跳，文檔不是必須的，完全可以不寫缺前，只需要產(chǎn)品經(jīng)理不斷跟技術(shù)的同事溝通蛀醉、時刻跟進(jìn)研發(fā)的每個步驟，產(chǎn)品做出來自然都是沒有問題的衅码。但這個過程效率太低了拯刁。而文檔的作用就是為了高效地傳遞產(chǎn)品經(jīng)理對產(chǎn)品功能的描述并予以記錄。為什么“不好”的文檔并不能讓成本降低逝段？因?yàn)檫@些文檔里對功能的描述不清楚垛玻、對細(xì)節(jié)邏輯梳理不清楚或者存在很多缺漏，導(dǎo)致技術(shù)的同事在依照文檔進(jìn)行開發(fā)時奶躯，不斷找產(chǎn)品經(jīng)理核對或者要求補(bǔ)充夭谤。

優(yōu)質(zhì)的產(chǎn)品文檔就應(yīng)該是提交給技術(shù)研發(fā)的同事后，再也不用來回確認(rèn)溝通的巫糙。由于現(xiàn)實(shí)因素這幾乎不可能實(shí)現(xiàn)朗儒，不過我們要盡力做到可以讓需要確認(rèn)的情況減少。

有了這條準(zhǔn)則参淹，我們就可以嘗試抽象出“好的”文檔應(yīng)當(dāng)滿足的幾個條件醉锄。

1.沒有邏輯硬傷

“硬傷”指文檔的內(nèi)容前后不一或者邏輯不通。一旦有硬傷出現(xiàn)浙值，那么文檔顯然就不可用恳不，技術(shù)的同事會搞不清楚到底該怎么做。

2.沒有疏漏

有經(jīng)驗(yàn)的產(chǎn)品經(jīng)理出現(xiàn)硬傷的幾率不大开呐，但疏漏的可能還是有的烟勋。一個功能牽連的信息和邏輯越多就越會有考慮不周全的地方，沒有定義清楚細(xì)節(jié)筐付，讓技術(shù)的同事開發(fā)到一半卵惦，發(fā)現(xiàn)有的功能應(yīng)當(dāng)有但沒描述，只好再找產(chǎn)品經(jīng)理要求補(bǔ)充瓦戚。

3.邏輯清晰

有的文檔內(nèi)容零散會給技術(shù)的同事造成困擾沮尿，看過很多遍也不知道如何下手。產(chǎn)品設(shè)計可以松散较解，但技術(shù)人員開發(fā)時如果不先從全局出發(fā)定義問題就無法展開工作畜疾，這是需要產(chǎn)品經(jīng)理盡量在文檔里配合的赴邻。

4.可讀性強(qiáng)

很多產(chǎn)品經(jīng)理只是考慮把事情說出來，而不是友好地說出來啡捶。有很多數(shù)據(jù)姥敛、信息、流程的展現(xiàn)用圖表更清楚瞎暑，但因?yàn)閼械米鐾玻蛶仔凶终f一下，大大增加了理解成本金顿。有很多名詞臊泌、解釋都說得模棱兩可、難以理解揍拆，以致在后續(xù)發(fā)展過程中還要反復(fù)向產(chǎn)品經(jīng)理確認(rèn)（多說一句渠概，有可能被誤解的名詞最好在文檔開頭予以解釋）。

只要滿足以上四點(diǎn)嫂拴，具體的展現(xiàn)方式就不是最重要的了播揪。

我們知道產(chǎn)品經(jīng)理不僅僅是要理解用戶的需求，還要配合好技術(shù)的同事理解他們的需求筒狠。產(chǎn)品人員需要能夠輸出給他們有效猪狈、友好的具體功能描述。要達(dá)到這個要求辩恼，就要對技術(shù)層面的很多事有初步的理解雇庙，也要知道產(chǎn)品功能的實(shí)現(xiàn)邏輯、數(shù)據(jù)的結(jié)構(gòu)和信息流灶伊。

圖7-2中上方的圖示疆前，是很多產(chǎn)品經(jīng)理自認(rèn)為所處的位置。對于他們來說聘萨，產(chǎn)品經(jīng)理主要就是跟用戶頻繁交互竹椒、跟用戶打交道，發(fā)掘需求并設(shè)計功能米辐。這是最核心的部分胸完，而不會特別關(guān)心輸出。需求文檔只是單向描述設(shè)計時的結(jié)果翘贮。

圖7-2中下方的圖示赊窥，則是我認(rèn)為更合理的表述。對于產(chǎn)品經(jīng)理择膝，輸入是不斷跟用戶產(chǎn)生互動誓琼，那輸出就是不斷跟技術(shù)研發(fā)人員產(chǎn)生互動。在互動中肴捉，完成需求分析腹侣、產(chǎn)品功能設(shè)計及協(xié)助產(chǎn)品實(shí)現(xiàn)的工作，前后兩端同樣重要齿穗。只關(guān)注用戶的輸入?yún)s不關(guān)注技術(shù)研發(fā)那端的輸出就會失衡傲隶。

image.png

三、文檔邏輯

剛才從寫文檔一事引出來了關(guān)于功能框架窃页、信息流程這樣的話題跺株。我們在討論問題、設(shè)計功能時要清楚這些邏輯脖卖，而文檔就是這些邏輯最后體現(xiàn)出的載體乒省。

在功能設(shè)計中，需要有三種邏輯關(guān)系是特別清晰的畦木。它們分別是功能框架的邏輯袖扛、業(yè)務(wù)流程的邏輯，以及功能描述的邏輯十籍。

1.功能框架的邏輯

對于很多創(chuàng)意型的產(chǎn)品經(jīng)理蛆封，“結(jié)構(gòu)”、“框架”這些詞看起來遙不可及勾栗。但任何事物一旦有復(fù)雜度惨篱，就必須在功能架構(gòu)上清晰無誤。如果不劃分結(jié)構(gòu)围俘，分工就無法開展砸讳。像淘寶這樣的巨型產(chǎn)品，幾千人甚至上萬人在這個產(chǎn)品上做工作界牡，必須有清楚的責(zé)任分工和協(xié)作方法簿寂。

在產(chǎn)品設(shè)計上劃分結(jié)構(gòu)、搭建基本框架欢揖，更有利于產(chǎn)品思路的梳理陶耍，也能夠由此衍生出合適的功能。對于研發(fā)部門也有意義她混，他們也可以以此框架解耦開發(fā)烈钞，以防把所有功能都做的糾纏不清。

那到底怎么才算有清晰的框架和結(jié)構(gòu)呢坤按？我們又該如何梳理呢毯欣？

? 拆分

要進(jìn)行整合，就要先拆分臭脓。把產(chǎn)品的功能（或者預(yù)期有的功能）枚舉出來酗钞，拆分成相對獨(dú)立的模塊，這是第一步。比如砚作，我們準(zhǔn)備做一個純粹的電商產(chǎn)品窘奏，沒有其他的屬性。那針對消費(fèi)者也就是買家這一端葫录，我們可以枚舉出有很多要做的功能着裹，如圖7-3所示。將能想到的可能有的功能都在其中了米同，那就是拆分完成了骇扇。

image.png

? 組合

接下來，我們就可以把剛才羅列的電商產(chǎn)品功能予以組合面粮。比如少孝，商品本身相關(guān)的幾個功能，介紹熬苍、類目稍走、屬性可以歸在商品模塊里。優(yōu)惠券冷溃、贈品這些營銷相關(guān)的組合在一起钱磅。最終，我們就得到了大致分開的幾個模塊似枕，如圖7-4所示盖淡。有了導(dǎo)購、商品凿歼、交易支付褪迟、營銷、售后答憔、個人中心六個模塊味赃，我們就對消費(fèi)者端的產(chǎn)品結(jié)構(gòu)一目了然了。而且未來相關(guān)的功能虐拓，我們都可以在其中找到合適的位置心俗。

image.png

對于任意產(chǎn)品都可以用類似方法拆分組合，整理出應(yīng)有的模塊劃分蓉驹，它們比較現(xiàn)實(shí)的意義是方便開發(fā)城榛，以及方便產(chǎn)品經(jīng)理自己分工。

圖7-5是眾包物流平臺“點(diǎn)我達(dá)”商家端的結(jié)構(gòu)劃分态兴，基于這種劃分狠持，將不同的模塊劃歸給不同的同事負(fù)責(zé)，這樣每個模塊的不同功能都能確保由熟悉前后邏輯的同一個人完成瞻润。

image.png

2.業(yè)務(wù)流程的邏輯

業(yè)務(wù)流程在這里指的是喘垂，產(chǎn)品所提供的功能或者服務(wù)實(shí)現(xiàn)的具體流程步驟甜刻。很多產(chǎn)品都有不止一個功能，對這個功能的使用涉及很多步驟正勒，并非是一次性的操作得院。比如電商、O2O常見的訂單流程的流轉(zhuǎn)就是由很多相關(guān)聯(lián)的功能和互相流通的數(shù)據(jù)來完成的昭齐。

這里可以從兩個維度去分析尿招，一是面向事件的矾柜，二是面向?qū)ο蟮摹?/p>

3.面向事件

面向事件指的是阱驾，要完成一件事可能會進(jìn)行很多次操作。而在這些步驟中要整理出健全的流程怪蔑，邏輯清楚且不存在缺漏里覆。一般情況下，我們使用流程圖來描述面向事件的流程步驟缆瓣。

比如喧枷，在物流平臺產(chǎn)品上提供了投訴的功能，配送員（騎手）可以通過該功能來對違反平臺規(guī)則的配送員或商家進(jìn)行投訴弓坞。

整個投訴的流程涉及App端和工單系統(tǒng)隧甚，而且整個投訴事件的生命周期是 App-工單-App這樣的，所以就要整理出整個過程的邏輯渡冻。最終設(shè)計的流程圖如圖7-6所示戚扳。可以看到族吻，不僅使用了常規(guī)流程圖帽借，還加入了“泳道”，可以直觀看到是在哪里處理投訴的信息超歌、完成投訴的流程砍艾。

image.png

4.面向?qū)ο?/h4>

面向?qū)ο螅傅氖菍ο蟮纳芷诖碇淮瓮暾墓δ苁褂梦【佟Ｗ畛Ｒ姷木褪怯唵未嗪桑瑥漠a(chǎn)生到消失（注銷）會有很多狀態(tài)的情況，要考察清楚狀態(tài)的轉(zhuǎn)化條件和流程懊悯，通常會用狀態(tài)轉(zhuǎn)化圖來表現(xiàn)蜓谋。

比如，圖7-8是美甲產(chǎn)品的第一個版本時所設(shè)計的訂單狀態(tài)轉(zhuǎn)化示意圖定枷。只有把完整的狀態(tài)轉(zhuǎn)化列清楚孤澎，才可能知道會不會有狀態(tài)缺漏，狀態(tài)是否合理欠窒。更重要的是確認(rèn)邏輯是否完備覆旭，以及讓技術(shù)開發(fā)的同事知道如何去實(shí)現(xiàn)訂單的流程退子。

image.png

5.功能描述的邏輯

對于一個功能設(shè)計出方案，并不意味著可以邏輯完整地描述清楚型将。而且對于功能方案寂祥，我們無論多么謹(jǐn)慎也總是有存在錯漏的地方。所以在描述功能時七兜，用各種方法盡量捋順邏輯丸凭，把內(nèi)容更有條理、更完整地描述清楚腕铸，可以避免很多問題惜犀。

比如眾包物流產(chǎn)品在設(shè)計配送員取消訂單時，要使用一套取消的邏輯狠裹，包含有扣罰款虽界、扣額度等。在不同的情況下涛菠，給配送員的提示（內(nèi)容也就是實(shí)際執(zhí)行的操作）都是不同的莉御，為了完整描述每種情況，用表格的形式展示俗冻，如圖7-9所示礁叔。

image.png

有很多方法能夠達(dá)到同樣的目的，比如可以講述扣額度的定義迄薄，然后說明“提示時根據(jù)不同情況提醒用戶目前額度的情況”琅关，但這對于開發(fā)的同事來說是不具體、不清晰的功能描述噪奄。他們拿到這樣的功能描述必須要自行再處理一遍死姚，才能變成可開發(fā)的內(nèi)容。

總結(jié)來看勤篮，在描述功能時有以下幾點(diǎn)要注意：

? 完整

盡量枚舉所有的情況都毒，并且分情況詳述功能內(nèi)容。最好從某個維度碰缔，比如業(yè)務(wù)的發(fā)生账劲、進(jìn)行的流程、訂單狀態(tài)變化的轉(zhuǎn)換等關(guān)注功能變化的情況金抡，以防漏掉什么特殊情況瀑焦。對正常流程來說，可能是像圖 7-10左側(cè)的情況梗肝，但對于一個完整的榛瓮、考慮到任何情況的功能描述來說會是圖 7-10右側(cè)的情況。

image.png

如果相關(guān)的情況比較多要描述的內(nèi)容比較復(fù)雜巫击，就用表格展示禀晓。

? 考慮到所有影響點(diǎn)

產(chǎn)品越大精续、功能越多，就越有可能存在牽一發(fā)而動全身的改動粹懒。對任何改動重付，即使再小都可能牽扯到其他的地方，所以要特別注意凫乖。還是舉眾包物流平臺的例子确垫，在更新配送員收入規(guī)則的時候，我們只關(guān)注了訂單頁面和個人賬戶頁面的收入描述帽芽，臨近上線時才發(fā)現(xiàn)在幫助頁中的某個大家都遺忘了的子頁面里還有收入規(guī)則的描述删掀，于是臨時緊急改掉。所幸工作量很小嚣镜，沒出太多問題爬迟，不然鬧起糾紛來，又是一樁麻煩事菊匿。

? 條件判斷清晰

條件判斷要足夠清晰，是在什么條件下有什么樣的功能计福，或者在怎樣的條件下觸發(fā)怎樣的特殊功能都要羅列清晰跌捆。這里可以參考編程語言中很常見的if/else、while象颖、switch等幾種邏輯描述佩厚。

? 含義明確

不要用模棱兩可的詞來描述功能，也不要用未定義清楚的詞造成混淆说订。著名的硅谷創(chuàng)業(yè)者抄瓦、SpaceX的老板馬斯克曾經(jīng)被很多看不懂的工程師們自創(chuàng)的縮寫詞搞得很惱火，于是發(fā)了一封郵件說：“除非得到我的批準(zhǔn)陶冷，其他縮寫詞不能列入SpaceX的詞匯表钙姊。例如，測試架不應(yīng)該有‘HTS’或‘VTS’這樣的稱呼埂伦，這討厭的縮寫版本事實(shí)上比原詞更費(fèi)解……”雖然這條規(guī)定被員工戲稱為“A.S.S Rule”（狗屁規(guī)定）煞额，但這確實(shí)讓大家的溝通更加高效。

? 敘述背景

讓邏輯鏈條更完整的一個好方法是敘述功能產(chǎn)生的背景及它要達(dá)到的目的沾谜。在之前提到基于場景挖掘需求時膊毁，也提到了要讓整個團(tuán)隊(duì)關(guān)注需求發(fā)生的場景，這樣更容易讓他們理解產(chǎn)品基跑。

成長建議Ⅶ

產(chǎn)品方面的文檔并沒有統(tǒng)一的標(biāo)準(zhǔn)婚温。在大公司里能夠用既有的模板詳述方案是好的，在創(chuàng)業(yè)團(tuán)隊(duì)用簡陋的形式一頁圖紙就說清楚功能也是可以的媳否。對于文檔要講求邏輯照皆、內(nèi)容清晰频轿，在不同的團(tuán)隊(duì)里不同的協(xié)作方式中都是至關(guān)重要的疟丙。如果非要提供一種可用的需求文檔寫法，建議用如圖7-11所示的用例萄凤。

image.png

要點(diǎn)反思

? 了解技術(shù)是為了更好地設(shè)計功能和協(xié)作，并不是幫技術(shù)的同事完成工作搪哪。

? 不管文檔是什么形式靡努、篇幅如何，能讓開發(fā)人員們看得懂的就是好文檔晓折。

? 文檔的完整性惑朦、邏輯性比文檔的可讀性、美觀程度都重要漓概。