week7-优化本地PRD文档

产品需求文档（PRD）是产品经理交付给研发部门的最终输出物。在短短的一年时间内，我们的需求文档经过了两次大的改版。

第一阶段：产品需求列表+需求规格说明书+UI+axure原型

需求规格说明书 变更记录（*变化状态：C-创建，A-增加，M-修改，D-删除）

需求规格说明书目录

需求列表

使用反馈：

产品同事花费大部分时间来撰写需求文档，收效甚微。产品经理提交到redmine中，由负责相应模块开发的同学逐字逐句看完这23页的需求文档。测试部门写测试案例的时候，会认真仔细的阅读。需求评审时，比照需求列表、原型、UI图逐一评审。

优点：

研发能够按照需求规格说明书来完成开发任务。

缺点：

评审时间比较长，一般2小时。需求评审现场甚至会出现所有评审成员逐字逐句修改需求规格说明书的文字

如果存在任何一点瑕疵，都可以用“需求文档中没有说明”来拒绝。

产品、研发的关系稍微有些紧张，每个需求都需要彻底分割清楚责任。

第二阶段：产品需求列表+UI打包

修改后需求列表

随着需求列表的使用过程中，我们优化了列表的项目，并取消了word版本。从原来的｛需求规格说明书（word)+需求列表+需求迭代说说明+UI ｝到现在的｛需求列表+UI｝，内容简化，减少了文档数量和撰写工作量。

使用反馈：

优点：

开发过程中，基本能够严格按照需求列表完成功能开发。相比较第一版，需求的权责比较明确。

缺点：

产品和开发部门的关系比较紧张。

感觉开发部门就是完成产品经理确定的功能，把开发同事当做了”资源“。经常会出现需求评审通过后再次进行需求变更，有的版本甚至变更三四次；有时发布到应用市场后，反映卡顿、加载慢等现象，然后再中间进行一个版本优化。

问题分析：

在需求评审的时候，往往是产品经理已经细分确定了该版本所要完成的功能，评审的目的是和开发部门就功能、实现达成一致认识，避免出现偏差。注意，产品这时候和研发的评审已经全部聚焦到功能的代码层面实现，而且使用白纸黑字（产品需求文档）来说明想达成的最终效果。所以，本质上，开发部门是实现产品要求的功能的执行部门，而不是完成一个给用户的产品，没有将研发部门、产品不同版本的目标、用户需求有效结合起来。

解决方案：

产品需求文档中：

以用户需求、期望达到的目标为主要内容+兼顾性能要求、压力要求等+产品功能列表=输出产品功能列表。

这样的好处，向开发同事说明，每一个功能是为了实现一个特定的用户需求（blablabla----)，使开发同学在版本初期就明确工作的价值和目的。尤其关于性能、压力等要求，可以在评审初期，提醒开发同事兼顾，避免上线后反馈卡顿、跳转慢等性能问题。