小程序功能迭代规范

小程序功能迭代规范做了快六年的小程序产品相关工作，我见过太多从爆红到销声匿迹的小程序，也陪着不少好产品一步步从几千活跃做到几十万上百万。总结下来，大部分小程序走下坡路，不是一开始的方向错了，而是后续功能迭代乱了章法：今天老板说要加个功能硬生生塞进排期，明天运营为了冲KPI随便改核心入口，后天发现加了新功能把老流程冲得一团乱，核心用户用着不舒服慢慢就走了。其实小程序因为体积轻、依赖平台生态、用户触点直接，对迭代的要求比APP更高，没有一套清晰的迭代规范，很容易做着做着就偏了方向。我结合这些年踩过的坑、攒下的实际经验，整理出这套完整的小程序功能迭代规范，从前期准备到执行再到上线复盘，每个环节都讲清楚明确要求，既能帮团队提效，也能保证迭代始终沿着对用户和业务有利的方向走。1迭代启动前的需求管控规范所有迭代乱的根源，几乎都是需求管控出了问题。没有把好需求这第一关，后面再努力也很难做出让用户满意的结果，所以迭代前的需求管控是整个规范的基础。1.1需求来源的分级分类梳理小程序的需求来源很杂，可能是用户后台的反馈留言，可能是运营为了拉新促活提的需求，可能是产品经理根据数据发现的体验问题，也可能是业务方或者管理者临时提的想法。不管需求从哪来，都必须先做分级分类，才能决定要不要做、什么时候做。我们一般把需求分成四个优先级：P0级是最高优先级，属于必须立刻做的需求，主要包括影响核心流程的严重bug、违反平台规则或者监管要求的合规问题、会导致大部分用户无法正常使用的功能故障，这类需求不解决，整个小程序都没法正常用，所以必须排到最前面；P1级是核心需求，指的是能提升核心业务体验、解决多数用户普遍痛点的需求，比如到店小程序用户一直反馈找不到开发票入口，电商小程序支付步骤太繁琐，这类需求是每个常规迭代周期的核心内容，大部分资源都要倾斜给这类需求；P2级是体验优化需求，比如调整按钮的位置、改一改容易引起误解的文案表述、优化页面加载速度，这类需求不影响核心使用，解决了能让体验更好，不解决也不会出大问题，排期有空就做，没空就往后推；P3级是探索性需求，比如想做一个新的引流模块、尝试做一套全新的会员体系之类的创新功能，这类需求还没有验证过实际价值，只能排在所有需求的最后，等到核心需求都做完了，有多余资源再碰。我之前吃过不分级的亏，好几年前有个项目，老板出去开会看到同行做了分销模块，回来要求两个月必须上线，硬生生把已经排好的P1级支付优化需求挤掉了，结果分销上线之后，没几个用户用，占了大量开发资源不说，原来支付的问题一直没改，支付转化率掉了快15%，亏了好多，从那之后我们就定了规矩，任何需求都必须先分级，哪怕是管理者提的也不例外，不符合优先级的就是不能插队，规矩面前所有需求一视同仁。1.2需求的前置验证不是所有提上来的需求都是真需求，必须在启动开发之前做好验证，避免做无用功，白费人力物力。1.2.1数据层面验证首先看现有数据能不能支撑需求的必要性。比如很多人说“我们的用户都觉得搜索不好用”，那你先去后台看搜索的使用率是多少，搜索结果的点击转化率是多少，有多少用户搜了之后直接退出了，如果数据显示只有不到5%的用户用搜索，那这个需求就不是急着要做的，反之如果超过30%的用户用搜索，退出率超过40%，那说明这个痛点真的存在，必须尽快做。1.2.2用户层面验证数据能说明问题，但也要听真实用户的声音，不能只看后台数字就拍板。比如有十几个用户留言说要加暗黑模式，你不能直接就排期，得去你的用户群里发个问卷，问问一百个活跃用户里有多少人真的需要，要是只有三五个人需要，那完全可以往后排，毕竟开发适配暗黑模式也要花不少精力。要是大部分用户都提，那才值得做。我一般习惯找五到十个提需求的用户直接聊一聊，问清楚他们要这个功能到底是用来解决什么问题，很多时候你会发现，用户要的不是A功能，是A功能能解决的B问题，换个更简单的方案就能解决，不用大动干戈改核心流程。1.2.3技术可行性预验证小程序依赖微信等平台的开放能力，很多功能你想做，平台不给权限也做不了。比如你想做一键导入通讯录，微信根本不开放这个权限，那想了也是白想，提前找技术负责人做个预评估，看看功能能不能实现、有没有什么限制，需要多少成本，确认可行了再进排期，别等到开发做了一半才发现做不了，耽误所有人的时间。1.3迭代排期规范需求确认之后，就要按照固定的规则排期，保证团队节奏稳定，不会乱忙。1.3.1固定常规迭代周期我们团队这么多年一直用两周一个常规迭代周期，我觉得对小程序来说这个节奏刚好，迭代周期太短，比如一周一个，需求刚梳理好就要上线，开发测试都很赶，容易出问题；周期太长，比如一个月一个，需求堆太多，万一哪里错了调整起来很麻烦，用户也等太久。当然固定周期不代表所有需求都等，紧急的P0需求走特殊快速通道，这个后面会单独说。1.3.2排期必须匹配现有资源很多团队排期的时候喜欢往满了塞，总觉得开发闲不住，能多做就多做，我一直不认同这个做法。排期的时候一定要算好每个开发的工作量，还要留出来至少五分之一的缓冲时间，万一哪个需求开发的时候碰到问题，或者临时需要调整，有转圜的空间。我之前那个项目，曾经为了赶一个活动节点，把两周的排期塞了三倍的工作量，结果开发天天熬夜，测试时间被挤得几乎没有，上线出了三个严重bug，活动开始半小时就崩了，最后活动没做成，还得罪了不少老用户，得不偿失，所以排期真的不是塞得越满越好，留余量反而整体效率更高。把需求和排期都定好，接下来就是迭代的执行阶段，这个阶段如果没有规范，很容易出现理解偏差，做出来的东西和想要的完全不一样，所以执行环节的每一步都要有明确要求。2迭代执行阶段的流程规范2.1需求评审与确认规范需求评审是统一所有人认知的关键一步，绝对不能少。2.1.1评审必须覆盖所有相关方只要是和这个需求有关的角色，产品、前端开发、后端开发、测试、UI设计、运营、业务方，全都要叫来参加评审，不能产品觉得没问题就直接给开发。我之前就吃过亏，一次做一个节日活动功能，评审没叫运营，开发做完了，运营才发现需要的统计字段都没加，没法看活动转化数据，又逼着开发改，耽误了快一周上线，错过了活动最佳时间，所以从那之后我们就定了，少一个相关方评审就不能开始，谁漏了谁负责。2.1.2评审必须讲清所有细节评审的时候不能只说“我要做一个分享功能”就完了，所有细节都要讲清楚：按钮放在哪个位置，分享出去的卡片标题是什么，用户没授权的时候怎么提示，分享失败跳什么页面，网不好的时候怎么显示，甚至极端情况比如用户手机内存满了，保存分享图片会不会崩，这些细节都要说到，不能说“你们看着做就行”，模棱两可的结果就是每个人理解不一样，做出来不对又返工，浪费时间。2.1.3评审确认后留档评审完所有人都没有异议了，把最终的原型、需求文档整理好，存在团队共享的空间里，所有人都能随时看，避免后面出了问题互相甩锅，其实也不是为了追责，就是保证所有人都对齐了信息，不会出现你说东我理解成西的情况。2.2开发与测试规范2.2.1开发要遵循统一规则小程序本身有包大小限制，微信对个人小程序和企业小程序的包大小都有明确要求，超了就没法上线，所以开发新功能的时候，必须遵循团队原来的代码规范，不能随便写，冗余代码要及时清理，注释要写清楚，方便后面其他人维护。另外，所有新功能上线都要提前埋好统计埋点，把你要观测的核心指标都提前埋好，别等到上线了要数据了才发现没埋点，再重新发版，耽误时间。2.2.2测试要覆盖全场景测试不能只测新开发的功能，一定要做全链路测试。就是你加了新功能，要把原来的核心流程从头走一遍，看看新功能有没有影响到老功能。我见过太多这种案例，加了一个新的个人中心模块，结果把原来的支付流程给改崩了，用户付不了钱，就是因为只测了新功能，没测老流程，对小程序来说，这种核心流程出问题，用户真的会直接删掉，不会给你弥补的机会。另外还要做边界测试，比如用户输入特殊字符会不会报错，网络差的时候会不会一直加载不出来，这些小细节最能体现产品的好坏，也最影响用户体验。2.2.3改完bug必须做回归测试开发改完bug，测试不能只测改的那个bug就完事，一定要再把相关的流程都走一遍，确保改这个bug没有弄坏别的地方，很多新bug都是改旧bug改出来的，这个步骤一定不能省，别嫌麻烦，省这一步后面可能出大问题。2.3上线前的平台审核预检小程序和APP不一样，上线必须经过平台审核，平台的规则经常变，很多时候你开发完了，审核不通过，耽误上线时间，所以上线前一定要自己先检查一遍。首先要对照平台最新的审核规则过一遍，比如有没有诱导分享、诱导关注，有没有违规内容，有没有未经授权用了别人的版权内容，这些都是平台审核会卡的点，提前改好，别等打回来再改。其次要做兼容性测试，不同品牌的手机、不同版本的微信、折叠屏和普通屏，都要测一测，别你自己用的最新款苹果手机没问题，大部分用户用的安卓旧机型打开就闪退，那上线就出大事了。很多人觉得功能上线了，迭代就结束了，其实不是，只有验证了功能真的解决了问题，迭代才算完成，上线后的验收和复盘，能帮我们把下一次迭代做得更好。3上线后的迭代验收与复盘规范3.1灰度发布与观测规范不管是什么功能，我都建议先灰度发布，不要一下子全量上线。灰度就是先给一部分用户开放，比如先给10%的活跃用户，或者只给某个区域的用户用，观察个两三天，看看有没有严重bug，数据有没有异常，要是有问题，直接下线就行，影响面很小，不会连累所有用户。我之前吃过全量上线的亏，一次大版本更新，没灰度直接全上了，结果部分老版本安卓系统打开就闪退，一天之内活跃掉了快八千，后悔都来不及，从那之后我们就定了规矩，任何功能上线都必须先灰度，哪怕是很小的优化也要先小范围试一下。灰度期间要盯紧核心指标，每个功能立项的时候都定了要达到什么目标，比如做支付优化就是要提升支付成功率，做分享功能就是要提升分享带来的新用户数，这些指标要每天看，连续看一周，等数据稳定了再看结果，刚上线的数据波动大，不准。同时还要主动收集用户反馈，看看用户有没有吐槽新功能不好用，有没有人说哪里用着不顺手，小问题记下来下次迭代改，大问题直接回滚，别硬扛着。3.2迭代效果验收规范灰度没问题全量上线之后，就要对照最初的需求做验收了。首先就是对标初始目标，当初我们做这个需求是为了解决什么问题，现在问题解决了没有？比如当初说用户找客服太难，要把客服入口放到首页，现在看用户咨询客服的比例提升了多少，用户因为找不到客服投诉的数量降了多少，如果达到了预期目标，那这个迭代就是成功的，如果没达到，就要找原因，是方案不对还是推广不到位。如果一个功能做出来，数据不好，用户也不买账，一定要及时止损，该下线下线该调整调整，别舍不得已经投入的成本，放在那里占位置，影响整体体验。我之前见过一个项目，花了三个多月做了一个商城模块，上线之后半年每个月都没几单，还占着底部导航最重要的位置，把原来核心的预约功能挤到了二级菜单，结果整体活跃掉了20%，就是因为负责人觉得花了这么多钱做的，下线太没面子，硬扛着，最后把整个项目拖垮了，所以该放下就要放下，没什么丢人的，承认错了改了就好。3.3迭代复盘沉淀规范每次迭代不管成功还是失败，都要做复盘，把经验教训留下来，让规范跟着项目一起成长。首先要总结做得好的地方，比如这次需求验证做得充分，做出来的功能用户满意度很高，那下次就继续保持；这次提前做了审核预检，审核一次就过了，比之前快了两天，这个经验也要记下来。然后要梳理存在的问题，比如这次排期太满，测试时间不够，出了好几个小bug，那下次排期就多留缓冲时间；这次评审没拉运营，导致后期改需求，那下次就把必须参会的角色写到规范里。最后要把复盘的结果更新到我们的迭代规范里，规范不是一成不变的死规则，是跟着我们的经验不断优化的，越用越好用。除了常规的功能迭代，我们还会碰到一些特殊场景，这些场景也有对应的规范要求。4特殊场景的迭代规范4.1紧急问题迭代规范如果上线之后出现了P0级的紧急问题，比如核心流程崩了、出现了合规问题，这个时候不用走常规的迭代流程，直接走快速通道：产品快速确认需求，开发优先排期做，测试加急测试，上线之后再补文档和复盘，绝对不能拖着，拖一个小时就多影响一个小时的用户，碰到紧急问题就是要快。4.2大版本重构迭代规范如果是整个小程序的大重构，比如换框架、全界面大改版，千万不要一下子全部换掉，最好分模块迭代，先改不影响核心流程的边缘模块，再改核心模块，改完一个测试一个上线一个，不要一次性全换，一下子全换很容易出各种问题，出了问题都不知道哪块错的。而且大改版之前一定要做足用户调研，提前通知老用户，