從2018年小程式誕生，到2020年今天的小程式。小程式的能力逐漸被放大，從入口、互動、獨有樣式，小程式已成了微信生態中不可少的一環。站在產品經理與開發者角度，小程式的稽核對比2018年，已經是難上加難了。

稽核的維度從登入註冊、到誘導分享判斷，再到虛擬產品等等。一個合格的小程式在推向使用者前，產品經理首先要先思考一個問題

“這樣做，小程式能不能稽核通過”

可是你知道嗎，小程式稽核的這條路並不容易。

花小程式稽核：登入註冊

小程式的稽核有個特點是：隨機性

我建議產品經理或開發者永遠不能因為有1次稽核通過後，就放鬆其他產品問題的警覺性。比如上面截圖顯示稽核登入註冊，其實在前面1.0、2.0是沒有發現的。在3.0卻出現了類似提示，逼得產品加上了暫時不登入的入口需求。

這類稽核問題不僅要影響前端邏輯、還需要重新整理UI設計。

小程式稽核：猜不透的產品型別

同樣要注意的是隨時更新小程式型別，上面這張圖是在2.0稽核不通過出現的。但線上1.0並沒有在之前出現過這類拒絕。由於每次稽核人員的隨機性，導致每個人工發現的問題都不一樣。這類問題需要產品經理或開發者在小程式稽核提交後臺更改自己類別。

但麻煩的是相信許多開發者和產品經理並不知道自己的型別，也只有等到稽核被拒才知道應該修為什麼型別

小程式稽核：難以找到的bug

上面這張圖是在3.0稽核的拒絕說明。這類稽核不通過是最致命的，甚至差點讓團隊感覺到放棄準備換個思路。甚至研發負責人當時還在調侃：“是不是稽核人員在忽悠我們？一天一個拒絕理由”

畢竟在真機環境上、還是測試機型都沒有存在這類問題。甚至在1.0灰度釋出後，也沒有得到使用者這類吐槽。

但後面開啟測試環境，反覆除錯發現這類bug復現需要重複登入若干次。所以第一是怪自己運氣不好，第二也是非常佩服微信小程式審合同事的敬業心。

小程式稽核：產品經理不容小看

其實在小程式策劃前，我們是非常期待小程式代表的移動端落地帶來使用者的快速增長。但是到真的釋出後，發現效果也是一般。

問題在哪裡？

第一：推廣期

無論小程式還是app，產品的核心還是要使用者的留存率。在產品有bug或未完善功能時候就不要釋出和推廣。損害了第一批使用者的體驗、降低了留存。

等到小程式後續完善了，使用者也離開了。要是在產品完成推出比較完善的版本，就會避免這類使用者流失

第二：小程式稽核次數

在小程式推廣前，我們太過於著急將小程式提審。結果線上環境的小程式要麼是有bug、要麼是產品設計存在邏輯問題。所以在整體小程式矩陣搭建下，我的建議是：完成小程式體驗版本多次釋出、但小程式先上版本要保持穩定、成熟再發布。

第三：小程式的能力限制

假如是策劃app，面向C端的產品經理可以發揮出自己的想法和尋找海量的競品借鑑。但現在的小程式更多的是線下場景，線上的app廠家很少有小程式落地。

大部分原因是就內容消費和閱讀體驗，因為前端的實現能力侷限。小程式對比app，app是有非常大的優勢。

比如PMTalk的小程式在原方案通過呼叫H5的方式直接換成了原生。前者目的是為了減少開發成本，而後面才發現傳播性、使用者閱讀體驗更重要。所以及時更換同樣也是為了增加開啟的使用者體驗。

同樣安卓小程式、和IOS小程式在閱讀效能上也是有較大差異。比如同為富文字處理的體驗報告，2者卻有明顯的閱讀視覺差距。需要產品經理與UI設計師共同除錯。

最後，近期也在打磨小程式系列課程。利用春節放假假期為大家帶來小程式的系列課程，學習我們在小程式從0到1、從1到10的增長和策劃經驗。