內容干貨 | 產品經理要了解技術類知識
編輯導讀:為什么產品經理和程序員之間總是發生矛盾,很多時候是因為認知不同。如果產品經理能掌握更多的技術支持,相信溝通會更加順暢。本文作者將圍繞思維碰撞、工作流程、基礎技術、技術術語、溝通技巧等多個維度進行講解,希望對你有幫助。
上一篇文章我們講了《產品經理要不要懂技術的底層邏輯》,沒看過的同學可以先行閱讀,再回來看本章節內容可能理解會更深刻。
由于篇幅原因,并未講解技術的具體內容,本章將圍繞思維碰撞、工作流程、基礎技術、技術術語、溝通技巧等多個維度進行講解,所有內容均為互聯網內容,爭取用簡單的語言來描述技術內容,讓非技術出身產品能輕松理解、學以致用。
01 思維碰撞
1. 產品思維
我理解的產品思維,是通過用戶和數據發現現象,分析現象的根本原因和是否需要解決,然后提出具體的解決方案,并將解決方案標準化和產品化的過程;
就像寫命題議論文,命題人所描述的可能是一個問題、一種現象、一種感受、一種情緒、甚至是一個結果,我們要去理解他的真實意圖,尋找有效的論點和論據組成解決方案,可以從多個角度進行論證,同時要求我們在論證時做到:
- 有觀點和立場:不能出現無目的、無意義的內容
- 是一個整體:不能出現毫無關聯的內容
- 嚴謹和邏輯自洽:不能出現自相矛盾的內容
整個過程是層層遞進且存在著不確定性,分析出的問題可能是錯的,提出的解決方案也可能解決不了問題,因為結果的不確定性,這時我們只會考慮解決方案的可行性,是否能解決用戶的問題,以及如何提高解決方案成功的概率,不會對實現方式過多的思考。
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. 開發說的“做不了”包含了哪些信息?
- 現有的技術根本無法實現,也就是經常說的超出了技術邊界,比如想要下載速度達到10G/s
- 受限于公司研發能力和技術棧限制,超出了能力邊界,比如原本是做小程序的要求去做人工智能開發
- 平臺或生態的限制,不支持這種做法,或者沒有開放對應的接口,比如微信沒有對外開放獲取好友列表的接口
- 現有技術架構不支持,如果要做成本會很高,需要重寫底層代碼,時間緊、任務重、不劃算
- 實現方法比較復雜,沒有快速實現的方法,無法滿足短時間內實現的要求
- 覺得所提的需求價值不大,沒有做的意義,也沒有動力去做
- 單純的不想做
- 煩你
搞清楚具體是哪一種情況,然后才能有效的進行判斷和解決。?
05 和開發友好溝通
1. 協調估時方法
開發估時主要都由團隊中的技術主管來把控,他們有責任來輔助估時、把控進度、協調任務;
因此這里說的方法不是讓產品經理來代替開發估時,而是在遇到估時遠超預期時,我們所能采取的策略;
判斷估時第一步:我們先看總時長,找出將總時長拉長的人的時間節點,看是否是任務安排不合理(個別人任務多)、還是順序銜接有問題(出現時間真空)、還是有其他任務打擾;
判斷估時第二步:解決個別人時長過長,有些人可能任務量正常、復雜度和其他人差不多,但估時就是比別人多;
- 先評估個人能力和所分配的任務是否匹配
- 然后詢問原因,可能會發現信息不對稱(如對需求的理解不對、對代碼庫的了解、對某些技術不了解等),產品經理可以引導其找對應的人解決,或者直接幫他解決,進行信息對稱
- 最后,這個人可能說不出為什么,也沒有意愿去解決時長過長的問題,產品經理有必要讓開發對他自己的任務進行拆解,可以按開發步驟、接口數、邏輯點拆解到天,直到無法拆解為止
- 可能有人說,我沒這個權力啊,我做不到讓開發和我詳細拆解任務,很多人確實沒有,但問題還是要解決,可以好言好語、可以求助他人,反正是想盡一切辦法來解決
判斷估時第三步:經過前兩步后,發現時長還是超,那只有砍掉一些不那么緊要的需求,按時交付永遠比完美上線更有價值。
2. 任務估時難度判斷
看邏輯:
-
- 邏輯本身很簡單,沒有很多的判斷(比如只是增刪改查),功能也比較獨立的,基本上評估1~2天是比較合理的,手腳快的可能半天就搞定了
- 如果知識純展示,從幾張表中拉去數據,加一些簡單的判斷,前端的復雜度和交互相關,后端復雜度較低,基本上也就半天一天的事
- 如果只是替換文字內容、圖片、簡單樣式(顏色、大小等),哪怕頁面比較多,也可以批量操作完成,可能繁瑣但不復雜,可以在短時間內完成,屬于舉手之勞
看資料:
-
- 一般有現成的接口文檔和SDK的,實現起來也較為簡單,花點時間研究下即可使用
- 有通用組件的,且之前有功能實現過,如果變化不大可以直接使用
通用復雜度:
-
- 兼容性問題會比較復雜,特別是一些不常用機型的的問題,有時還不好定位問題
- 性能問題通常比較難,需要一點點的去分析找到性能瓶頸,并測試優化
- 核心功能會比較復雜,尤其是要提供給很多模塊使用的功能
- 研究性的工作通常比較耗時,產品經理在做需求時,如果發現可能需要用到新的技術,可以提前和開發打招呼,讓他們先研究起來,把耗時問題先前置解決
3. 溝通和提問
掌握一門知識,不是為了將別人比下去,而是讓自己做事情更有章法和效率;
懂技術能讓你在溝通時有底氣,不會被人問倒,也能根據對方的回答提出合理的問題,大多數事情是可以通過面對面溝通解決;
我們在溝通時要“多認可、少諷刺”,盡量做到平等對話,有些直白的語言,換成另外一種話語,會換來意想不到的效果:
把“為什么做不了?”,換成“我想了解下具體原因?”或者“有沒有其他的方法實現?”
把“這么簡單的需求,要這么久嗎?”,換成“我覺得這塊時間有點久,能加快點嗎?”
把“X,有bug”,換成“這里操作不了,看下是我哪里操作有問題嗎?”
不輕易放棄,不接受模棱兩可的答案,對開發說的內容不滿意應該繼續追問,直到拿到令你信服的答案;
產品經理為產品的最終結果負責,遇到問題,沒有人會反過來替你想怎么解決,也不要指望問題能自動消失,能解決問題的只有你,懂技術只是手段,不是目的;
鼓足勇氣、翻越障礙、高山登頂。
作者:周武,曾就職于騰訊、邊鋒,現在一家上市公司產品負責人;公眾號:周武說
本文由@周武 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 pexels,基于CC0協議。
感謝分享!
講真寫的都是很常用的溝通詞,能讓剛入門的看懂,點贊
感謝認可??
這個不就是起點學院的某個課程的課程筆記嗎。。。。。16年就有那個課了
沒看過這個課程,不會這么巧一模一樣吧?
X,有bug
X,有bug