将文档群发给项目的所有利益相关方，并且抄送给其他可能对文档感兴趣的团队（例如你所在的产品团队，整个支持团队等）。

　　跟进这些关键人员是否接受了会议邀请：将会执行这件事情的人，和所有对这件事情有通过/否决权力的人。

　　5. 评审文档（1小时）

　　在开始会议之前，询问是否有参会者没有详细阅读你的文档。通常都会有一两个人中枪，在这种情况下可以说：“没问题，我们先用 10 分钟一起来看一下文档。已经读过文档的人可以利用这个时间先放松休息一下。”

　　这次会议上你需要获得利益相关方的同意，并且获得执行方（工程师、支持团队等）的知晓、认可以及人力支持。

　　你可能需要开多次评审会议，并且根据评审会议上沟通的信息不断修改文档。

　　6. 通过评审后，及时同步信息和建立工单（1-2小时）

　　会后同步信息的电子邮件需要包含更新后的产品文档链接，和此项目相关的工单链接（例如在页面上添加 Java 代码，完成数据分析报告，测试 Staging 环境，和支持团队预演流程，等等）。

　　一般接下来将会有一位工程师完成技术文档，不过并不总是这样（文中的示例项目就不需要这一步）。

　　产品文档进阶技巧：

　　1. 尽量简短

　　没有比这更重要的文档写作建议了。简洁意味着清晰的思路和沟通，也意味着你的文档更加易于阅读和理解——这一点至关重要。

　　2. 使用平白的语言和简单的格式

　　使用简短而不是花哨的语句，使用列表和加粗强调可以使文章更一目了然，以放松有趣的方式写作而不是一板一眼，如果你有得体的幽默感就再好不过了。

　　3. 为开发团队预留时间

　　通过评审并且达成一致通过的文档才是完善的文档。如果你希望在未来的某一个迭代 Sprint 中开发此项目，就应该提前两到三周开始这个产品文档写作流程。

　　4. 像工程师一样思考

　　在项目得以进入开发之时，常常会发现大量未预料到的边缘情况——但这种情形其实可以避免。如果你认真考虑过项目进入开发的所有必要条件，你就可以提前发现这些问题（例如，是否在移动设备中可以使用在线聊天功能？）。

　　5. 确保每一个人都跟上了你的节奏

　　当我组织产品评审时，会议室里的大部分人都已经大致了解我要讲的内容——因为我已经提前在讨论会和日常聊天中沟通过这个事情了。既然大家都已经清楚了「做什么」和「为什么要做」的问题，文档评审会上我们只要关注实施细节就好了。

　　6. 在图表中下功夫

　　流程图、线框图等图表可以通过易于理解的方式提供很大的信息量，同时也需要消耗非常多的时间来制作这些图表。

　　7. 在思考和写文档上花 0.5-3 天时间

　　具体时间根据项目大小而定。花费在写文档上的时间越长，所带来的边际收益就会递减。特别需要指出的是，没有人能够读的下去超过 5-6 页的文档。

　　8. 指明方向，明晰愿景

　　你不仅仅是在定义一个功能，也是在解释「为什么我们要做这件事情」以及「我们的目标是什么」，在文档中指出这个项目将会对更高层面的规划造成什么影响，以及接下来会发生什么。

　　9. 确保你的观众阅读了文档

　　如果你的文档又臭又长，或者从来不分享给对应的人，那你还不如不写文档。务必确保你的文档被对应的人阅读了，atv，我上面关于评审开始时留时间给大家读文档的建议值得大家参考。

　　10. 获取真诚的反馈

　　你的文档是否是在赘述人尽皆知的事情？或者是文档缺乏足够的细节？是否在后续实施中发现了太多的边缘情况？又或者，是否在制定计划和文档评审上耗费了太多的时间？你应该和你的团队时刻保持沟通。

　　产品文档与敏捷开发矛盾吗？

　　我知道会有争议，但是产品文档和敏捷开发的原则没有丝毫冲突，并且在类似于 Scrum 这样的敏捷方法上得到了充分发挥。