4500字干貨！UI和PM都需要知道的開發技術知識

今天要討論的是一個老生常談的問題，產品經理或設計師，需不需要懂技術？

我可以直接給出答案 —— 必須要懂！而下面要討論的，就是為什么該懂技術，以及該懂哪些技術！

技術基礎科普：

一、為什么我們要懂技術

無論產品經理還是 UI 設計師，都是互聯網產品團隊中的一員，我們的工作產出都要通過編程和其它技術轉化成最終的成品。

將產品設計研發的流程進行簡化，就可以劃分成方案和實施兩個部分，方案包含功能設計和界面設計，施工包含前端開發和后端開發。

除了面向網絡營銷的運營設計師外，幾乎任何具有方案設計的行業中，都包含實施的階段。換句話說，方案和實施是分離開的，它們需要有不同的專業人員來負責對應的工作。

比如，建筑的規劃和設計，需要工程團隊進行施工。鞋帽服裝的靈感和設計，都需要交給產線批量生產。轎車的研發和設計，也需要交給車間進行組裝。

雖然每個崗位是獨立的，不需要方案人員到車間里去打螺絲，但不代表他們可以只沉浸在自己的工作和暢享中，完全不需要理解和關注實施階段的知識和限制。常規的項目流程中，方案進入實施階段必然會包含一個審查的節點，通過會議、審計、評估、測試來確定方案的可行性。

無論是建筑、服裝、室內、家具或者工業領域，方案設計的專業人員都必然要學習和實施有關的知識。建筑設計師需要學習結構力學和工程學知識，服裝設計師需要學習各類染色技術和面料知識，汽車設計師需要學習空氣動力學和材料學等……

這和互聯網行業形成巨大的反差，原因就是這些行業都相對成熟，在漫長的發展過程中充分認識到了方案制定者對實施方式和技術原理認知的重要性，所以在本科教育階段就會著重制定對應的教材和考試。

而產品、UI 設計師這些崗位僅是這十幾年才興起的崗位，相關認知方面的教育一片空白。所以自學的從業者普遍也會認為，這又不是我負責的事情，為什么要了解？是需求分析太容易，還是設計的工作太少了？

當這種想法開始根深蒂固并自我強化后，那么團隊成員間的隔閡就會放大，協作效率就會受損。因為大量的方案和決策在技術端的可行性或成本是完全不能接受的，而這種盲目導致的結果就會演變成產品或設計單純認為開發人員消極怠工（不管是不是），不配合你們的工作。

首先我們先從產品層面討論，為什么產品規劃需要懂技術。因為作為整個項目的起點，產品對需求優先級的判斷就必須考慮技術成本。

比如有時候一個不是很重要又小的改動需要耗費大量的開發資源，那在前期就可以直接往后排而不需要等到評審時再討論。或者一些構思出來的新需求技術端根本不可能在指定時間內交付，那需求肯定要改進并簡化。

到具體的業務需求中，搭建了一個中臺，要從不同業務系統中同步某項數據，并做統一的備份和管理，那么產品經理制定需求就必須要了解數據庫和接口本身的特性，理解數據是怎么在不同服務器間分發并存儲到指定數據庫表文件或者運用數據倉庫的方式。

或者設計一個跨境支付功能，要接入銀行和境外支付服務商，除了理解業務邏輯外，為了保證功能的嚴謹和有效，對第三方的技術和 API、SDK 都需要做深入的檢查和分析，然后才能制定最終的需求交給開發評估，而不可能只是畫個原型剩下的交給開發自己處理。

在設計和視覺方向，同樣涉及很多需要了解技術才能執行的場景。最常見的就是設計支持響應式的網站，響應式本身是由前端技術發展出來的設計模式，如果對 HTML、CSS、JS 等代碼邏輯沒有任何學習，就很難理解響應式的具體是怎么“響應”的，然后在第一步創建畫布就不知道應該怎么辦，更遑論后續設計出符合響應式需要的組件元素。

再到一些圖形應用中，如數據圖表或 3D 可視化場景，大多是由技術特征去驅動的設計，而不是設計成什么樣開發就要做成什么樣。從一開始產品和技術就要根據場景選擇的圖形引擎（WebGL、Unity、Unreal 等），而引擎類型決定了圖表生成、3D 模型、渲染方式的差異，無論是功能還是視覺都必須尊重引擎本身的特征和限制，否則方案就肯定和落地效果南轅北轍。

能舉的例子還有非常非常多，相信有工作經驗的同學一定也有感慨。而我要表達的意思，就是如果產品經理或設計師完全不懂技術，是不夠稱職的，必須對技術的認知持開放、學習的態度。

逃避不能解決問題，只會積壓更多問題……

二、我們應該懂那些技術

既然產品和設計師都需要懂技術，那下個問題就是應該懂哪些技術，懂到什么地步呢？

提前聲明一點，懂技術并不是指必須全部學會程序員應用的編程語言和框架模型，而是通過幾個基礎的編程語言入門，再學習理解產品、功能、服務運轉的技術邏輯即可。

第一步掌握幾個基礎的編程語言這點，只需要簡單入門，再做一些案例練習即可，目的是為了理解和具備開發的思維模式，這是通過他人分享和教學無法實現的實踐經驗。

而我建議掌握定的程序類型包含下面幾個：

HTML、CSS、React / Vue / Python、SQL

1. HTML & CSS

這是前端最基礎的兩種語言，用于在客戶端運行并展示頁面內容。HTML 是類似 Markdown 的標記型語言，通過固定的一些標簽和簡單的語法來描述內容的含義。幾乎沒有任什么學習成本，在一天能就能掌握并入門。

而 CSS 則是專門搭配 HTML 用于指定標簽樣式的表，通過指定標簽背景色彩、位置、大小、字號、字色等屬性值來控制頁面的樣式。

這兩個語言因為太簡單，屬于被程序員開除“編程”籍的代碼類型。但簡單不代表它們不重要，學習它們是為了感受頁面樣式搭建的過程，理解前端代碼本身的局限性，以及為什么跟著設計稿還原出來的效果就是不一致的原因。

而 iOS、Android、Windows 等平臺應用雖然不用這兩個語言，但實現界面的邏輯大體一致，所以學習 HTML & CSS 可以在很短的時間內帶給我們長遠的收益。

之前我們自己也做過相應的干貨分享和教學，可以直接學習：

2. React / Vue / Python

作為正經的編程語言，它們和 HTML&CSS 最大的差異，就是需要應用條件判斷和函數處理等復雜功能。只要入門并掌握其中的一門語言，就可以對編程的邏輯和思考方式有初步的認識。一方面今后再使用 Axure、Protopie 等工具的表達式時就可以得心應手，另一方面和程序員的溝通也會更容易和高效。

其中 React / Vue，都是在 JavaScript（簡稱 JS）基礎上開發的前端框架，類似之前的 JQuery。而很多了解過一點網頁開發的同學肯定都聽過網頁開發三件套是 HTML、CSS、JS，之所以不建議直接學 JS 是因為它實在是太“啰嗦”了，這些新的 JS 框架就是對原有語法的重構，上手更容易，用起來更輕松。對于不是專業從事前端開發工作的我們來說再適合不過。

至于 Python 相信大家一定沒少聽說，也是各大網站或者朋友圈天天在推送賣課的編程類型，被不同的互聯網大佬呼吁要加入小學課程，以及互聯網從業者必會的語言。它的主要特征也是簡單、清晰、易用，它不僅可以幫助我們適應編程的思維，也可以在生活、職業發展中帶給我們巨大的幫助（要自己去了解了）。

學習它們我都不建議直接到不同網站中看幾十個小時的視頻教學，或者買一本大部頭編程指南，而是直接到編程類的知識庫網站，如 W3Cschool、菜鳥教學等，跟著章節學習入門既可，建立初步的認識后再搜索其它稍微進階點的教學深入。

3. SQL

SQL 是一個關系型數據庫管理語言，用于對數據庫進行增、刪、改、查的操作。SQL 非常的簡單，可以說是一個上午就可以學會基礎的語法和入門應用，而相對高級的功能和命令也只需要花幾個小時看一遍就夠了，在真有需要的時候再回頭來查看相關的命令手冊即可。

學習它的主要目標一方面是理解數據庫的概念，數據存儲和調用在 B 端項目中至關重要，絕對不是把業務需求轉述給開發就可以避開的工作。所以針對這方面的需求，才衍生出一個專門的崗位 —— 數據產品經理。

另一方面是 SQL 在日常工作中是有大量應用場景的。在缺乏可視化統計工具的情況下，產品經理和運營都需要自己去數據庫拉數據手動換算。

上面這些編程的基礎知識，只需要花兩周時間就可以入門，慢的話一個月也夠了（再久就自己反省，沒錯，就是你自己的問題）。

然后，就可以進入下一步，去理解功能、服務、技術運轉的邏輯了。簡單解釋一下，就是去理解你日常接觸到的各類 IT 服務、軟件功能、新技術領域背后的技術實現原理和框架。這是個沒辦法系統學習只能依靠自己主動去搜索和理解的過程，所以下面我會舉一些簡單的例子，幫助大家上手這個過程。

比如之前我分享過一篇有關 SaaS 的說明，它是通過連接遠程服務器（云服務）而實現的軟件服務方式。在此之上還有 PaaS、IaaS 等服務，這些服務分布在 9 個從屬條件之中。而這每一級的作用和詳情都可以去做進一步的認識和理解。

或者一個網站的運行和訪問是怎么實現的，從用戶在瀏覽器輸入域名以后，如何進行通信，解析域名，并在服務器端計算并準備對應數據返回給客戶端，然后進行文件的解析和圖形渲染的全部過程。

我非常建議大家自己動手整個軟路由或者 DIY NAS，通過在自己家中搭建一個簡單的 “服務器” 來實現公網的連接，然后安裝你需要的應用或 Docker （同步盤、相冊備份、影視存儲、PT 下載、虛擬機等）進行遠程訪問。這樣你就不得不搞清楚內網、公網、網關、端口、轉發、IP、TCP 等技術的關聯和作用。

除此之外，還有每隔一段時間就會興起的一些新技術，我們都可以去網上搜它們的技術原理和專業性科普。比如之前的區塊鏈應用，再到近期的 AIGC。只要你愿意花時間找，這些熱門的新技術都會有非常全面的解釋，包含了詳盡的文字說明和圖例。

可以了解的技術內容太多了，而以上的建議，并不是要讓你們成為運維還是 IT 專員，而是和我們關聯較大，或者熱門的題材更能激發你們的興趣。在這個過程中你們就會明白，理解背后的邏輯并不是非得需要懂代碼不可，而建立出完整的服務，必然要涉及多個端、層級、領域的共同作用，任何編程語言都僅僅是實現這個服務中的其中一環，而不是全部。

在這個過程中，我們要學會的就是理解和建立負責服務的技術框架，能以目標為導向用更宏觀的視角來理解技術的實現方式，并能對每個不了解的節點自發進行咨詢和掃盲，不會再對項目的技術內容一無所知。

這就能理解不同程序員在這個框架下的職能，發揮的作用，以及整個框架的優缺點、上限和下限，并能夠在出現問題時和技術人員共同定位問題節點。

對技術的認識不是一步到位的，而是隨著項目經驗的積累逐步增加，在一定時間之后，你就可以獲得足以駕馭相關議題、會議、需求的能力。

尤其在 B 端的領域，技術對項目的重要程度是毋庸置疑的，且大量 B 端產品解決的本身就是技術問題，如云服務、自動化、數據管理、DevOps 等產品都是建立在技術需求上的產物，從業人員對技術本身一無所知是不可能的。

了解技術，對于 B 端產品經理和設計師已經不能算隱性要求，它不僅能幫助我們有效的解決真實的項目問題，還能擴大我們的擇業范圍，一定不要忽視它的重要性！

結尾

基于技術類的知識，過幾天就會有一篇 DevOps 相關文章分享~

因為我自己對它們的理解也很碎片，所以接下來一段時間我還會繼續深度學習和重新整理這些知識點，把它們串聯起來并能系統性一點的分享出來（想想還有點小興奮）。

這次的分享就到這里，下篇再賤~

歡迎關注作者的微信公眾號：「超人的電話亭」