產(chǎn)品經(jīng)理要不要懂技術?
產(chǎn)品經(jīng)理需不需要懂技術?大多數(shù)同行可能都認為需要，因為可以和開發(fā)平等對話，但真的懂技術之后會是這樣嗎?不懂技術就沒有優(yōu)勢嗎?本文根據(jù)我的經(jīng)驗和遇到的問題進行整理，感謝閱讀。
月初和一位產(chǎn)品朋友聊天，提到了產(chǎn)品崗是否需要懂技術的問題，網(wǎng)上也有很多觀點，有的極端、有的中庸。
因為我大學專業(yè)是軟件工程，雖然掛了很多科，但實習的時候也正兒八經(jīng)混了兩個小項目經(jīng)驗。之后無論是做測試，還是做售前，也一直在技術圈子的邊緣游離。所以我應該屬于在產(chǎn)品同行中略懂一點技術的。
懂技術給我的日常工作中帶來了很多幫助，但也造成了我后續(xù)(包括現(xiàn)在)的一些瓶頸與精神內(nèi)耗。
今天根據(jù)自己的理解和日常工作經(jīng)驗談談看法，希望能對各位產(chǎn)品同仁有點幫助。
01 為什么會有這個疑問?
也許是因為多年前一句“人人都是產(chǎn)品經(jīng)理”的影響，也許是很多人感覺產(chǎn)品崗的入行門檻低，于是乎很多跨行業(yè)轉(zhuǎn)型的產(chǎn)品人層出不窮，然而至今都很少有大學專門設立產(chǎn)品課。
即便市場上出現(xiàn)了很多產(chǎn)品培訓、知識星球等等，但更多也都是從底層思維、行業(yè)知識、產(chǎn)品方法論等方面展開。
所以對于大部分產(chǎn)品人來說，技術、軟件工程等相關的理論，不好學、也沒機會學。
但在實際工作中，打交道最多的應該就是技術同學了(某些特定行業(yè)、特定崗位不在討論范圍內(nèi))，無論前端、后端，無論公司的架構(gòu)、開發(fā)語言是哪種，只要我們想把產(chǎn)品設計推進落地，終究離不開與技術同學對接。
尤其是當我們提的需求，技術同學說做不了的時候，或者和他們討論方案的時候，亦或是出現(xiàn)了一些奇怪的bug來分析問題的時候，不懂技術的我們只能一臉茫然的聽著，或佯裝疑惑、或佯裝點頭。
所以大家很自然的會想到一個問題：我要不要學一下技術，起碼能和開發(fā)平等對話呢。
02 幾個小伙伴的統(tǒng)一訴求
包括在我身邊，團隊中的四位產(chǎn)品小伙伴。
一位英語專業(yè)轉(zhuǎn)型
一位UI轉(zhuǎn)型
一位化學農(nóng)藥啥啥的專業(yè)轉(zhuǎn)型
還有一位是企業(yè)管理專業(yè)轉(zhuǎn)型
七月份我們新制定了個人中短期成長規(guī)劃，他們也都把“了解技術、能和開發(fā)正常對接”之類的能力提升，作為下半年的學習目標。
團隊四人中，英語專業(yè)轉(zhuǎn)型的小姐姐已經(jīng)被“磨煉”到懂技術的行列了。來公司前就已經(jīng)在之前的工作中掌握了數(shù)據(jù)庫基本操作，在公司這幾年，整日與開發(fā)battle，討論方案、評審設計，已經(jīng)能在技術評審時指出很多流程與結(jié)構(gòu)方面的問題。
03 技術那么多，從何下手?
如果要了解技術，我的個人建議是從這幾個方面來入手(以下建議僅針對自己的認知，偏向常規(guī)系統(tǒng)，很多新興行業(yè)的系統(tǒng)與技術，或技術專業(yè)性較強的業(yè)務，就需要大家自己學習啦)。
之前我買過一本《給產(chǎn)品經(jīng)理講技術》的入門書，看了目錄，然后針對性看了幾個章節(jié)。也許是當時自己沒有良好的讀書習慣，也許是之后工作中沒有應用的場景，所以沒過多久也都忘了。不過當自己偶爾遇到一些技術問題時，還會再翻出來學習一下。
這也是我想和大家說的，我們?nèi)绻肓私饧夹g，一定要“用哪里、學哪里”，盡量不要體系化學習。因為體系化學習過程中，很多知識點在工作中運用不到，遲早會忘，而且也不一定有那么多時間體系化學習。
比如現(xiàn)在有些向產(chǎn)品推薦的數(shù)據(jù)分析課程，通過Python或其他語言進行編寫，如果自己只是感興趣，工作中并沒有實際應用，學習一段時間后，大概率會因為實操難度而“從入門到放棄”，奇奇怪怪的失敗經(jīng)驗又一次+1。
本身產(chǎn)品底層能力成長和行業(yè)知識成長就已經(jīng)需要我們花費大量的精力了。
其次我們可以學一些基礎的，或者幾乎各個系統(tǒng)/產(chǎn)品都會涉及的技術工具。比如我給團隊小伙伴的建議是：先學會基礎的sql語句，然后學會看服務器日志。
這樣起碼我們能通過工具查看業(yè)務處理邏輯是否合理，或者后續(xù)在迭代中，針對復雜的業(yè)務場景，和開發(fā)一起進行流程設計。就像我在之前提升測試效率的推文中提到的，我們?nèi)粘＝佑|的系統(tǒng)問題，很多都是業(yè)務處理不合理導致的功能性問題。而非因為性能、技術平臺選型所導致的技術難題。
當我們能夠通過系統(tǒng)日志，把主流程的處理邏輯轉(zhuǎn)化成流程圖時，就已經(jīng)很夠用了，再通過不斷地實踐、練習，讓自己熟悉。不出半年，和開發(fā)的溝通討論就會順暢很多。下面這張圖就是我們一位測試小姐姐在剛?cè)肼殨r通過查日志并結(jié)合數(shù)據(jù)庫梳理出的平臺業(yè)務流程及處理邏輯，一共40頁，太贊了!
另一方面，我們需要了解一些基礎的概念。比如【接口】、【加密】、【數(shù)據(jù)字典】、【定時任務】、【前后端分離】，以及常見的架構(gòu)概念。
以當下流行的微服務架構(gòu)為例，注冊中心、配置中心、通訊網(wǎng)關、日志歸集、協(xié)議轉(zhuǎn)換等等之類的概念，可以在網(wǎng)上一搜一大把的文章中做個了解。前提是，公司的產(chǎn)品用哪套技術架構(gòu)，我們?nèi)ニ涯奶住?/p>
第三步，如果產(chǎn)品涉及到第三方系統(tǒng)的對接合作，則可以了解第三方的API文檔，基于前期的技術理解，分析產(chǎn)品各個模塊與第三方合作系統(tǒng)的關聯(lián)關系及相互影響策略，最終產(chǎn)出業(yè)務架構(gòu)圖、或系統(tǒng)間業(yè)務流程圖、數(shù)據(jù)流圖，基本就超出業(yè)內(nèi)很多產(chǎn)品同仁了。
當然很多中后臺的產(chǎn)品經(jīng)理，或者網(wǎng)絡層、數(shù)據(jù)層、硬件相關行業(yè)的產(chǎn)品人，在入行之后跟隨產(chǎn)品的迭代，也能夠或多或少掌握很多專業(yè)技術知識，有些可能還會轉(zhuǎn)型為架構(gòu)師。但是這些專業(yè)性較強，也有很多高效但不通用的方法，在此不再展開討論(當然這些我也不會)。
其實我也很想看到有產(chǎn)品同仁總結(jié)分享，自己是如何在工作中從0技術一步步學習成長的。很遺憾這種經(jīng)歷我沒有，也寫不出來。
04 懂技術，然后呢?
當我們真的了解基本的技術，理解開發(fā)人員之后，緊接著我們將面臨一個嚴重的問題：用技術思維設計產(chǎn)品，或因為技術思維而影響產(chǎn)品設計。
因為我本身在這兩年的產(chǎn)品工作中一直在面臨這個問題，也陷入了“掙扎”與“精神內(nèi)耗”。
當我們在功能設計完成后，與研發(fā)進行評審或日常溝通時，會不自覺的被技術同事代入“這個功能很難做”、“這個功能花的時間會很長”的思維怪圈。最后可能自己因為同理心等原因，主動就把功能簡化了，尤其是在進度計劃已經(jīng)確定的條件下。
一來二去，后續(xù)迭代過程中，便會自覺把一些技術難題，或者邏輯變更大的需求砍掉，逐漸讓迭代方案從功能層面越來越弱。
原本懂技術是件好事，我們可以甄別出設計風險，和技術一起想出更優(yōu)解決方案，或者在技術同事“敷衍”、“夸大難度”時進行合理識別。但久而久之，我們原本很重要的產(chǎn)品思維、對設計體驗的極致要求，占比會持續(xù)走低。
當我發(fā)現(xiàn)這個問題之后，在后續(xù)的設計中雖然還會考慮方案的難度，但會刻意提醒自己：我要對用戶負責，要對產(chǎn)品的體驗與價值負責。
這也是很多技術轉(zhuǎn)型產(chǎn)品的過程中必將遇到的問題，當我們對產(chǎn)品有更高的要求時，技術思維也會讓我們陷入瓶頸。
于是出現(xiàn)了現(xiàn)階段的辯證關系：城外的人想進來，城里的人想出去。
05 不懂技術有優(yōu)勢嗎?
其實我挺羨慕交互設計和UI設計的，但也可能是因為自己不了解。其實他們在推進新規(guī)范與新體驗時，也勢必會遇到技術上的障礙。
但是真正的靈感，或者真正好的功能與體驗，更可能由這些不懂技術的產(chǎn)品人提出來。因為他們是更專注的，目標更清晰的。
在現(xiàn)如今這個創(chuàng)新乏力的環(huán)境下，只有真正的觀察用戶、觀察競品、體驗自己的產(chǎn)品，才能真正想出一些能夠擊中用戶痛點的【微創(chuàng)新】功能，才能在現(xiàn)有版本的基礎上創(chuàng)造出更極致的交互，設計出更有溫度的功能。而這些，需要花時間探索，且不使用技術思維探索。
當我們真正有了創(chuàng)新的想法，更愿意讓想法落地，去堅持和技術battle，堅持實現(xiàn)自己的方案，且不打折扣。當然這個過程很難，當我們真正懂技術又不精通技術時，可能自己就。。。
放棄了~
所以我一直在刻意鍛煉自己，在思考時不去想落地。但這，也挺難的。就像“明知故犯”一樣，我知道這個設計做不出來，或者沒時間做，那我還要繼續(xù)想嗎?
06 到底應該怎樣?
說了這么多，總結(jié)一下我的觀點：
剛?cè)胄械漠a(chǎn)品人，不要把技術當做首要目標，更重要的依然是產(chǎn)品的設計能力、邏輯能力、協(xié)作能力、行業(yè)知識等。
工作中遇到技術問題或想和研發(fā)平等對話時，選擇可以“即學即用”的知識點快速突破，同時可采用我的建議，從數(shù)據(jù)庫和日志層面快速上手。
但是無論何時，不要丟掉產(chǎn)品的核心思維和對用戶體驗的追求。
當我們能力達到較高水平時，或者擁有較高話語權時，還是要做一個“偏執(zhí)”的產(chǎn)品人，畢竟——產(chǎn)品經(jīng)理可以改變世界【手動狗頭】
07 寫在最后
真正一款好的產(chǎn)品問世，既要有良好的產(chǎn)品設計，又要有嚴謹?shù)募夹g支撐，本身兩者應通力合作，一起為了目標而努力。產(chǎn)品和技術不應該被對立，我們理應合力采用十八般武藝讓理想逐漸照進現(xiàn)實。
學習技術，是為了更好的工作;不學習技術，也可以更好的工作;吵架與爭執(zhí)，一定不會更好的工作。
堅守設計理念與愿景，路要一步一個腳印地走。
來源：人人都是產(chǎn)品經(jīng)理
以上是關于用戶增長師的相關信息，以供大家查看了解。想要了解更多用戶增長師信息，第一時間了解用戶增長師相關資訊，敬請關注唯學網(wǎng)用戶增長師欄目，如有任何疑問也可在線留言，小編會為您在第一時間解答!
