修改循环检测
从哪里来 这么多轮修改？
回想上一个修改过多的项目，回答这些问题。
你的结果
回答所有问题后，这里会显示问题可能出在哪里，以及最先该迈出的一小步。
假设与边界
- 这个检测根据你的回答显示规律。有些项目确实需要更多轮修改，例如客户自己还在摸索时。
- 关于修改的合同条款，代替不了合作出问题时的一次谈话。
你的输入只保留在此浏览器中，不会保存或发送任何内容。
你如何察觉它
快完成了。 已经好几周了。
- 第三轮推翻了第一轮，已经没人知道当初定了什么。
- 反馈来自没参加需求沟通的人。
- 项目当初算得很好，现在利润却没了。
理解原因
四个原因， 早在第一次修改之前。
- 01
需求简报不明确
- 你如何察觉它
- 客户直到看到初稿，才意识到自己真正想要什么。
- 为什么会发生
- 开工前没有把目标和标准确定下来。
- 有什么帮助
- 把目标、目标群体和成功标准写下来，并请对方确认。
- 边界
- 有些客户事先确实不知道；这时一份小小的初稿可以当作明确需求的工具。
- 02
分散的反馈
- 你如何察觉它
- 客户那边每个人都发来自己的修改要求。
- 为什么会发生
- 没有规定如何收集和协调反馈。
- 有什么帮助
- 约定每一轮由客户内部协调好，统一给出一份反馈。
- 边界
- 你只能要求客户内部先协调好，不能替他们去做。
- 03
没有固定的审批人
- 你如何察觉它
- 临近收尾时，冒出一个新意见。
- 为什么会发生
- 最终拍板的人，并没有从一开始就参与。
- 有什么帮助
- 在启动会上指定审批人，并在每个里程碑让他参与。
- 边界
- 大型组织往往有多道审批；那就逐一指定。
- 04
没有约定轮次
- 你如何察觉它
- 额外的轮次就是无偿劳动。
- 为什么会发生
- 报价和协议里都没写包含多少次修改。
- 有什么帮助
- 把修改轮数和额外轮次的价格写进报价。
- 边界
- 合同里的边界，只有你在项目中也提出来才有效。
解决路径
更少的轮次。 不吵架。
| 路径 | 足够，如果 | 边界 |
|---|---|---|
| 需求简报模板和邮件审批 | 项目不多，客户那边只有一个对接人。 | 反馈和审批仍然散落在收件箱里。 |
| 在报价中约定修改轮次 | 修改轮次主要源于缺少边界。 | 解决不了需求简报不清或缺少审批的问题。 |
| 专门的校对或审批工具 | 你主要交付设计或文件，供对方标注和评论。 | 给客户又多一个工具；报价和任务还在别处。 |
| Peak One | 你想把一个项目的报价、需求简报、任务和审批放在一起。 | 不能替代图形标注工具；约定多少轮修改由你决定。 |
Peak One 实际演示
从第七轮修改 到一次明确的审批。
- 触发条件为什么这个项目没完没了？
- 01 · 任务信号Peak Board 中的 Project Board 显示哪些任务一再被退回进行中。
- 02 · 文档理解需求简报和决定都在 Peak Docs 中；Document Decisions 显示哪些事已经定过。
- 03 · 报价决定在 Offer Builder 中，你写明交付什么、按什么条件，包括修改轮次。
- 04 · 审批操作在 Peak Automations 中，审批成为流程中独立的一步，你能看到当前进行到哪一步。
相关应用
从报价到审批。
视图
进展和决定。
三个步骤
缩短下一轮。
- 01 / 03
请客户确认需求简报
在下一稿之前，用三句话写下目标，并请对方书面确认。
- 02 / 03
一位审批人
问客户谁做最终审批，并邀请这个人参加下一次评审。
- 03 / 03
把轮次写进报价
从下一份报价开始，写明包含几轮修改。
常见问题
简要回答。
多少轮修改算正常？
没有一个通用的数字。很多服务商会在报价中约定固定次数。关键是事先定好数字，并且双方都知道。
怎样提出额外修改，又不惹客户不快？
尽早并就事论事：说明约定的轮次已经用完，并提出下一轮按工作量收费。如果报价里写明了边界，这会容易得多。
变更和修改是一回事吗？
不是。修改是让成果符合约定的需求简报。变更则是改变需求简报本身，应作为新的工作量来商谈。
继续探索
包含的内容。
- 功能任务与项目项目以看板呈现，任务进入日计划，每个项目一个聊天。查看
- 功能利润率与边际贡献每个产品和变体的边际贡献，含情景与库存。查看
- 使用场景干净利落地结束项目理清未决事项、记录成果、留下一条客户评价并规划下一步。查看
- 软件类别项目管理软件每个项目任务都有负责人、截止日期和可见的进度。查看
- 问题报价耗时太长从沟通到报价要过好几天，客户的热情逐渐冷却。查看
- 问题客户看不到项目进度客户不知道项目进展如何，一再追问。查看
✦ 一条 Peak 原则
先求清晰。其余随之而来。
一件接一件
