TEAM LEARNING / VALUE STREAMPROJECT → PRODUCT
Mik Kersten · Flow Framework

从项目到产品

数字化时代，如何从临时项目、职能交接和资源利用率，转向长期产品价值流、稳定团队与端到端业务结果。

团队授课材料·价值流组织与产品运营模式
STOP STARTING.
START FINISHING.
cizen.net · OPEN LEARNING
AGENDA共同语言

今天，我们要回答六个问题

01

为什么项目制会失效？

项目完成，不等于客户价值实现。

02

什么是产品价值流？

从客户需求到业务结果的长期闭环。

03

价值流里流动什么？

Feature、Defect、Risk、Debt。

04

如何衡量流动？

速度、时间、效率、负载与分布。

05

组织怎么随之改变？

团队、架构与业务结构必须对齐。

06

我们如何开始试点？

先跑通一条价值流，再逐步扩展。

方向：从“管项目”转向“管价值流”
WHY PROJECTS FAIL临时结构 vs 长期价值

项目可以结束，客户价值流不会结束

项目的默认假设

  • 有明确起止时间
  • 范围可以提前确定
  • 人员临时组建
  • 按时间、预算、范围验收
  • 交付后移交、结项、解散

数字产品的真实世界

  • 客户需求持续变化
  • 功能要不断演进
  • 缺陷与风险持续出现
  • 架构和技术债必须治理
  • 运营数据不断触发新决策
真正的问题不是“项目有没有按时完成”，而是“客户是否持续获得价值，组织是否拥有持续交付能力”。
项目是临时容器；产品是长期责任
SEE THE FLOW工作很忙 ≠ 价值在流动

从需求到客户，等待往往比工作更久

业务机会客户问题 / 战略目标
立项排期审批 / 争资源
产品分析需求 / 方案
技术开发设计 / 实现
测试验收修复 / 等反馈
发布运营上线 / 推广
客户结果采用 / 收益
真实工作时间排队、交接、审批、阻塞、返工

价值流管理先问：工作在系统里停在哪里？而不是先问：谁还不够忙？

优化系统，不是催促个人
OPERATING MODEL SHIFT管理对象改变

不是改一个名字，而是改变整套管理系统

管理维度
项目思维
产品 / 价值流思维
组织对象
临时项目
长期产品价值流
团队
临时借调、完成后解散
稳定、跨职能、端到端
资金
按项目立项和预算
按价值流持续投资、动态调整
成功标准
时间、预算、范围
客户价值、业务结果、流动能力
管理重点
资源利用率和任务完成
减少等待、WIP和交付周期
终点
验收、移交、结项
持续运营、学习、演进
产品模式 = 长期责任 + 持续反馈 + 动态投资
FLOW FRAMEWORK共同语言

让业务与技术看见同一条价值流

业务黑箱

  • 战略与投资
  • 客户与市场
  • 收入与成本
  • 经营目标
  • 优先级决策
↔

技术黑箱

  • 需求与开发
  • 测试与发布
  • 缺陷与风险
  • 架构与技术债
  • 工具与交付过程
Flow Framework 用“工作类型 + 流动指标 + 业务结果”，把技术活动翻译成业务可以理解和决策的语言。
业务不只看结果；技术不只看产出
WHAT FLOWS?4 FLOW ITEMS

价值流里不只有 Feature

01 / VALUE

Feature

向客户或业务交付新的、可感知的产品价值。

例：自动补货建议、商品机会评分、新履约方式。
02 / QUALITY

Defect

修复影响客户体验、稳定性或产品质量的问题。

例：计算错误、数据延迟、页面故障、线上事故。
03 / PROTECTION

Risk

处理安全、隐私、合规、治理与业务连续性风险。

例：权限、隐私、平台合规、安全漏洞。
04 / FUTURE FLOW

Debt

偿还阻碍未来交付的技术债、架构债和流程债。

例：模块重构、平台化、接口化、自动化测试。
Feature创造新价值；其余三类保护已有价值与未来能力
FLOW DISTRIBUTION投资组合的真实镜子

我们把能力花在哪里，决定产品会走向哪里

Feature

新价值与增长

Defect

质量恢复与客户信任

Risk

安全、合规与风险保护

Debt

未来速度与可持续能力

→

不存在固定的“最佳比例”

  • 探索期：Feature可能更高
  • 质量危机：Defect必须上升
  • 合规窗口：Risk成为优先
  • 架构制约：Debt需要保护投入
  • 比例必须与产品阶段和业务结果联动
只做 Feature，会制造短期繁荣和长期失速；只做基础建设，也会失去客户价值。
Flow Distribution = 看得见的能力配置
HOW DOES IT FLOW?5 FLOW METRICS

从“大家很忙”转向“价值流得怎么样”

VELOCITY

流量

一定周期内完成多少 Flow Item。

完成速率如何？
TIME

流动时间

从进入价值流，到客户真正获得价值的总时间。

客户要等多久？
EFFICIENCY

流动效率

活跃工作时间占总流动时间的比例。

时间花在工作还是等待？
LOAD

流动负载

当前同时进行中的工作数量，即价值流层面的 WIP。

是否启动得太多？
DISTRIBUTION

流动分布

Feature、Defect、Risk、Debt 的能力投入比例。

能力花在哪里？
Flow Metrics 用来诊断系统，不用来评价个人
FLOW → OUTCOME不能为了流动而流动

流动改善，必须连接业务结果

流动指标

  • Flow Velocity
  • Flow Time
  • Flow Efficiency
  • Flow Load
  • Flow Distribution
→

Value

收入、续费、转化、采用率、持续出单。

Cost

单位交付成本、运营成本、获客成本。

Quality

缺陷率、退货率、事故、投诉、返工。

Happiness

客户满意、员工体验、团队健康、流失率。

Velocity 上升，但价值、质量或幸福感下降，不是真正的成功。
Output不是Outcome；流动不是目的，价值才是
ALIGN THE SYSTEM业务 × 技术 × 组织

三种结构不对齐，Feature 就会跨部门排队

业务结构

客户、产品、收入、成本、经营目标和战略投资。

错位表现：优先级争夺，目标无法落到工作。

技术架构

系统、模块、平台、接口、数据与技术约束。

错位表现：一个需求跨多个系统和组件排队。

组织结构

团队边界、职责、决策权、治理与协作方式。

错位表现：对结果负责，却没有端到端能力。
组织不应围绕技术组件或职能方便来设计，而应尽量围绕客户价值流来设计。
康威定律：沟通结构会塑造系统结构
TEAM DESIGN价值流组织映射

谁对结果负责，谁提供复用能力？

GST

价值流对齐的长期增长团队

  • 明确客户与业务价值
  • 稳定跨职能成员
  • 对北极星指标负责
  • 管理四类 Flow Item
  • 具备端到端交付与运营能力

PST

平台 / 赋能型支撑团队

  • 沉淀共性能力
  • 减少重复建设
  • 提供标准服务
  • 帮助GST提升能力
风险：变成被动接单和排队中心

技术中心

技术基座与复杂能力

  • 平台化
  • 服务化
  • 接口化
  • 数据化
  • MCP化
目标：降低依赖成本，而不是增加审批
GST管结果；PST管复用；技术中心管基座
START SMALL一条价值流，六步试点

不要一次性重构全公司，先跑通一条价值流

01

定义产品价值流

客户、价值、起点、终点和长期产品是什么？

02

建立稳定团队

明确GST、PST、技术中心的成员、权限与边界。

03

统一四类工作

在同一价值流中识别Feature、Defect、Risk、Debt。

04

采集流动基线

先记录Flow Time、Flow Load、Flow Distribution。

05

连接业务结果

选少量Value、Cost、Quality、Happiness指标。

06

周期复盘调整

看瓶颈、WIP、工作分布和投资是否需要变化。

先证明一种新运行方式可行，再规模化
TEAM DISCUSSION把概念连接到当前项目

请团队一起回答

Q1

我们的“产品价值流”服务谁？起点和终点在哪里？

Q2

一个Feature从提出到客户使用，最长的等待在哪里？

Q3

GST是否拥有对结果负责所需的资源与决策权？

Q4

PST与技术中心在减少依赖，还是制造新的排队？

Q5

我们当前的Feature、Defect、Risk、Debt投入是否失衡？

Q6

哪一条价值流最适合用90天做最小试点？

概念只有进入真实问题，才会变成组织能力
TAKEAWAYPROJECT → PRODUCT

从项目到产品，本质是从交付任务转向持续创造价值

01 / 管理对象围绕长期产品价值流，而不是临时项目。
02 / 管理系统度量端到端流动，而不是局部忙碌。
03 / 管理结果连接客户和业务结果，而不是只看产出。
© cizen.net · 团队学习材料
⌂ 01 / 15