中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

在互聯網公司里，總有那么兩撥相愛相殺的動物，程序狗和產品喵，你覺得我大忽悠，我覺得你傲嬌，互相覺得是傻逼，兩者之間總會發生一些驢唇不對馬嘴的對話因而造成彼此的怨恨。要解決這種互看不爽問題，產品應該站在主動的位置。說得好聽點，這是產品應該做的事情，直白點說，產品還得求人干活呢（個人不太喜歡這種說法，后面細說）。

工作中，我和各種崗位的工程師（客戶端前端后臺和數據）都有打過交道，自認為和工程師之間的溝通還算順暢和諧，今天就給大家介紹一下我的心得。個人認為無非三點：尊重、信任和理解。這三個詞比較虛，其實和所有人打交道都離不開這三點，但在對待工程師這種特定的物種時，這三個詞都有一些更具體的含義。

建立良好溝通的三大要點

尊重

這個需求麻煩你幫忙開發一下吧，做完了請你吃飯！

因為產品經理是一個目標導向極強的崗位，簡言之就是以項目成敗論英雄，而工程師天然有著追求技術難度的屬性（應該沒有說錯吧？這個在社會評價產品經理或工程師是否成功的標準中已經體現的很明顯了），雖然有時候目標達成和技術難度在大方向大部分是時候是一致的，但追求上細微的不一致造成了我們現在看到的常見產品和技術的交流模式：產品跪舔技術去完成項目。也因此，我敢負責任的說，在大部分的產品經理眼中，工程師只是他們完成項目的工具而已。不相信？前面我說的“產品還得求工程師干活”這句話有多少人覺得不對勁？

在我看來，這種“產品求著工程干活”的思想就是對工程師崗位的不尊重，這種思想看起來在提高工程師的地位，但實際上是將工程師工具化并排除在最終的成果之外。尊重是應該從心里而來的，而不是在諂媚的行為和語言中（比如前面說的跪舔和各種甜言蜜語，但有時候請吃飯是必不可少）。那么什么才是代表著尊重的關系呢？個人認為，產品經理應該把工程師當做最親密的合作伙伴。合作伙伴，就是大家有共同的目標，一起努力去完成目標，榮辱與共。從項目角度來說，一個項目的成功，除了產品層面的內容，也需要技術上的完美無瑕，而技術問題的解決，是離不開工程師的積極心態的。

在建立這種可靠的合作關系中，產品經理有主動的責任，那么如何才能激發工程師們的主人翁精神，建立合作關系呢？這里有幾個可行的建議：

• 多向工程師描述大愿景而不僅僅是去描述眼前的功能
• 讓工程師了解更多的背景、目標、成果等，而不是只是告訴工程師要做什么
• 少說“我”，多說“我們”，不要說“這個應該很簡單吧”

作為合作伙伴，你也需要避免自己在工程師被定義為競對功能抄襲機器和領導訓話傳達者，認真對待自己的每個需求，能夠很好的解釋需求的意義和目標，提升自己的靠譜程度。當然有時候，即使做好了自己，你也會碰到看不起產品經理的工程師（可能之前被我們不靠譜的同行傷害過而抱有偏見），你自己的工作都不能得到應有的尊重，這種情況下，唯有你持續的專業表現才是唯一的解藥。

信任

這個應該要不了這么久吧？

相信大家都聽到過（或說過）類似“這個怎么要做這么久？”這樣的描述，產品和工程師之間的互看不爽很可能都是從這類話開始的，將心比心，這類不信任的話誰聽了心里都不會開心。做人啊，最重要的要始終做到善意猜測，即對任何人的任何行為，都要認為對方是基于一個積極的目的的。落實到工作中，善意猜測就是要相信工程師的能力和品格，盡量對工程師給出的技術反饋（方案設計、估時等等）保持足夠的信任，絕大部分情況下，應該也沒有人會故意耍滑頭。如果你身邊真的有這種工程師，我這邊也建議先自省一下：有工程師朋友告訴我，他在估時的時候就習慣性的多估幾天，因為產品總是在開發過程中有各種各樣的需求變更。

如果你真的懷疑有詐的時候怎么辦呢？我有兩個建議：首先是增加自己對一些技術實現的了解，能夠有自己的一些基本判斷；二是在遇到有疑問時找其他的工程師朋友（別告訴我你把工程師都得罪光了[/嚇]）幫忙確認，如果有問題時可以通過細化分解技術方案讓一切花招顯形，或者尋求升級解決。

理解

不用這么復雜吧，我只要改一下文案就可以了??！

在我看來，大部分產品經理對工程師的偏見，是因為不理解工程師的思維和工作方式造成的。一個產品需求擺在面前的時候，大多數產品經理想到的是產品要完成的樣子，也就是現在，而工程師必須要去考慮如何實現，要考慮到過去、現在和將來。比如，一個文案的修改，產品經理看到的只是幾個字的變化，而工程師要考慮現在文案的實現邏輯，文案的修改如何去完成，以及這種修改的方式在未來的拓展性。經驗表明，很多后來被證明為坑的需求，真的就是沒有考慮過去和將來造成的。所以我也堅持認為，真正牛逼的工程師和產品經理的組合，是完成當前的需求，填上過去的坑，不給未來留坑的CP。悲哀的是，大多數只做到了完成當前的需求（更悲哀的是在現實中，解決這些隱形的問題于未然并不會給工程師和產品經理帶來足夠的肯定）。

如何才能理解工程師，讓大家保持一致的步調呢？我認為最重要的是要有一些工程師思維，這里的工程師思維我指的是了解計算機程序如何工作以及大致的實現邏輯?？催^很多文章說產品經理不需要懂技術，這個觀點我部分認同。確實，產品經理不需要懂怎么編碼怎么實現，但不能對計算機世界的邏輯一無所知。在敝司我認為靠譜的產品經理或我的偶像中，無一例外都是邏輯清晰，能夠描述出需求相關的邏輯實現和了解產品緊密相關的技術問題。

產品經理必須要了解的知識

根據工作時間，在策略產品經理的工作中，有幾組我認為必須要了解的技術邏輯/思維/…（我也不知道叫啥）：

1.MVC

在我短暫的玩耍式的coding生涯中，我理解最核心的就是這個詞啦，如果能理解這個詞，也就能理解工程師的思維方式。MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典范，用一種業務邏輯、數據、界面顯示分離的方法組織代碼。這個概念不重要，不用細究，但體現的是工程師的思維方式，通俗的來解釋，就是讓程序的每一步都去完成一個特定的功能，設計的宗旨是減少耦合方便改進優化和修改。因此程序的邏輯是分層分塊的，每一層每一塊完成特定的功能，這樣當需要修改某些特定的功能的時候，只需要修改很少的部分就能完成。舉個簡單的例子，在這種程序設計下，刪除評價內容在評價存儲功能中處理，修改商品的評分在評分計算功能處理，修改評價的展示在客戶端完成。所以，當工程師在說這部分更適合xx部門來做的時候，千萬不要吃驚，事實上，誰來做什么這類事情你最好提前考慮好。

2.存儲、接口和展示

在現在的工程實踐中，對數據的處理離不開這三個步驟，像我們以數據為命的策略產品經理，所有的需求也不可能離開三件事。

存儲就是將數據存在數據庫啦，一般有生產數據庫和離線數據庫，前者是需要和線上服務一起進行增刪改查操作的數據庫，后者可以認為是生產數據庫的拷貝，一般會定時從生產庫同步過來，因而是有延遲的，主要用于數據的加工和分析。之所以這么做，是為了不給添加生產服務器增加無關的壓力。數據可能存在硬盤也可能存在內存，工程師會在性能和價格中做出平衡選擇。

讓正常的理解，在展示的時候，我們直接從存儲中獲取信息就夠了，《數據結構和數據庫》課中也是這么教的。在數據量少的情況下，這是可行的，但現在可是大數據時代，那些數據庫扛不起那么大的數據量，接口就是為了解決這個問題。接口的作用就是“連接”，根據上層的需求，在底層中獲取數據并通過一些邏輯計算，按照信息需求和性能需求將數據提供給上層。

接口有各種格式，在不同的“連接”處都有合適的接口形式，產品經理最熟悉的一類接口，我們常稱為API（按定義講API有更廣泛的定義，我也解釋不明白），這是后臺的最后一層接口，作用是連接后臺和前端，所有的展示信息基本上都是從這類接口中來的，因為這類接口往往是http格式，所以也是產品經理可以把關檢驗的一類接口，在需求驗收和故障排查中經常會用到。

3.響應時間、緩存和QPS

已經有很多數據證明，頁面加載速度回影響用戶體驗和轉化率，加載速度是產品經理必須了解和關注的內容，也因此如何用合理的架構和存儲方式保障性能也是后臺工程師孜孜不倦的追求，也是工程師是否牛逼的檢驗標準。前面在存儲和接口中已經提到了性能問題，計算機的計算能力是有限的，當數據量大或運算復雜的時候，計算結果的時間可能會超出用戶的忍受范圍，這時候工程師往往會拋出緩存這樣的解決方式。緩存簡單理解就是放棄實時計算，將需要的數據提前準備好。它的壞處是犧牲了實時性，這個時候就需要產品根據產品特性，在實時性和性能之間做出平衡。

另外，QPS也是工程師經常會提到的名詞，它的全稱是Query Per Second（每秒查詢率），這個值和性能緊密相關，后臺結構的設計往往依靠對QPS的預估，一個qps10的功能和一個qps1000的功能對工程師來說完全是兩回事。產品經理在設計功能時，最好能將這個值的預估提供給工程師，以免上線之后還得下線重構，與此相同的表述還有每天請求量等等。

以上是我認為要理解工程師必須了解的一些概念和問題，了解他們可以避免和RD產生一些不必要的沖突。當然，不同的產品崗位需要了解的常見技術知識是不一樣的，但要記住的是不能對技術一無所知，盡量去理解工程師的話，平時多和工程師聊聊天，對于不了解的技術問題，把工程師當老師多問問。如果你連鋼筋都不懂，怎么建出高樓大廈呢？

總之，產品經理應該從心里有這樣的新年：和諧一點吧，畢竟大家都是十二生肖！總結一下，要和工程師有和諧的溝通，不妨先做到下面三條：

• 尊重工程師的工作，把工程師當做伙伴
• 信任工程師的能力和品格，做到永遠善意猜測
• 了解一些技術思維和知識，盡量去理解技術實現

作者@?hihipm

來源@策略產品經理講堂（公眾號ID；hihipm）

本文由 @hihipm 授權發布于人人都是產品經理 ，未經許可，禁止轉載。