在互聯(lián)網(wǎng)公司里，總有那么兩撥相愛相殺的動物，程序“猿”和產(chǎn)品“狗”，你覺得我大忽悠，我覺得你傲嬌，互相覺得是傻逼，兩者之間總會發(fā)生一些驢唇不對馬嘴的對話因而造成彼此的怨恨。要解決這種互看不爽問題，產(chǎn)品應(yīng)該站在主動的位置。說得好聽點(diǎn)，這是產(chǎn)品應(yīng)該做的事情，直白點(diǎn)說，產(chǎn)品還得求人干活呢（個人不太喜歡這種說法，后面細(xì)說）。
工作中，我和各種崗位的工程師（客戶端前端后臺和數(shù)據(jù)）都有打過交道，自認(rèn)為和工程師之間的溝通還算順暢和諧，今天就給大家介紹一下我的心得。個人認(rèn)為無非三點(diǎn)：尊重、信任和理解。這三個詞比較虛，其實(shí)和所有人打交道都離不開這三點(diǎn)，但在對待工程師這種特定的物種時，這三個詞都有一些更具體的含義。
尊重
*這個需求麻煩你幫忙開發(fā)一下吧，做完了請你吃飯！
因?yàn)楫a(chǎn)品經(jīng)理是一個目標(biāo)導(dǎo)向極強(qiáng)的崗位，簡言之就是以項(xiàng)目成敗論英雄，而工程師天然有著追求技術(shù)難度的屬性（應(yīng)該沒有說錯吧？這個在社會評價產(chǎn)品經(jīng)理或工程師是否成功的標(biāo)準(zhǔn)中已經(jīng)體現(xiàn)的很明顯了），雖然有時候目標(biāo)達(dá)成和技術(shù)難度在大方向大部分是時候是一致的，但追求上細(xì)微的不一致造成了我們現(xiàn)在看到的常見產(chǎn)品和技術(shù)的交流模式：產(chǎn)品跪舔技術(shù)去完成項(xiàng)目。也因此，我敢負(fù)責(zé)任的說，在大部分的產(chǎn)品經(jīng)理眼中，工程師只是他們完成項(xiàng)目的工具而已。不相信？前面我說的“產(chǎn)品還得求工程師干活”這句話有多少人覺得不對勁？
在我看來，這種“產(chǎn)品求著工程干活”的思想就是對工程師崗位的不尊重，這種思想看起來在提高工程師的地位，但實(shí)際上是將工程師工具化并排除在最終的成果之外。尊重是應(yīng)該從心里而來的，而不是在諂媚的行為和語言中（比如前面說的跪舔和各種甜言蜜語，但有時候請吃飯是必不可少）。那么什么才是代表著尊重的關(guān)系呢？個人認(rèn)為，產(chǎn)品經(jīng)理應(yīng)該把工程師當(dāng)做最親密的合作伙伴。合作伙伴，就是大家有共同的目標(biāo)，一起努力去完成目標(biāo)，榮辱與共。從項(xiàng)目角度來說，一個項(xiàng)目的成功，除了產(chǎn)品層面的內(nèi)容，也需要技術(shù)上的完美無瑕，而技術(shù)問題的解決，是離不開工程師的積極心態(tài)的。
在建立這種可靠的合作關(guān)系中，產(chǎn)品經(jīng)理有主動的責(zé)任，那么如何才能激發(fā)工程師們的主人翁精神，建立合作關(guān)系呢？這里有幾個可行的建議：
多向工程師描述大愿景而不僅僅是去描述眼前的功能
讓工程師了解更多的背景、目標(biāo)、成果等，而不是只是告訴工程師要做什么
少說“我”，多說“我們”，不要說“這個應(yīng)該很簡單吧”
作為合作伙伴，你也需要避免自己在工程師被定義為競對功能抄襲機(jī)器和領(lǐng)導(dǎo)訓(xùn)話傳達(dá)者，認(rèn)真對待自己的每個需求，能夠很好的解釋需求的意義和目標(biāo)，提升自己的靠譜程度。當(dāng)然有時候，即使做好了自己，你也會碰到看不起產(chǎn)品經(jīng)理的工程師（可能之前被我們不靠譜的同行傷害過而抱有偏見），你自己的工作都不能得到應(yīng)有的尊重，這種情況下，唯有你持續(xù)的專業(yè)表現(xiàn)才是唯一的解藥。
信任
*這個應(yīng)該要不了這么久吧？
相信大家都聽到過（或說過）類似“這個怎么要做這么久？”這樣的描述，產(chǎn)品和工程師之間的互看不爽很可能都是從這類話開始的，將心比心，這類不信任的話誰聽了心里都不會開心。做人啊，最重要的要始終做到善意猜測，即對任何人的任何行為，都要認(rèn)為對方是基于一個積極的目的的。落實(shí)到工作中，善意猜測就是要相信工程師的能力和品格，盡量對工程師給出的技術(shù)反饋（方案設(shè)計、估時等等）保持足夠的信任，絕大部分情況下，應(yīng)該也沒有人會故意耍滑頭。如果你身邊真的有這種工程師，我這邊也建議先自省一下：有工程師朋友告訴我，他在估時的時候就習(xí)慣性的多估幾天，因?yàn)楫a(chǎn)品總是在開發(fā)過程中有各種各樣的需求變更。
如果你真的懷疑有詐的時候怎么辦呢？我有兩個建議：首先是增加自己對一些技術(shù)實(shí)現(xiàn)的了解，能夠有自己的一些基本判斷；二是在遇到有疑問時找其他的工程師朋友（別告訴我你把工程師都得罪光了[/嚇]）幫忙確認(rèn)，如果有問題時可以通過細(xì)化分解技術(shù)方案讓一切花招顯形，或者尋求升級解決。
理解
*不用這么復(fù)雜吧，我只要改一下文案就可以了??！
在我看來，大部分產(chǎn)品經(jīng)理對工程師的偏見，是因?yàn)椴焕斫夤こ處煹乃季S和工作方式造成的。一個產(chǎn)品需求擺在面前的時候，大多數(shù)產(chǎn)品經(jīng)理想到的是產(chǎn)品要完成的樣子，也就是現(xiàn)在，而工程師必須要去考慮如何實(shí)現(xiàn)，要考慮到過去、現(xiàn)在和將來。比如，一個文案的修改，產(chǎn)品經(jīng)理看到的只是幾個字的變化，而工程師要考慮現(xiàn)在文案的實(shí)現(xiàn)邏輯，文案的修改如何去完成，以及這種修改的方式在未來的拓展性。經(jīng)驗(yàn)表明，很多后來被證明為坑的需求，真的就是沒有考慮過去和將來造成的。所以我也堅(jiān)持認(rèn)為，真正牛逼的工程師和產(chǎn)品經(jīng)理的組合，是完成當(dāng)前的需求，填上過去的坑，不給未來留坑的CP。悲哀的是，大多數(shù)只做到了完成當(dāng)前的需求（更悲哀的是在現(xiàn)實(shí)中，解決這些隱形的問題于未然并不會給工程師和產(chǎn)品經(jīng)理帶來足夠的肯定）。
如何才能理解工程師，讓大家保持一致的步調(diào)呢？我認(rèn)為最重要的是要有一些工程師思維，這里的工程師思維我指的是了解計算機(jī)程序如何工作以及大致的實(shí)現(xiàn)邏輯?？催^很多文章說產(chǎn)品經(jīng)理不需要懂技術(shù)，這個觀點(diǎn)我部分認(rèn)同。確實(shí)，產(chǎn)品經(jīng)理不需要懂怎么編碼怎么實(shí)現(xiàn)，但不能對計算機(jī)世界的邏輯一無所知。在敝司我認(rèn)為靠譜的產(chǎn)品經(jīng)理或我的偶像中，無一例外都是邏輯清晰，能夠描述出需求相關(guān)的邏輯實(shí)現(xiàn)和了解產(chǎn)品緊密相關(guān)的技術(shù)問題。
根據(jù)工作時間，在策略產(chǎn)品經(jīng)理的工作中，有幾組我認(rèn)為必須要了解的技術(shù)邏輯/思維/…（我也不知道叫啥）：
1.MVC
在我短暫的玩耍式的coding生涯中，我理解最核心的就是這個詞啦，如果能理解這個詞，也就能理解工程師的思維方式。MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設(shè)計典范，用一種業(yè)務(wù)邏輯、數(shù)據(jù)、界面顯示分離的方法組織代碼。這個概念不重要，不用細(xì)究，但體現(xiàn)的是工程師的思維方式，通俗的來解釋，就是讓程序的每一步都去完成一個特定的功能，設(shè)計的宗旨是減少耦合方便改進(jìn)優(yōu)化和修改。因此程序的邏輯是分層分塊的，每一層每一塊完成特定的功能，這樣當(dāng)需要修改某些特定的功能的時候，只需要修改很少的部分就能完成。舉個簡單的例子，在這種程序設(shè)計下，刪除評價內(nèi)容在評價存儲功能中處理，修改商品的評分在評分計算功能處理，修改評價的展示在客戶端完成。所以，當(dāng)工程師在說這部分更適合xx部門來做的時候，千萬不要吃驚，事實(shí)上，誰來做什么這類事情你最好提前考慮好。
2.存儲、接口和展示
在現(xiàn)在的工程實(shí)踐中，對數(shù)據(jù)的處理離不開這三個步驟，像我們以數(shù)據(jù)為命的策略產(chǎn)品經(jīng)理，所有的需求也不可能離開三件事。
存儲就是將數(shù)據(jù)存在數(shù)據(jù)庫啦，一般有生產(chǎn)數(shù)據(jù)庫和離線數(shù)據(jù)庫，前者是需要和線上服務(wù)一起進(jìn)行增刪改查操作的數(shù)據(jù)庫，后者可以認(rèn)為是生產(chǎn)數(shù)據(jù)庫的拷貝，一般會定時從生產(chǎn)庫同步過來，因而是有延遲的，主要用于數(shù)據(jù)的加工和分析。之所以這么做，是為了不給添加生產(chǎn)服務(wù)器增加無關(guān)的壓力。數(shù)據(jù)可能存在硬盤也可能存在內(nèi)存，工程師會在性能和價格中做出平衡選擇。
讓正常的理解，在展示的時候，我們直接從存儲中獲取信息就夠了，《數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)庫》課中也是這么教的。在數(shù)據(jù)量少的情況下，這是可行的，但現(xiàn)在可是大數(shù)據(jù)時代，那些數(shù)據(jù)庫扛不起那么大的數(shù)據(jù)量，接口就是為了解決這個問題。接口的作用就是“連接”，根據(jù)上層的需求，在底層中獲取數(shù)據(jù)并通過一些邏輯計算，按照信息需求和性能需求將數(shù)據(jù)提供給上層。
接口有各種格式，在不同的“連接”處都有合適的接口形式，產(chǎn)品經(jīng)理最熟悉的一類接口，我們常稱為API（按定義講API有更廣泛的定義，我也解釋不明白），這是后臺的最后一層接口，作用是連接后臺和前端，所有的展示信息基本上都是從這類接口中來的，因?yàn)檫@類接口往往是http格式，所以也是產(chǎn)品經(jīng)理可以把關(guān)檢驗(yàn)的一類接口，在需求驗(yàn)收和故障排查中經(jīng)常會用到。
3.響應(yīng)時間、緩存和QPS
已經(jīng)有很多數(shù)據(jù)證明，頁面加載速度回影響用戶體驗(yàn)和轉(zhuǎn)化率，加載速度是產(chǎn)品經(jīng)理必須了解和關(guān)注的內(nèi)容，也因此如何用合理的架構(gòu)和存儲方式保障性能也是后臺工程師孜孜不倦的追求，也是工程師是否牛逼的檢驗(yàn)標(biāo)準(zhǔn)。前面在存儲和接口中已經(jīng)提到了性能問題，計算機(jī)的計算能力是有限的，當(dāng)數(shù)據(jù)量大或運(yùn)算復(fù)雜的時候，計算結(jié)果的時間可能會超出用戶的忍受范圍，這時候工程師往往會拋出緩存這樣的解決方式。緩存簡單理解就是放棄實(shí)時計算，將需要的數(shù)據(jù)提前準(zhǔn)備好。它的壞處是犧牲了實(shí)時性，這個時候就需要產(chǎn)品根據(jù)產(chǎn)品特性，在實(shí)時性和性能之間做出平衡。
另外，QPS也是工程師經(jīng)常會提到的名詞，它的全稱是Query Per Second（每秒查詢率），這個值和性能緊密相關(guān)，后臺結(jié)構(gòu)的設(shè)計往往依靠對QPS的預(yù)估，一個qps10的功能和一個qps1000的功能對工程師來說完全是兩回事。產(chǎn)品經(jīng)理在設(shè)計功能時，最好能將這個值的預(yù)估提供給工程師，以免上線之后還得下線重構(gòu)，與此相同的表述還有每天請求量等等。
以上是我認(rèn)為要理解工程師必須了解的一些概念和問題，了解他們可以避免和RD產(chǎn)生一些不必要的沖突。當(dāng)然，不同的產(chǎn)品崗位需要了解的常見技術(shù)知識是不一樣的，但要記住的是不能對技術(shù)一無所知，盡量去理解工程師的話，平時多和工程師聊聊天，對于不了解的技術(shù)問題，把工程師當(dāng)老師多問問。如果你連鋼筋都不懂，怎么建出高樓大廈呢？
總之，產(chǎn)品經(jīng)理應(yīng)該從心里有這樣的新年：和諧一點(diǎn)吧，畢竟大家都是十二生肖！總結(jié)一下，要和工程師有和諧的溝通，不妨先做到下面三條：
尊重工程師的工作，把工程師當(dāng)做伙伴
信任工程師的能力和品格，做到永遠(yuǎn)善意猜測
了解一些技術(shù)思維和知識，盡量去理解技術(shù)實(shí)現(xiàn)
分享干貨我們是認(rèn)真的，更多干貨盡在愛盈利！
