产品经理工作流程
一个项目,就是从“客户随口说的一句话”走到“真正上线跑起来”。这中间要经过下面这一串环节,产品经理就是全程盯着这条流水线的人:把需求收上来、拆清楚、写成方案、推着开发做、盯到上线。
下面按顺序讲清楚每一段路怎么走、留下什么产出物、要拉谁一起干、最容易在哪儿栽跟头。
先用一句话记住这条链路:
需求收集 → 需求分析 → 方案设计 → 评审 → 排期 → 开发跟进 → 测试验收 → 上线 → 复盘
越靠前的环节出错,后面返工越贵。需求没问清,开发做完才发现做错,等于全部重来。
每个阶段都会留下“产出物”,它既是下一阶段的输入,也是事后验收和追责的依据:
| 阶段 | 核心动作 | 产出物 |
|---|---|---|
| 需求收集 | 把相关人说的话完整记下来 | 原始需求清单 |
| 需求分析 | 拆功能点、判断真伪、定范围 | 需求分析结论 |
| 方案设计 | 定功能、字段、规则、流程 | 需求文档 / 功能规格 / 原型 |
| 评审 | 拉齐各方,确认要做的到底是什么 | 评审结论、修改后的文档 |
| 排期 | 和技术主管一起定时间 | 排期表、迭代计划 |
| 开发跟进 | 答疑、对齐接口、处理变更 | 接口文档、变更记录 |
| 测试验收 | 按验收标准逐条核对 | 测试报告、问题清单 |
| 上线 | 核对后正式发布 | 上线清单 |
| 复盘 | 看数据、找问题、沉淀经验 | 复盘记录、优化项 |
阶段一 需求收集与立项
Section titled “阶段一 需求收集与立项”一句话:先搞清楚“谁想要什么”,记全,别急着说行不行。
需求一般从这几个地方来:
| 来源 | 说明 |
|---|---|
| 用户 | 客户直接提的,最原始、最口语 |
| 老板 / 决策人 | 能拍板的人,优先级最高 |
| 数据 | 后台数据暴露出来的问题,比如某个页面流失特别高 |
| 竞品 | 对手有的功能,客户会说“人家也有” |
要问清的问题:
- 谁用?在什么场景下用?
- 现在没有这个功能,用户是怎么凑合解决的?
- 你到底想解决什么问题?(先问问题,别急着接功能)
- 期望什么时候能用上?
| 做什么 | 产出什么 | 找谁配合 | 常见坑 |
|---|---|---|---|
| 把用户、老板、数据、竞品提出的需求完整记录下来,先记录不评判 | 原始需求清单 | 客户、老板、运营 | 用户说“加个按钮”,照做后才发现他真正要的是另一个功能 |
| 追问使用场景和要解决的问题,还原真实目标 | 对需求背景的一致理解 | 客户 | 只记“要什么”、不记“为什么”,后面没法判断优先级 |
| 判断这件事要不要做、值不值得立项 | 立项判断 | 老板 / 决策人 | 需求没问清就开工,做到一半推翻重来 |
阶段二 需求分析
Section titled “阶段二 需求分析”一句话:把一句模糊的话,拆成一个个能独立开发、能独立验收的功能点。
这一步要做四件事:
- 拆解成功能点
- 区分真伪需求
- 定范围(做什么 / 不做什么)
- 排优先级
用户往往给你的是“解决方案”,而不是“问题”。多问一句“你要这个是为了解决什么”,常常能发现更省事的做法。
| 做什么 | 产出什么 | 找谁配合 | 常见坑 |
|---|---|---|---|
| 把需求拆成可独立交付的功能点,每个功能点写清 输入 / 处理 / 输出 / 异常 | 功能点清单 | 客户、技术主管 | 一句话里藏着好几个功能,当成一件事估工期,必然估错 |
| 区分真需求与伪需求:用户说的 vs 用户真正需要的 | 需求分析结论 | 客户 | 用户说“要个导出 Excel”,其实他要的是一份能直接发出去的报表 |
| 划清范围:本轮做什么、明确不做什么 | 范围清单(in scope / out of scope) | 客户、决策人 | 范围不写清,后面每加一点都变成“顺手的事” |
| 排优先级:必须做 → 应该做 → 可以做 | 优先级列表 | 客户 / 决策人最终确认 | 产品经理只给建议,别越权替客户拍板 |
阶段三 方案设计
Section titled “阶段三 方案设计”一句话:把功能点写成技术团队照着就能做的东西。
这一步要出四样东西:功能规格、字段与规则、流程与异常、原型。
| 做什么 | 产出什么 | 找谁配合 | 常见坑 |
|---|---|---|---|
| 写功能规格:每个功能有哪些字段、谁能操作、操作后发生什么 | 功能规格文档 | 技术主管、后端开发 | 只写正常流程,不写异常和边界 |
| 定义字段与规则:字段类型、是否必填、长度、唯一性、计算规则 | 字段与规则表 | 后端开发、前端开发 | 字段规则含糊,前后端口径不一致 |
| 画清流程与异常:主流程 + 异常分支(断网、超时、余额不足等) | 流程图(文字 / 原型标注) | 技术主管 | 异常没人管,上线后一出事就找不到状态 |
| 出原型:页面结构、交互流程、状态 | 原型图 | UI 设计师、客户 | 原型没确认就开始开发,方向错了返工大 |
阶段四 评审与排期
Section titled “阶段四 评审与排期”一句话:把要做的、不做的、什么时候做,当着一屋子人定下来。
需求评审会怎么开:
- 提前把文档发给参会人,让大家先看,别在会上现读
- 会上按功能点逐条过,先讲背景与目标,让大家知道“为什么做”
- 收集技术上的疑问和风险,当场记录,不当场吵
- 会后更新文档,以更新后的版本为唯一依据
排期的规矩:
- 时间由技术主管给定,产品经理不自己拍脑袋
- 按优先级安排迭代,核心流程先做
- 标注依赖关系和前置条件,别让后置任务先开工
| 做什么 | 产出什么 | 找谁配合 | 常见坑 |
|---|---|---|---|
| 组织需求评审会,逐条对齐功能点、背景与目标 | 评审结论 | 技术主管、前后端、测试、UI | 会上没人提意见,会后各做各的,做出来互相不搭 |
| 收集技术疑虑与风险并当场记录 | 风险清单 | 技术团队 | 风险没记下来,开发到一半才发现技术做不了 |
| 与技术主管确认排期,按优先级安排迭代 | 排期表、迭代计划 | 技术主管 | 产品经理自己给客户承诺时间,开发不认账 |
| 标注依赖关系与前置条件 | 前置条件清单 | 技术主管、各方 | 前置任务没完成,后置任务空等 |
阶段五 开发跟进与变更管理
Section titled “阶段五 开发跟进与变更管理”一句话:开发过程中顶住“需求黑洞”,把变更加进透明流程里。
三件事:
- 答疑:随时解答开发过程中的需求疑问,开发不许自己猜需求
- 接口对齐:和前后端确认接口字段与数据流向,接口一变立刻通知双方
- 变更管理:任何变更都要记录原因、影响范围、排期影响,评估后再执行
| 做什么 | 产出什么 | 找谁配合 | 常见坑 |
|---|---|---|---|
| 随时解答开发提出的需求疑问,避免开发自行猜测 | 解答记录 | 前后端开发 | 开发猜需求,做出来的东西跟设计对不上 |
| 与前后端确认接口字段与数据流向 | 接口文档 | 前端开发、后端开发 | 接口字段没对齐,联调时才发现对不上 |
| 处理需求变更:记录原因、影响范围、排期影响,评估后再执行 | 变更记录 | 客户、技术主管 | 口头加需求不记档,时间一长没人说得清改了什么 |
| 及时同步进度与风险 | 进度同步记录 | 客户、老板 | 出了风险藏着不说,最后一起爆雷 |
阶段六 测试与验收
Section titled “阶段六 测试与验收”一句话:按当初写下的验收标准,一条一条对着核,不合格就退回。
- 按验收标准逐条核对,不合格项退回并说明具体差异
- 记录问题并跟踪到修复完成,别记了就忘
- 上线前核对功能、文案、图片是否与需求一致
| 做什么 | 产出什么 | 找谁配合 | 常见坑 |
|---|---|---|---|
| 按验收标准逐条核对功能是否达标 | 测试报告 | 测试工程师、开发 | 验收标准当初没写清,现在只能靠感觉判断 |
| 记录问题并跟踪到修复完成 | 问题清单 | 测试、开发 | 问题记了不跟,上线后老问题又冒出来 |
| 上线前核对功能、文案、图片与需求一致 | 上线前核对表 | 测试、UI、客户 | 文案图片和需求不一致,客户第一眼就发现 |
阶段七 上线与复盘
Section titled “阶段七 上线与复盘”一句话:上线不是终点,上线之后才第一次拿到真实数据。
- 上线核对:按上线清单检查功能、配置、账号是否到位
- 数据回顾:看关键指标,是否达到当初的预期
- 复盘沉淀:哪些做对了、哪些踩了坑、下个迭代先改什么
| 做什么 | 产出什么 | 找谁配合 | 常见坑 |
|---|---|---|---|
| 按上线清单核对功能、配置、账号是否齐全 | 上线清单 | 运维、技术主管、测试 | 上线才发现配置没配、账号没开,临时救火 |
| 回顾上线后的关键数据 | 数据回顾记录 | 运营、客户 | 只看“有没有上线”,不看“上线有没有用” |
| 组织复盘,沉淀经验与下轮优化项 | 复盘记录、优化项 | 全体参与者 | 复盘变成走过场,同一个坑下个项目再踩一遍 |