辯證難題 - 產(chǎn)品經(jīng)理要不要懂技術(shù)

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