產品經理的技術素養
04-04
經常有產品經理問我：產品經理到底需不需要懂技術？我：你覺得呢？他：需要吧？我：產品經理對需求負責，你覺得自己有懂技術的需求嗎？他：有啊，懂技術後能讓需求更符合實際情況，更好的根開發溝通，更好的評估開發需要的時間，還能在功能和性能之間找到平衡點...
技能篇1. 最好掌握的技能科學上網：網路世界哪么大，要常出去看看，畢竟Copy to China還是主流的創新模式...資料庫查詢：項目初期運營系統還沒有那麼完善的時候，如果你會查詢資料庫，能大幅的提升數據分析的效率！微調HTML/CSS：不需要會做複雜的前端布局，但是如果你可以對Web頁面的樣式進行微調，更容易做出最滿意的效果，輸出你自己的品味；2. 至少了解的概念下面這些概念，如果你能了解他們的優勢與不足，那麼在與開發溝通和產品決策的時候，會有很大的幫助（例如之前提到的HTTPS能夠解決運營商劫持的問題）：資料庫、緩存、消息隊列、Web伺服器、負載均衡、CDN；TCP、UDP、FTP、HTTP/HTTPS、Protobuf；
推薦閱讀：
我：那還不趕快去學！
他：你能教教我么？我：原來你在這等著我...於是，就有了這篇文章：產品經理的技術素養。常識篇當下ToC的創業項目，要麼是守著iOS和Android平台做APP，要麼是守著微信平台做HTML5的應用，所以就講講這兩個領域的開發常識吧。APP 開發常識1. APP能穩定運行是對客戶端開發的最低要求，沒的商量！任何的客戶端閃退和卡死都是客戶端開發的錯，也許他們會說這是因為伺服器返回結果的格式不對呀，或是返回的數據裡面有臟數據呀，或是網路異常導致的呀......但是我要告訴你們，這都不是客戶端閃退或卡死的理由！返回格式不對，友好的提示下就好了呀，臟數據過濾掉呀，網路異常就超時結束請求，提示用戶網路有問題就好了呀，閃退或卡死就是客戶端沒處理好！理論上，哪怕是服務端所在的機房炸了，客戶端也應該是除了不能讀取新的數據，其他功能都可以正常運行，這才是優秀的APP該有的素質（你們自己關閉網路，然後用微信感受下）！2. 所有的閃退都要收集回來並解決！再完善的測試，也無法做到將所有的情況都考慮到，特別是在複雜變的手機端。所以對於APP影響最大的閃退，一定要藉助第三方平台對所有閃退的異常進行完整收集！這裡的完整是指系統平台（iOS&Android），應用版本，程序的報錯描述，引發閃退的相關數據等，這些信息可以幫助開發快速的定位出錯的位置，減少開發說我這裡重現不了，沒辦法解決的情況，對於解決閃退非常有幫助。推薦兩個用戶量比較多的閃退監控平台，方便你們選擇吧：1. Fabric(twitter維護)2. BugTags(國內團隊維護)3. 熱修復技術：線上嚴重故障的救命稻草！這個技術主要是解決應用上線之後，在主幹流程上發現嚴重BUG，例如閃退或者數據載入出錯等問題。以前遇到的這樣的問題，就只能緊急修復並發版，一面安排運營安撫用戶，另一面祈禱各大市場趕快幫忙通過審核，相當的狼狽。現在有了熱修復技術，可以通過在應用啟動的時候，從網上下載一段代碼到本地，替換掉本地有問題的代碼，從而達到無需發版就能修復嚴重BUG的效果，有效的保證產品的穩定性。推薦幾個常用的熱修復解決方案：1. iOS平台下阿Bang同學的JSPatch相當的靠譜，微信都在用。
2. Android平台下阿里維護的AndFix也是個不錯的選擇。
4. Andriod的兼容與適配Android開發最繁瑣地方，莫過於適配各種屏幕尺寸和兼容各種廠商修改過的系統了。建議上線前優先適配主流機型，上線後重點適配你應用的用戶使用最多的機型，並結合前面提到的閃退收集和熱修復技術，保證應用的穩定性。5. iOS的內測分發與審核iOS應用做有一定規模的內測分發是一件挺麻煩的事情，如果你用的是99美元的開發者賬戶，就只能通過一個個的添加測試用戶手機的UDID，才能進行呢測。更好的辦法是申請一個299美元的企業開發者賬號，使用這個賬號的證書打包的應用可以自由分發，再結合一些分發平台（http://fir.im或者蒲公英等），可以非常方便進行千人規模的內測，獲得更多的用戶反饋。但是，申請企業開發者賬號是需要提供企業的鄧白氏編碼才能申請，然而由於國內很多第三方蘋果市場對企業開發者賬號的濫用（所謂的免越獄安裝應用，就是靠使用企業開發者賬號打包實現的），導致蘋果對大陸地區企業賬號審核的越來越嚴格，一度淘寶上一個企業開發者賬號都炒到了10W＋，所以有一定規模內測需求的項目，初期就開始申請企業開發者賬號吧，因為一般需要一兩個月才能搞定。6. 客戶端和服務端都可以做的功能，大多數情況下建議在服務端實現項目推進的過程中，經常會遇到有些功能客戶端也可以做，服務端也可以做的情況，這種情況下，大多數時候建議在服務端實現，這樣有兩個好處：1. 核心邏輯只在服務端實現一次，不用在兩個客戶端平台都開發一遍，節省開發時間。2. 如果有BUG，可以在服務端即時修改，而不需要重新發版。舉個例子，查看附近的人列表裡，每條記錄都有個距離的數值，這個距離在客戶端計算也行，在服務端計算也行，但是在服務端計算並將結果直接返回給客戶端可以保證數據的一致性，一方面減少由於客戶端選用的GIS庫不同，導致iOS算出來是1.81km，Andorid算出來是1.82km的詭異情況；另一方面如果計算出錯，只要在伺服器調整距離的演算法，客戶端自動就可以正確顯示了。
微信&HTML5 開發常識1. 微信授權登錄微信提供的應用授權登錄作為目前最流行的第三方登錄方式，基本已經成為應用的標配了，而相應的微信服務號提供的Web授權登錄，也已經成為微信HTML5應用獲取用戶信息的利器，但是這裡有一個坑，就是默認情況下，應用授權登錄的返回的用戶唯一標識（即OpenID）與Web授權登錄返回的OpenID不一致，哪怕是同樣的應用名稱也是如此。解決辦法是將你的服務號綁定到微信開放平台下，這樣兩種授權的返回信息中，會多一個統一的UnionID字斷，用做用戶的唯一標識。但是UnionID不能用於發送消息模版的需求，所以最終每個微信授權的用戶，需要同時保存OpenID和UnionID，才能順利的完成打通和後續的業務處理。另外微信的授權登錄有兩個模式，基礎授權和高級授權。前者的好處是用戶無感知，但是只返回OpenID和UnionID；後者需要額外跳轉一次頁面進行授權，但是能拿到包括昵稱、性別、城市等在內的完整的用戶信息。這裡有一個優化的技巧是當用戶登錄的時候，先使用基礎授權登錄的方式獲取用用戶的OpenID和UnionID，然後在你的用戶信息中查詢，如果該用戶存在，則直接完成登錄；如果該用戶不存在，再跳轉到高級授權登錄，獲取完整的用戶信息並保存，這樣這個用戶再下次登錄的時候，就不需要使用高級授權登錄了，直接通過基礎授權即可無跳轉的完成登錄。2. 防欺詐提示
3. 運營商劫持
主要的應用推送服務（包括蘋果和Android的第三方推送服務），用來承載內容的空間一般也就是256個位元組（utf-8編碼下，一個漢字佔三個位元組），超過的話會發送失敗。如果遇到有些推送能收到，有些推送收不到的情況，很可能就是文案超長了，可以檢查下。
微信服務號推送的客服信息不能超過2048個位元組，並且用戶與服務號之間48小時內要有互動，否則會發送失敗。2. 使用雲服務別再用Excel管理項目了！別再自己找機房買伺服器了！別再自己搞文件存儲了！別再自己開發統計分析系統了！現在有大量的優質的雲服務，可以大幅的提高創業團隊的效率，果斷用起來吧！推薦一些不錯雲服務給你們：項目管理：TeamBition、Tower；雲主機：阿里雲、Ucloud；消息推送：極光推送、個推；簡訊：創藍、螺絲帽；雲存儲&CDN：七牛、又拍；即時通訊：融雲、環信；
代碼託管：Coding、Bitbucket；統計分析：友盟、騰訊分析；3. 關於開發外包如果實在招聘不到合適的開發人員，項目原型的開發可以找你信得過的朋友來做並付費。別老想著找人免費幫你做，適當的付費能大幅提高朋友的開發效率，從有空寫寫變成努力完成，絕對是雙贏的！如果找外包公司開發的話，找個你信得過的朋友做顧問，審核資料庫的設計和核心代碼，儘可能的避免項目發展過程中因為系統設計不當，導致需要推翻重來的風險。另外，項目原型是用來快速驗證想法的，不要過於追求細節，關注核心業務的功能即可，快速上線去檢驗你的商業模式才是關鍵。4. 關於代碼重構產品經理經常聽到開發要求對現有代碼進行重構，這裡的重構一方面是改進趕進度時寫的低質量代碼，另一方面是把一些通用的功能和模塊進行抽象，方便後續開發。建議每個月至少給開發留2個工作日進行代碼重構吧。輪詢、推送；
灰度發布、AB測試；推薦系統、搜索系統；溝通篇1. 如何提需求？差的方式產品：我們需要做一個刷臉付款的功能，用戶通過刷臉完成支付。開發：人臉識別可靠性差，特徵容易改變或者相同，在全球範圍內都是難點，用來做支付太不安全了！好的方式產品：我們為了提高用戶的榮耀感增加一個營銷的口碑傳播點，想做一個刷臉支付的功能，你們看看安全性方面有沒有什麼好的方案？這個功能使用的流程是......（過程描述略之）開發：人臉識別可靠性差，最好加入一個二次確認的過程，例如微信上發條確認信息，用戶確認一下，其它應該沒什麼問題。抓到要點沒？沒有的話，看看我的總結吧：1. 先講需求背後的訴求，再講需求的要點；2. 提出需求要點中技術上的不確定部分，徵詢開發意見；3. 最後再補充細節，並允許開發對細節進行合理的調整；2. 如何協商開發進度？差的方式產品：這個需求開發完成需要多少時間？開發：一周產品：要這麼久？這個需求不是很複雜呀？開發：這個需要XXXX...（一堆產品可能聽不懂的術語）產品：不用這麼麻煩吧！開發：你行你來做啊！產品：好吧，那就一周吧...好的方式產品：這個需求開發完成需要多少時間？開發：一周產品：要這麼久？那我們一起把這個需求拆分一下，拆分成幾個一到兩天內可以完成並測試的小需求吧。開發：這個需求可以拆分成ABCD四個任務，A任務需要1天，B任務需要1天，C任務應該要2天，D任務需要1天。產品：好的，就這麼定了，我重新把這幾個需求寫到任務系統上。抓到要點沒？沒有的話，繼續看總結吧：1. 尊重技術的評估，不要想當然；2. 如果一個需求的開發時間超出了你的預期，就對需求進行拆分，每個需求的開發時間控制在兩天以內，這樣的好處是可以快速的了解到開發的進展，不斷確認產出的結果是否是產品所需要的，避免一周後，發現開發和產品對需求的理解有很大的偏差而導致的延期。另外，如果真的是個非常簡單的需求，開發根本無法進行分解，他自然會縮減時間的。PS：別把開發進度逼的太緊，可能會影響系統質量...3. 如何報BUG？差的方式為什麼我的賬號不能登錄呀？好的方式為什麼我的賬號不能登錄呀？提示帳號密碼錯誤！我測試的帳號是：cc123 密碼是：123456，用的是蘋果手機，安裝的最新的版本！剛剛測試的，相關信息我都寫在TeamBition（Bug跟蹤系統）上了，儘快處理下，這個BUG的優先順序最高！抓到要點沒？沒有的話，最後再幫你們的總結一次：1. 提供穩定復現的流程和錯誤信息(最好有截圖)；2. 提供支持復現BUG的完整數據(相關帳號密碼、測試的輸入等)；3. 提供準確的應用信息(應用版本、測試環境/正式環境 等)和平台信息(iOS、Android等)；4. 明確BUG的緊急程度；5. 將BUG錄入到追蹤系統，以防被忽略；4. 開發延期怎麼辦？開發沒有按照約定的時間完成工作...工期一天天的延期，你很焦慮...怎麼辦？怎麼？怎麼辦？接受現實吧，輕度的Delay是難以避免的宿命！如果開發每次都特別準時的交工，那你們的開發一定在保留實力，並沒有拼盡全力…如果你每天上午到公司的時候，看見他們已經在對著你昨晚反饋的BUG冥思苦想了；每天晚上你離開的時候，他們還圍在一起討論解決方案...那麼他們已經儘力了，但畢竟人力有窮盡，輕度的Delay代表他們對產品儘早完工的渴望和你一樣強烈，對產品儘快上線和你一樣的期待，才會讓自己這麼的辛苦的加班。此時你能做的是，把優先順序低的BUG整理好後，在每天的溝通會議上一起提交給他們，而不是一次次的打斷他們；你還能做的是把當前節點裡不太重要但是又比較複雜的功能，放進下一個節點，讓他們能夠專註在重點的功能。但是，如果你的開發團隊面對一天天Delay泰然自若，繼續該遲到遲到，該早退早退...如果你不斷的詢問要延期到什麼時候，但是並沒有人能給出準確的答覆！是時候找CEO和技術負責人一起好好的討論下了，一個項目組人不多心還不齊，這項目不幹也罷了。一個項目想要成事，一定是和一群能夠前途相托，甚至性命相託人在一起，才有可能！所以，產品經理對技術該了解到什麼程度？舉個打車的例子吧：
產品經理相當於一個乘客，知道要去哪兒，開發團隊就相當於是司機。產品經理可以不會開車，不會踩是離合器不會掛擋，但是如果他知道：1. 哪條路最短？2. 哪條路雖然繞一點但是最順暢？3. 如果出現特殊情況，兩條道路都不能走了，步行是否可行，需要多久？就可以省錢省時間！說了這麼多，再送給你們一段我很喜歡的話吧（From 邱岳）：對產品負責，最直接的表現就是「讓正確的事情相繼發生」！如果在這個過程中需要懂技術，就去學技術，需要懂交互，就去學交互，需要懂畫圖，就去學畫圖，需要懂演講，就去學演講，需要懂什麼，就去學什麼…團隊中，誰都可以說這不是我的職責範圍，只有產品經理不行，受不了這個委屈，就別乾產品經理。關注「譜曰」公眾號，第一時間收到我的分享。推薦閱讀：
※鬥魚直播與熊貓直播競品分析
※To Be A Product Manager | Week 54
※如何成為BAT瘋搶的產品實習生？
※你如何看待產品運營這一職位的能力要求？