《独具匠心：做最小可行性产品（MVP）方法与实践》：赋能产品经理，赋能企业产品。作者：张乐飞
?业务规则：每上产品在开发时都有相应的业务规则，将这些规则清晰的描述出来，
让开发、测试人员能够直观的明白该规则，且没有产生歧义。业务规则必需是完整
的、准确的、易懂的。业务规则的描述上如果涉及到页面交互或者页面的修改，建
议给出页面的草图或者页面截图在图上说明要修改的内容。另外也建议对页面的输
入框、下拉框的内容格式、长度、控件之间的关联性做出说明，什么时候可见，不
可见，灰掉或点亮的条件在文档中都给出说明。方便阅读者理解业务规则。
?界面原型：如前所述，涉及到页面交互的部分，产品经理需要设计页面原型。原型
设计通常需要产品经理和UI设计师一起来完成。建议的做法是，产品经理可设计
一个页面框架，将该页面要呈现的字段及其特征以及页面要使用的场景向交互设计
师解释清楚。之后交互和视觉设计师完成产品的原型设计。
?使用者说明：对产品使用者做出说明，可融入简要说明中。
?前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像的文件。
?后置条件：操作后引发的后续处理。
?主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个
功能流程走向分点说明(这是非常重要的)。
看过很多的PRD（包含FSD），文档中对既没有前提条件，也没有后置条件，只对主流
程做了说明，但是在描述主流程时却没有描写主流程中每个功能流程的各种走向，只有一个
主走向，让人感觉PRD成了操作手册。事实上，对分支的介绍是非常重要的，开发和测试
中提出的各类问题均与对分支的定义不明有关。一个合格的PRD不仅要描述主流程，同时
对分支流程所出现的各类问题都要做详细阐述并给出解决办法。PRD的特征一定是明确的、
全面的阐述需求及各类异常情况的处理而不是等到开发和测试阶段发现问题后再给以答案
（虽然PRD不可能百分之百地覆盖所有的可能，但是最大化的思考所有的业务问题是编制
PRD时必须遵守的原则）。另外，在描写功能需求时给出的办法中不能出现“可能”、“或者”
等词，一定是明确的，准确的描述。如果有别的方案，建议写入“可选方案”，在产品构建的
早期可选方案可以为功能实现提供更多的选择，当方案确定后可在文档中注明本次使用了哪
种方案。
推荐一个方法：“用例”，在面向对象的软件设计模型中，用例是一个被阐述的
内容，用例是对功能使用场景的解释。用例很条理的介绍了每个功能的前置、后置条
件，主流程介绍，帮助开发、测试等角色快速的了解产品功能。
产品会MVP联盟中国产品经理学习型组织做最有价值的人做最小可行性产品 |
|
