小程序服务质量 第1篇
小程序运营属于软件产品运营的一种类别。从产品生命期来看，小程序运营分别为研发期、种子期、成长期、成熟期、衰退期。另外由于小程序在运行模式和定位的不同，表现在推广形式上与平常的软件产品有很大的差别。接下来，我会用【GS比赛计分】【数据查询助手】小程序为例子佐证分享小程序的运营经验。
当你不是运营小程序的产品策划者，你需要首先要搞清楚产品的定位以及目标用户。（这也是多数互联网公司将产品策划和运营作为一个岗位的原因）。在整个产品的研发期，需要跟进产品的每一个细微功能点，要明晰产品的使用用户；还要时刻去观察产品的领域有没有竞品的出现，用户习惯有什么改变；要时刻去衡量产品的竞争优势，为之后的发布运营做好准备。【数据查询助手】是提供自定义信息查询服务的小程序。任何微信用户均可以上传自定义的数据（报表，成绩单等任何表格数据）建立查询。
当在产品研发的一个月，我不断的探索小程序领域，APP领域，Web领域有没有相同的功能产品或服务。甚至将问卷系统（腾讯问卷、问卷星、问卷网）作为潜在的竞争对手。
另外我还制作了web版和原生APP的Demo去体验他们与小程序体验的不同。去确定微信小程序是很好的适应平台。从而为之后的运营做足了准备，提升了自己的信心。
小程序体验版相当于其他应用平台的内测版。体验版可以更高层次的模仿真实的用户环境。在这一阶段更容易发现用户间连接要求高的应用缺陷。同时可以在安全的范围内去聆听用户的真是使用反馈。
【GS比赛计分】开展了长达1个月的体验版。邀请了20个核心用户去体验。由于应用需要与服务端建立实时连接。用户不同的设备，不同网络环境对程序的稳定性做出了很大的考验。在这一阶段修复了不少场景不同导致的错误或者效率低下问题。
另外一开始推出的小程序界面设计只遵从了功能设计，没有很好的考虑真实的使用场景。所以在这一阶段，我最大程度上听取体验用户的建议，对整个界面进行改版，使交互更加的亲近用户。
当小程序功能稳定后，到了成长阶段，用户使用是最核心的任务。获取用户的时候，必须先让对方了解自己的产品，建立认知，将产品介绍给用户，让用户进入小程序之后，想方设法让产品与用户产生交互，让用户不断体验产品，让活动始终覆盖用户，让用户对产品认可，要完成产品与用户的关系构建。
从现在许多小程序的运营手段来看，基本上都围绕着社交裂变和线下推广的方式来提升小程序的获客表现。而小程序由于较低的开发成本，较快的更新速度，以及较低的试错成本，使得多数很强势的小程序都采用功能矩阵发展模式，快速实现功能及迭代。
小程序获取用户的手段主要由下：
朋友圈分享（包括图片二维码、广告直接进入）；
聊天好友推荐转发；
线下二维码（包含商家推广、广告推广）；
微信搜索（一般由其他社交平台或者用户需求引起）；
线上识别二维码（线上推广，文章推广，或其他社交平台的推广）；
其他小程序的跳转（互相推荐）
公众号跳转（公众号运营推广）
APP跳转（一般是APP延展的简洁功能推广，或者轻量级触达用户形式的推广）
小程序发掘社交推广的手段主要由下：
社交立减金，实现社交裂变；
社交比拼玩法，引导社交裂变；
互动加入分享按钮，提醒用户转发；
设计同伴环境，鼓励社群传播；
设计任务玩法，领取奖励；
设计福利，鼓励好友助力；
聚焦核心功能，促进口碑传播；
【数据查询助手】从产品定位上就自带社交裂变的元素，当查询创建者创建了一个查询后，他可以根据要分享的人群情况选择多种分享方法。如果是企业微信或者微信工作群，那么可以直接分享小程序到聊天窗口。其他的用户可以直接进入小程序进行查询。如果是线下的查询（推广会，现场发布等），可以通过小程序二维码的方式进入查询界面查询。对于其他社交平台来讲，可以用二维码来做分享，如果是常用用户（添加到我饿小程序或者桌面作为常用工具的用户），可以直接通过复制文字（含查询码）然后进入应用的方式快速开始查询。
同时每一个查询者，都可能是潜在的查询创建者和程序推广者。所以要在这一阶段不断的优化体验流程，尽可能做更多事情覆盖多场景的查询（比如微信搜一搜直接搜索查询码，直接查询），去吸引用户，留住用户。
由于小程序用完即走的理念，导致许多工具类小程序（不含深度融合线下和社交的）用户的留存普遍较低。既然工具类就是服务用户，那么就把小程序慢慢的做成一种用户习惯，从习惯的养成变为行业应用的转化。从转化中寻找切入点，进而挖掘可以创造价值的功能产品。
所以，做小程序不要过分贪图大规模的使用率，大批量的用户。他本身是一种服务理念的触达和养成，你需要在用户心里养成使用习惯，而不要上来糖衣炮弹把用户打蒙，甚至反感。这样小程序的生态就被搞乱了。
刚才讲到，小程序有较低的开发成本，较快的更新速度，以及较低的试错成本。所以在小程序成熟期需要根据用户数据不断的去更正调整功能，去保持较高的运营分数。在产品功能中，适时的进行用户付费转化。
付费转化一方面可以拉开用户层次，对小程序的用户是一种活水作用，提升用户的使用粘性，容易过滤最核心的用户，提供更加好的产品服务。如果在成长期很好的进行用户习惯的养成，这个过程会更加自然。反之，应用将会更快的进入衰退期。
付费转化的方式主要由几类：
电商类：主要靠活动、优惠刺激（现实抢购、秒杀、预约、限时满减、显示商品库存和抢购人数）；
游戏类：游戏道具（向朋友求助、每日签到、社区活动等方式免费获得，但数量有限，且都是一些级别较低的道具）高价值道具付费、皮肤售卖、游戏币购买；
内容类：付费文章、阅读币购买、付费课程；
小程序开发周期短，很多时候应用分析不够透彻，更多的是一些商业或推广试错。导致许多小程序还没有进入成长期就进入晚期了。这一类小程序直接舍弃就好，不需要什么转化了，这也不算小程序的衰退期（没有盛何来衰）。
对于经历过成熟期的产品主要有几个原因导致进入衰退期：
现在多种多样的互联网产品不断产生，产品竞争异常激烈。互联网产品的运营手段也是推陈出新，花样繁多。在这里我不给大家分享一些运营花样，因为每个小程序都是独特的，应该有自己独特的运营手段，具体是什么，希望产品者和运营者本身用热爱小程序的心去发现和实践。
永远保持对产品的尊重，对用户的尊敬是每个产品人最重要的事情。如果对应用足够热爱，你会厌恶他被污染，他被别人嫌弃；你会尽自己的可能让他变得更加本真，你会合理的去运营突破，去帮助产品走向更高的位置。
如果你没有爱你的产品，再出色的产品也只是昙花一现而已，并不能给你带来任何长远的意义。
小程序服务质量 第2篇
要清楚的认识到小程序对自己需求的最大赋能，需要从最初去理解小程序的定位，微信团队对于小程序的定义是这样的：
微信小程序是一种全新的连接用户与服务的方式，它可以在微信内被便捷地获取和传播，同时具有出色的使用体验。
通过对小程序提供能力的分析，不难看出。小程序相对于APP来说，在降低开发门槛的同时能够满足最普遍的应用需求，适合生活服务类线下商铺以及非刚需低频应用领域。使得微信通过小程序作为生态的建立者和维护者，赋能商家和应用者。以一种生态触角的状态来迅速的捕捉最大化生态红利。
当清楚的理解小程序的定位后，那么就需要合理的筛选需求并进行应用的功能设计。我将会使用【GS比赛计分】作为例子进行分析说明。
首先思考的是，自己需要做的功能都有哪些，使用人群是谁？使用场景是什么？需要数据的实时性吗？
一开始设计【GS比赛计分】的时候，目的是为了解决现在的中小型比赛使用人工计分的失效性差，出错率高，人工和时间成本昂贵的问题。程序的目的是将比赛计分的相关人员用互联网工具联系起来，以提升计分效率。
当明晰了产品目标后，开始考虑使用人群。一般来看，大多数的比赛计分都是由两种角色构成的，一个是评委（分数确定者），另一个是工作人员（分数汇总者）。
传统的计分过程是通过现场工作人员将评委的分数以纸质的形式送达计分人员。在这一过程中就有大量的成本浪费了（一个是人力成本，另一个是时间成本）。另外，计分人员以Excel或计算器和笔记的形式进行比分汇总，在这一过程中又存在大量的成本浪费（人力成本和时间成本甚至还有错误风险）。
所以横观所有的主观评分的线下比赛，无一例外都存在比赛结束后有长时间的节目或视频热场环节，其实这都是在为人工计分的缓慢争取时间。
所以，【GS比赛计分】的使用人群和使用场景就确定下来了，与传统人工计分的过程类似，只不过需要互联网赋能，解决时间和人力成本。需要数据的实时交互。
【GS比赛计分】作为解决现象问题的工具，首先需要做的就是不要违背现象中事件的发生次序。所以功能完全参照比赛计分过程来设计。具体功能如下，提交成绩，撤回成绩，弃权处理，实时的选手分数，实时的选手名次，清楚评委数据，解绑评委，重启比赛，结束比赛，比赛内置会话。
当程序的功能确定好后，不要着急着手界面设计，功能模块的组合，交互设计这些过程。当你在进行这些过程之前，需要认真的去考虑你的应用是不是适合在小程序上开发。
小程序的火爆，注定有许多人盲目的进入这一领域，但不是所有的应用都适合小程序的推广模式，也不是所有应用都能吃得起小程序的运行效率的。所以在确定开发小程序之前，正确的认识的合适与不合适，避免让自己的成本白白的付出。
如何确定适不适合用小程序来做呢？我们可以让小程序作为一个互联网平台，把应用带入到互联网的每一个平台中去，进行横向的对比，去找出各自的优点与不足，当做出客观的判断后，应用在小程序上相比于其他平台有没有优势就很明显了。
还是以【GS比赛计分】举例。我所横向对比平台包括PC、原生APP、Web平台、轻应用、小程序。首先从满足功能来说，比赛计分需要很稳定的实时性，所以我将Web平台排除（因为复杂的比赛环境，不同的设备浏览器难免会有问题）。
然后将剩下的平台做分析。PC平台使用可能性太小（原因：比赛现场成本太高昂，租借笔记本可能都不是现实的）；原生APP不适合（原因：评委评分前需要下载APP，比赛结束后没什么用了，需要把这个APP卸载。而且IOS和安卓两大平台增加了研发成本）；轻应用有阻碍（原因：百度轻应用由于装机量小，覆盖人群不多。支付宝小程序没有社交关系链，无法有效的推送给需要的人。产业联盟轻应用，苹果用户怎么考虑？）
经过一系列的对比，很明显。对于【GS比赛计分】来讲，微信小程序是最好的应用平台。同时微信小程序仍然可以和不同的平台进行联系，所以可扩展性，功能延展性都是最佳的。
当确定小程序是最理想的应用平台时，我们需要对小程序进行便利化的设计。这就需要抛弃一部分原生应用开发或Web开发的一些设计理念。追求“极致、简约”的风格设计。
在【GS比赛计分】的详细设计时，我考虑到，以个人账户的形式去下发比赛的流程是行不通的，既然服务于比赛，那么就以比赛为最基本的账户组成单元，明确一个比赛ID。而同一个比赛的不同角色，以不同的IK进行区别，而角色的设置包含在比赛设计中，由比赛创建者在创建比赛时自行创建。
那么小程序的使用场景就出来了。以比赛现场的告知或者微信聊天的分享，告知比赛参与角色其ID和IK，就可以让角色快速的进入绑定角色并使用程序。免去注册的一系列烦恼。
同时在微信用户面前，这个账户体系是平权的，任何用户在得知ID和IK的情况下都可以进入（账户绑定情况下不可以进入），一定程度上免除密码和忘记密码，注销账户这一系列的麻烦。
当完成比赛后，程序已经完成了自己所有的任务时，使用者可以直接退出程序，不需要注销比赛等操作。真正做到即走。
在使用过程中，要清楚的考虑用户的使用过程，从而做一些保险机制。微信小程序运行在微信上，微信是社交工具，就免不了用户会退出小程序甚至微信去做一些其他的事情。所以【GS比赛计分】在设计时要保证用户回来要用到自己想要的，在程序设计中有中间状态界面能够保证用户可以迅速进入使用状态。
现在的【GS比赛计分】其实是一个大的生态系统，结合有线下的网络接口，展示接口，线上小程序，web平台。每一个部分都承载着自己独特的应用价值。
比如Web平台就承载比赛管理的任务，创建比赛，上传比赛文件，选手图片，设置选手（名称、介绍、手机号、图片、出场顺序），设置评分项（名称、权值、预置分数），设置评委（名称、权值，IK）。从实际的分析来看，比赛管理最适合在PC端进行，不管是文件还是图片，公认都是PC上传比较容易。
在最初设计的时候，我错误的把系统分成了多个小程序进行系统搭建，在实际使用过程中造成了重大的缺陷和用户流失。最大的表现是，我开发了【GS比赛创建】小程序，作为比赛的入口程序。从而造成比赛数量增速缓慢，大的使用场景无法突破，老用户意见上升等一系列问题。不得不注销了【GS比赛创建】小程序，并进行很大的架构调整。【GS比赛计分】暂停使用，造成大量的用户流失。
所以，当设计多场景，前后联动性很强的应用时，需要将功能进行使用划分，每一个划分需要找最适合的平台。最适合小程序的部分，就做好与其他平台的无缝结合。
目前来看，小程序的应用场景主要包括支付场景，比如扫码支付、快消餐饮、移动购物、交通出行等等，工具类小程序能更碎片化、垂直化地满足细分的应用场景需求。
根据微信的最近更新变化来看，公众号和小程序的协同作用将越发明显，公众号的作用也将进一步放大，因此未来发展的机会可能在这几方面。
内容营销，小程序能通过更完善更精准的服务进而提高用户黏性。具体来看包括各大知识付费的小程序以及在教育风口上的小程序。当然，这些小程序也可同时开发APP（按微信对小程序的开发步骤来看）从而实现用户沉淀。
具有支付场景的各类商家。包括传统的已有一定客户群的商家提供更方便的服务或者实现线上线下联动以及新零售。
工具类小程序。包括共享经济领域，这类小程序即用即走，轻量化，便捷化。
天生具有社交属性的小程序。比如抽奖、互赠礼品、拼团减价、社交性的小游戏以及帮拿快递等。
小程序服务质量 第3篇
小程序业务后台，包括小程序基础后台、编译后台、小程序包管理、开发者工具后台等；
小程序双线程模型
小程序双线程模型，现在大家都已经很熟悉了，小程序在当时是一种新的产品形态，在小程序技术方案设计时，有一个很重要的点，就是要求安全、可管控，为了是实现这个要求，设计了双线程模型，将小程序分成了渲染层和逻辑层，在这基础上衍生出了小程序特有的通信模型、生命周期、事件系统、渲染机制等核心机制，后来为了解决双线程模型的一些性能限制、丰富开发生态等，衍生出了组件系统和插件系统。同时还涉及小程序的WXML、WXSS语言、编译、小程序的包管理等部分。
因此这是一个复杂的业务系统。如何保障这样一个复杂系统的质量是一个复杂的挑战。
早期研发模式
在小程序发展早期，需求是用git issue管理，用milestone管理版本，当时的研发模式比较简单。到后期随着业务的发展，逐渐暴露出一些问题。
第一，是代码合入没有管控和检查，还有一些开发直接在发布用的分支上进行开发，容易出现代码漏合、夹带的问题；
第二，版本没有一个固定周期，经常出现测试过程中有新需求合入的情况，导致版本越积越大，整体测试时间拉长，质量很难保障；
第三个问题，灰度没有控制，直接按百分比灰度用户，并且灰度的速度也没有标准，容易出现灰度过快的情况，当我们感知到有会影响用户的问题时，影响的范围已经很大。
还有就是，前面有提到到，小程序除了基础库，还涉及客户端、开发者工具、核心后台等产品的联动，原先在版本发布过程中，主要是靠人工沟通来进行流程的扭转，成本高且容易出现失误。
研发模式优化
首先是将研发流程细化，增加新功能测试阶段，新功能需要测试完成之后，通过mr合入release分支，同时对新开发、底层机制改动等情况引入code review机制；另外就是引入了开发者灰度，我们认为开发者对自身的小程序的问题是比较敏感的，反馈问题的意愿也比较高，平常也会调试自己的小程序，会更容易发现基础库潜在的问题，并且开发者拥有过开发者社区作为渠道进行反馈，反馈会更加的及时和准确。
同时在整个流程的各阶段分别整合、使用Bg内外的一些平台和能力，研发阶段利用蓝盾流水线、aflow等提高效率，开始灰度后利用ifeedback、ilogs等系统提升问题发现的能力，达到提升整体质量效能的目的。
具体措施
自动化完善及测试效率提升
在自动化完善的过程中，我们遇到了一些痛点：原自动化框架对小程序的场景覆盖能力不足，自动化效率低，小程序场景复杂、需要回归的用例多等。
针对场景覆盖能力不足
我们基于小程序调试协议新建了一套小程序测试框架minium，这么做有以下好处：
针对执行时间长
对测试框架进行进行了wetest云真机的支持改造，在集成时可以多任务、多机器并行执行，提高执行效率。
针对小程序场景复杂，需回归用例多的特点
利用分而治之的思想，根据小程序的特点，将UI/接口/核心机制的用例进行分层设计和组织，同时对研发流程的不同阶段，拆分不同粒度的测试任务，使自动化可以在更早的研发阶段跑起来，更早的发现问题，降低问题修复成本，针对集成阶段，对渲染自动化、组件自动化等耗时更长的任务，分配更多的机器，达到缩短整体执行时间的效果。
自动化完善及效率优化效果
基础库用户体验保障
小程序的启动性能是影响用户体验的一项重要因素，为了优化启动性能，业务团队专门成立了一个专项组，在优化的过程中，我们遇到了启动性能获取不准确，常规性能测试工具无法分析性能瓶颈，发现了性能恶化，定位和验证困难等问题。
为了能够准确的获取到启动过程中各阶段的耗时，我们细化了启动过程，采取客户端+基础库协议上报的方式进行性能数据获取。
然后划分启动场景制定启动自动化用例，建立了一套机制自动拉取协议数据，并计算不同阶段耗时，对比各个阶段的历史执行数据，生成测试报告以及可视化启动时序图，可以详细分析每个流程中的所有耗时细节 ，用来发现性能瓶颈。当出现性能异常时，利用二分思想采取自动构建、编包的方式，辅助定位导致异常的提交。每季度进行基准小程序+多类目小程序的方式进行启动性能竞品对比，保证微信小程序的用户体验。
智能monkey效果优化
为了能够更多的覆盖线上场景，发现潜在问题，我们会对线上的小程序进行monkey探索，目标是可以覆盖尽可能多的页面，发现js error/黑白屏/crash等，小程序运行过程中的页面可能会出现多种元素类型包括原生元素、小程序元素、以及canvas组件等特殊组件，怎样获取有效的操作元素，是保障monkey效果的前提。
以小程序元素为例，通过自建测试框架注入js的方式，获取到整个页面的页面树，然后结合前端和小程序的特征，将无效元素过滤，最终得到页面中的有效操作元素。
采用这样的元素获取方案后，执行20分钟monkey平均页面覆盖率提高到了36%，对比全程使用目标检测的方式，提升了89%。可以较为有效的对线上的小程序进行探索覆盖，保障版本质量。
总结
介绍了优化小程序基础库的研发模式，完善自动化能力和执行效率的工作，通过分析业务特点和研发过程各阶段的核心诉求，参与研发全过程，运用测试左移、右移，分层测试、分而治之等测试思想，与业务紧密结合，解决业务问题，提升业务质量和效能。
通过上面的一系列措施，基础库每月需求吞吐量提升超过30%，影响用户的问题比例下降90%，在保障业务迭代速度的同时较好的保障了业务质量。
腾讯WeTest提供