作為產品經理，如何對應用的質量狀況進行監控？
提這個問題挺忐忑的，因為我們的開發也在上知乎。
我是一個移動應用的產品經理，目前負責一個有幾百萬用戶的應用，最近上線了一個新版的產品之後，在用戶群裡面收到一些用戶的反饋，表示使用過程中容易卡，有的甚至閃退。我將這個問題反饋給我們開發同學之後，他說這只是個別情況，不需要理會。目前他正在提離職，一個月後就走，我覺得他有點心不在工作上了，一切需求都是在敷衍。我需要怎樣才能知道開發說的是不是真的呢？突然意識到自己對應用的質量有點失控了。我不懂技術。
o(︶︿︶)o 唉，這個問題，是產品與技術之間的歷史遺留問題啊~
產品經理不懂技術，就會經常被開發同學鄙視，甚至忽悠。
不懂技術沒關係，他們還不懂產品呢！（開玩笑哈開發同學別打我）不懂技術，但是你要會一些技術手段，比如一個能夠監控你應用質量狀態的工具，比如Crash率低於多少，個別Crash對用戶的影響有多大，都是要去關注的。不是開發說一句「這個錯誤影響小」你就可以忽略的。開發不是喜歡「用數據說話」嗎？你就讓他看數據唄！--------------------------------------------------------------------------------------這個問題把我拉回了之前一段痛苦的經歷：產品規劃做好了，發布時間也定好了，但是移動開發工程師一直還沒有招到，因為戰略原因，必須在定好的時間發布這一款應用，實在找不到人了，只好去找外包開發同學。給我們做應用的這位同學也是兼職做外包的，有自己的本職工作，非常忙，在這樣的背景下，我和他的拉鋸戰就這麼開始了。
那個時候，每次拿到包，我都會去內測用戶群裡面讓大家體驗，然後收集用戶反饋，整理後發給這位開發同學，經常會遇到一些無名的crash，我這邊無法重現，於是開發同學就不去解決了。但是每次更新包拿給用戶體驗後，都會發現總有幾個用戶的機型會重現這個錯誤，這個crash的一直未修復，已經引起了他們的不滿。但是開發同學說：那只是個例，影響不大。我竟然不知道該怎麼反駁他。這幾個用戶使用的機型是現在市面上流行的機型，而直覺告訴我，這絕不是個例。- 幾個你需要關注的與質量相關的指標
Crash次數：在選定的某段時間內，應用程序報錯的次數；單純只看這個數字沒辦法看出什麼問題，這個錯誤次數要跟錯誤覆蓋人數、活躍用戶數、用戶留存率等指標進行重疊查看。
Crash覆蓋人數：指的是在選定的某段時間內，應用程序報錯的設備數，這個指標就很能說明問題哦，如果這個指標很大，就說明你的應用的質量問題已經影響很廣泛了，用戶這個時候可能已經準備卸載你的應用並且上社交網路叼你了。每次啟動的Crash次數：在選定的某段時間內，你的應用平均每啟動一次會出現多少次錯誤，計算方法：Crash次數 / 啟動次數。這個字數越小越好。
接下來以移動統計-騰訊分析的報表作為例子來解讀這些指標。
可以看一下下面的這個圖，從這個數字可以看到這個應用昨天錯誤次數有208，錯誤覆蓋人數/設備是84，還好每次啟動錯誤的次數僅有0.0686。但是我們看一下錯誤覆蓋活躍用戶佔比，達到了1%，也就是每100個經常使用我們應用的用戶（活躍用戶）裡面，有1個人就會發生錯誤。活躍用戶是我們需要重點去維護的群體，有一句話叫做「好事不出門，壞事傳千里」，一個應用用得好，用戶可能不會在社交網路上去發聲，但是如果一個應用給用戶帶來了不好的體驗，那麼他會有很大幾率去社交網路上去發泄。
- 如何判斷錯誤是個例還是普遍存在
之前的那個案例中，我有提過那幾個不滿的用戶使用的是流行的機型，也恰恰是這個報表中顯示的錯誤頻發的五大機型之一。內測階段，錯誤一旦發生在這麼幾個流行機型當中，如果錯誤沒有被解決，那麼公測的時候這些錯誤很有可能會被放大到幾個數量級，對於我的習慣來說，不管錯誤是個例還是普遍存在，在內測階段，絕對不允許錯誤的存在。
當然，當你獲得你想要的說服性數據之後，還是要保持謙卑的狀態，去跟開發同學提bug修復需求。不然就沒人給你做事啦！
--------------------------------------------------------
其實，產品和開發、運營、設計同學之間那麼多的段子，都是因為看問題的角度和立場不一樣，產品希望其他同學有產品sense，開發同學希望其他同學有技術思維，運營同學希望其他同學有市場觸覺，設計同學希望其他同學有審美觀。如果你是有求於人，就必須站在他的立場，用他能夠理解的語言去溝通。我覺得問題偏了。產品經理對質量問題帶來的結果負責，質量監控是統計系統的職責。
具體到事情上，你只有一件事情做錯了：你把用戶的反饋，再反饋給研發同學，這只是收集彙報，沒有分析。這是客服同學做的事情，不是產品。
像其他人說的，你需要
1、增加對崩潰的監控。如果現在沒有就列出需求請研發做崩潰數統計，如果系統對崩潰統計不全就自己設狀態，啟動時檢查上次是否正常退出2、分析、定位和重現問題。去問用戶怎麼遇到問題的，找到出問題的地方。如果找不到就多找幾個用戶，多試幾台機器，多花點時間。一兩天弄不出結果就列為長期跟蹤事項，知會相關各方和老大請求幫忙關注。真正的疑難雜症半年一年後才能找到根源也很正常，但沒就算沒有結果也要去做，因為這才是產品的工作
2a、分析競品。3、安撫用戶。不是說光發發郵件就行了，制訂方案，論壇發帖寫blog公開信官方微博，根據情況而定。
4、推動研發。如果他要走了，找接替的人；如果沒有接替的人，找主管要，如果第2步做好了得到認同，那肯定有；如果接替的人能力不足/沒時間/沒找到辦法，給他時間和幫助，同時做好2 和3
5、評估損失，評估時間，提出彌補的方案。如果這個崩潰就是解決不了的怎麼辦，如果新人要好幾個月怎麼辦？日子還是要過，kpi還是要做，崩潰不是理由，再多崩潰你也要把目標完成。評估一下優先順序吧一個有幾百萬用戶的應用。也就是你有做應用統計吧?隨便一個統計平台，都有應用崩潰的統計。所以...哎...知乎軟文太多了
1.一個幾百萬用戶的產品，最基本的數據track應該是有的吧，必備不是？比如：日激活、DAU、MAU、Crash率、安裝留存、活躍留存、活躍時長……迭代中產品或者開發都應該根據需要去track一些數據吧，比如某個功能交互流程的層層轉化率、比如用戶在某個地方的交互行為分布等等
有了數據，問題就能定量、定性。到時候閃退之類問題還需要靠用戶提的feedback來發現？有了數據，問題還需要靠誰來拍腦袋說是否嚴重？
2.發布後，按理說PM和Dev都應該時刻關注數據趨勢。發現數據異常，不就應該分頭分析原因么？產品分析是否產品層面決策失誤，開發分析是否存在代碼bug或是否存在數據track的bug。3.質量把關不該有個標準，根據測試結果來決定是否合格才發布么？發布後發現反饋變慢、閃退，測試是不是也該行動起來，復現下用戶提的問題甚至做做壓力測試么？4.一個團隊的東西，質量把關不該是一個人的事啊，更不應該靠拍腦袋啊，數據！最近在負責一款Android 導購應用的APP，在產品開發過程及完成後，對應用質量的測試及監控涉及到以下要素：響應速度
- 啟動速度
- 推出速度
- View切換速度
- 啟動內存
- 退出內存
- 後台運行內存
- 正常運行內存
- Monkey後 測試內存
- 錄放測試後內存
- 啟動CPU
- 退出CPU
- 後台運行CPU
- 正常運行CPU
- Monkey測試CPU
- 啟動能耗
- 退出能耗
- 後台運行能耗
- 正常運行能耗
- Monkey測試能耗
- 網路連接成功率
- 流量測試
- 網速測試
- 網路並發利用率
- 數據並發利用率
- 來電應用並發
- 簡訊應用並發
- 彩信應用並發
- 鬧鐘應用並發
- Monkey測試
- 人工操作
邊界情況
- 異常來電
- 低存儲空間
Findbugs測試報告
內存泄露測試
自身功能測試bug的數量（一般某一類型的應用的bug達到一定數量，才可達到相對穩定）最後是針對競品的功耗、啟動速度、載入速度、功耗、內存泄露等測試數據對比
希望對你有幫助哈首先確認用戶使用的機型。
聯繫QA（軟體測試）用同樣的機型確認。如果確實有問題，提交bug，產品經理根據bug的現象制定bug的級別和修改的時間。如果QA沒有發現「使用過程中容易卡，有的甚至閃退」的現象的話，那很可能就是用戶的環境本身不是很流暢了。（裝載的應用太多，後台運行的東西太多等）如果你們公司沒有QA的話，那我只能建議產品經理你親自測試了。同時記得成立測試部門，招一些測試人員……最後，如果一個產品經理不懂技術的話，他起碼要懂基本的代碼邏輯（可以不會寫不會讀代碼，但是要能聽懂開發是怎麼實現的），以及了解或掌握黑盒測試技能。幾百萬用戶的應用，怎麼知道的？應該有統計上報吧！1、crash每日都要統計crash率，一般是每日的crash總數/啟動總數＊100%，生產環境中如果這個值高於1%就比較嚴重了，每日郵件給項目組成員、領導，大家都看到結果，crash高了，自然有人問了2、統計不只統計crash，還要統計用戶的行為，常用功能，這樣可以用數據說明產品修改的側重方向，否則光憑一張嘴，大家都以為PM在折騰，產品質量自然難以提升3、RD在離職，就別指望太多，做了是敬業，不做也沒辦法
可以使用dyna trace，可以監測應用，並且快速定位故障，節省時間
我之前發布移動應用的時候也遇到過類似問題，被類似的話擋回來了。結果是問題一直沒有解決，直到後來公司又進來了一個細緻的移動開發程序猿，仔細的檢查了每一個Crash，發現了一大堆問題，最終解決了問題，主要是設計架構和編程不仔細，或者因為省事，壓根沒寫驗證代碼。但是，有句話一直在程序猿的信念中，就是只要你能想出來，開發是無所不能的。就算沒有解決辦法，也一定有事件的原因。只要發生過類似的情況，尤其在測試階段，就算是個例也應該高度關注。以個例的情況進行分析，是否是某種手機，是否是某種版本，運營作為中間體，就應該推斷出一些方向，再根據客戶反饋或者內部測試，進行進一步的差錯擴大性測試，查找問題原因，給開發者節省查錯的時間，互相合作。我覺得把這個問題都賴在統計上，是種懶政，就像是政府總把小事當做個例處理一樣，覺得特例就不處理，遲早出大事。反過來，作為開發，要省事，要做大事不拘小節的想法可以理解，但這其實是有背服務用戶的理念的。
推薦閱讀：
※你為什麼做產品經理？
※產品經理如何進行市場調研？
※產品經理需要背負銷售額么？
※mockups和墨刀還有axure，三個對於產品的發展來說哪個更好？
※flyme4現有系統中，你覺得改進空間最大的模塊是哪一個?