這陣子，經歷了一個做產品以來速度最快的一個項目，太多第一次遇到的情況，從中秋節前到現在，除去校招出去的5天，一直都在趕項目。即使是校招，也是以項目為主題進行群面和創意PK。

每天早上9點多到公司，晚上12點后收工，甚至有到凌晨4點才下班，早上7點多起床，中午還不休息。

趕項目的節奏，大抵如此吧。這不是一種健康的狀態，會逐步調整過來。

先說一點特別重要的事情：

無論進度多趕的項目，發布前，請一定內測。

無論進度多趕的項目，發布前，請一定內測。

無論進度多趕的項目，發布前，請一定內測。

這段時間，真的忙不過來，文章寫的少。一些人說，BLUES，你有多少多少粉絲，我的感覺是，千萬不要說什么粉絲，我有自知之明，個人還沒那么多魅力，大家訂閱BLUES的公眾號，是因為對工作，對生活有幫助。

我們能成為朋友就挺好了，別指望什么粉絲，所幸還是在公眾平臺交到不少朋友。

看到自己的文章，被朋友們推薦轉發，也是極好的，我也偶爾發發紅包表示感謝。

有的好友從第一篇文章開始就和BLUES互動，時常在后臺給些建議，說些感想，發幾個打賞，也讓BLUES感受一下拿紅包的快樂，也是一種作者的存在感吧，雖然，從一開始寫文章，也沒想過什么回報，后來的回報都是水到渠成。

互聯網產品上線前：產品經理、開發、測試該做些什么？這是近些天，我們的項目團隊在做的事情。寫一些心得吧，來自騰訊、YY、迅雷的工作實踐匯總，有些雜亂，不一定全對，供大家參考，有興趣的同學可以整理一下。

歡迎大家評論、回復留言進行補充、完善，BLUES匯總后再發給大家修訂版。

產品經理的自查

1. 需求文檔是否補充完整？例如交互圖、設計稿是否已經更新；
2. 客服文檔是否已經提交并進行客服培訓；
3. 每個功能特性是否有確定的輸入、處理、輸出？
4. 是否有異常結果的處理？
5. 頁面跳轉是否有給出明確的地址？
6. 產品文字是否已檢查？（包括但不限于頁面文字、廣告語）
7. 發布策略是否已考慮，灰度發布是否在文檔中有說明？
8. 已有功能、標識的改動，在其他模塊的呈現，是否覆蓋完整？
9. 如涉及現有產品的老功能刪減，需要和客服溝通；
10. 需求特性是否區分用戶身份？
11. 未實現的需求是否在文檔中注明？
12. 除了正常狀態，異常條件下的兼容措施是否考慮？
13. 統計需求是否明確提出？數據是否正常上報？

草擬了一個產品經理的自查表，供大家參考。

模塊表格的字段如下：

1. 頁面
2. 功能點
3. 用戶狀態
4. 輸入（操作）
5. 處理
6. 輸出（結果）
7. 異常處理
8. 跳轉
9. 文案
10. 統計需求
11. 備注與問題

產品運營的自查

1. 產品的冷啟動是否已經準備完畢？
2. 內容運營的更新機制是否已經確認，并進行部署，是自動更新，還是人工更新，有無更新機制和審核發布機制？
3. 產品活動運營是否已經進行規劃？是否有專人負責？周期性的活動，是否已經有運營模板？
4. 產品數據是否已經正確上報？是否通過數據測試？數據報表是否已經就緒？
5. 新媒體運營的賬號是否已經建立，是否有專人負責？是否有內容規劃？內容獲取途徑是否已經建立？
6. 渠道運營是否已經建立，例如應用商店的合作，SEO，ASO的計劃和實施；
7. 用戶消費充值的路徑是否順暢？數值是否準確？

開發自查

1. 每個功能是否全面自測？邊界/異常參數的確認和驗證（如果有以類似lib方式對外提供被調用API）
2. 是否進行高危函數掃描？
3. 是否進行安全漏洞掃描？
4. 是否有內存泄漏的檢測和結果（如果是C/C++代碼）？
5. 不必要log是否刪除了，以及log信息是否清晰完整詳細？
6. 統計上報是否完整？
7. 代碼在編譯環境已編譯通過？
8. 是否有socket泄漏？
9. 是否影響其他相關模塊功能表現？
10. 自身系統壓力是否已評估？
11. 后端支撐系統負載變化是否已評估？
12. 是否對業務流量有影響？
13. 轉測試文件和ARS單是否完整
14. 產品體驗是否通過？體驗反饋的問題是否已修復？
15. 是否需要灰度，采用何種灰度方案
16. 是否需要提前發布配置？

測試人員自查

1. 產品通過測試的發布標準建立；
2. 用例編寫是否100%覆蓋需求；
3. 是否及時有效地修改自動化用例(CGI的修改涉及到自動化用例部分的內容) ；
4. 用例編寫是否有考慮異常邏輯&優化(如web前臺,性能等)的情況 ；
5. 是否有認真閱讀提測郵件的測試重點,有針對性的編寫用例；
6. 是否有發起用例評審,并根據評審意見修訂用例；
7. 測試Bug是否進行有效性跟處理,直至閉環；
8. 版本發布時是否確認Bug單的狀態為已關閉或已掛起,否則不允許發布 ；
9. 測試報告是否及時發送；
10. 開發完成后，頁面重構人員把版本內涉及的文件提取并入測試環境原版本內 ；
11. 提供相關ARS單信息給開發pm提單操作；
12. 配host到測試環境，確認代碼版本正確，確保無bug，確保頁面準確還原設計稿；
13. 測試過程中，會提出為改善用戶體驗以及細節的缺陷，測試人員會通過XXXX系統提交bug單發送給相關責任人；
14. 評估名下bug單的優先級和處理時間點，統一時間處理；
15. 處理完成后，及時更新bug單的狀態；
16. 代碼是否上傳XXX系統？
17. bug狀態是否已更新？
18. 遺留bug是否已經過PDM、PM、TE評估？（致命及嚴重bug需要測試leader和總監確認）
19. 發布時間和內容是否符合發布規范（例如版本中包含后臺server發布，晚上高峰期需要經過審批才能發，日常版本不能包含cgi等）
20. 配置文件的修改是否恢復；
21. 外網運營環境版本是否與測試環境一致；
22. 影響到其他模塊表現的，發布前對方測試人員是否已做功能驗證并確認ok
23. 版本發布后是否留守進行外網驗證,發出驗證報告后才離開
24. 外網驗證的Bug是否有跟進處理(嚴重Bug要跟進及時處理,其他Bug階段性的跟進處理)

#專欄作家#

Blues，微信公眾號：BLUEMIDOU，人人都是產品經理專欄作家，迅雷產品總監，原YY語音、騰訊高級產品經理。具有十年產品經驗，多年產品講師經驗。著名自媒體人，WeMedia自媒體聯盟成員，十佳自媒體人之一。擅長產品策劃、產品運營、數據分析、用戶研究、行業分析等。

本文原創發布于人人都是產品經理，未經許可，不得轉載。