之前有在板上分享上分享过每天上版的部署流程、单一功能释出从功能拆解到分阶段释出的概念，这篇文章则会着重分享之前文中提到的 Beta Release、Feature Flags 的使用方法。
主要也是写给 PM 看的，文章内容包含：
- 适用 Feature Flags 的时机
- Beta Release 的流程规划
- Beta Release 的受众选择、移除功能的做法、测后访谈方向
- 实作 Feature Flags 的工具分享
- 上线规划如何与其他产品研究方法互补
- 结语＆推荐书单
有图有排版有延伸阅读连结 medium 好读版：
http://a0.pise.pw/SRFCZ
这篇文章的背景为，产品为已在目标市场中稳定发展的网络产品，产品改动都以提供新功能、优化使用者体验、解决现有使用者问题为主，工作方法以敏捷式开发为主。
▍适用 Feature Flags 的时机
Feature Flags（功能开关、特性切换）是一种软件开发技术，概念上就是正式环境中有多个程式码分支，某些特定功能只会出现在特定分支上，拥有最高权限者可以自由地切换新版本给特定使用者，例如：QA、内部团队、小批量的真实试用者等等，而让其他使用者默认使用原始的版本。
这种做法允许我们在不影响现有使用者体验的情况下，一张一张 Tickets 慢慢上线、测试，在正式环境优先开启功能给内部产品团队，直至 Epic 内的所有任务都完成开发、内部测试并上线后，再依据要验证的目标来决定分阶段释出的受众。
根据上篇提到分阶段释出与验证的流程中，适用 Feature Flags 的时机包含：
1. 我们确定这功能要做、且规划完整，或是现有功能的大改版，但功能整包太大，怕一次大上线会出错（着重在程式码的分阶段上线与测试）
2. 我们确定这个功能要上线，它已经经过测试且各方面回馈都很正向，但是因为改动很大，我们想要让使用者主动切换并慢慢适应，最终目标是让所有人切换使用新版本（着重在受众的分阶段上线）
3. 我们不确定这功能值不值得持续花资源做、解法方向对不对、使用者体验好不好、数据会不会改善（着重在受众的分阶段测试）
第一点很直觉，重点就是 Epic 下各个 Tickets 要怎么拆解、技术实作、测试。跟第三方服务串接的时候也很好用，可以先开给合作厂商一起做测试。
第二点常见于一些大型软件改版，例如 iOS 版本升级，使用者要主动选择升级后才能开始使用新版本。有些产品团队的作法则是先强制开启新功能给所有使用者，但允许使用者手动切换回旧功能，例如 JIRA 某次更新版本后，论坛中开始出现各种询问如何关掉新功能的文章。
让使用者主动更新与切换至新版本的 Feature Flags 作法很常出现在 B2B 产品中，因为一个产品会有非常多不同类型的使用者，企业端通常会希望做好新版本的内部教育训练后再来进行。
第三点则可以透过先将功能推给小部分使用者试用，再慢慢扩大范围，最终释出给所有人；若中间任一步骤发现苗头不对，就暂停释出，根据得到的回馈来修正产品。
这种分阶段释出的做法在中国有一个很传神的名字叫做灰度发布，亦即有个版本是黑、有个版本是白，我们的产品状态就在这之间的灰度游移。欧美的命名则是用了一个我比较难理解的名称金丝雀发布（Canary Release），听说是以前矿工开矿要放人下去前，会先放一只金丝雀进去看看是否有有毒气体，如果金丝雀活下来了，人类矿工才会下去工作。
常见的 A/B Testing 就是这其中一种方法，而我这篇要来分享的是以质化使用者研究与解法验证为主要目的的 Beta Release、Beta Testing 的方法。
▍Beta Release 的流程规划
https://imgur.com/a/C8AXoBW
这里的目标跟假设，可以是针对使用者提出的需求、我们定义的问题、或是实际解法的假设，而对应到这个假设，就需要有一系列的验证标准，可以是比较模糊的质化目标，也可以是非常明确的量化指标。
量化指标的比较又可以分为同时有对照组与实验组的“同期比较”，以及同一批使用者在改动前、改动后的“前后比较”。
关于如何设定一个好的目标、合理的指标成长数字，可以参考 Nana Chiang《给产品经理和分析师：如何用指标框架计算产品改动影响力（Impact Sizing）？》中的手把手计算教学与思考框架。
由上图可知我们通常都会进行多批（Batch）的阶段性释出（Phased/Staged Rollout），每个阶段的目的可能相同、也可能不同，并根据每个阶段的结果来决定是否要继续走下去。
举例来说，第一批锁定“该功能重度使用者”来验证功能本身适不适用、使用频率正不正常，并且会认真的做质化访谈；修改或调整过后，第二批开放给更多潜在重度使用者，远端观察数据、使用行为，事情况做质化访谈，同时确认第一批使用者遇到的问题都已经被解决了；第三批则随机挑选非重度使用者、新使用者来测试，看看是否会有负面影响。当然，也可以反过来操作。
▍Beta Release 的受众选择
如果目的是提升整体的指标，从整体使用者中去做随机分配来做测试就很重要，A/B Testing 会是较好的做法；但如果流量过小（样本数过小）或是目的是服务特定对象的使用者，就可以试着挑选出特定型态的使用者来测试、同时确认不会伤害到其他型态使用者的体验与指标。
在 Nana Chiang 分享的《如何在低流量产品中做实验，做出有品质的产品决策？》中有提到“证据金字塔”的概念，不同形式的证据是不同强弱程度的证明，从高到低代表证据的强到低。样本数愈多，证据就愈强。
而“群组研究”的研究方法特别适合运用在使用者付费的 SaaS 产品、B2B 产品的场景中。这边的“群组”可以用使用者样貌（行销角度）、参与度高低等方法来分类，以下也分享一些挑选测试受众时可以切入的其他方向。
1. 友好测试名单
在 B2B 产品中，客户花钱使用产品，通常会非常愿意提供想法。我们曾经有一份约 30 名客户的“友好测试名单”，包含常抱怨的、常提建议的、我们访谈过的客户。他们已经习惯我们的产品开发流程，也了解这只是最阳春的测试版本，因此对对于新功能的试用有正确的期待。
我们第一批测试受众通常就会优先从这个名单中去找寻适合的测试对象，蒐集回馈的当下，也可以避免跟不熟的客户打交道造成的品牌公关危机。
而 B2C 产品中可以让使用者主动注册成为“优先试用”的前导受测者（Pilot Testers），也可以称他们为早期采用者（Early Adopters）。对他们来说不但可以第一时间得知产品的最新功能，自己提供给产品团队的建议也有机会被采纳，这个群体经营得好的话会是一群很棒的死忠粉丝！
2. 曾经提过需求者
在访谈过需求者，定义完问题后，很多时候我们无法确认我们的解法是否有正中要害，也有很多时候老板觉得 A 解法比较好、我觉得 B 解法才合理、设计师却对 C 解法更有信心。
提出需求的使用者有时候也不知道他们真正需要什么（反正跟你们提提看不花他多少时间），但他们的确是有遇到问题、拥有痛点的使用者，因此先用这种 soft launch 测试的方式来跟曾经提过需求者试探水温能够帮助我们后续的决策。
根据想测试的内容不同，大致可以分为两种做法：
- 第一种是主动告知我们有新功能，包含寄发讯息、或是在接口上明示，询问、观察他是否会想要试用、使用情况，同时蒐集回馈与建议；
- 第二种是不主动告知我们有新功能，设定一段观察时间，观察使用者会不会察觉到新功能并主动使用、功能使用频率是否符合预期，最后再来蒐集回馈。
3. 假设下的需求者
我们在设计产品时列出的假设，通常也会包含实际有提过需求的那群使用者所提到的使用情境，因此这边可以开放给更多虽然没主动提过、但我们认为会有类似需求与使用情境的使用者来试用。
4. 不能只照顾抱怨者！！！
我早期在设计产品做过一件超雷的事。
当时 A 功能是使用 A1 逻辑，有许多使用者抱怨 A1 逻辑不合理，应该要使用 A2 逻辑才对，因此崇尚“以使用者为中心”的听话产品经理如我就毫不犹豫地改了逻辑并一次上线给全部使用者。
没想到我们有一群默不吭声、且一直觉得 A 功能用 A1 逻辑非常棒的使用者，我们改成了 A2 逻辑后，瞬间被原先满意的使用者骂到臭头。而有些人则是用我们没想过的用途在使用 A 功能，这也是我们没有考虑到的。
所以在前期使用者研究阶段，除了关注大声抱怨者之外，也要关注一般人，把使用情境想透彻。而在上线之前，除了让提出需求者测试，也一定要事先开放给未提出需求者、一般人使用，全面性的考虑并确认不会造成负面影响，在风险低、信心足的情况下再释出给所有人。
【补充】移除功能、淘汰功能
另一种比较特别的使用情境是“移除现有功能”以及“淘汰现有功能、更新为新版”的流程，也很适合使用 Feature Flags 来实作。
相较于上线新功能，移除现有功能更容易造成使用者反弹。B2B 产品尤其严重。
最常见的处理方式是将用户分群，“新注册用户”一律使用新版本、“现有用户、但没在用该功能者”强制切换至新版本并发送简单通知、“现有用户、有在用该功能者”则分批次分阶段通知客户、细心处理资料移动（migration），并预留一段较长的时间慢慢让所有人有心理准备并顺利转换，这段时间也要把想要备份资料的、吵着要换平台的客户都安顿好。
▍Beta Release 的使用者分类与测后访谈方向
无论是上述哪一种类型的 Beta 使用者，在测试后期大致可以分为三种类型。这三者的回馈都需要蒐集，并且观察比例，了解最大的问题到底出在哪个环节、有什么有价值的切入点可以推进产品。
1. 有开始试用、且有持续使用新功能（Active Users）
- 为什么使用此功能、使用情境为何、带来的价值如何？
- 这个功能或解法还有什么优化的空间？（次要问题）
2. 有开始试用、但没持续使用（Abandoners）
- 既然有起心动念试用，为何最后没继续使用？不满处为何？
- 是否有与此功能相关的问题或痛点？若有，目前如何解决？
3. 根本没发现有新功能、有发现但没开始试用（Non-starters）
- 是否有发现平台上有新功能？（适用于我们没有主动告知的情境）
- 若有，为什么没有开始试用新功能？
- 是否有与此功能相关的问题或痛点？若有，目前如何解决？
▍实作 Feature Flags 的工具分享
Feature Flags 可以由内部技术团队自行实作，或是付费找外部的 SaaS 工具协助。
技术团队自行实作可以参考 Etsy — Feature API、Reddit’s feature flagging API等团队的文件，包含全开、全关、开给特定使用者、开给一定比例使用者、A/B Testing 等等不同类型的释出条件。也可以参考这篇长文《Feature Toggles (aka Feature Flags) — Pete Hodgson》的内容。
至于如何找特定受众呢？如果是技术团队自行实作的话，可以使用一些追踪工具来调出特定使用者行为或分类下的使用者 ID，或是透过客户管理工具（CRM）、客户沟通与回馈蒐集工具（例如 Intercom、Zendesk、Canny、Kustomer）来捞出曾经提出特定回馈或需求的客户名单，再利用上述的 Feature Flags 实作方式开启给这些名单来抢先试用。
外部工具的部分，做产品优化与测试的工具中 Optimizely 算是满广为人知的一个平台，产品功能很全面但价位也较高；LaunchDarkly 也是一个专注在上线管理与功能管理的产品，另外也可以参考 APPTIMIZE、Rollout、Centercode 等等。
如果想要了解 Feature Flags 可以在哪些情境下使用，我很推荐看看上述这些工具的部落格（例如这篇），里面除了概念性、功能说明的文章外，也会有些实际案例可以参考。
而最后当某个版本已经释出给所有使用者后，表示 Feature Flags 的阶段性任务完成，必须将它拔掉（或说退休），让正式环境未来都直接使用新版本的程式码，否则长久下来会累积许多切换负债，这也是技术债的一种。
我知道有些团队会将 Feature Flags 当成一个永久的功能给内部团队使用，例如让业务团队可以特别开启某些进阶功能给 Key Accounts 使用，若是这样则需要建立明确的权限管理守则。
▍上线规划如何与其他产品研究方法互补？
Beta Release 就是社会的缩影。它是使用者研究的一环，可以补足其他使用者研究没办法探索到的问题。
前期使用者访谈，我的访谈技巧可能也没有好到覆蓋所有可能的探索方向，有时候是使用者在启发与引导我们做产品、有时候是我们在启发使用者的想法、激荡出新的使用情境；制作 prototype 的阶段，使用者看上去满意，礼貌性比个赞，甚至提出更多进阶功能想法，但这一切有时候也不是真实的。
有时候验证东西就是要花时间。经过一段时间的试玩，使用者才知道他喜不喜欢、上不上手；又或者，使用者自己一个人在电脑前尝试时，刚开始用两下便觉得太复杂或没兴致，因此只试用了一次就晾在旁边放弃；更甚者，这个功能从摆在架上的最一开始就无法吸引他的注意力，当然也就无法驱使他开始使用。这些有时候是单纯访谈、测试 prototype 中很难得到的资讯，还是得实际试车才能见真章。
数据相对的不会骗人，而在得到一翻两瞪眼的验证数据后，能够抓出这些我们最初的“错误假设”，再次透过质化研究来了解背后的原因、蒐集资讯、调整命题，才能有信心地推出调整过、优化过的产品。
有趣的是，有时候客户抱怨连连、回馈一堆、激动不已，但是口嫌体正直、嫌货才是买货人，数据反映出来的却是新功能的使用频率高，这可能代表我们其实已经走在对的道路上，只是还有很多可以改进的地方。产品释出之后所做的改善才是最有价值的。
▍结语＆推荐书单
这几篇文章分享的心态与做法都是一种以顾客为中心的开发方法（Customer Development），而工具真的有千千百百种，我也还在努力理解各种方法论、学习什么时机点应该用什么工具来抽丝剥茧、拨云见日，希望这一系列的上线管理与上线规划的分享对各位有帮助。
常见的产品开发方法论通常都是双钻石（Double Diamond），而最近 Zendesk 提出了三钻石（Triple Diamond）的流程，不知道大家觉得如何？（Ref: The Zendesk Triple Diamond）
产品方法论推荐书籍：
《精实创业 The Lean Startup》
《使用者故事对照 User Story Mapping》
《产品专案管理全书 INSPIRED》（作者来台演讲内容繁中笔记）
数据、实验、假设推荐书籍：
《精实数据分析 Lean Analytics》
《善用数据帮你打造好设计 Designing with Data》

7ㄟ ㄅ推推