第十五期嘉賓：郭理靖

EGO會(huì)員，目前擔(dān)任北京簡網(wǎng)CTO，負(fù)責(zé)產(chǎn)品與技術(shù)部門。十二年互聯(lián)網(wǎng)、六年云計(jì)算行業(yè)開發(fā)經(jīng)驗(yàn)，曾任北京同仁堂國際CTO、京東云平臺(tái)高級(jí)總監(jiān)。

據(jù)說全球每天發(fā)生12萬6423次需求變更，造成了1243萬行代碼廢棄，影響了50萬程序員的情緒，導(dǎo)致500個(gè)家庭的破裂。而每個(gè)IDC的機(jī)房里，有95%的代碼都沒有被執(zhí)行，這些被遺棄的代碼對(duì)擁在CPU懷里的同類發(fā)出怒恨的聲音，被運(yùn)維工程師稱之為Codemourne。

產(chǎn)品經(jīng)理就像女人一樣，需求如同她的心情，每天都有新的變化。

————byBetaCat

最近五年多的工作中，我所管理的團(tuán)隊(duì)都包括產(chǎn)品與技術(shù)這兩個(gè)角色，因此對(duì)這兩個(gè)角色也有一些了解。同時(shí)我做過一些失敗的產(chǎn)品，也做過一些相對(duì)還行的產(chǎn)品，對(duì)失敗的經(jīng)驗(yàn)進(jìn)行一些總結(jié)，對(duì)一些做的好的方法進(jìn)行提煉，希望對(duì)大家后面的工作能起到借鑒的意義。

對(duì)于產(chǎn)品與技術(shù)的思維方式的區(qū)別，我們可以用簡單的一句話來描述：產(chǎn)品是一個(gè)發(fā)現(xiàn)問題、定義問題的人，而技術(shù)是一個(gè)會(huì)利用不同手段解決問題的人。發(fā)現(xiàn)問題的人需要敏銳的觀察力、旺盛的好奇心和卓越的猜測力，而解決問題的人需要扎實(shí)的知識(shí)、廣闊的視野以及能靈活的利用各項(xiàng)工具。 

當(dāng)然，產(chǎn)品與技術(shù)的思維方式其實(shí)是有共性的，大家都有比較嚴(yán)謹(jǐn)?shù)倪壿嬓运季S。一般來說，技術(shù)的嚴(yán)謹(jǐn)性會(huì)稍微強(qiáng)一些，它經(jīng)常能幫產(chǎn)品完善邏輯流程(功能流程圖)。我下午畫了一個(gè)表格，簡單分析了產(chǎn)品和技術(shù)在不同角度的能力的差異：
5分制，指數(shù)并不絕對(duì)，只是我想描述一下差別。在發(fā)散性和用戶的同理心上，技術(shù)和產(chǎn)品的差異是比較大的。當(dāng)然這個(gè)表格不是要表達(dá)說產(chǎn)品比技術(shù)重要，相應(yīng)的比較項(xiàng)也是比較偏向于產(chǎn)品經(jīng)理的技術(shù)樹的。這也是容易造成大家后面有分歧的原因。 

對(duì)產(chǎn)品經(jīng)理而言，人生的煩惱就是技術(shù)說這個(gè)實(shí)現(xiàn)不了、那個(gè)實(shí)現(xiàn)不了、只能改成那樣了，嫌棄技術(shù)水平爛。

對(duì)技術(shù)人員而言，人生的煩惱就是產(chǎn)品原型太粗略，結(jié)果這里少一個(gè)邏輯，那里少一個(gè)文案，嫌棄產(chǎn)品考慮不周全。 

對(duì)產(chǎn)品與技術(shù)而言，人生最大的煩惱就是運(yùn)營說：我靠，你們做的東西不是我想要的，我們的需求其實(shí)是@￥%￥%@￥。 

我見到過很多團(tuán)隊(duì)和公司，聊天的時(shí)候，我發(fā)現(xiàn)沒有幾個(gè)CEO和Leader對(duì)自己的團(tuán)隊(duì)工作效率是特別滿意的（資本家心態(tài))。很多人都說，我們做的太慢了、功能更新的太慢了、迭代的太慢了，為什么一個(gè)簡單的功能要整那么久呢？我們先來談一個(gè)簡單的案例，以下故事純屬虛擬，如有雷同，純屬巧合：

A公司是一家做電商類服務(wù)的，剛剛開始開發(fā)產(chǎn)品，CEO說我們的產(chǎn)品要簡潔好用（老板說的都是對(duì)的），于是產(chǎn)品經(jīng)理決定從用戶注冊(cè)登錄入手。鑒于現(xiàn)在的用戶都比較反感注冊(cè)，我們就只用第三方授權(quán)登錄來減輕用戶注冊(cè)的負(fù)擔(dān)，這年頭誰沒有個(gè)微信、微博啊，我們就支持微信和微博的第三方登錄就可以了。

哐當(dāng)~~~產(chǎn)品上線，市場推廣很給力，一下子拉了很多用戶上來。但是用戶反饋怎么沒有QQ登錄啊，這個(gè)得加上；怎么沒有淘寶登錄啊，這個(gè)得加上；怎么沒有豆瓣登錄啊，這個(gè)得加上。產(chǎn)品說：我們得增加更多第三方登錄，技術(shù)一聽，行吧，就用第三方組件把業(yè)界知名的第三方登錄全加上了。上線了，登錄頁下面全是密密麻麻的第三方授權(quán)圖標(biāo)，產(chǎn)品說太多圖標(biāo)了，我們只展現(xiàn)第三方授權(quán)，其它的授權(quán)放到更多里面，于是又改了一版。 

運(yùn)營了一段時(shí)間，發(fā)現(xiàn)了下面幾個(gè)嚴(yán)重的問題：

1. 用戶有時(shí)候忘了自己到底是用哪個(gè)授權(quán)進(jìn)來的，重新登錄的時(shí)候選錯(cuò)了授權(quán)，發(fā)現(xiàn)自己的訂單沒有，暴怒，打客服電話狂投訴：你們技術(shù)怎么這么爛，把我的訂單都搞沒了。

2. 安卓版本App信息的到達(dá)率低，整體APP信息打開率比較低。

3. 辛辛苦苦獲取的用戶用過一次后就刪除App，再也沒法做召回了。

經(jīng)產(chǎn)品和運(yùn)營討論研究決定，所有用戶要綁定手機(jī)號(hào)碼。新用戶注冊(cè)需要直接綁定，老用戶引導(dǎo)綁定手機(jī)號(hào)碼。技術(shù)一聽好吧，綁定手機(jī)號(hào)碼對(duì)業(yè)務(wù)有很多幫助，那得做。嗯，老版本的兼容器都保證。同一個(gè)用戶，歷史用過不同的第三方授權(quán)賬號(hào)如何處理？給用戶發(fā)送消息的時(shí)候，如果用戶沒有手機(jī)號(hào)碼如何處理？于是很多關(guān)于用戶的環(huán)節(jié)上，都加上了相應(yīng)的邏輯判斷，而且還要給運(yùn)營和產(chǎn)品統(tǒng)計(jì)用戶手機(jī)號(hào)碼的綁定率。 

于是好多邏輯的代碼要加上，也多了很多test case, 整體的工作量就上來了。但是CEO就體會(huì)不到這些工作量，不就是加個(gè)手機(jī)號(hào)碼嘛，怎么這個(gè)功能要搞這么久？不就是數(shù)據(jù)庫里多搞個(gè)字段嘛？一個(gè)團(tuán)隊(duì)工作“效率低”（這只是表象，其實(shí)產(chǎn)品和技術(shù)都累的像狗一樣，每天其實(shí)都不得閑，）會(huì)有很多種原因，我把我經(jīng)歷過的總結(jié)一下：

1. 持續(xù)性打補(bǔ)丁式的開發(fā)。補(bǔ)丁越來越多，代碼越來越難讀懂，業(yè)務(wù)邏輯越來越難理解，除了親手寫的人，沒有人明白是怎么回事，維護(hù)起來也特別困難。 

2. 持續(xù)性的無文檔開發(fā)。所有資料圖表都口口相傳，在前期沖刺階段，因?yàn)閳F(tuán)隊(duì)成員的相對(duì)默契，心有靈犀一點(diǎn)通，不用寫詳細(xì)的PRD、不用對(duì)API文檔的返回值和錯(cuò)誤做解釋、不需要數(shù)據(jù)字典，這可能還行。但是對(duì)新加入的成員來說，學(xué)習(xí)成本就過高了，產(chǎn)品的原型是有，但是產(chǎn)品邏輯圖非常粗糙，各種細(xì)節(jié)與方案需要技術(shù)腦補(bǔ)。 

3. 前期利用了第三方的開發(fā)組件、服務(wù)和開源代碼，在業(yè)務(wù)出現(xiàn)新變化和需求的時(shí)候，從技術(shù)的角度無法得到滿足，用戶訴求的功能遲遲無法實(shí)現(xiàn)。產(chǎn)品在設(shè)計(jì)一些新的需求的時(shí)候可能對(duì)這些第三方了解不多，導(dǎo)致需求做不了，而又或者對(duì)這些功能了解的太少，不知道如何利用這個(gè)第三方服務(wù)來加速產(chǎn)品功能。比如功能A雖然不是那么緊急，但是如果利用第三方的一個(gè)功能半天就能完成的話，這在ROI上講是非常劃算，也是值得做的。 

4. 技術(shù)團(tuán)隊(duì)整體有短板。整體的技術(shù)棧鏈條其實(shí)是很長的，移動(dòng)端、前端、API、負(fù)載均衡、防攻擊、數(shù)據(jù)庫、日志分析、數(shù)據(jù)報(bào)表等等，比如整個(gè)團(tuán)隊(duì)沒有懂?dāng)?shù)據(jù)庫的人才，出現(xiàn)數(shù)據(jù)庫問題的時(shí)候就一籌莫展了。 

5. 信息不夠透明開放。有些事情在群里、QQ或郵件里說了就算了，信息并沒有對(duì)全部人員開放。大家看到一個(gè)事情的前因后果，不知道事情的進(jìn)展如何。這種情況經(jīng)常發(fā)生，特別是在產(chǎn)品有一個(gè)小需求需要改動(dòng)的時(shí)候，可能就并沒有落在紙面上，而是碰到開發(fā)就口頭說了。很多人會(huì)有這個(gè)思維慣性：以為自己開口說了，全世界人民都是應(yīng)該知道這個(gè)事的。這個(gè)說法看上去很蠢，實(shí)際上你總會(huì)碰到這樣的同學(xué)。 

6. 產(chǎn)品設(shè)計(jì)其實(shí)缺乏前瞻性。對(duì)未來的需要沒有考慮到位，導(dǎo)致后續(xù)改版成本居高不下。 

7. 其實(shí)大家都沒有搞清楚我們到底要做個(gè)什么樣的東西、到底能不能產(chǎn)生價(jià)值，但是基于公司運(yùn)行三大定律之“不能閑下來”的基本原則，那就先開搞再說了~ 

我們總說互聯(lián)網(wǎng)節(jié)奏要求快，要小步快跑，快速進(jìn)入市場、驗(yàn)證產(chǎn)品、收集反饋需求再迭代改進(jìn)。在實(shí)操上，小步快跑難度其實(shí)遠(yuǎn)超我們的預(yù)期。在小步快跑的路上，不知道有多少團(tuán)隊(duì)死在體力不支上。下面談幾點(diǎn)我個(gè)人覺得要注意的地方： 

1. 保持產(chǎn)品主干線邏輯大體不變。這個(gè)真的沒啥好講的，連這個(gè)都變了，代碼那絕對(duì)是廢了。 

2. 產(chǎn)品迭代周期的良好把控。WEB前端以及后臺(tái)的產(chǎn)品迭代周期是可以比較快的、風(fēng)險(xiǎn)相對(duì)可控，有了beta環(huán)境和回滾機(jī)制，基本上就問題不大。但是對(duì)移動(dòng)端的產(chǎn)品來說，多久的一個(gè)更新周期是比較合理的呢？每個(gè)更新周期內(nèi)應(yīng)該做什么樣的功能才會(huì)讓用戶有驚喜感，讓用戶覺得整個(gè)團(tuán)隊(duì)是在不斷進(jìn)步的呢？每一次的移動(dòng)端的版本更新都會(huì)帶來日活的小增長，但是太頻繁的更新也會(huì)讓用戶覺得反感。而在之前iOS上架更新動(dòng)不動(dòng)就需要2周時(shí)間的情況下，如何把控安卓、iOS的進(jìn)度特別是讓iOS能有提前量，這些都是產(chǎn)品迭代特別需要注意的。 

產(chǎn)品功能盡量分期迭代。產(chǎn)品著重細(xì)化當(dāng)期的各種邏輯細(xì)節(jié)，但是讓技術(shù)能夠看到整個(gè)產(chǎn)品的全貌，而不是管中窺豹，知其然而不知其所以然。產(chǎn)品可以和技術(shù)一起規(guī)劃一期、二期甚至三期的功能以及期望達(dá)到目標(biāo)，迭代的過程真心可以采用MVP的思想。 

3. 如何帶著腳鏈跳舞。開發(fā)新功能的時(shí)候還需要填老功能的坑，技術(shù)要合理的分配時(shí)間，產(chǎn)品也要給技術(shù)留有一定的余量，很多項(xiàng)目的延期和矛盾的產(chǎn)生就是在于沒有給開發(fā)留出一些時(shí)間余量地解決歷史問題。技術(shù)對(duì)于產(chǎn)品的新功能需求，使用的第三方服務(wù)不支持想要的特性，也要多開腦洞想想如何搞（辦法總比困難多），盡量避免說做不了、實(shí)現(xiàn)不了，要多提提有沒有好的替代方案。 

4. 新功能的ROI要衡量，產(chǎn)品要數(shù)據(jù)化運(yùn)營。對(duì)于新的功能，我們還都是要做數(shù)據(jù)采集的埋點(diǎn)。對(duì)一些重大的功能，都需要做AB test. 數(shù)據(jù)化的采集在產(chǎn)品的中后期極其重點(diǎn)，前期真的可以靠產(chǎn)品的直覺出發(fā)，但是中后期還是要靠數(shù)據(jù)說話。有數(shù)據(jù)在手，產(chǎn)品也更能夠容易證明自己的想法是對(duì)的。 

產(chǎn)品對(duì)技術(shù)的方法要曉之以情、動(dòng)之以理，畢竟技術(shù)還是沖鋒陷陣戰(zhàn)斗在第一線的人員，要做好關(guān)懷工作。而且對(duì)技術(shù)人員而言，做出來的東西，運(yùn)營數(shù)據(jù)非常好看，那是最好的激勵(lì)。 

5. 性能與功能的權(quán)衡得失。比如在首頁加更多的內(nèi)容或者App啟動(dòng)多調(diào)用幾個(gè)API，這必然會(huì)帶來性能上的損失。其實(shí)在這一點(diǎn)上，經(jīng)驗(yàn)不是很豐富的團(tuán)隊(duì)比較容易犯這樣的錯(cuò)誤。產(chǎn)品經(jīng)理光顧著增加新的功能，技術(shù)也顧著功能的實(shí)現(xiàn)，于是導(dǎo)致用戶的體驗(yàn)變差了，反而降低了留存，出現(xiàn)這樣的問題有時(shí)候還很難被發(fā)現(xiàn)，如果團(tuán)隊(duì)在一開始的時(shí)候就對(duì)用戶行為有詳細(xì)的收集，對(duì)服務(wù)的質(zhì)量有詳細(xì)的記錄，那就可能比較容易對(duì)問題進(jìn)行定位。 

天下武功，唯快不破，應(yīng)用越快的響應(yīng)對(duì)用戶留存是一定有正向作用的。 

6. 老版本兼容性問題。維護(hù)過API 1.0 、API 2.0 、API 3.0的同學(xué)說出來都是淚啊，（API是技術(shù)設(shè)計(jì)的產(chǎn)品）API這個(gè)種東西一旦放出去，就別想著有一天能夠一次性的搞定。每一次API的強(qiáng)制升級(jí)都會(huì)經(jīng)歷腥風(fēng)血雨，每當(dāng)你正式關(guān)閉一個(gè)服務(wù)的API時(shí)，指不定又冒出來幾個(gè)調(diào)用方說你的API影響到我的服務(wù)了。同時(shí)你永遠(yuǎn)不知道還有沒有如幽靈般的App用戶還在使用極其古老的版本。所以，版本管理要做在前面，產(chǎn)品設(shè)計(jì)時(shí)要盡量保證前后的一致性，避免動(dòng)不動(dòng)就來一個(gè)全部強(qiáng)制升級(jí)的事情。 

反正我是比較討厭那些一定要我升級(jí)App才能讓我使用的App（12306除外，我很有耐心等待它的升級(jí)）。

正循環(huán)的形成單單靠產(chǎn)品與技術(shù)這兩個(gè)角色是不夠的，這兩個(gè)點(diǎn)只能構(gòu)成直線，三個(gè)點(diǎn)才能構(gòu)成穩(wěn)定的三角形。想形成正循環(huán)，還得有運(yùn)營的角色。 

1. 需求寬進(jìn)嚴(yán)出。相信我不管是在哪家公司，不管是在公司的哪個(gè)階段，需求是永遠(yuǎn)做不完的。 

2. 產(chǎn)品評(píng)審嚴(yán)格進(jìn)行。在我看來其實(shí)這一塊有點(diǎn)難度，有時(shí)候大家面對(duì)一個(gè)基本的產(chǎn)品原型，很難靜下心來想產(chǎn)品的細(xì)節(jié)（也許細(xì)節(jié)太多了，想想就很煩），反正開了那么多場產(chǎn)品評(píng)審會(huì)，越嚴(yán)格、討論越多的會(huì)，后面開發(fā)的效率越高，反之亦然。 

3. 驗(yàn)收流程完善。技術(shù)提交測試，測試交付產(chǎn)品，產(chǎn)品驗(yàn)收交付運(yùn)營進(jìn)行內(nèi)部體驗(yàn)。面向用戶的產(chǎn)品，內(nèi)部還是要深度消化過后才能上線上架 

4. 工具、規(guī)范、分析做在前面。雖然有時(shí)候感覺會(huì)浪費(fèi)時(shí)間，但是不去花時(shí)間思考更好地把事情做好的話，反而會(huì)造成更大的浪費(fèi)。這世上有多少事輸在謀定而后動(dòng)，磨刀不誤砍柴工這兩句話上。 

5. 良好而且充分的溝通。這也是最重要的一點(diǎn)。 結(jié)伙創(chuàng)業(yè)，一起共事就和搭伙過日子一樣，話說互聯(lián)網(wǎng)的大部分人和同事在一起的時(shí)間比和老婆在一起的時(shí)間還要長。技術(shù)與產(chǎn)品其實(shí)就像兩口子，吵架的原因很多是因?yàn)椋何夷敲磹勰?，你怎么還不能理解我的意思與痛苦呢？