本章將圍繞思維碰撞、工作流程、基礎(chǔ)技術(shù)、技術(shù)術(shù)語、溝通技巧等多個維度進行講解，所有內(nèi)容均為互聯(lián)網(wǎng)內(nèi)容，爭取用簡單的語言來描述技術(shù)內(nèi)容，讓非技術(shù)出身產(chǎn)品能輕松理解、學(xué)以致用。

01

思維碰撞

產(chǎn)品思維

我理解的產(chǎn)品思維，是通過用戶和數(shù)據(jù)發(fā)現(xiàn)現(xiàn)象，分析現(xiàn)象的根本原因和是否需要解決，然后提出具體的解決方案，并將解決方案標(biāo)準(zhǔn)化和產(chǎn)品化的過程；

就像寫命題議論文，命題人所描述的可能是一個問題、一種現(xiàn)象、一種感受、一種情緒、甚至是一個結(jié)果，我們要去理解他的真實意圖，尋找有效的論點和論據(jù)組成解決方案，可以從多個角度進行論證，同時要求我們在論證時做到：

有觀點和立場：不能出現(xiàn)無目的、無意義的內(nèi)容

是一個整體：不能出現(xiàn)毫無關(guān)聯(lián)的內(nèi)容

嚴(yán)謹(jǐn)和邏輯自洽：不能出現(xiàn)自相矛盾的內(nèi)容

整個過程是層層遞進且存在著不確定性，分析出的問題可能是錯的，提出的解決方案也可能解決不了問題，因為結(jié)果的不確定性，這時我們只會考慮解決方案的可行性，是否能解決用戶的問題，以及如何提高解決方案成功的概率，不會對實現(xiàn)方式過多的思考。

技術(shù)思維

技術(shù)思維是一種方案實現(xiàn)的思維方式，基于已經(jīng)證實的原理和確定的數(shù)據(jù)為支撐，并從影響面、編碼復(fù)雜度、投入成本等三個變量評估實現(xiàn)難度的過程；

有點像解數(shù)學(xué)題，在已知的數(shù)學(xué)公式中尋找解決思路，可以存在多種解法，但答案只有一個，最終只有有解和無解兩種結(jié)果，要不就找到了答案，要不就是題目本身錯了；

在思維碰撞時，大多的爭論都在產(chǎn)品邏輯前后矛盾和邏輯缺失，以至于開發(fā)要自己腦補邏輯，在開發(fā)心中產(chǎn)生了極大的不確定性，技術(shù)思維是不擅長解不確定性的題的，因此會不斷提問來修補確認(rèn)，作為產(chǎn)品經(jīng)理，我們在提需求時要盡量消除這種不確定性；

然后，由于之前對實現(xiàn)方式缺乏思考，在評估后發(fā)現(xiàn)實現(xiàn)難度過高，開發(fā)會本能的出現(xiàn)退縮的現(xiàn)象，并質(zhì)疑題目是否正確，這時，我們需要拋出需求價值（觀點和立場）來強化需求的目的，拔高需求的投產(chǎn)比，讓開發(fā)能感受到完成帶來的意義，以此根據(jù)需求目的提出對應(yīng)方案以此來降低實現(xiàn)難度；

產(chǎn)品經(jīng)理可以在一開始不講“為什么要這么做”，但一定要在開發(fā)詢問時能及時進行解答，以專業(yè)的姿態(tài)讓需求變得完整、前后呼應(yīng)；

在做需求時，對一些感覺可能會有障礙的功能，先做提前溝通，在影響面、編碼復(fù)雜度、投入成本三個變量進行預(yù)判，并做好了充分的邏輯思考，或者適當(dāng)修改自己的方案，以滿足產(chǎn)品最優(yōu)解，這就是具備了一定的技術(shù)思維。

02

人員分工和流程

崗位分工和職責(zé)

• UI設(shè)計：對軟件人機交互的視覺效果設(shè)計，負(fù)責(zé)頁面美觀度、切圖

• 前端：將設(shè)計好的圖片，轉(zhuǎn)換成用戶能操作的軟件界面或HTML頁面，負(fù)責(zé)產(chǎn)品界面和交互

• 后端：提供數(shù)據(jù)庫、平臺和接口設(shè)計，負(fù)責(zé)功能邏輯實現(xiàn)和數(shù)據(jù)存儲處理

• 測試：驗收開發(fā)出來的產(chǎn)品與預(yù)期是否相符，負(fù)責(zé)把關(guān)產(chǎn)品質(zhì)量

• DBA：負(fù)責(zé)數(shù)據(jù)庫的管理和運維，保證數(shù)據(jù)庫的穩(wěn)定、安全、完整和高性能

• 運維：對網(wǎng)絡(luò)、服務(wù)器、系統(tǒng)環(huán)境、服務(wù)的生命周期各個階段的運營與維護，在成本、穩(wěn)定性、效率上達成一致可接受的狀態(tài)

產(chǎn)品開發(fā)流程

一個完整的開發(fā)流程如下：

03

基礎(chǔ)技術(shù)內(nèi)容

WEB基礎(chǔ)技術(shù)

• URL：統(tǒng)一資源定位符，用來訪問網(wǎng)頁、圖片、視頻等內(nèi)容，互聯(lián)網(wǎng)上所有資源都有一個唯一的URL，以http開頭，可以是ip也可以是域名，其實是一種路徑

• TCP/IP：是指能夠在多個不同網(wǎng)絡(luò)間實現(xiàn)信息傳輸?shù)膮f(xié)議簇，它是在網(wǎng)絡(luò)的使用中的最基本的通信協(xié)議

• HTTP：全球超文本傳輸協(xié)議，基于TCP之上，是互聯(lián)網(wǎng)的基本協(xié)議，所有的WWW服務(wù)都必須遵守HTTP協(xié)議，保證客戶端與服務(wù)器之間的通信

• SSL：可以在互聯(lián)網(wǎng)上提供秘密性傳輸，使用戶/服務(wù)器應(yīng)用之間的通信不被攻擊者竊聽，并且始終對服務(wù)器進行認(rèn)證，一般用于安全要求較高的系統(tǒng)，比如網(wǎng)絡(luò)支付

前端技術(shù)

• SDK：指輔助開發(fā)某一類軟件的相關(guān)文檔、范例和工具的集合，包括軟件、框架、硬件、系統(tǒng)等，以前端使用最為廣泛，可以極大減少開發(fā)難度，提高開發(fā)效率；比如我么要接入移動支付，就可以下載一個支付寶的客戶端SDK，配置并調(diào)用支付接口即可；

• POST/GET：是兩種常見的http請求方式，Get 是用來從服務(wù)器上獲得數(shù)據(jù)，而 Post 是用來向服務(wù)器上傳遞數(shù)據(jù)；Get數(shù)據(jù)放在URL中，對用戶可見，Post通過request body傳遞參數(shù)，對用戶不可見；

• AJAX：使用異步數(shù)據(jù)傳輸，網(wǎng)頁應(yīng)用能夠快速地將增量更新呈現(xiàn)在用戶界面上，而不需要重載（刷新）整個頁面，這使得程序能夠更快地回應(yīng)用戶的操作，在用戶端體驗會更加友好（刷新頁面在視覺上會出現(xiàn)跳幀讓用戶失去了焦點）；

• COOKIE/SESSION：兩種會話儲存技術(shù)，多用于用戶身份識別或狀態(tài)存儲，cookie是儲存在本地（瀏覽器中可修改查看），session儲存在服務(wù)器會更安全；

• TOKEN：服務(wù)端生成的一串字符串，以作客戶端進行請求的一個令牌，一般用作用戶登錄后判斷身份，無需再次輸入賬號密碼，就像我們拿卡代替鑰匙開鎖一樣；

• 原生開發(fā)：是指在Android、IOS等移動平臺上利用官方提供的開發(fā)語言、開發(fā)類庫、開發(fā)工具進行App開發(fā)，優(yōu)點是體驗好、性能佳；缺點是不同手機系統(tǒng)要開發(fā)兩遍，開發(fā)周期長，成本高；

• 混合開發(fā)：使用原生（native）+ HTML5 進行開發(fā)，然后打包成不同平臺的app，優(yōu)點是開發(fā)快，UI表現(xiàn)一致；缺點是性能和原生有差距，有些能力無法實現(xiàn)；

• 小程序：是一種不需要下載安裝即可使用的應(yīng)用，用戶用完即走，不用關(guān)心是否安裝太多應(yīng)用的問題；小程序開發(fā)門檻低，能滿足大多數(shù)業(yè)務(wù)需求，使用也很方便，由微信16年第一次提出，現(xiàn)在幾乎所有超級APP都內(nèi)置了小程序；

后端技術(shù)

• 短連接：客戶端和服務(wù)器每進行一次HTTP操作，就建立一次連接，任務(wù)結(jié)束就中斷連接，大部分web服務(wù)都為短連接，比較省資源；

• 長連接：客戶端和服務(wù)器在建立一次連接后，一直保持連接，多用于操作頻繁的、對消息及時性要求較高的場景，比如游戲、即時聊天；

• 同步：按順序執(zhí)行，調(diào)用某個東西是時，調(diào)用方得等待這個調(diào)用返回結(jié)果才能繼續(xù)往后執(zhí)行；比如ATM機取錢，取完一個才能下一個；

• 異步：調(diào)用方不會立即得到結(jié)果，而是在調(diào)用發(fā)出后調(diào)用者可用繼續(xù)執(zhí)行后續(xù)操作，被調(diào)用者通過狀態(tài)來通知調(diào)用者，或者通過回調(diào)函數(shù)來處理這個調(diào)用；比如點餐，點完后旁邊等待出餐，下一個繼續(xù)點餐，出餐后用喇叭通知取餐；

• 隊列：可以理解為現(xiàn)實生活中的排隊，隊尾進隊頭出，即“先進先出”，常用于秒殺或團購活動中，防止并發(fā)過大導(dǎo)致服務(wù)宕機；

• 棧：又叫堆棧，采用“后進先出”規(guī)則，比如進出電梯，后進去的因為站在門口要先出去；

API接口

是客戶端和服務(wù)端進行數(shù)據(jù)傳輸和交互的協(xié)議，是兩個系統(tǒng)間同步數(shù)據(jù)的一個途徑，一般由錯誤代碼、錯誤消息、數(shù)據(jù)內(nèi)容三部分組成，可以是JSON、XML、或字符串等形式返回，由服務(wù)端開發(fā)編寫，且要提供接口文檔以方便前端使用。

接口的設(shè)計極大的減少了依賴，提高了數(shù)據(jù)訪問的安全性，技術(shù)人員常說的前后端分離，就是讓前后端專注于自己的業(yè)務(wù)邏輯，通過標(biāo)準(zhǔn)的接口來進行數(shù)據(jù)對接。

需要注意的是，為了讓用戶體驗更加友好，盡量使用非專業(yè)的文字來描述錯誤消息，不要顯示錯誤代碼在頁面上。

行業(yè)名詞

• 服務(wù)器：在網(wǎng)絡(luò)中為其它客戶機提供計算或者應(yīng)用服務(wù)，我們的代碼就要部署到服務(wù)器上，和我們的電腦主機類似，但它比電腦運行的更快，每個服務(wù)器可以分配一個公網(wǎng)的ip，才能對外提供訪問服務(wù)；

• 系統(tǒng)：一般指運行在服務(wù)器上的操作系統(tǒng)，應(yīng)用程序需要在操作系統(tǒng)上才能運行，常見的服務(wù)器系統(tǒng)有windows、linux（開源）；

• 數(shù)據(jù)庫：按照數(shù)據(jù)結(jié)構(gòu)來組織、存儲和管理數(shù)據(jù)的倉庫；分關(guān)系型數(shù)據(jù)庫（如：Mysql，SqlServer）和非關(guān)系型數(shù)據(jù)庫（如：MongoDB）；類似現(xiàn)實中的倉庫，貨架對應(yīng)的就是數(shù)據(jù)表，貨架上每一格貨物類似數(shù)據(jù)表中的一條條數(shù)據(jù)；

• 緩存：指可以進行高速數(shù)據(jù)交換的存儲器，它先于內(nèi)存與CPU交換數(shù)據(jù)，因此速率很快，緩存的作用不直接訪問數(shù)據(jù)庫，防止訪問量過大導(dǎo)致數(shù)據(jù)庫宕機，提高我們數(shù)據(jù)的訪問效率；如常用的內(nèi)存型緩存Redis、Memcache；

• 定時任務(wù)：在服務(wù)器上每隔一段時間執(zhí)行一段代碼，以取得某個結(jié)果的操作，一般使用crontab，我們常將一些比較耗時的比如數(shù)據(jù)統(tǒng)計，放在凌晨訪問量少的時候定時執(zhí)行，生成數(shù)據(jù)表、發(fā)郵件；

工具的使用

• IDE：是用于提供程序開發(fā)環(huán)境的應(yīng)用程序，一般包括代碼編輯器、編譯器、調(diào)試器和圖形用戶界面等工具（男人的工具箱，里面什么都有），IDE的出現(xiàn)讓開發(fā)過程變得簡單、便捷，開發(fā)們都有自己喜歡的IDE，也通過不斷優(yōu)化和配置形成自己獨特的習(xí)慣，它是士兵上戰(zhàn)場的武器；

• Postman：是一個接口測試工具，它相當(dāng)于一個客戶端，可以模擬用戶發(fā)起的各類HTTP請求，將請求數(shù)據(jù)發(fā)送至服務(wù)端，獲取對應(yīng)的響應(yīng)結(jié)果，驗證響應(yīng)中的結(jié)果數(shù)據(jù)是否和預(yù)期值相匹配；

• Firebug：也叫開發(fā)者工具，它是集HTML查看和編輯、Javascript控制臺、網(wǎng)絡(luò)狀況監(jiān)視器于一體，是前端開發(fā)得力工具，可以直接在瀏覽器中調(diào)試代碼；原本是火狐瀏覽器的一個擴展，由于過于優(yōu)秀極大的方便前端開發(fā)調(diào)試，目前瀏覽器都已支持；

04

技術(shù)常說的術(shù)語

技術(shù)術(shù)語

• 搭環(huán)境：分開發(fā)生產(chǎn)和產(chǎn)品運行環(huán)境。

  • 開發(fā)環(huán)境：新員工第一天入職，都要先搭建自己的開發(fā)環(huán)境，即崗位所需要的IDE、運行、調(diào)試軟件的集合，還會根據(jù)自己的習(xí)慣來配置IDE，提高開發(fā)效率；

  • 運行環(huán)境：產(chǎn)品開發(fā)完后需要放到服務(wù)器上，這樣用戶才能使用和訪問，就需要搭建服務(wù)器環(huán)境，同樣的也是一些列的軟件、插件的集合，有的時候還需要優(yōu)化下操作系統(tǒng)的配置，就像你優(yōu)化自己的電腦設(shè)置一樣；

  • 環(huán)境分類：運行環(huán)境還要區(qū)分dev（開發(fā)）、test（測試）、product（生產(chǎn)）等環(huán)境；嚴(yán)謹(jǐn)一些的還有預(yù)發(fā)布環(huán)境（使用的是生產(chǎn)環(huán)境的數(shù)據(jù)，但代碼還沒有發(fā)布到生產(chǎn)環(huán)境），灰度環(huán)境（小部分人群可以看到）等等；

• 建表：根據(jù)業(yè)務(wù)邏輯需要，設(shè)計數(shù)據(jù)庫表結(jié)構(gòu)，用于存儲數(shù)據(jù)，主要是后端開發(fā)的工作，也有可能是DBA的工作；

• 寫死：

  • 是指參數(shù)或者配置內(nèi)容寫死，代表著這些內(nèi)容是要寫在代碼里，修改需要重新發(fā)布代碼；如用戶注冊時選擇省/市，可以直接寫在前端代碼里，無需通過后端提供接口，就省去了建表和寫接口的時間；

  • 寫死的好處就是開發(fā)效率高，壞處就是修改不方便，需要重新發(fā)布版本；

開發(fā)說的“做不了”包含了哪些信息？

現(xiàn)有的技術(shù)根本無法實現(xiàn)，也就是經(jīng)常說的超出了技術(shù)邊界，比如想要下載速度達到10G/s

受限于公司研發(fā)能力和技術(shù)棧限制，超出了能力邊界，比如原本是做小程序的要求去做人工智能開發(fā)

平臺或生態(tài)的限制，不支持這種做法，或者沒有開放對應(yīng)的接口，比如微信沒有對外開放獲取好友列表的接口

現(xiàn)有技術(shù)架構(gòu)不支持，如果要做成本會很高，需要重寫底層代碼，時間緊、任務(wù)重、不劃算

實現(xiàn)方法比較復(fù)雜，沒有快速實現(xiàn)的方法，無法滿足短時間內(nèi)實現(xiàn)的要求

覺得所提的需求價值不大，沒有做的意義，也沒有動力去做

單純的不想做

煩你

搞清楚具體是哪一種情況，然后才能有效的進行判斷和解決。

05

和開發(fā)友好溝通

協(xié)調(diào)估時方法

開發(fā)估時主要都由團隊中的技術(shù)主管來把控，他們有責(zé)任來輔助估時、把控進度、協(xié)調(diào)任務(wù)；

因此這里說的方法不是讓產(chǎn)品經(jīng)理來代替開發(fā)估時，而是在遇到估時遠超預(yù)期時，我們所能采取的策略；

判斷估時第一步：我們先看總時長，找出將總時長拉長的人的時間節(jié)點，看是否是任務(wù)安排不合理（個別人任務(wù)多）、還是順序銜接有問題（出現(xiàn)時間真空）、還是有其他任務(wù)打擾；

判斷估時第二步：解決個別人時長過長，有些人可能任務(wù)量正常、復(fù)雜度和其他人差不多，但估時就是比別人多；

• 先評估個人能力和所分配的任務(wù)是否匹配

• 然后詢問原因，可能會發(fā)現(xiàn)信息不對稱（如對需求的理解不對、對代碼庫的了解、對某些技術(shù)不了解等），產(chǎn)品經(jīng)理可以引導(dǎo)其找對應(yīng)的人解決，或者直接幫他解決，進行信息對稱

• 最后，這個人可能說不出為什么，也沒有意愿去解決時長過長的問題，產(chǎn)品經(jīng)理有必要讓開發(fā)對他自己的任務(wù)進行拆解，可以按開發(fā)步驟、接口數(shù)、邏輯點拆解到天，直到無法拆解為止

• 可能有人說，我沒這個權(quán)力啊，我做不到讓開發(fā)和我詳細拆解任務(wù)，很多人確實沒有，但問題還是要解決，可以好言好語、可以求助他人，反正是想盡一切辦法來解決

判斷估時第三步：經(jīng)過前兩步后，發(fā)現(xiàn)時長還是超，那只有砍掉一些不那么緊要的需求，按時交付永遠比完美上線更有價值。

任務(wù)估時難度判斷

看邏輯：

• 邏輯本身很簡單，沒有很多的判斷（比如只是增刪改查），功能也比較獨立的，基本上評估1~2天是比較合理的，手腳快的可能半天就搞定了

• 如果知識純展示，從幾張表中拉去數(shù)據(jù)，加一些簡單的判斷，前端的復(fù)雜度和交互相關(guān)，后端復(fù)雜度較低，基本上也就半天一天的事

• 如果只是替換文字內(nèi)容、圖片、簡單樣式（顏色、大小等），哪怕頁面比較多，也可以批量操作完成，可能繁瑣但不復(fù)雜，可以在短時間內(nèi)完成，屬于舉手之勞

看資料：

• 一般有現(xiàn)成的接口文檔和SDK的，實現(xiàn)起來也較為簡單，花點時間研究下即可使用

• 有通用組件的，且之前有功能實現(xiàn)過，如果變化不大可以直接使用

通用復(fù)雜度：

• 兼容性問題會比較復(fù)雜，特別是一些不常用機型的的問題，有時還不好定位問題

• 性能問題通常比較難，需要一點點的去分析找到性能瓶頸，并測試優(yōu)化

• 核心功能會比較復(fù)雜，尤其是要提供給很多模塊使用的功能

• 研究性的工作通常比較耗時，產(chǎn)品經(jīng)理在做需求時，如果發(fā)現(xiàn)可能需要用到新的技術(shù)，可以提前和開發(fā)打招呼，讓他們先研究起來，把耗時問題先前置解決

溝通和提問

掌握一門知識，不是為了將別人比下去，而是讓自己做事情更有章法和效率；

懂技術(shù)能讓你在溝通時有底氣，不會被人問倒，也能根據(jù)對方的回答提出合理的問題，大多數(shù)事情是可以通過面對面溝通解決；

我們在溝通時要“多認(rèn)可、少諷刺”，盡量做到平等對話，有些直白的語言，換成另外一種話語，會換來意想不到的效果：

把“為什么做不了？”，換成“我想了解下具體原因？”或者“有沒有其他的方法實現(xiàn)？”

把“這么簡單的需求，要這么久嗎？”，換成“我覺得這塊時間有點久，能加快點嗎？”

把“X，有bug”，換成“這里操作不了，看下是我哪里操作有問題嗎？”

不輕易放棄，不接受模棱兩可的答案，對開發(fā)說的內(nèi)容不滿意應(yīng)該繼續(xù)追問，直到拿到令你信服的答案；

產(chǎn)品經(jīng)理為產(chǎn)品的最終結(jié)果負(fù)責(zé)，遇到問題，沒有人會反過來替你想怎么解決，也不要指望問題能自動消失，能解決問題的只有你，懂技術(shù)只是手段，不是目的；

鼓足勇氣、翻越障礙、高山登頂。

↘好文推薦：

Notion：后office時代的新生產(chǎn)力平臺

張小龍力薦的貝索斯演講：善良比聰明更重要

騰訊分享：AB實驗，歸因和解讀才是王道！

👇歡迎關(guān)注：

點個“在看”吧

總結(jié)

以上是生活随笔為你收集整理的干货 | 产品经理要了解的技术类知识的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。