編輯導讀：為什么產品經理和程序員之間總是發生矛盾，很多時候是因為認知不同。如果產品經理能掌握更多的技術支持，相信溝通會更加順暢。本文作者將圍繞思維碰撞、工作流程、基礎技術、技術術語、溝通技巧等多個維度進行講解，希望對你有幫助。

上一篇文章我們講了《產品經理要不要懂技術的底層邏輯》，沒看過的同學可以先行閱讀，再回來看本章節內容可能理解會更深刻。

由于篇幅原因，并未講解技術的具體內容，本章將圍繞思維碰撞、工作流程、基礎技術、技術術語、溝通技巧等多個維度進行講解，所有內容均為互聯網內容，爭取用簡單的語言來描述技術內容，讓非技術出身產品能輕松理解、學以致用。

01 思維碰撞

1. 產品思維

我理解的產品思維，是通過用戶和數據發現現象，分析現象的根本原因和是否需要解決，然后提出具體的解決方案，并將解決方案標準化和產品化的過程；

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

1. 有觀點和立場：不能出現無目的、無意義的內容
2. 是一個整體：不能出現毫無關聯的內容
3. 嚴謹和邏輯自洽：不能出現自相矛盾的內容

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

2. 技術思維

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

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

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

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

產品經理可以在一開始不講“為什么要這么做”，但一定要在開發詢問時能及時進行解答，以專業的姿態讓需求變得完整、前后呼應；

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

02 人員分工和流程

1. 崗位分工和職責

• UI設計：對軟件人機交互的視覺效果設計，負責頁面美觀度、切圖
• 前端：將設計好的圖片，轉換成用戶能操作的軟件界面或HTML頁面，負責產品界面和交互
• 后端：提供數據庫、平臺和接口設計，負責功能邏輯實現和數據存儲處理
• 測試：驗收開發出來的產品與預期是否相符，負責把關產品質量
• DBA：負責數據庫的管理和運維，保證數據庫的穩定、安全、完整和高性能
• 運維：對網絡、服務器、系統環境、服務的生命周期各個階段的運營與維護，在成本、穩定性、效率上達成一致可接受的狀態

2. 產品開發流程

一個完整的開發流程如下：

03 基礎技術內容

1. WEB基礎技術

• URL：統一資源定位符，用來訪問網頁、圖片、視頻等內容，互聯網上所有資源都有一個唯一的URL，以http開頭，可以是ip也可以是域名，其實是一種路徑
• TCP/IP：是指能夠在多個不同網絡間實現信息傳輸的協議簇，它是在網絡的使用中的最基本的通信協議
• HTTP：全球超文本傳輸協議，基于TCP之上，是互聯網的基本協議，所有的WWW服務都必須遵守HTTP協議，保證客戶端與服務器之間的通信
• SSL：可以在互聯網上提供秘密性傳輸，使用戶/服務器應用之間的通信不被攻擊者竊聽，并且始終對服務器進行認證，一般用于安全要求較高的系統，比如網絡支付

2. 前端技術

• SDK：指輔助開發某一類軟件的相關文檔、范例和工具的集合，包括軟件、框架、硬件、系統等，以前端使用最為廣泛，可以極大減少開發難度，提高開發效率；比如我么要接入移動支付，就可以下載一個支付寶的客戶端SDK，配置并調用支付接口即可；
• POST/GET：是兩種常見的http請求方式，Get 是用來從服務器上獲得數據，而 Post 是用來向服務器上傳遞數據；Get數據放在URL中，對用戶可見，Post通過request body傳遞參數，對用戶不可見；
• AJAX：使用異步數據傳輸，網頁應用能夠快速地將增量更新呈現在用戶界面上，而不需要重載（刷新）整個頁面，這使得程序能夠更快地回應用戶的操作，在用戶端體驗會更加友好（刷新頁面在視覺上會出現跳幀讓用戶失去了焦點）；
• COOKIE/SESSION：兩種會話儲存技術，多用于用戶身份識別或狀態存儲，cookie是儲存在本地（瀏覽器中可修改查看），session儲存在服務器會更安全；
• TOKEN：服務端生成的一串字符串，以作客戶端進行請求的一個令牌，一般用作用戶登錄后判斷身份，無需再次輸入賬號密碼，就像我們拿卡代替鑰匙開鎖一樣；
• 原生開發：是指在Android、IOS等移動平臺上利用官方提供的開發語言、開發類庫、開發工具進行App開發，優點是體驗好、性能佳；缺點是不同手機系統要開發兩遍，開發周期長，成本高；
• 混合開發：使用原生（native）+ HTML5 進行開發，然后打包成不同平臺的app，優點是開發快，UI表現一致；缺點是性能和原生有差距，有些能力無法實現；
• 小程序：是一種不需要下載安裝即可使用的應用，用戶用完即走，不用關心是否安裝太多應用的問題；小程序開發門檻低，能滿足大多數業務需求，使用也很方便，由微信16年第一次提出，現在幾乎所有超級APP都內置了小程序；

3. 后端技術

• 短連接：客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接，大部分web服務都為短連接，比較省資源；
• 長連接：客戶端和服務器在建立一次連接后，一直保持連接，多用于操作頻繁的、對消息及時性要求較高的場景，比如游戲、即時聊天；
• 同步：按順序執行，調用某個東西是時，調用方得等待這個調用返回結果才能繼續往后執行；比如ATM機取錢，取完一個才能下一個；
• 異步：調用方不會立即得到結果，而是在調用發出后調用者可用繼續執行后續操作，被調用者通過狀態來通知調用者，或者通過回調函數來處理這個調用；比如點餐，點完后旁邊等待出餐，下一個繼續點餐，出餐后用喇叭通知取餐；
• 隊列：可以理解為現實生活中的排隊，隊尾進隊頭出，即“先進先出”，常用于秒殺或團購活動中，防止并發過大導致服務宕機；
• 棧：又叫堆棧，采用“后進先出”規則，比如進出電梯，后進去的因為站在門口要先出去；

4. API接口

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

接口的設計極大的減少了依賴，提高了數據訪問的安全性，技術人員常說的前后端分離，就是讓前后端專注于自己的業務邏輯，通過標準的接口來進行數據對接。

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

5. 行業名詞

• 服務器：在網絡中為其它客戶機提供計算或者應用服務，我們的代碼就要部署到服務器上，和我們的電腦主機類似，但它比電腦運行的更快，每個服務器可以分配一個公網的ip，才能對外提供訪問服務；
• 系統：一般指運行在服務器上的操作系統，應用程序需要在操作系統上才能運行，常見的服務器系統有windows、linux（開源）；
• 數據庫：按照數據結構來組織、存儲和管理數據的倉庫；分關系型數據庫（如：Mysql，SqlServer）和非關系型數據庫（如：MongoDB）；類似現實中的倉庫，貨架對應的就是數據表，貨架上每一格貨物類似數據表中的一條條數據；
• 緩存：指可以進行高速數據交換的存儲器，它先于內存與CPU交換數據，因此速率很快，緩存的作用不直接訪問數據庫，防止訪問量過大導致數據庫宕機，提高我們數據的訪問效率；如常用的內存型緩存Redis、Memcache；
• 定時任務：在服務器上每隔一段時間執行一段代碼，以取得某個結果的操作，一般使用crontab，我們常將一些比較耗時的比如數據統計，放在凌晨訪問量少的時候定時執行，生成數據表、發郵件；

6. 工具的使用

• IDE：是用于提供程序開發環境的應用程序，一般包括代碼編輯器、編譯器、調試器和圖形用戶界面等工具（男人的工具箱，里面什么都有），IDE的出現讓開發過程變得簡單、便捷，開發們都有自己喜歡的IDE，也通過不斷優化和配置形成自己獨特的習慣，它是士兵上戰場的武器；
• Postman：是一個接口測試工具，它相當于一個客戶端，可以模擬用戶發起的各類HTTP請求，將請求數據發送至服務端，獲取對應的響應結果，驗證響應中的結果數據是否和預期值相匹配；
• Firebug：也叫開發者工具，它是集HTML查看和編輯、Javascript控制臺、網絡狀況監視器于一體，是前端開發得力工具，可以直接在瀏覽器中調試代碼；原本是火狐瀏覽器的一個擴展，由于過于優秀極大的方便前端開發調試，目前瀏覽器都已支持；

04 技術常說的術語

1. 技術術語

搭環境：分開發生產和產品運行環境。

• 開發環境：新員工第一天入職，都要先搭建自己的開發環境，即崗位所需要的IDE、運行、調試軟件的集合，還會根據自己的習慣來配置IDE，提高開發效率；
• 運行環境：產品開發完后需要放到服務器上，這樣用戶才能使用和訪問，就需要搭建服務器環境，同樣的也是一些列的軟件、插件的集合，有的時候還需要優化下操作系統的配置，就像你優化自己的電腦設置一樣；
• 環境分類：運行環境還要區分dev（開發）、test（測試）、product（生產）等環境；嚴謹一些的還有預發布環境（使用的是生產環境的數據，但代碼還沒有發布到生產環境），灰度環境（小部分人群可以看到）環境等等；

建表：根據業務邏輯需要，設計數據庫表結構，用于存儲數據，主要是后端開發的工作，也有可能是DBA的工作；

寫死：

• 是指參數或者配置內容寫死，代表著這些內容是要寫在代碼里，修改需要重新發布代碼；如用戶注冊時選擇省/市，可以直接寫在前端代碼里，無需通過后端提供接口，就省去了建表和寫接口的時間；
• 寫死的好處就是開發效率高，壞處就是修改不方便，需要重新發布版本；

2. 開發說的“做不了”包含了哪些信息？

1. 現有的技術根本無法實現，也就是經常說的超出了技術邊界，比如想要下載速度達到10G/s
2. 受限于公司研發能力和技術棧限制，超出了能力邊界，比如原本是做小程序的要求去做人工智能開發
3. 平臺或生態的限制，不支持這種做法，或者沒有開放對應的接口，比如微信沒有對外開放獲取好友列表的接口
4. 現有技術架構不支持，如果要做成本會很高，需要重寫底層代碼，時間緊、任務重、不劃算
5. 實現方法比較復雜，沒有快速實現的方法，無法滿足短時間內實現的要求
6. 覺得所提的需求價值不大，沒有做的意義，也沒有動力去做
7. 單純的不想做
8. 煩你

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

05 和開發友好溝通

1. 協調估時方法

開發估時主要都由團隊中的技術主管來把控，他們有責任來輔助估時、把控進度、協調任務；

因此這里說的方法不是讓產品經理來代替開發估時，而是在遇到估時遠超預期時，我們所能采取的策略；

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

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

• 先評估個人能力和所分配的任務是否匹配
• 然后詢問原因，可能會發現信息不對稱（如對需求的理解不對、對代碼庫的了解、對某些技術不了解等），產品經理可以引導其找對應的人解決，或者直接幫他解決，進行信息對稱
• 最后，這個人可能說不出為什么，也沒有意愿去解決時長過長的問題，產品經理有必要讓開發對他自己的任務進行拆解，可以按開發步驟、接口數、邏輯點拆解到天，直到無法拆解為止
• 可能有人說，我沒這個權力啊，我做不到讓開發和我詳細拆解任務，很多人確實沒有，但問題還是要解決，可以好言好語、可以求助他人，反正是想盡一切辦法來解決

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

2. 任務估時難度判斷

看邏輯：

• • 邏輯本身很簡單，沒有很多的判斷（比如只是增刪改查），功能也比較獨立的，基本上評估1~2天是比較合理的，手腳快的可能半天就搞定了
  • 如果知識純展示，從幾張表中拉去數據，加一些簡單的判斷，前端的復雜度和交互相關，后端復雜度較低，基本上也就半天一天的事
  • 如果只是替換文字內容、圖片、簡單樣式（顏色、大小等），哪怕頁面比較多，也可以批量操作完成，可能繁瑣但不復雜，可以在短時間內完成，屬于舉手之勞

看資料：

• • 一般有現成的接口文檔和SDK的，實現起來也較為簡單，花點時間研究下即可使用
  • 有通用組件的，且之前有功能實現過，如果變化不大可以直接使用

通用復雜度：

• • 兼容性問題會比較復雜，特別是一些不常用機型的的問題，有時還不好定位問題
  • 性能問題通常比較難，需要一點點的去分析找到性能瓶頸，并測試優化
  • 核心功能會比較復雜，尤其是要提供給很多模塊使用的功能
  • 研究性的工作通常比較耗時，產品經理在做需求時，如果發現可能需要用到新的技術，可以提前和開發打招呼，讓他們先研究起來，把耗時問題先前置解決

3. 溝通和提問

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

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

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

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

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

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

不輕易放棄，不接受模棱兩可的答案，對開發說的內容不滿意應該繼續追問，直到拿到令你信服的答案；

產品經理為產品的最終結果負責，遇到問題，沒有人會反過來替你想怎么解決，也不要指望問題能自動消失，能解決問題的只有你，懂技術只是手段，不是目的；

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

作者：周武，曾就職于騰訊、邊鋒，現在一家上市公司產品負責人；公眾號：周武說

本文由@周武 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 pexels，基于CC0協議。