产品开发生命周期——从想法到交付的产品
产品开发生命周期，在一张交互式画布上讲清楚：探索、定义、设计、构建、测试与上线——还有验证关卡，以及把结果送回下一轮的闭环。
产品开发生命周期是一件产品从想法走到客户手里所经过的顺序：探索问题、定义范围、设计方案、构建并测试、发布，然后度量并重新开始。
产品开发生命周期——从想法到交付的产品
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- 顺着箭头从左往右走完六个阶段；流向会在泳道之间移动，因为每个阶段归属于不同的职能。
- 唯一的决策“已用真实用户验证？”就是那道关卡，它挡住没验证过的工作进入构建——它的“否”分支指向后方。
- 最后一个方框在概念上合上了这个环：生命周期会重复，这张画布的结束也就是下一轮的开始。
决定要造什么
“探索问题与市场”在“产品”泳道里开场，“定义产品愿景与范围”则钉死什么算成功、什么不在范围内。“设计方案与体验”把工作交到“设计”泳道。接着，验证关卡——“已用真实用户验证？”——在工程投入任何成本之前，先拿设计去面对真实用户，把不通过的情况送回定义那一步，而不是放它继续往构建走。
构建与测试
“工程团队构建功能”是设计变成代码的地方，“QA 测试并修复缺陷”是任何东西被称作完成之前的质量关卡。这两个方框都在“工程”泳道里，因为它们是同一个职能的责任；图解把它们放在相邻位置，好让构建与测试这个循环读起来像一个整体。
交付与学习
“上市推广团队筹备发布”与 QA 并行推进——市场和赋能的工作不会等到代码变绿才开始。“交付给客户”是发布本身，而“度量使用情况并规划下一轮”是这个环的铰链：发布产出的数据，决定了下一个探索阶段。“产品”泳道同时承载了第一个和最后一个方框，正是为了把这份归属写明白。
Key relationships and takeaways
- 生命周期是一个环，不是一条线——发布得到的数据会成为下一轮探索的输入。
- 验证关卡的意义是让失败变得便宜：没验证的想法应当在设计阶段被拦下，而不是在构建之后。
- 每个阶段归属于一个职能，流向也就像真实的交接那样在泳道之间来回。
- 上市推广与构建、测试并行，而不是排在它们后面。
- 产品负责人握着两头——发现问题，以及度量结果。
When to use this visual
- 让新加入的团队快速看清自己的工作落在产品周期的哪一段，以及谁交接给谁。
- 规划一个功能：把各阶段走一遍，看清哪一段缺失、又该先验证什么。
- 审视一个团队的流程——一条没有验证关卡的生命周期，解释了构建为什么老是出错。
运作方式
把阶段改成你的流程
把这六列换成你实际的阶段——你可能有一个 beta 阶段或一段销售周期，是这套通用阶段没有画出来的。
加上你真实的关卡
把流程里真实存在的审批和检查点插进来——设计评审、安全评审、发布签署——每一个都做成带明确出口的决策。
画出并行的工作
如果你的团队是这么运作的，就加一条市场或赋能泳道，让它自己的方框与构建并排推进，并在发布处汇合。
把指标标注出来
在最后一个方框上注明你发布之后真正度量的指标，以及它们如何进入下一轮探索，让这个环变得具体。
常见问题
什么是产品开发生命周期？
它是一件产品或一个功能从最初的想法走到客户手里所经历的一连串阶段：探索问题、定义范围、设计方案、构建并测试、发布，然后度量并迭代。不同组织给这些阶段起的名字不一样，但它的形状——决定、构建、交付、学习——几乎在所有组织里都相同。
为什么在构建之前需要一道验证关卡？
因为产品开发里最昂贵的错误，是把错的东西造得很好。验证关卡——在工程投入之前拿设计去面对真实用户——能在代价还低的时候抓住这个错误。图解里的“已用真实用户验证？”这个决策把它变成了硬规则：没验证的工作会绕回定义阶段，而不是进入构建。
生命周期的每个阶段归谁负责？
阶段归属于职能，而不是归属于流程本身：产品做探索和定义，设计打造体验，工程负责构建与测试，上市推广负责发布。产品负责人通常握着两头——定义问题，以及度量结果——这也是图解把第一个和最后一个方框都放进“产品”泳道的原因。
生命周期是线性流程还是一个环？
它是一个被画成直线的环。图解结束在“度量使用情况并规划下一轮”，因为一次发布产出的数据会进入下一个探索阶段。把生命周期理解成发布即结束，正是团队反复造出同一个错东西的原因——这个环才是重点。
在 QueryChart（FlowJam）中编辑这张图解
把上面这张生命周期画布原样打开成你自己的图表，把阶段改成你的流程，再加上你真实的关卡。