讀《給產品經理講技術》後有感
我認為產品經理是要懂技術的。至於什麼程度，當然越多越好。最底線就是不影響與開發人員交流。一起基本的開發詞語要了解。了解技術的目的就是提搞工作效率，與溝通效率。達到目的即可。程度不可規定。如果開發都是你的親朋好友，技術方面可以什麼都不用了解啊。
下面是我看這本書的讀書筆記，感覺很基礎一共約8k 字有興趣的可以看看
本書由陳宇、鞏曉波、高楊、楊俊勇、關磊5位騰訊開發高級工程師人員撰寫。書中介紹說這是一本專為非技術背景的互聯網行業從業者和想了解互聯網技術的人員量身定製，並希望能本書成為非技術背景產品經理步入互聯網技術世界的敲門磚。它是希望產品經理能懂開發技術上一些基本的概念，這樣就使大家在溝通之前，能有一些基本的共識，以提高效率。2019年由人人都是產品經理與起點學院聯合出品。全書共28萬餘字，書中提到用白話和通俗易懂的例子解釋工作中常見的技術原理是本書一大特色，讀者不需要任何技術基礎。在書的前頁還有一張大而全的彩色技術圖譜。
作為純純小白的我讀完給我的感覺更像是一本小字典，大部分是一些技術上的名詞解釋，當然比百度上的解釋要更通俗易懂一些，或者說更系統一些。不過很多就是內容就是在解釋這個名詞是什麼，這個技術大都時候都是應用哪些地方，一些比較難懂名詞還是看不懂，需要自己查B站之類的視頻看看會更理解一點。視頻的方式更能容易的理解內容。最後一章還是有些思考的。產品懂技術知識是很重要的，而怎麼用這些知識更為重要。如何只是為了在與程序員「PK」中更能壓制博弈對方，那還不如不去了解那些東西。別要用學到的皮毛去挑戰別人的飯碗，你永遠Battle不過專業的人。即使你是從技術崗轉過來的，在Battle中也要適可為止，你懂你明白可是人家是靠這是拿工資的，有一百種維護自己的支持自己的有利條件。把技術的知識用在完善自己工作能力上是最重要的，預估工作量、準確的找到技術負責人、風險把控等上。最最重要的是減少與技術人員的溝通矛盾、和溝通成本。這才是產品懂技術的目的。
從技術人員的角度提煉出產品人員應該了解的知識和高效溝通方式。
一、Wed前端。
RD(程序開發)包括前端開發與後端開發。那首先要知道什麼是前端，前端在我的理解就是在界面所有的能看到的內容以及按鈕交互操作都是前端，換句話說與用戶有直接關係的就是前端。與之相反後端是不與用戶產生直接關係的，它是負責產品的業務邏輯、數據相關以及性能和安全的問題。為什麼要知道前端與後端的區別呢？因為一個項目的開發不是一個人倆個人就可以完成的，是需要多人協作開發，如果不能明確這個BUG是誰造成的，容易提交給錯誤的開發人員，會大大降低BUG的解決效率以及溝通成本，在文中作者做為來發人員說到他常常會出於對產品負責的態度把產品人員反映的問題先接下來然後在轉接給相應的人員，我認為這種間接傳遞問題是不提倡的，有時候反而會加劇很大的解決成本。另外，如果團隊規模較大，或者由各地的項目組拼湊而成，勢必會增加溝通成本。雖然說有QA（測試）崗位在處理這些。畢竟產品是要負責整個項目的跟進與溝通的，這些基本的區別肯定要知道的。在前端技術中涉及到的主要名詞有：HTML、CSS、JavaScript、DOM、URL、HTTP、Chrome。還有許多名詞解釋。
HTML：是超文本標記語言。可以說是一套編輯規則，以蓋房子類比，必須定義這個房子有多長、多寬。每一塊面積如何規劃，例如哪裡是衛生間、哪裡是飯廳、哪裡是卧室。將這些定義好，網頁也就有了最基本的樣子。總之，HTML就是用來布局網頁中的每一 個元素的。它是W3C的結構層。相當於只有206塊骨頭的女朋友。
CSS：是級聯樣式表。CSS中的「樣式」就是指外觀。還以蓋房為例，定義好了各個空間，房子也蓋起來了，但還要裝修，例如給客廳貼壁紙、給卧室鋪地板。 CSS就是起裝修作用的，要和HTML一起配合使用。它是W3C的表現層。相當於女朋友有血又有肉了。如果血肉分配合理的話還會是個絕世佳人。
JavaScript：是一種腳本語言。房子已經裝修好，貼上了牆紙，鋪上了地板，桌子、板凳、沙發都已經擺好，一切都很完美。可是，因為生活總是在變化，有時要買些新傢具，或者把茶換幾個位置，這時移動、添加、減少物件就只能靠JavaScript實現。想想一天里你家裡的大大小小的東西動了多少次。它是W3C的行為層。也是最難的，最複雜的層次。相當於女朋友可以隨意移動，還可以發出聲音。這不就完美了。
W3C：當前互聯網上的任何一個網頁都是由它們三個構建起來的也就是所謂的W3C，雖然簡單，但不可不知。前端就像學醫一樣，裡面的內容浩如煙海，變化無窮，不要以為懂了一些，前端開發人員說的什麼都要質疑下。
HTML5：是HTML規範的最新版本，一系列用來製作Web內容的相關技術的總稱。
伺服器：這個誰都知道。也可以看做中轉站。現在的技術離不開伺服器。在客服端輸入，然後傳到伺服器，伺服器做出處理後再傳遞給客戶。
HTTP：是瀏覽器與伺服器之間信息傳遞的一種公用的傳遞協議。如果HTTP中規定0是你，1是好。如果你在瀏覽器中輸入你好，傳遞出去的就是01。到伺服器中再翻譯出你好再傳遞出去。
HTTPS：就是更高級的、更安全的協議。所有人都知道01是你好，那可還行了，於是他們各種又設置了自己的密碼譬如908代表你8665代表好。而且這個密碼只有他們自己人知道不外泄。這樣別人即使截獲了9088665也不知道是什麼意思，還是信息還是安全的。
Chrome: 它和IE、火狐等都是瀏覽器都是瀏覽器應該不用多說。這裡面有些冷知識感覺挺有意思的。這種東西現在知乎百度一搜就能搜到就不說了。
URL：URL統一資源標識符。用定位的方式標識就是URL，如果用命名的方式標識就是URN。舉例;假如打王者你想用李白，用URL法就是點刺客第二排第三個英雄我可以命名為http；//http://www.ck23.com代表李白。用URN法就是在搜索中打李白就可以了我可命名為http；//http://www.libai.com就好了。看起來或者更為簡單，但是由於這種方法需要強大的解析器。所以現在多數都在用URL的方法。
DOM：文檔對象模型（DOM）是Web前端里最基礎、最常用的一個模型。例如，一個網頁其實就是一個 HTML文件（就好比還在孕婦肚子里的嬰兒它也是一個人只是能做的事情太少了），經過瀏覽器的解析， 最終呈現在用戶面前。HTML語言是由很多標籤組成的，這些標籤有管開始的叫開始標籤<head>還有管下一級的標籤<body>。標籤就像使用說明一樣告訴你一步幹啥第二步幹啥。就像做菜一樣第一步起鍋燒油，第二步放菜，具體多大火多少油什麼樣的菜還是由自己來決定的。把每個標籤 抽象成代碼里的對象，按照這種層次分明的結構組織，這就是DOM
DOM樹：就是很多個標籤按照一定的規範排列著像一個樹一樣。
強烈推薦B站搜索尚矽谷Web前端初學者零基礎入門視頻。用詼諧幽默的語言講解前端系統的知識。
二、客戶端技術
客戶端是指開發面向客戶的程序，分很多平台，比如Window安卓，蘋果，還有遊戲客戶端也算一類。文中指出Android與IOS 差別，Android會私自的喚醒應用。同時也介紹的客戶端實現推送的方式。總結起來，APP和後台的連接方式有兩種，一種叫pull，也叫輪詢，就是定期地不斷向後台請求，缺點是耗電，費流量，不環保；另一種叫 push,APP 和後台一直維持了一條通信通道，不定期地發送心跳包，也能攜帶信息。缺點是要維持一條長連接通道，這條通道如果不用 一些特殊手段保持連通性，很容易受系統或其他安全軟體的影響而斷開。同時也介紹了美顏APP的原理以及聽歌識曲的基本原理。這些都是可以在網上都是可以查到的。在客戶端技術的的最後一小節介紹了應用的生命周期。下圖為一個 Android 應用的例子。
可以將圖中的Activity簡單地理解為呈現給用戶的應用界面。可以看到這裡有8種狀態在按照一定的順序進行切換，上半部分屬於創建，下半部分屬於消亡，但是整個過程並不是完全不走回頭路消亡路徑上的一些狀態，也可以在一些條件下轉換成創建路徑上的狀態。產品人員解了應用的生命周期後，再去使用應用時，就可以判斷出程序設計的優劣，偶爾還能提一些建設性的意見。
三、開發技術
「空指針」是什麼。顧名思義就是指向空的指針。但是「空」是一種極度抽象的概念，管理員立一塊箭頭牌子，總得把它指向某個具體的地址。既然沒法指向真正的「空」，那就在內存中模擬出一個地址來代表「空」。具體指向沒有明確的統一規定，不同的系統可以指向不同的地址，不過一般情況下，會指向0地址，訪問它是非法的。大部分空指針的Bug是隱藏在代碼的茫茫大海中的。不過，因為改起來很簡單，程序員可喜歡改空指針的 Bug了，可是簡單修復了空指針後會引發哪些後續問題，很多程序員就不會去考慮了。
「越界」是什麼。發生數組越界的原因很簡單，假設一 個列表中只有10個元素，但是某個函數偏偏要取列表的第11個元素，就會產生「數組越界」。程序員要存儲的數字超過了他選用的數據類型所能表示的最大範圍時，就會發生數據範圍越界。
「起名」有多難。程序設 計里最難的兩件事，一件是保證緩存一致性，另一件就是命名。編程五分鐘，命名倆小時。在命名的時候，什麼是Manager、Controller，什麼又是Interface， 需要程序員通盤考慮。如果命名不當，後期維護的成本是很高的。
耦合與解耦。「解耦」和「耦合」是對立的，產生了耦合才需要解耦。耦合是代碼結構設計中產生的問題。當公司需要開發一個應用時，往往會將應用中的 各個功能分配給不同的程序員，但各個功能在聯動時會直接互相調用對方提供的方法，這就是耦合的溫床。解耦就是把耦合的東西在拆分出來，並且不影響原先的結構，解耦是每一個程序員非常反感的事情。
「Bug」有些不能改。不是所有的Bug都是可以改的，世界上沒有Bug的代碼是不存在的，有些Bug開發是知道的不過修改這個可能會引起更多的Bug所以沒有人想去冒這個風險。
「編不過」是什麼。程序員說的「編」就是編譯器在進 行翻譯，「編不過」就是編譯器在翻譯的過程中發現有單詞和語法不符合規範，向程序員提出警告：必須按照規範來，否則不予通過。這和 Bug 還不一樣，Bug是編包成功後，在使用的時候出現的，但是這種在編譯 階段出現的錯誤，必須解決了才能繼續。那為什麼會一更新就「編不 過」呢？大多是因為一些不負責任的程序員沒有好好檢查自己的代碼就提交到代碼管理庫中去了。「掛了」是什麼。經常會有用戶反饋程序用著用著就強行退出，也就是常說的應用程序崩潰，俗稱「掛了」。一般說某程序不穩定，就是說該應用容易「掛」。產生原因有倆種，其一，都是程序員的錯。程序員寫出的代碼就是應用程序的「行為清單」，應用程序運行的每一步都一絲不苟地按照程序員的指示進行。其二，操作系統不靠譜。所有的軟體都是有Bug的。像操作系統這種極其複雜的軟體更加無法倖免。所有的應用軟體都依託於操作系統提供的基礎能力運行。如果操作系統本身不穩定，就會對應用程序的運行造成影響。
「重構」是什麼。重構就是在保留現有功能的基礎上，重新梳理軟體中的代碼結構，讓原本雜亂無章的代碼重新具有可讀性、結構性和擴展性，增加軟體的開發效率，優化程序的性能。重構的範圍可大可小，大到涉及整個產品的各個模塊，小到一個函數。在軟體開發過程中，每一款軟體一開始都是經過精心設計的，具有良好的結構。但隨著需求不斷變更，之前的結構開始慢慢變得不適應， 就像隔壁老王的房子，本來是為平房設計的承重系統，後來娶媳婦想改裝房子。現在的房子要承受二層樓和陽台的重量，這種變化可能是當初的設計者始料未及的。為了快速完成需求，開發者可能會使用一些違背當前軟體架構的方式實現功能，久而久之，這種「另類」的代碼越來越多，導致軟體之前的結構已經淹沒在 了這些雜亂無章的邏輯中，使得整個軟體沒有清晰的脈絡，嚴重降低了代碼的可讀性和可維護性，一點小小的修改都會造成不可預知的 Bug 產生。在這種情況下進行大規模的需求開發，後果可能是災難性的。
四名詞解釋
抽象、封裝、類、實例和對象。這幾個詞可以用一句話串聯為：對事物進行「抽象」，從而封裝 為「類」，由「類」可以生成「實例」或「對象」。 抽象 是面向對象思維方式最基礎的邏輯和思維，是封裝的前提，是對一系列擁有共同屬性或行為的描述。喝水、喝酒、喝西北風，可以抽象出「喝」;抽煙、抽風、抽鴉片，可以抽象出「抽」。抽象對應的是具體，抽象之後具體消失，共性出現。這些共性被用來封裝為類。類可以定義實例，實例也稱為對象。
鉤子（hook）。在Windows系統中一切皆消息，按鍵盤上的鍵，也是一個消息。Hook的意思是鉤住，也就是在消息過去之前，先把消息鉤住，不讓其傳遞，使用戶可以優先處理。執行這種操作的函 數也稱為鉤子函數。簡單地講，就是「要想從這過，留下買路財」。要去公共廁所，必須 先經過公廁門口老爺爺的收費允許，老爺爺就是在下「鉤子」，這個鉤子函數的功能是付款。程序員在討論時也常說「可以先鉤住再處理」，即執行某操作之前，優先處理一下，再決定後面的執行走向。
模板。代碼也是有模板的，跟PPT模板一樣，有了模板改改內容就可以得到自己想要的東西了。模板就像輪子一樣，別人的能用就用，何必自己要先造一個輪子呢？
棧的含義。棧首先是一種數據結構。棧也表示由操作系統管理和分配的一些內存區域，這些內存區域用來存儲程序中的變數及參數，程序員常說的「棧溢出」就是指這塊內存空間被用完了，內存不夠程序就崩潰了。棧也表示信息常指程序出錯的列印信息。如果再聽到程序員說「棧信息列印出來了嗎？」或「把棧發給我看看」，其實是在用棧信息定位問題。還有全棧工程師是指啥都會很牛叉的工程師前後技術都會，一個人能幹二個職位的活。技術的垂直度很高的工程師。
開源。程序員寫了一些代碼，覺得自己寫的代碼可能會對這個世界上的其他人有所幫助，就在網上公開源代碼，讓每個人都可以自 由地查看、下載和分發，這就是開源。
介面。指提供一種別人可調用的能力的標準。例如，小明寫一封簡歷找 工作，這個簡歷就是小明的介面清單，這個介面清單描述了小明具備 的「介面」。簡歷上寫會寫文檔，老闆看到了聘用他讓她去寫文檔。「讓後台給我提供一個介面」，這句話在工程中一般表示的是僅僅提供一項能力供調用方使用，這跟我們上文講的介面的定義不完全一樣。例如，後台提供了一項能力，終端可以從後台調用這個介面，查詢當前所在位置的天氣。這種話在開發過程中講得比較多，常用於前端和後台 的聯調。 「你來設計一個介面，我來實現」，語境一般是在面向對象的程序設計中，對一種能力的抽象分別由不同的開發者實現介面象徵著提供出來的能力，定義者和實現者一般是不同的，調用 者並不需要關注具體細節，只需要關注介面暴露出來的能力就可以了。如果程序員說「你給我封裝一個介面，我直接調用」，應該他說的意思是：「我不關心你如何實現這個能力，只要我要用的時候，你給我正確的結果就好了。
兼容。它包括向前兼容與向後兼容。向後兼容指的是對已經發出去的老版本兼容，向前兼容指的是對還沒有做好的版本兼容。顯然，向未來兼容難上加難，理論上也是做不到的，因為我們永遠不知道未來要做什麼功能或需求。但向後兼容是一定能夠做到的，程序員都可以面對老版本分析出當前的狀態和兼容的辦法。如果有程序員對你說無法兼容老版本，那他一定是想偷懶。總而言之，向後兼容是一定要做的，而且一定是有解決方案的。向前兼容是可以適度做的，但一定是無法長期兼容的。
五、溝通
工作上的溝通無非就是想要解決問題、提高效率，要不然誰沒事溝通啊說話的藝術真的很費腦子。
首先要了解程序員的分工，知道他們每一個都是負責什麼的，當然如果那個人是全棧工程師就沒什麼可了解的了。
如何正確地提需求。1.提需求要有節奏感 ，在功能開發、單元測試、集成測試中適當的提出需求。到了灰度驗證和上線發布階段，大家都繃緊了神經，天天盯著用戶反饋和線上的各種指標。若這時產品經理突然有了一個絕妙的需求，請 控制一下，因為這時提任何需求都會被記恨。2.先自己嘗試評估需求難度 。產品經理評估需求難度這件事需要一點技術含量。有些需求天生很難，例如智能推薦、智能識別和搜索引擎，這些都需要很強的技術能 力。還有些需求需要前後端聯調，後端開介面，商量協議，實現起來耗時要翻倍。除了這些，剩下的要取決於是否有現成的「輪子」。尤其是在排需求優先順序時，盡量不要出現不確定的語言，什麼做不做都行。有條件就做之類的。3.下點功夫做準備。這是個簡單的道理，你讓別人給你辦事，吩咐半天講不清楚，別人肯定不耐煩。如果你的需求是模仿別人的，可以拿別人做好的效果演示，這是最直截了當的。
寫出程序員想要的文檔。程序員和產品經理之間產生的矛盾大多是因為一個 叫產品需求文檔（PRD）的東西。有一種讓人頭疼的需求文檔，如表所示。
產品經理將這樣的文檔轉交給程序員的時候，程序員的內心一定是崩潰的，他一定會問若干個「如果」：如果發生A情況，該怎麼處理；如果發生意外，產生了B情況，又該怎麼處理。產品經理收到反饋再來更新需求文檔，你問，我改，再問，再改，等大家都疲憊了，需求文檔也成熟了。最後誰都看不懂，一份文檔束之高閣，沒有任何價值。
需求文檔中的「優先順序」選項也是令程序員很頭疼的，優先順序分為 高、中、低三個選項，大多數產品經理會說，高優先順序必須上線，中低優先順序也是需要做的。那還分什麼優先順序呢？或者說中低選做，這種模稜兩可的感覺還不如抽象成做或者不做。當然，這需要產品經理提升能力，能夠清晰地評估出一個版本能否涵蓋這麼多的內容，其實程序員根本不需要這種文字式的需求告白書，這種文檔應該是產品經理腦中的思路，而不應該被描述成文字交出來。程序員需要的是一份大家都認可的清晰的交互圖，其關鍵位置需要有一些邊界條件的說明。這份交互圖不一定非要用專業的原型工具輸出，一張草紙加鉛筆描述清晰即可。作者認為由產品經理和程序員一起討論功能的關鍵路徑，並一起確定每一個流程，然後簡單地畫出草稿，才是效率最高的方式，並且可以少開很多會議。若僅一個人想好了就發起評審，結果往往是需求被改得面目全非，不如大家在初期就一起討論得出結論。 當然，程序員是很高傲的，產品經理沒叫他參與討論時，他會抱怨：「什麼都不叫我，亂決策，現在一團糟，根本實現不了。」產品經理 他的時候，他又會說：「整天跟產品經理在一起討論問題，技術上都 沒有長進，沒有積累。」或者抱怨說：「白天跟產品經理討論，只有晚上加班才能寫點代碼，筋疲力盡，還總被批評效率不高。」程序員大多認為自己有些武功，所以跟不同的程序員交流要用不同的方法，例如多請他們吃飯。從另一個角度看，所謂能力越大，責任越大，明白的程序員與產品經理早就想明白了，他們每天工作不是為他的老闆，而是為自己，無論在哪裡干，都當是創業。
精益（mvp）的作用是最小成本驗證可行性，把所有資源投入到最大可能的方向。直播興起的時候，是應該以產品上線為首要目的的，不應該過多地考慮帶寬不夠怎麼辦、用戶激增到500萬怎麼辦，或者播放質量不夠高怎麼辦等問題。道理很簡單，做到卻不容易，希望產品經理明確地知道當前目標，而不是抱著「既要……也要……還要……」的想法應對一個驗證過程。目標明確，只突出一個點，能促使自己與程序員和設計師更快地達成一致。
六、你只是在為自己工作
在職場，僱傭關係告訴你在為別人打工，使你常常放鬆自己，有了干多干少都是為老闆的感覺。這種想法很容易使你錯過最佳的成長時間窗。吳軍博士講過，一個人工作做到95分和100分，其實並不僅僅是5分的差距都遠遠大於他直接做到100%所用的成本。如果一個人一直在追求那最後的5分，可以為了那5分付出遠大於前面95分的努力時，也就區分出了高手和普通人，高手在任何一個領域都會勝出一籌，這來源於長期的刻意訓練。
如果你一直覺得工作就是為別人打工，就會習慣性地得過且過、患得患失、抱怨不斷，從而缺乏持續性的積累，導致未來成長動力不足。
人生是長跑，至少要工作到60歲，我們必須追求每一天都比前一天更有厚度，只有抱著為自己工作的心態才能做到。工作是為了自己，這 一點永遠都最重要。
原創文章，作者：投稿專員，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/323639.html
微信掃一掃 
支付寶掃一掃 