起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識做過技術，你就是懂技術的產品經理嗎？
作為什么都需要會一點、懂一點的產品經理而言，技術也是產品經理必懂的一門知識。掌握了技術技能后，產品經理能夠對產品的框架進行更加全面、細化的規劃，為后面的產品工作打好基礎。
做過技術就是懂技術的產品經理嗎？如果是這樣的話，豈不是人人都是產品經理？
近日和某大佬聊到工作相關的話題，結合剛剛結束的高考，討論了大學應該讀什么專業比較好。對比來對比去，發現像產品經理、產品運營這塊，大學里好像沒有專門的課程。
于是乎又聊到自己身邊的一些產品經理，我發現了一個問題：
很多產品經理都是開發到了一定的年限轉來的，所以很多時候會突出自己是【懂技術的產品經理】。但是實際工作中，他并沒有利用自己的技術背景為公司做太多事情，而僅僅是畫畫原型之類的。
那么【懂技術的產品經理】應該是怎么樣的呢？
實際上，一個懂技術的產品經理，說是產品的架構師也不為過。
因為在技術方面，你得懂這些內容：抓包、反編譯、數據庫、HOOK技術、服務器相關、客戶端相關等………..
這些技術你不用很精，因為你不用去寫代碼，但是你必須得懂，得知道技術怎么去做才最好。
關于競品分析：
在公司做某一款產品的時候，PM通常會將競品的所有功能以PRD的方式去呈現，然后去調查用戶、收集行情等。
當然，這么做是沒有錯的，但是在設計整個框架的時候，這些完全不夠。很多產品之所以失敗，就是因為前期框架沒搭好，以至于后期的需求，還有修復BUG等，是一件非常痛苦的事。
下面，我將舉例進行說明：
需求一：做一個視頻點播的APP
相關競品有愛奇藝、優酷。
首先，技術方面的競品分析是必須做的，要理清楚競品是怎么實現這些功能的。
所以我們必須懂【抓包】，而且得會抓，包括使用工具下斷點、過證書驗證（很多APP有HTTPS驗證）、修改返回值看客戶端的異常處理等。
抓包的工具我就不說了，也可以參照我在吾愛破解論壇發布的原創技術貼【Fiddler為所欲為】系列。
直接開始，通過抓包可以得知：
愛奇藝接口：cache.video.iqiyi.com/
如：
優酷接口：ups.youku.com
如：
通過接口，可以得知以下信息：
1. 愛奇藝是將一部視頻切割成了若干個小的視頻，而每個小視頻下，都有各自的接口?？蛻舳嗣看尾シ艜フ埱笤摻涌谙碌男∫曨l的接口，每個視頻時間在5分鐘以內，格式為f4v。
2. 優酷一部電影只有一個接口，該視頻從接口看沒有被切割（暫不考慮m3u8是ts的切割，僅從接口來看），格式為m3u8。
那么問題來了——面對同一個需求，為什么優酷和愛奇藝的實現方式會有不同，它們的優缺點分別是什么。而這就是【懂技術的產品經理】應該去做的事情了。
我的看法：
優酷：由于m3u8一直觀看，得一直訪問該視頻的ts，因此，當觀看的人數多了，會造成服務器壓力大，服務器并發高的話費用就會很大。
通過域名暫無法得知優酷是將文件保存在自己的服務器下還是第三方服務器（如阿里云）。但是會減少很多CDN的成本，因為用戶不可能每個人都從頭看到尾，哪怕是跳過片頭片尾，也是解決了非常多的CDN。
愛奇藝：類似于自己做了個m3u8的邏輯出來，每段視頻都有自己的地址。m3u8是看到哪下載哪，但是愛奇藝的邏輯是需要下載到指定的片段，因此對CDN的成本會提高很多，每個視頻下載一次，對服務器的壓力會減少很多。
從用戶體驗來講的話：
當用戶網絡暢通的情況下，兩者基本無區別。而當用戶網絡不佳的情況下，體驗就有很大的區別。
優酷：緩沖時間短，但是會放一小段就卡一會。
愛奇藝：緩沖時間較長，但是畫面出來過后，后續緩沖的情況小（因為一段視頻在5分鐘左右，播放期間會去緩沖下一段視頻）。
技術成本上來看優酷會更簡單，有現成的。
那么如果我們也要做視頻點播功能，應該采取優酷還是愛奇藝呢？這就得根據公司實際情況來看了。
需求二：APP的開屏廣告，可以設置在某個時間段顯示圖片A，另一個時間段顯示圖片B
這個需求是不是很簡單？可以用這種方式來實現：每次打開APP的時候請求一個接口，客戶端根據返回的結果來看。
然而身為一個【懂產品的產品經理】，絕對不能這樣做。你必須知道，實現某個功能，通常來說有兩種方式：
- 接口
- 配置文件（這種方式很多技術還有很多人不知道……）
接口就不用解釋了，配置文件一般是指放在自己或者第三方的的服務器上，客戶端下載指定的文件，從文件進行讀取，然后APP生效。
這種方式適用于APP大多數功能，包括：
- 定時的功能
- 某些一直不變的內容，如APP的關于我們?？蛻舳酥挥孟螺d好了用作本地緩存即可。
那么什么時候用接口，什么時候用配置文件呢？
通常來講APP的量級大，就用配置文件的方式。因為通常第三方服務器，如阿里云，服務器比較能承受高并發。而接口形式適合用戶量級小的APP。
同時，配置文件會產生CDN的費用，接口卻不會產生。不過配置文件有個風險——如果用戶下載文件失敗，會導致一定的結果；而接口卻不會。
所以數據的重要性也是決策用哪個技術的。
另外，如果使用配置文件，客戶端和服務器端必須懂HTTP協議的HEAD方法，不是HEAD頭，而是就像POST、GET一樣的方法，避免重復產生CDN成本。
需求三：在APP的部分頁面彈廣告A，部分頁面不允許彈廣告
通常情況下是這樣做的：服務器告知客戶端哪些頁面應該彈廣告，哪些頁面不能彈廣告，客戶端拿到廣告根據相應的規則來。
當然，這樣設計本身是沒錯，但是拓展性很差，萬一哪天需求改成這樣：部分頁面彈廣告A，部分頁面彈廣告B，A和B不能同時顯示。
需求改成這樣是不是意味著客戶端得進行版本迭代了？否則沒辦法立即實現。
其實這個需求是非常簡單的——當PM在設計后臺的時候，像上述需求，只用告知哪個頁面要顯示，然后后臺做一下限制就OK了。也就是說可以理解為一個簡單的概念——顯示廣告的需求。這樣的話技術也簡單，操作起來也簡單。
需求四：客戶端和服務器都能實現某個需求，那么應該由誰來做？
很多PM或者技術在考慮這個問題的時候，會根據誰容易實現，誰比較有空，就決定由誰來做。
但實際上并不能這樣，身為PM，你得考慮到各種風險。
比如由服務器來做，那么服務器的壓力、成本都在你的考慮范圍。并且它還有一個缺點——在用戶網絡不暢通的情況下，這個功能就屬于擺設了。
放在客戶端來做，客戶端的兼容性和穩定性也是你的考慮范圍。做了這個功能，會不會導致安裝包體積增大，從而增加CDN的成本，這些各方面的因素。
結語
一個【懂技術的產品經理】是一個非常難的，也是非常優秀的產品經理。一個產品經理真正做到了懂技術，將會對用戶體驗和公司的運營成本進行極大的改善。
身為懂技術的產品經理，除了PM必備工具以及編程的思想以外，你得學會并精通各種工具的使用，例如Fiddler、xposed框架下的工具、存儲重定向、MT管理器、MyAndroidTools等。
其次是一些常見的安卓技術：熱更新、插件化開發、增量更新等（版本迭代必須了解的技術，只有了解這些，才知道哪些需求可以立馬做，哪些需要版本迭代。）
本文由 @狂暴補師 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
還未公司節省了架構師的錢
一名并不想懂技術的產品前來點贊
對了，樓主還在找坑。
坐標哪里
成都