项目状态模板
一份更新， 无需再追问。
把示例行换成你的项目。把结果复制到给客户的邮件里。
你的计划
4 行中已完成 4 行。
Die Beispielzeilen sind nur ein Anfang. Überschreibe sie mit deinen eigenen Einträgen.
假设与边界
- 模板帮你整理填写的内容。进展是否属实，只有你的团队知道。
- 当某个日期真的悬了，更新替代不了沟通。那时最好直接打电话。
你的输入只保留在此浏览器中，不会保存或发送任何内容。
你如何察觉它
客户在等。 却不知道在等什么。
- 客户通过邮件、电话和聊天询问进展，同一个问题常常问了不同的人。
- 客户为延误而恼火，可延误其实是他造成的，因为缺了一项批准。
- 每次见客户之前，你都得先在团队里汇总进展。
理解原因
为什么客户 被蒙在鼓里。
- 01
没有固定节奏
- 你如何察觉它
- 有人有空或客户来问时，才会有更新。
- 为什么会发生
- 没人约定过客户在什么时候得知什么。
- 有什么帮助
- 约定一个固定的更新日，并坚持下去，即使进展不多。
- 边界
- 对于很短的项目，每个里程碑更新一次就够了。
- 02
进展分散在各处
- 你如何察觉它
- 每写一次更新，你都要问三位同事。
- 为什么会发生
- 任务、沟通和文件分散在不同工具里。
- 有什么帮助
- 在一个地方维护项目进展，更新就从这里生成。
- 边界
- 只有团队真正在那里工作，集中一处才有用。
- 03
等待时间看不见
- 你如何察觉它
- 客户没意识到项目正在等他的批准。
- 为什么会发生
- 更新罗列了做过什么，却没说现在轮到谁。
- 有什么帮助
- 在更新中坦率说明哪些在等客户处理、截止何时。
- 边界
- 这解决不了所有延误，但能清楚显示延误发生在哪里。
解决路径
共享进展。 尽量简单。
| 路径 | 足够，如果 | 边界 |
|---|---|---|
| 用上方模板每周发送状态邮件 | 客户项目不多，且有一个人了解进展。 | 全靠手工；每次都要重新汇总进展。 |
| 与客户共享的文档 | 客户会一起阅读，团队也能可靠地维护文档。 | 常常变成实际任务之外的第二份清单。 |
| 项目工具的客户门户 | 希望客户随时能自己查看任务。 | 往往暴露了比客户想看或应该看到的更多内部细节。 |
| Peak One | 你希望进展直接来自团队正在使用的任务和文档。 | 访客只能看到共享的内容；共享什么，由你按项目自行决定。 |
Peak One 实际演示
从追问 到固定更新。
- 触发条件Müller 客户的项目进展到哪里了？
- 01 · 项目信号Peak Board 中的 Project Portfolio 显示哪些客户项目现在需要关注。
- 02 · 任务理解Project Board 显示每项任务的进展，以及哪些在等客户。
- 03 · 交付决定Peak Service 中的 Delivery 显示你们是否按时交付了承诺的内容。
- 04 · 文档操作你在 Peak Docs 中撰写更新，让每一次进展都集中在一处、随时可查。
相关应用
Peak One 中的项目进展。
动手试试
记录并共享进展。
三个步骤
从本周起，不再被追问。
- 01 / 03
确定更新日
告诉你的客户，每周哪一天他会收到进展。
- 02 / 03
四行就够了
已完成、进行中、等你们处理、下一步。一份好的更新很少需要更多。
- 03 / 03
写明等待事项
写明哪些在等客户处理、截止何时。这样延误就不会算在你头上。
常见问题
简要回答。
我应该多久向客户通报一次项目进展？
频率以客户不必追问为准。大多数项目适合每周固定一次，短项目则每个里程碑更新一次。
应该让客户直接查看我们的任务吗？
这取决于客户。很多客户想要的是一份简短更新，而不是每项任务。在 Peak Board 中，访客只能看到共享的内容，所以由你决定哪些可见。
没有进展时我该写什么？
就如实写，附上原因和下一步。一句坦诚的“本周没有进展，因为……”比跳过一次更新更能建立信任。
继续探索
包含的内容。
- 功能任务与项目项目以看板呈现，任务进入日计划，每个项目一个聊天。查看
- 使用场景回复客户询问每个询问都有负责人，常见问题公开回答一次即可。查看
- 软件类别项目管理软件每个项目任务都有负责人、截止日期和可见的进度。查看
- 问题没完没了的修改循环每一轮反馈都带来新一轮修改，项目永远完不成。查看
- 问题项目失控每个项目都在勉强推进，却没人说得清它真正进展到哪一步。查看
- 问题错过截止日期日期都承诺了，到截止日却还是没全部完成。查看
✦ 一条 Peak 原则
先理解，再改变。这样每一步都有效果。
Peak 与你一同学习
