之前有在板上分享我们每天上版、一些 deployment, release 流程介绍，
最近又写了一篇文章则来从 PM 做产品管理的角度分享，
该如何针对一个新功能、流程改动来做产品上线规划，
以及前篇文章提到的阶段性释出的工具、方法与工作细节。
文章内容包含：
- 什么是产品上线规划？从旧开发流程转变到新开发流程的原因？
- 分阶段释出：产品改动（Epic、Tickets、Feature Flags）
- 分阶段释出：产品受众（Dogfooding、Beta Testing、A/B Testing）
- 产品上线规划文件
- 目标导向＆假设驱动开发
有图有连结 medium 好读版：
http://a0.pise.pw/SN2GG
这篇文章的背景为，产品为已在目标市场中稳定发展的网络产品，产品改动都以提供新功能、优化使用者体验、解决现有使用者问题为主，工作方法以敏捷式开发为主。
虽然上篇文章分享了每天上版的流程，但平心而论，我并不认为追求“每天上版”是一个好的工作方法，我真正喜欢的是我们背后“分阶段释出”来降低风险与快速探索方向的核心概念，而每天上新版只是在当时有多个团队同时冲刺新功能造成的结果。
有些 PM 会调侃自己只是功能开发团队（Feature Team）、功能开发工厂（Feature Factory）的推手，而非在真正的产品团队（Product Team）创造价值。
如果你读过《精实创业 The Lean Startup》《使用者故事对照 User Story Mapping》《产品专案管理全书 INSPIRED》等书而且也熟悉实作的方法，这篇文章可能不会对你有太多帮助。
但如果你的团队跟我一样正在功能开发工厂的光谱上游移，希望这篇文章能提供你一些思考方向。（当然，上面那几本书也很建议去翻一翻。）
跟上一篇的状况一样，不论是跟台湾团队还是海外团队工作，我们在提到某些专有名词时都是用英文称呼，也因此讲话总是中英夹杂，文章中我会尝试翻译，但习惯上还是会用其原文单字表达！
▍什么是产品上线规划？
产品上线规划（Product Release Planning）顾名思义就是针对你负责的产品、单一功能、流程优化、问题解法从开发、测试到正式上线的规划。
刚开始做产品工作时，我们团队的工作流程非常线性、直觉：
研究：蒐集使用者回馈
开发：打造使用者想要的功能
上线：释出功能给使用者
上线后，专案正式结束，我们就会着手去处理下一个使用者遇到的问题、期待我们开发的功能。这些产品功能开发短则几周、长则几个月，所谓的上线规划几乎就等于功能开发时程表。
然而我们渐渐遇到了一些让团队不开心、使用者也不开心的状况，例如：
- 开发出来的新功能的使用频率很低，感觉像在做白工
- 开发出来的新功能没有满足使用者的需求与期待，甚至得到负面评价
- 为了做好功能，当 PM、QA 检查时遇到问题，总是在最后时刻更改或新增需求，导致开发跟测试一直来来回回，花非常多时间才完成
有鉴于此，我们着手改变工作方式，核心概念类似于精实创业（Lean Startup）的开发－评估－学习（Build-Measure-Learn）模式，将每个步骤切小、切碎，这种非单一线性的流程，可以让团队在每个阶段稍做评估与排序，若遇到问题则可以回到前面的阶段重新出发。这也就是大家很常说的叠代（iteration）。
https://imgur.com/hpMbaBM
这篇的产品上线规划指的就是上图中“分阶段释出与验证成果”这个步骤的执行方法，而其中又可以分为两个面向：产品改动（程式码）的分阶段释出、产品受众（使用者）的分阶段释出。
▍分阶段释出：产品改动
每个大问题、大功能都可以分为三个层次。最上层是 Initiative（计画），也就是最大的目标；第二层是 Epic（史诗故事），其下有多张 Tickets（票），每张 Tickets 的内容可能是底层架构或 API 的改动、可能是一个或数个使用者故事。
这边的名称都是取自专案管理工具 JIRA 的用法，官方定义可以参考《Epics, Stories, Themes, and Initiatives》。
请注意，在某些方法论、书中这些的定义可能会有些许不同。
举例来说，我们团队前阵子从 JIRA 换到了 GitHub 的专案管理工具，他将阶段性任务称为 Milestone（里程碑），下面可以包含多个 Issues、Pull Request，这个对应方式跟上面提到的 Epic、Tickets 的关系是很类似的。
分阶段开发 — Tickets vs Epic
分阶段释出产品改动，代表每一张 Ticket 都可以独立被部署上线、每一个 Epic 都是可以被验证的最小单位。
【Tickets】与其一次做完一整个功能，不如将它分为更细的改动来释出。这样做的优点是透过将每个部分的技术实作、Use Case Review、Code Review、测试范围缩小，来降低出错的机会，避免来来回回修改；另一方面也方便分工，让团队持续交付，能在短时间内透明化且直接的看见进度与产出。
【Epic】所谓可以被验证的最小单位，表示功能并不需要一次完全到位，而是先抓出最核心的使用者故事们，来验证需求是否真实存在、问题是否值得花资源处理、解法是否符合使用者期待、商业指标是否有相对应的提升等等，蒐集回馈后再来调整下一个阶段（Next Phase）要做的事情。
这个验证单位也有可能只是很小的改动，一张 Ticket 就可以完成；相反的，如果是非常明确的需求，那其版本可能就需要做到非常完整，举例来说若是电商系统要串接新的物流商，不可能只做到“出货、取货”功能而没有“退货”流程就上线。
在开始动用工程资源之前，也有许多的验证方法可以避免我们浪费工程资源走在歧途上。举例来说：假门测试（Fake Door Testing）、原型测试（Prototype Testing）等等，产品经理的其中一个重要工作就是辨认何时要使用何种工具，降低风险、提升效率，让团队一起朝对的方向前进。
不过就算上述这些“前期测试”的结果是正向的，也不代表我们已在康庄大道阳光前行，分阶段释出的方法还是很值得使用。
实作方法 — Feature Flags
我们是用 Feature Flags（功能开关、特性切换）来实作。每一个 Epic 会有一个独立的 Feature Flag，其下的每张 Tickets 都会被包在其中。我们可以为特定的使用者开关功能 —— 关闭状态时，前台使用旧程式码逻辑；开启状态时，前台使用新上线的程式码逻辑。
这种做法允许我们在不影响现有使用者体验的情况下，一张一张 Tickets 慢慢上线、测试，在正式环境优先开启功能给内部产品团队，直至 Epic 内的所有任务都完成开发、内部测试并上线后，再依据要验证的目标来决定分阶段释出的受众。
https://imgur.com/4tfUspY
左图：每一次部署的版本包含很多不同主题的 Tickets、右图：其中一个 Epic 与其包含的 Tickets。
左图为每一次部署所包含的 Tickets，包含修 Bug、设计改动、小功能等等，同时也会有已经被切分开来的各种 Epic 的部分任务，也就是上篇文章提到的上线管理的范畴。其中，小改动们原则上不需要上线规划，就是修好、测试完、上线没问题就行了，再后面就是跟内部团队的告知与沟通。
右图则是一个 Epic 与其包含的各种任务，对于大型功能来说，任务的切法其实很仰赖工程师的帮忙，可能会从前后端、页面、使用者故事 … 等不同角度来切；如果我们要验证的项目很简单，也有可能一张 Ticket 就完成改动。
从上图案例可以发现，我们必须每天上版的原因就是因为同时有多个产品团队在共同打造产品，每个团队每天、周或多或少都会上一些东西。如果你的产品使用 Microservices（微服务）的架构，事情也许会简单一些。
▍分阶段释出：产品受众
预期的改动都被部署到正式环境后，并不会直接呈现在使用者面前，而是由 PM 来决定如何分阶段释出 — — 先释出给哪些目标使用者、每个阶段释出的时间间隔、什么情况下继续释出或喊停。
这边分享一些在不同阶段可以使用的工具与测试对象。每个工具的成功/失败验证指标、开放使用者人数（比例）、所需经历的时间因情况而异，这边就不详述。
1. 内部团队 — Dogfooding、Alpha Testing
【主要目标】基本品质管理。
【实作内容】在正式环境抓 bug、确认基本使用情境下正常运作。
【适用时机】任何情况。
这个阶段为内部测试，我们通常 Epic 上完就会先开放给公司的人试用，一方面让大家一起在正式环境抓 bug、另一方面也是让团队知道这个功能已经阶段性准备好，我们即将开始释出给真实使用者测试了。
2. 特定使用者 — Beta Release
【主要目标】透过实际产品互动再次探索使用者问题与需求，确认解法方向是否正确，并提前辨认完整上线时可能会遇到的风险。
【实作内容】了解目标客群对功能的回馈（质化）、观察功能的使用频率与指标变化（量化）。
【适用时机】全新功能上线、现有功能/接口/流程改版。
优先释出功能给一群被挑选的、特定的、可控的使用者试用，从他们身上蒐集回馈、小范围观察数据变化，若反应都是正向的则可考虑整体上线、或是进行下一阶段测试。
反应是负面的常见状况如下：
小部分释出后发现根本没人使用，表示这个功能、解法不一定值得花时间继续投资；
重要指标下降，要深入研究原因再决定是否值得继续释出
对于 Phase 1 需要包含的内容判断错误，使用者表示确实有这个问题、解法有解决问题，但现在版本所功能包含的内容太少所以他还不想用、无法给予好不好用的想法（这样通常就是不好用吧），因此可能要将 Phase 2 的内容包含进来，再重新进行分阶段释出与测试。
https://imgur.com/hpMbaBM
回到最上面的流程图，将每个步骤切小、将一个大个任务切成很多小任务就能够依照回馈的状况，决定是否要回到前面研究的步骤重新探索一次、或是回到打造功能的阶段做调整。
3. 随机使用者 — A/B Testing
【主要目标】比较旧版本与新版本的指标差异，确认新版本是否有显著达成目标。
【实作内容】将 A/B 版本分别释出，观察重要指标的变动状况（量化）。
【适用时机】与现有指标相关的改动上线、现有功能/接口/流程改版。
A/B Testing 的方法则是一种随机测试的产品实验方式，将两个（或多个）版本丢给随机的使用者，透过系统化变因控制与差异计算，来验证假设并判断哪个版本比较好。
通常这两个版本分别为现有的旧版本（对照组）、开发后的新版本（实验组），若反应正向就可以考虑整体上线，若反应负面则通常不会上新版本。
▍产品上线规划文件
上面谈了工作方法与流程，而实际的文件通常包含这些项目：
1. 基本资料：名称、目标、背景与功能简介、上线内容、正式环境测试连结
2. 上线规划内容：验证项目、成功/失败指标、目前所在阶段、整体上线规划与时程
整体上线规划与时程包含每个阶段的释出时间（时间间隔）、目标使用者（开放人数、开放对象）。例如：
07/01 - 内部测试
07/08 - 第一批 Beta Testing （名单连结）
07/15 - Bug 修复、产品调整
07/22 - 第二批 Beta Testing（名单连结）
07/29 - 确认全体上线与否、全体上线时间
每开放完一个阶段，蒐集到数字或回馈后，可以适时更新最新状况；若整个专案要喊停、确认不继续进行，也要告知团队原因，以及下一个 Phase 要做的事。
这边虽然称为“文件”但他不一定是个独立出来的档案，它可以只是一条发给团队的沟通内容，例如：
- 专门发布上线规划的 Slack channel
- 内部团队使用的 dashboard 与公告栏
- 内部团队共同维护的上线规划表单
https://imgur.com/f5MhJux
当然，我自己在写产品需求文件（PRD）的时候，里面本身就会包含上线规划的内容。上面提炼出的这个精简版本主要为了跟团队沟通使用。
▍目标导向＆假设驱动开发
所有的“上线规划”都应该在上线前完成，更准确的说，是在前期产品探索至一阶段，开始撰写产品需求文件时就应该一并考虑进去。
在订定产品目标的同时就开始规划你的产品上线策略 — — 如何验证假设、如何挑选受众，而不是等到产品改动都准备要上线了才开始思考。
假设驱动开发（Hypothesis-Driven Development, HDD）是一种用验证假设为核心概念的开发方法，将目标拆解成多个问题、每个问题又有多个解法，而每个问题、解法其实都是未知的假设，我们要做的就是想办法用有效率的方式去验证这些假设，一边开发、一边学习，淘汰掉错误的假设与不可行的解法，不断调整产品设计方向，尝试在浪费最少资源的情况下，为公司或使用者带来最大的价值。
https://imgur.com/CiEKDxZ
既然是假设，就代表我们其实不知道他对不对，随时都处在“测试阶段”“实验阶段”中。 实务上，我们透过这样的方法降低长远资源的浪费与潜在风险；心态上，我们不断在从市场与使用者身上学习与获取回馈，而这个学习循环周期的时间历时愈短愈好，代表团队可以更有效率的调整方向。
而在这样的工作方法中，很难在这个“上线规划”中交代一个明确的“功能上线时间”。
如果测试结果很失败，决定东西不上了，要回到前面的使用者研究阶段、解法设计阶段找其他机会点来优化；也有可能实验结果不上不下，因此决定针对 Beta 功能做一些挑整后、持续测试，直到我们有足够信心后再开放给全体使用者。
我相信“不确定的上线时间”让业务、行销、客服常常很头痛，我们在跟他们沟通时通常都是用“季”为单位在讨论，也就是“2020 Q3 我们预计会出‘跟优化购物车转换率相关的功能’，而这个专案预计会朝 XXX、YYY、ZZZ 这几个方向尝试”这样模糊的说法。
但相对的，我们有“可控制的发布时间”，不受限于部署当下遇到的问题，而且发布的版本是内部团队与部分使用者已经在正式环境看过、用过、验证过的，同时，我们可以从“达成目标”的角度、而非“开发功能”的角度来思考要做什么，这才是最重要的对吧！
▍结语
这篇文章大致上说明了如何从源头规划产品上线，Release、Phased/Staged Rollout、Full Rollout 中间的流程与决策点，以及这种工作方法背后的理由。
讲起来很简单，做起来真的很不容易，文内说明得好像是我们一开始就知道该怎么做、各种专有名词与方法论信手拈来，但实际情况是我们不断修正做事方法，参考网络文章、工具书、其他产品团队的实务经验，并且仰赖 DevOps 团队的努力，最后从一些社群推崇的方法论中尝试调整成当下适合自己产品、团队的工作流程。
值得一提的是，公司内不同的产品团队做事方法依然不尽相同，保持适度的弹性也是很重要的。有时候难以避免地，有些东西就是非开发不可嘛～～～为了投资人、为了老板、为了跟竞争对手抢市场、为了跟上时下最夯的话题，或是做给内部团队使用的工具，可能就不会用这样的流程工作囉
下一篇文章，我会再分享 Beta Release、Feature Flags 的实务经验。