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