一、產(chǎn)品經(jīng)理要不要懂技術(shù)？
大家通常提到的產(chǎn)品經(jīng)理，除了常規(guī)意義上全權(quán)負(fù)責(zé)產(chǎn)品的產(chǎn)品經(jīng)理之外，還有產(chǎn)品設(shè)計(jì)師、用戶體驗(yàn)產(chǎn)品經(jīng)理，以及后臺(tái)產(chǎn)品經(jīng)理、需求分析師等很多種。不同的公司，產(chǎn)品經(jīng)理負(fù)責(zé)的事務(wù)也各不相同。
從行業(yè)角度，也可以分為技術(shù)型產(chǎn)品的 PM、設(shè)計(jì)型產(chǎn)品的 PM、運(yùn)營(yíng)導(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)品對(duì)應(yīng)的產(chǎn)品經(jīng)理所需要的技術(shù)知識(shí)有所不同。百度搜索的產(chǎn)品經(jīng)理不可能對(duì)搜索算法不敏感。而在產(chǎn)品實(shí)現(xiàn)并不困難的情況下，或者說在非技術(shù)因素更重的產(chǎn)品中，可能就不太需要了解太多技術(shù)背景。
我們?cè)趯懞?jiǎn)歷的時(shí)候都知道有一種寫法是把技能描述成“精通”、“掌握”、“了解”等，其實(shí)這樣寫沒有意義，因?yàn)楦窘忉尣磺宄銓?duì)技能的掌握程度。如果說精通PS，到底是精通到可以手繪出蒙娜麗莎，還是精通到可以給女朋友修個(gè)照片而已呢？我們需要的是實(shí)際的描述。
同理，“懂”這個(gè)詞也可以解釋成很多行為。知道Java和C++的區(qū)別算不算懂？可以設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)和一些算法算不算懂？能夠自己馬上實(shí)現(xiàn)所有代碼算不算懂？最淺層次的“懂”，是任何產(chǎn)品經(jīng)理都應(yīng)該達(dá)到的。很多產(chǎn)品經(jīng)理居然都不知道自己產(chǎn)品的后臺(tái)是用什么語言寫的，也不知道 API是什么意思，更不知道產(chǎn)品包含的所有數(shù)據(jù)是怎樣流通的。而比較高層次的“懂”，到底是不是需要懂得讀代碼、寫代碼，則要看實(shí)際情況了。
“技術(shù)”到底是什么呢？大多數(shù)人只會(huì)把技術(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)的時(shí)候，我們會(huì)對(duì)原生系統(tǒng)提供的一些可復(fù)用的模塊很熟悉，這樣我們會(huì)設(shè)計(jì)出成本更低的方案；在做上門美甲及現(xiàn)在的眾包物流時(shí)，我們會(huì)跟開發(fā)的同事一起設(shè)計(jì)訂單邏輯和數(shù)據(jù)結(jié)構(gòu)，因?yàn)檫@些既跟具體實(shí)現(xiàn)的方法有關(guān)系，也跟用戶對(duì)產(chǎn)品的使用效率有關(guān)系。
這些可以算作技術(shù)，卻并不是日常生活里理解的“用C語言寫一個(gè)排序”那樣的技術(shù)。比較讓人頭疼的是，很多人問“產(chǎn)品經(jīng)理是不是需要懂技術(shù)”的問題時(shí)，腦海里想的是“下個(gè)星期要不要報(bào)個(gè)Java學(xué)習(xí)班或者買本《7天學(xué)會(huì)安卓開發(fā)》”，這樣的想法是很荒謬的。
二、好的文檔到底是什么樣的？
不同公司的產(chǎn)品文檔差別很大。草創(chuàng)階段公司的文檔就是幾頁紙，標(biāo)注著整體的邏輯、描述功能細(xì)節(jié)。而在諸如BAT這樣的大廠的主產(chǎn)品，一個(gè)小的產(chǎn)品改動(dòng)可能就要經(jīng)歷BRD、MRD和PRD。我們?nèi)ピu(píng)判到底哪種格式正確，就好像討論哪種口紅顏色最好看一樣，沒有意義?？诩t要看涂在誰的唇上，如同文檔要看用在怎樣的項(xiàng)目中。
了解過很多產(chǎn)品經(jīng)理的文檔格式，也使用過很多不同的文檔格式，但想對(duì)“好的”產(chǎn)品文檔下個(gè)定義，還真的很難。一個(gè)檢驗(yàn)方法：能夠減少甚至免除在開發(fā)過程中技術(shù)人員跟產(chǎn)品經(jīng)理溝通的文檔就是好的文檔。
這是基于文檔的根本意義的檢驗(yàn)。嚴(yán)格來說，文檔不是必須的，完全可以不寫，只需要產(chǎn)品經(jīng)理不斷跟技術(shù)的同事溝通、時(shí)刻跟進(jìn)研發(fā)的每個(gè)步驟，產(chǎn)品做出來自然都是沒有問題的。但這個(gè)過程效率太低了。而文檔的作用就是為了高效地傳遞產(chǎn)品經(jīng)理對(duì)產(chǎn)品功能的描述并予以記錄。為什么“不好”的文檔并不能讓成本降低？因?yàn)檫@些文檔里對(duì)功能的描述不清楚、對(duì)細(xì)節(jié)邏輯梳理不清楚或者存在很多缺漏，導(dǎo)致技術(shù)的同事在依照文檔進(jìn)行開發(fā)時(shí)，不斷找產(chǎn)品經(jīng)理核對(duì)或者要求補(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)滿足的幾個(gè)條件。
1.沒有邏輯硬傷
“硬傷”指文檔的內(nèi)容前后不一或者邏輯不通。一旦有硬傷出現(xiàn)，那么文檔顯然就不可用，技術(shù)的同事會(huì)搞不清楚到底該怎么做。
2.沒有疏漏
有經(jīng)驗(yàn)的產(chǎn)品經(jīng)理出現(xiàn)硬傷的幾率不大，但疏漏的可能還是有的。一個(gè)功能牽連的信息和邏輯越多就越會(huì)有考慮不周全的地方，沒有定義清楚細(xì)節(jié)，讓技術(shù)的同事開發(fā)到一半，發(fā)現(xiàn)有的功能應(yīng)當(dāng)有但沒描述，只好再找產(chǎn)品經(jīng)理要求補(bǔ)充。
3.邏輯清晰
有的文檔內(nèi)容零散會(huì)給技術(shù)的同事造成困擾，看過很多遍也不知道如何下手。產(chǎn)品設(shè)計(jì)可以松散，但技術(shù)人員開發(fā)時(shí)如果不先從全局出發(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á)到這個(gè)要求，就要對(duì)技術(shù)層面的很多事有初步的理解，也要知道產(chǎn)品功能的實(shí)現(xiàn)邏輯、數(shù)據(jù)的結(jié)構(gòu)和信息流。
圖7-2中上方的圖示，是很多產(chǎn)品經(jīng)理自認(rèn)為所處的位置。對(duì)于他們來說，產(chǎn)品經(jīng)理主要就是跟用戶頻繁交互、跟用戶打交道，發(fā)掘需求并設(shè)計(jì)功能。這是最核心的部分，而不會(huì)特別關(guān)心輸出。需求文檔只是單向描述設(shè)計(jì)時(shí)的結(jié)果。
圖7-2中下方的圖示，則是我認(rèn)為更合理的表述。對(duì)于產(chǎn)品經(jīng)理，輸入是不斷跟用戶產(chǎn)生互動(dòng)，那輸出就是不斷跟技術(shù)研發(fā)人員產(chǎn)生互動(dòng)。在互動(dòng)中，完成需求分析、產(chǎn)品功能設(shè)計(jì)及協(xié)助產(chǎn)品實(shí)現(xiàn)的工作，前后兩端同樣重要。只關(guān)注用戶的輸入?yún)s不關(guān)注技術(shù)研發(fā)那端的輸出就會(huì)失衡。
三、文檔邏輯
剛才從寫文檔一事引出來了關(guān)于功能框架、信息流程這樣的話題。我們?cè)谟懻搯栴}、設(shè)計(jì)功能時(shí)要清楚這些邏輯，而文檔就是這些邏輯最后體現(xiàn)出的載體。
在功能設(shè)計(jì)中，需要有三種邏輯關(guān)系是特別清晰的。它們分別是功能框架的邏輯、業(yè)務(wù)流程的邏輯，以及功能描述的邏輯。
1.功能框架的邏輯
對(duì)于很多創(chuàng)意型的產(chǎn)品經(jīng)理，“結(jié)構(gòu)”、“框架”這些詞看起來遙不可及。但任何事物一旦有復(fù)雜度，就必須在功能架構(gòu)上清晰無誤。如果不劃分結(jié)構(gòu)，分工就無法開展。像淘寶這樣的巨型產(chǎn)品，幾千人甚至上萬人在這個(gè)產(chǎn)品上做工作，必須有清楚的責(zé)任分工和協(xié)作方法。
在產(chǎn)品設(shè)計(jì)上劃分結(jié)構(gòu)、搭建基本框架，更有利于產(chǎn)品思路的梳理，也能夠由此衍生出合適的功能。對(duì)于研發(fā)部門也有意義，他們也可以以此框架解耦開發(fā)，以防把所有功能都做的糾纏不清。
那到底怎么才算有清晰的框架和結(jié)構(gòu)呢？我們又該如何梳理呢？
? 拆分
要進(jìn)行整合，就要先拆分。把產(chǎn)品的功能（或者預(yù)期有的功能）枚舉出來，拆分成相對(duì)獨(dú)立的模塊，這是第一步。比如，我們準(zhǔn)備做一個(gè)純粹的電商產(chǎn)品，沒有其他的屬性。那針對(duì)消費(fèi)者也就是買家這一端，我們可以枚舉出有很多要做的功能，如圖7-3所示。將能想到的可能有的功能都在其中了，那就是拆分完成了。
? 組合
接下來，我們就可以把剛才羅列的電商產(chǎn)品功能予以組合。比如，商品本身相關(guān)的幾個(gè)功能，介紹、類目、屬性可以歸在商品模塊里。優(yōu)惠券、贈(zèng)品這些營(yíng)銷相關(guān)的組合在一起。最終，我們就得到了大致分開的幾個(gè)模塊，如圖7-4所示。有了導(dǎo)購、商品、交易支付、營(yíng)銷、售后、個(gè)人中心六個(gè)模塊，我們就對(duì)消費(fèi)者端的產(chǎn)品結(jié)構(gòu)一目了然了。而且未來相關(guān)的功能，我們都可以在其中找到合適的位置。
對(duì)于任意產(chǎn)品都可以用類似方法拆分組合，整理出應(yīng)有的模塊劃分，它們比較現(xiàn)實(shí)的意義是方便開發(fā)，以及方便產(chǎn)品經(jīng)理自己分工。
圖7-5是眾包物流平臺(tái)“點(diǎn)我達(dá)”商家端的結(jié)構(gòu)劃分，基于這種劃分，將不同的模塊劃歸給不同的同事負(fù)責(zé)，這樣每個(gè)模塊的不同功能都能確保由熟悉前后邏輯的同一個(gè)人完成。
2.業(yè)務(wù)流程的邏輯
業(yè)務(wù)流程在這里指的是，產(chǎn)品所提供的功能或者服務(wù)實(shí)現(xiàn)的具體流程步驟。很多產(chǎn)品都有不止一個(gè)功能，對(duì)這個(gè)功能的使用涉及很多步驟，并非是一次性的操作。比如電商、O2O常見的訂單流程的流轉(zhuǎn)就是由很多相關(guān)聯(lián)的功能和互相流通的數(shù)據(jù)來完成的。
這里可以從兩個(gè)維度去分析，一是面向事件的，二是面向?qū)ο蟮摹?/p>
3.面向事件
面向事件指的是，要完成一件事可能會(huì)進(jìn)行很多次操作。而在這些步驟中要整理出健全的流程，邏輯清楚且不存在缺漏。一般情況下，我們使用流程圖來描述面向事件的流程步驟。
比如，在物流平臺(tái)產(chǎn)品上提供了投訴的功能，配送員（騎手）可以通過該功能來對(duì)違反平臺(tái)規(guī)則的配送員或商家進(jìn)行投訴。
整個(gè)投訴的流程涉及App端和工單系統(tǒng)，而且整個(gè)投訴事件的生命周期是 App-工單-App這樣的，所以就要整理出整個(gè)過程的邏輯。最終設(shè)計(jì)的流程圖如圖7-6所示。可以看到，不僅使用了常規(guī)流程圖，還加入了“泳道”，可以直觀看到是在哪里處理投訴的信息、完成投訴的流程。
4.面向?qū)ο?/h4>
面向?qū)ο?，指的是?duì)象的生命周期代表著一次完整的功能使用。最常見的就是訂單，從產(chǎn)生到消失（注銷）會(huì)有很多狀態(tài)的情況，要考察清楚狀態(tài)的轉(zhuǎn)化條件和流程，通常會(huì)用狀態(tài)轉(zhuǎn)化圖來表現(xiàn)。
比如，圖7-8是美甲產(chǎn)品的第一個(gè)版本時(shí)所設(shè)計(jì)的訂單狀態(tài)轉(zhuǎn)化示意圖。只有把完整的狀態(tài)轉(zhuǎn)化列清楚，才可能知道會(huì)不會(huì)有狀態(tài)缺漏，狀態(tài)是否合理。更重要的是確認(rèn)邏輯是否完備，以及讓技術(shù)開發(fā)的同事知道如何去實(shí)現(xiàn)訂單的流程。
5.功能描述的邏輯
對(duì)于一個(gè)功能設(shè)計(jì)出方案，并不意味著可以邏輯完整地描述清楚。而且對(duì)于功能方案，我們無論多么謹(jǐn)慎也總是有存在錯(cuò)漏的地方。所以在描述功能時(shí)，用各種方法盡量捋順邏輯，把內(nèi)容更有條理、更完整地描述清楚，可以避免很多問題。
比如眾包物流產(chǎn)品在設(shè)計(jì)配送員取消訂單時(shí)，要使用一套取消的邏輯，包含有扣罰款、扣額度等。在不同的情況下，給配送員的提示（內(nèi)容也就是實(shí)際執(zhí)行的操作）都是不同的，為了完整描述每種情況，用表格的形式展示，如圖7-9所示。
有很多方法能夠達(dá)到同樣的目的，比如可以講述扣額度的定義，然后說明“提示時(shí)根據(jù)不同情況提醒用戶目前額度的情況”，但這對(duì)于開發(fā)的同事來說是不具體、不清晰的功能描述。他們拿到這樣的功能描述必須要自行再處理一遍，才能變成可開發(fā)的內(nèi)容。
總結(jié)來看，在描述功能時(shí)有以下幾點(diǎn)要注意：
? 完整
盡量枚舉所有的情況，并且分情況詳述功能內(nèi)容。最好從某個(gè)維度，比如業(yè)務(wù)的發(fā)生、進(jìn)行的流程、訂單狀態(tài)變化的轉(zhuǎn)換等關(guān)注功能變化的情況，以防漏掉什么特殊情況。對(duì)正常流程來說，可能是像圖 7-10左側(cè)的情況，但對(duì)于一個(gè)完整的、考慮到任何情況的功能描述來說會(huì)是圖 7-10右側(cè)的情況。
如果相關(guān)的情況比較多要描述的內(nèi)容比較復(fù)雜，就用表格展示。
? 考慮到所有影響點(diǎn)
產(chǎn)品越大、功能越多，就越有可能存在牽一發(fā)而動(dòng)全身的改動(dòng)。對(duì)任何改動(dòng)，即使再小都可能牽扯到其他的地方，所以要特別注意。還是舉眾包物流平臺(tái)的例子，在更新配送員收入規(guī)則的時(shí)候，我們只關(guān)注了訂單頁面和個(gè)人賬戶頁面的收入描述，臨近上線時(shí)才發(fā)現(xiàn)在幫助頁中的某個(gè)大家都遺忘了的子頁面里還有收入規(guī)則的描述，于是臨時(shí)緊急改掉。所幸工作量很小，沒出太多問題，不然鬧起糾紛來，又是一樁麻煩事。
? 條件判斷清晰
條件判斷要足夠清晰，是在什么條件下有什么樣的功能，或者在怎樣的條件下觸發(fā)怎樣的特殊功能都要羅列清晰。這里可以參考編程語言中很常見的if/else、while、switch等幾種邏輯描述。
? 含義明確
不要用模棱兩可的詞來描述功能，也不要用未定義清楚的詞造成混淆。著名的硅谷創(chuàng)業(yè)者、SpaceX的老板馬斯克曾經(jīng)被很多看不懂的工程師們自創(chuàng)的縮寫詞搞得很惱火，于是發(fā)了一封郵件說：“除非得到我的批準(zhǔn)，其他縮寫詞不能列入SpaceX的詞匯表。例如，測(cè)試架不應(yīng)該有‘HTS’或‘VTS’這樣的稱呼，這討厭的縮寫版本事實(shí)上比原詞更費(fèi)解……”雖然這條規(guī)定被員工戲稱為“A.S.S Rule”（狗屁規(guī)定），但這確實(shí)讓大家的溝通更加高效。
? 敘述背景
讓邏輯鏈條更完整的一個(gè)好方法是敘述功能產(chǎn)生的背景及它要達(dá)到的目的。在之前提到基于場(chǎng)景挖掘需求時(shí)，也提到了要讓整個(gè)團(tuán)隊(duì)關(guān)注需求發(fā)生的場(chǎng)景，這樣更容易讓他們理解產(chǎn)品。
成長(zhǎng)建議Ⅶ
產(chǎn)品方面的文檔并沒有統(tǒng)一的標(biāo)準(zhǔn)。在大公司里能夠用既有的模板詳述方案是好的，在創(chuàng)業(yè)團(tuán)隊(duì)用簡(jiǎn)陋的形式一頁圖紙就說清楚功能也是可以的。對(duì)于文檔要講求邏輯、內(nèi)容清晰，在不同的團(tuán)隊(duì)里不同的協(xié)作方式中都是至關(guān)重要的。如果非要提供一種可用的需求文檔寫法，建議用如圖7-11所示的用例。
要點(diǎn)反思
? 了解技術(shù)是為了更好地設(shè)計(jì)功能和協(xié)作，并不是幫技術(shù)的同事完成工作。
? 不管文檔是什么形式、篇幅如何，能讓開發(fā)人員們看得懂的就是好文檔。
? 文檔的完整性、邏輯性比文檔的可讀性、美觀程度都重要。
