第章重新定义产品说明文档

第18章　重新定义产品说明文档　Reinventing the Product Spec

安息吧，纸质说明文档

我认为产品说明文档的形式早就该改革了。有人说敏捷方法已经解决了这个问题：干脆放弃产品说明文档。虽然这样做存在一些问题，但我认为他们的方向没错。

讨论如何改革前，先来看看现今纸质的产品说明文档存在的问题。产品说明文档包含的范围很广，名称五花八门，有产品需求文档、市场需求文档、业务需求文档、功能规格书等等。内容覆盖范围、详细程度、文档本身的质量差别很大，就连形式也变化多端，有的是Word文档，有的是电子表格，有的是Wiki页面，还有的是用专业需求管理工具生成的。这些不同的文档本来作用各不相同，但是随着时间流逝，彼此间的界线越来越模糊。

我确实读过几份很不错的产品说明文档，但大部分产品说明文档既没有提供必要的细节，也不包含关键信息，更不能解决问题，虽然花费了大量时间撰写，却很少有人阅读。更要命的是，对管理层和产品团队来说，产品说明文档很容易成为一个幌子，仿佛一切都进展顺利。

产品经理的核心责任是确保向开发团队交付具有成功潜力的产品说明文档。认同这一点的人只要仔细审视产品是如何定义的，就不得不承认现有产品说明文档存在不足之处。

我认为理想的产品说明文档应该满足以下要求。

1. 产品说明文档应该完整地描述用户体验——不只是用户需求，还包括交互设计和视觉设计。希望大家已经明白用户需求和用户体验是密不可分的。

2. 产品说明文档必须准确地描述软件的行为。文字和图片的表达能力实在有限，不足以完成这项任务。

3. 产品说明文档的受众较广——开发人员、测试人员、客服人员、市场营销人员、运维人员、销售人员、管理层等等。因此，产品说明文档必须以某种直观的方式把产品信息和产品行为告诉所有人。

4. 产品说明文档应该可以修改。虽然进入开发阶段后，应该尽量避免修改产品说明文档，但总有意想不到的问题出现，需要修改产品说明文档以适应新情况。

5. 撰写产品说明文档的过程中会出现许多衍生物，比如，按优先级排列的需求列表、线框图、实体模型，但应该有一个主体来代表产品，避免混淆不清，版本错乱。

在我看来，只有一种形式的产品说明文档可以满足以上所有要求，那就是高保真产品原型。

“高保真”的含义是原型应该真实地体现用户体验。除了描绘用户界面的某些细微之处以外，我不建议使用“纸上原型” 。如今使用工具创建高保真原型既简单又快捷，成本也不高，没理由不这么做。为了获得接近真实的用户体验，甚至应该模拟后台处理流程和某些数据。

过去几年，我的想法一直在改变。以前我认为原型只需要包含关键的用户体验组件，现在我要求原型尽可能地体现产品细节——包括所有的页面和主要的用例。尽管还是会出现一些意想不到的错误和极端状况，但原型毕竟能让产品团队更直观地把握设计要求，其优势完全可以弥补增加的成本。

当然仅仅有原型是不够的，因为有些产品行为不容易用原型体现，比如业务逻辑（税务表单和运费等）、发布要求（性能表现、可靠性、扩展性等）、平台交付要求（安装要求、浏览器兼容性等）。用例可以作为有效的补充，用来描述重要的产品行为。

另外，如何展示补充的说明文档也值得考虑。最理想的方法是在原型上增加注释，不过这种技术还没有实现，退而求其次，我建议使用Wiki或内部网站。这样团队成员可以随时读到最新的信息，再不用浪费时间查找版本混乱的纸质文档。网站可以定期通知大家产品说明文档的更新情况，方便大家提问和讨论，并保存所有决策记录。

当然，产品说明文档的主体应该是高保真原型，由它体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计。

在我看来，除了符合以上要求外，高保真原型最突出的优势是可以用于测试。你可以把它放到真实用户面前，观察他们是否清楚如何使用（可用性），是否渴望使用你的产品（价值） 。只有通过这两项测试，产品说明文档才算合格，产品才值得开发。如果等到质检或公开测试阶段再验证，就太迟了。

我保证如果你尝试一次，创建体现功能和用户体验的高保真原型，产品团队一定会拥护这种做法。开发人员是最直接的受益者，因为他们终于看到了明确有效的产品说明，遇到不清楚的地方，随时可以参考。测试部门的工作也变得容易了，因为他们终于知道什么样的测试结果是正常的。市场部门、销售部门和客服部门也会很高兴提前了解产品。管理层也会支持这种做法，因为向投资者、董事会成员和商业伙伴展示产品时，产品原型远比PPT来得有效。高保真原型的优势还不止于此。

最让人吃惊的是，使用高保真原型可以大大缩短产品上市时间。没错，我知道这听起来不可思议，但只要我稍稍解释传统软件开发的情况，你就能理解了。因为传统的产品说明文档起不到应有的作用（不完整、含糊不清，特别是未经测试），而且几乎没有确定关键细节，也不解决实际困难，必须等到开发阶段这些问题才能得到解决。这导致项目要么被迫反复调整（产品说明文档不断变更，造成项目延期、士气低落），要么开发人员只能凭空猜测，交付的产品一团糟，用户不得不等待下一个版本或多个补丁发布后才能使用。无论哪种情况，产品上市的时间都将推迟。

所以我建议大家尝试高保真原型，与其花几个星期撰写冗长的Word文档，既没人读，也无法测试，还不如和设计师一起创建产品原型。把产品原型拿给团队检查，交给目标用户测试。也许要反复修改多次才能确定原型，但现在修改总比开发几个月做出糟糕的产品强。等产品原型确定后，用它代替产品说明文档交付开发，看看会有什么结果。

范例

高保真原型和产品说明文档的范例请参考http://www.svpg.com/examples。