01 / 最适合日常协作的材料
一页总览 + 场景操作卡 + 协作模板
思维导图负责看全局；工作指南负责查做法；任务卡负责推进具体事项。
建议以这份指南作为团队共同入口。首次对齐时讲清全流程；平时直接展开对应场景；具体负责人、状态和证据继续留在现有任务系统及项目资料库。
看市场与客户 → 定目标与取舍 → 澄清需求 → 书面评审 → 开发测试 → 发布验收 → 验证价值与复用 ↺
每项工作都用同一句话讲清楚
为了让【用户】在【场景】获得【结果】，由【负责人】在【节点】交付【成果】，按【条件】验收；现在需要【协作人】提供【输入】，证据放在【链接】。
本指南结合原会议三主线、前一版思维导图及本地产品开发部管理规范整理；角色建议、模板与试用节奏待团队确认，不代表已经指派人员或启用新的管理制度。
02 / 按事找入口
遇到这六类事情，分别这样推进
每张卡都回答：谁牵头、谁配合、做什么、交什么、到哪里算完成。
01客户又提了一个需求先判断问题和承诺，再决定是否进入研发。
- 谁牵头
- 产品经理
- 谁配合
- 交付提供现场样本；商务核对承诺；研发提供可行性判断
- 开始前准备
- 客户原话、角色场景、现有做法、样本、期望时间、合同范围
- 具体怎么做
- ① 还原谁在什么场景遇到什么问题；② 区分Bug、新需求、配置和实施问题；③ 选择标准能力、配置、定制、验证或不做；④ 留下结论和下一步。
- 交付什么
- 需求卡 + 分流结论 + 需求ID
- 到哪里算完成
- 目标、边界、证据与验收能说清；新增需求经评审后按现有流程登记研发任务。
- 容易踩的坑
- 把“客户希望”写成“已承诺”；开发人员接到一句话直接开工。
02要决定下个月或下季度做什么按价值与依赖排序，把能力放进版本。
- 谁牵头
- 产品负责人
- 谁配合
- 市场/售前提供趋势；研发估成本；交付提供复用与阻塞证据；决策人确认取舍
- 开始前准备
- 市场洞察、需求池、项目承诺、产品现状、资源约束
- 具体怎么做
- ① 按软件、硬件、资质归类；② 先看准入与交付阻塞，再看共性价值和复用；③ 明确本期、后续、验证与不做；④ 研发评估后确认里程碑。
- 交付什么
- 产品路线图 + 本期范围 + 不做清单 + 资源缺口
- 到哪里算完成
- 每项有目标场景、价值、责任人、依赖与阶段成果；估时未完成时不承诺正式日期。
- 容易踩的坑
- 把所有需求排进去；用功能数量代替产品目标。
03需求要开评审会让业务、实现和验收形成同一份结论。
- 谁牵头
- 产品经理
- 谁配合
- 业务确认价值；研发确认实现与依赖；测试确认验收；交付确认现场条件
- 开始前准备
- 需求版本、流程、规则、原型或样本、未决问题、验收草案
- 具体怎么做
- ① 会前发材料并标出待决问题；② 会中先定范围再定规则与异常；③ 逐项记录通过、补充复审、暂缓或不做；④ 会后确认责任人和补齐时间。
- 交付什么
- 书面评审记录 + 冻结版本 + 待办清单
- 到哪里算完成
- 阻塞问题已解决，或明确退回复审；影响范围与关键规则的变更需要重新确认。
- 容易踩的坑
- “聊过了”就算通过；只看页面、不讨论数据和异常。
04开发开始了，或者中途卡住了把需求拆成可验收任务，及时处理依赖和变更。
- 谁牵头
- 研发负责人（实现）；产品经理（需求澄清）
- 谁配合
- 前后端、测试、接口/硬件责任人；经理协调资源
- 开始前准备
- 已确认需求、接口/数据/权限契约、开发任务、估时和依赖
- 具体怎么做
- ① 拆分可验收结果并关联需求；② 确认共享契约后执行；③ 记录阻塞的对象、影响与需协助事项；④ 范围变化先评估成本和节点影响。
- 交付什么
- 任务进展 + 代码/接口关联 + 变更和阻塞记录
- 到哪里算完成
- 开发交付达到提测条件；测试用例、环境、版本与数据准备明确。
- 容易踩的坑
- 产品暗改范围；开发“完成”但测试不知版本；延期只有一句“还没好”。
05准备测试、上线或客户验收分别证明功能、发布和业务流程是否成立。
- 谁牵头
- 测试负责人（质量）；交付/项目负责人（现场验收）
- 谁配合
- 产品确认业务结果；研发修复问题并提供版本；授权人员确认发布
- 开始前准备
- 验收条件、版本、环境、授权样本、设备/数据依赖
- 具体怎么做
- ① 验证正常与异常流程；② 需要时验证历史兼容、硬件和数据；③ 形成发布及恢复条件；④ 项目端到端验收并记录结果。
- 交付什么
- 测试报告 + 缺陷结论 + 发布记录 + 验收证据
- 到哪里算完成
- 测试、发布、产品验收、客户验收分别记录；未满足的条件明确保留，不笼统写完成。
- 容易踩的坑
- 部署完成等于验收完成；截图没有版本或场景；无恢复安排就覆盖基础数据。
06做完了，怎么汇报和沉淀证明有什么变化，并判断能否复用。
- 谁牵头
- 产品负责人
- 谁配合
- 交付提供工时和问题；业务确认效果；研发/测试提供版本与质量证据
- 开始前准备
- 使用前基线、验收结果、实施投入、客户反馈、标准/定制分类
- 具体怎么做
- ① 写实际结果而非动作清单；② 对比同场景耗时、差错或人工工作量；③ 区分实测与预计收益；④ 沉淀标准方案并决定继续、修正或退出。
- 交付什么
- 价值复盘 + 标准能力/配置资产 + 下一轮决策
- 到哪里算完成
- 证据可追溯，价值未测出则标缺口；新项目实际复用后再声称可复制。
- 容易踩的坑
- 把完成页面当成增收；只有一个项目就宣称标准化成功。
03 / 把交接说清楚
每一位角色，都交付下一位能接手的内容
| 角色 | 日常必须说清楚 | 交接给下一位的内容 |
|---|---|---|
| 产品负责人 | 为什么做、优先级与范围如何取舍 | 路线图、资源缺口和决策结论 |
| 产品经理 | 用户问题、流程规则和验收是什么 | 带版本的需求、评审结论和待决问题 |
| 研发负责人 / 开发 | 怎么实现、依赖谁、什么时候具备提测条件 | 任务、代码/接口、版本、限制和变更 |
| 测试 | 如何证明正确，哪些风险仍未覆盖 | 测试证据、缺陷、未通过项与质量判断 |
| 交付 / 项目负责人 | 现场条件是否具备，谁确认业务验收 | 部署配置、端到端验收、客户反馈及阻塞 |
| 商务 / 售前 | 客户期望、合同约定和正式承诺分别是什么 | 原始需求、约定范围、评分要求与商业边界 |
一人兼多岗时也要区分责任；每个具体事项明确一位最终跟进人。客户承诺、范围取舍与发布由有权限的人确认。
04 / 让协同形成节奏
每天解阻塞，每周做决策，每月看价值
| 时点 | 只对齐这些事情 | 留下什么 |
|---|---|---|
| 每天｜利用既有站会或任务更新 | 今天交付什么；卡在哪里；需要谁在何时帮什么 | 原任务更新下一步、依赖、风险，不另写一套日报数据 |
| 每周｜产品与项目协同 | 本周成果证据；未来节点；跨角色阻塞；范围和优先级决策 | 一份周协同记录，决策关联任务ID |
| 每月｜产品复盘 | 市场变化；版本实际结果；复用与交付投入；能力缺口 | 更新产品地图和路线图，决定继续、修正或暂缓 |
| 每季度｜规划评审 | 目标达成与价值证据；下季取舍；资源与退出事项 | 季度目标、版本路线图、资源与不做清单 |
周会建议先看这四件事
结果完成了什么，有什么证据
阻塞缺什么输入，影响哪个节点
决策谁决定，做或不做，代价是什么
行动谁在何时交付下一成果
不把周会变成长篇逐人报流水账。无需决策的详细进度会前更新；会议集中解决跨角色依赖和范围取舍。
| 放在哪里 | 负责记录什么 | 减少重复的方式 |
|---|---|---|
| 现有需求 / 任务系统（如云效） | 需求、开发任务、缺陷、状态、估时/工时、代码关联 | 作为具体执行记录；本指南不新建另一份在线任务系统 |
| 现有周计划 / 项目进度表 | 跨项目节点、人员负荷、风险、偏差和协同事项 | 引用任务ID与链接，避免重新抄写全部任务详情 |
| 微盘 / 项目资料库 | 原始资料、方案、评审、测试、验收和复盘资产 | 保存有版本的正式材料；在任务中放链接 |
| Codeup / 接口与质量平台 | 代码、合并、发布版本、接口和质量证据 | 关联同一任务；系统状态写入仍遵循现有权限和流程 |
05 / 复制即可用于具体工作
一张任务卡，一份周会记录
这些是填写模板，不是实时协作看板。复制到既有任务、在线表格或项目文档中使用，由原系统记录正式状态。
| 任务卡字段 | 怎么填写 |
|---|---|
| 任务ID | 填写现有系统编号，关联需求及项目 |
| 目标与场景 | 谁在什么情况下，要获得什么结果 |
| 本次范围 / 不做 | 本次做到哪里，哪些明确不包含 |
| 负责人 / 协作人 | 一位最终跟进人；协作人各负责哪一项输入 |
| 阶段 / 风险 | 沿用现有任务系统状态；风险、日期单独填写 |
| 计划节点 / 依赖 | 节点、上游交付、外部条件与等待对象 |
| 下一步 / 时间 | 下一个可执行动作、执行人和预期完成时间 |
| 验收与证据 | 输入、动作、预期结果；对应版本和证据链接 |
| 变更 / 决策 | 谁决定了什么，影响什么范围或节点 |
周协同会议模板
会议主题：本周产品与项目协同 日期 / 主持 / 记录：待填写 1. 上周承诺：成果是什么，证据链接在哪里？ 2. 本周目标：谁在什么节点交付什么可验收结果？ 3. 当前阻塞：卡在谁的输入，需要什么决定，何时答复？ 4. 范围变更：为什么改，影响成本/时间/验收哪些部分？ 5. 当场决策：通过 / 补充复审 / 暂缓 / 不做；决策人是谁？ 6. 会后行动：任务ID｜责任人｜下一步｜计划节点｜证据入口 结束前：行动责任人确认，未决项指定跟进人。
06 / 用真实事项理解方法
把方法套回本次产品工作
| 事项 | 今天先做什么 | 谁协作 | 这一步的完成证据 |
|---|---|---|---|
| 基础库统一 | 先盘点来源、单位、版本、历史引用和冲突，再开治理方案评审 | 产品、研发、营养专业人员、采购 | 数据盘点和规则评审结论；不是“库已更新”的口头汇报 |
| 菜谱量化 | 核实各子项设计/开发/待测试状态，定义量化到采购准备的最小闭环 | 产品、采购、研发、营养、测试 | 可追溯任务范围、基准样本和异常验收规则 |
| 机场对账 | 先确认当前项目状态，再明确对账双方、账期、差异和验收样本 | 产品、财务/业务、研发、交付 | 已确认需求卡；未核实前不沿用会议的相对日期 |
| 硬件与资质 | 按项目必要性列差距，核对型号版本、证明主体及适用范围 | 硬件、研发、交付、售前、资质负责人 | 兼容/准入矩阵及证据链接，不以品牌名或口述代替 |
以上为推进示例。会议进度是当时口述，当前任务状态、具体责任人和可承诺工期需回到现有记录核实。
07 / 最轻的落地方式
先用一周，验证是否更容易协作
- 首次对齐：用总览统一流程；确认具体的产品、研发、测试与交付接口人，以及任务和资料的存放位置。
- 选择两项试用：一项近期项目需求、一项通用产品能力。补齐任务卡并按对应操作卡推进。
- 沿用既有会议：每天更新下一步和阻塞；本周协同会按模板形成明确决策与行动。
- 一周后复盘：看是否更容易找责任人、减少反复问进度、降低重复填表，并让验收证据更完整；保留有用字段，删掉重复字段。
最终要做到：任何人接手一项工作，都能找到它为什么做、谁负责、卡在哪里、下一步是什么，以及怎样算完成。