文章主要围绕如何制作一份可读性高的产品说明书展开，与大家分享，希望能够给大家的工作带来启发。

新入职产品经理助理的同学，或者是需求人员面对的第一个问题可能不是市场分析、竞品分析、原型设计、产品体验、也不是复杂的业务逻辑，而是把公司的产品文档通通读一遍，从而熟悉公司的整个业务流程，了解公司的整个产品线，然而事实是残酷的，很多同学在第一步就被前辈们坑了，脸上露出大写的懵B。

很多公司由于开发进度紧，加上产品管理不规范，在开发一个新的产品或者是功能的时候没能很好的管理和规范文档，从而导致新来的同学面对一大堆杂乱文字也无从下手。那么究竟怎么维护一份可读性高的产品说明书呢？

最初进行传统的软件开发，我们都要撰写软件需求说明书，那时候需求说明书特别重要，因为那时候还没有原型工具，所有的信息都要开发人员通过阅读需求说明书来进行编程。好处是大家会认真的对待和迭代文档。每一个细节，每一处逻辑都会以用例图，流程图，活动图，协作图，顺序图详细的进行说明。缺点是那时候还没有提出敏捷开发的概念，从而导致开发一个大规模的项目需要较多的精力进行维护文档，而且这个周期特别长，有点繁琐。而现在我们有大量的工具和文档工具进行原型以及产品的输出，最终的目的也只有一个，让开发人员快速的，更加清楚的理解产品的逻辑和原型设计。下面我们以一个生活小例子来说明。

大家都知道我们做产品通常是解决了用户在某一个场景下的痛点。帮助用户解决问题，或者实现价值。打个比方，现在小明下班回家了，但是到了家门口突然发现钥匙不见了，进不了家门。这时候我们作为产品人员应该怎么办？小红遇到这样的情况傻了眼，马上求助于小明如何开门，小明由于拥有多年的产品经验，并且是个动手能力非常强的人，面对小红的慌张并没有打乱他的阵脚，小明开始思考起来。

1. 是谁提出的需求？（小红提出来的，她是我的女朋友，她的问题就是我的问题，必须解决）
2. 在什么样的地方会出现这样的需求？（钥匙忘在公司，钥匙被偷，钥匙掉在路上）
3. 发生问题的描述（钥匙找不到了导致我开不了家里的门）
4. 为什么会出现这样的问题（粗心大意，可能是钥匙被偷窃了）
5. 需求是否重要紧急？（回不了家当然非常紧急）
6. 一次性需求还是需要持续的跟进（只要能让我回家，家里有备用钥匙，下次注意钥匙安全）
7. 需要哪些支持(钥匙店？门锁商？开锁匠？警察？铁棍撬开？梯子爬窗？消防队天梯。)

第一步  提出问题，分辨真伪需求（需求概要说明）

那我们从上可以知道小明思考这么7个问题无非是想确定小红真的遇到了大问题，遇到的问题是什么样的，这个问题会导致什么后果。这个问题是否需必须马上解决。需要什么资源进行配合。在任何情况下回答清楚这7个问题都有助于帮助我们理清楚现在的境况，从而更好的解决问题。

第二步  提出解决办法（业务流程说明：逻辑整理，提出业务解决办法。）

既然这个问题现在已经清楚是个非常重要的需求了，那么我们应该怎么解决它呢？

1. 把门砸开。
2. 去配一把钥匙。
3. 打车回公司看是否落在公司。
4. 叫开锁师傅来开锁
5. 楼层低的话梯子爬进去。
6. 自己制作一把钥匙。

综合考虑实际情况小明是个动手能力非常强的人，小明决定用第六种方案自己制作一把钥匙来解决这个问题。（假设小明有这个手艺哦，哈哈）。因为考虑到其他方案可能都是不最好的解决方案，因为砸门可能会引起更大的损失导致门的损坏，因小失大，而且成本不太划算，其他解决方案也不是太让人满意。解决方法，把每条业务方案详细说明后，梳理出最可行的业务流程解决方案，那么就可以确定我们制作的产品每个场景需要有什么功能了。

第三步  把可行性业务流程用例化（业务流抽象成用例）

这步需要我们去明确用例。

第四步  把业务用例功能化（产品功能概要：把各个场景下的业务用例功能化）

为了简单的说明，下面举的都是简单的用例：

1. 为了保证我们的钥匙能以后能打开门，我们必须要造出一把万能钥匙。如果等下自己的门都开不了那就尴尬了，所以我们这里提出要有开自己家锁的功能，但是小明艺高人胆大，能造出万能钥匙（核心功能。
2. 为了钥匙不会再掉，我们有报警模块。模块可以和手机蓝牙绑定，钥匙离开手机一定距离报警（钥匙和手机通常是不会有很大距离的，一个人外出时钥匙和手机通常是配对携带，做功能时一定要考虑到场景）。
3. 钥匙必须绑定到皮带上，不脱裤子解不下来，除非不穿裤子。（钥匙没了，我还要裤子干嘛？裸奔算了，产品要有自己的特点，差异化。虽然挺弱智的 ，但是也是差异化解决方案）。

第五步 功能流程化（流程图：利用流程图把各个功能点串联起来）

以上的功能是最粗粒度的功能，我们可能在实际过程中需要去不断细化功能粒度，不断的去优化调整流程图，在这一步我建议对每个功能进行顺序图，流程图，协作图，活动图，状态图的绘制，尽可能全的描述出各个功能模块是如何串联起来工作的。

第六步 流程产品化，且建立产品地图（设计原型：把功能在原型上体现出来）

上图就是原型图，虽然丑了点，但是产品经理的核心在于理清功能逻辑，后面还有UI，UE的工作呢，这里请忽略美。在这里我们必须对原型上的每个关键元素进行描述（钥匙孔，蓝牙模块，核心机关）我们必须在原型上给以注释。帮助其他人理解产品原型上的元素。

蓝牙模块由于和手机上存在联系，那么还需要对蓝牙模块进行说明从而制作我们说的产品地图。下图就是点击蓝牙模块颜色按钮产品的各个界面状态的展示。在我们做网站中我们需要对各个重要按钮的跳转做一个产品地图，帮助我们更好的理解逻辑。

第七步 产品地图元素化（页面元素的详细说明）

到了这个阶段，产品的原型以及产品各个状态之间的切换，页面之间的跳转逻辑关系已经很清晰了，但是对于开发人员来说，他们需要不仅仅对逻辑结构徐璈非常清楚，而且需要对每一处细节都需要把控，这样的情况下，我们需要去把产品各个页面也就是产品地图上的元素进行描述，这样会更加清楚的帮助程序员去定义字段，以及字段规则，字段之间的联系。这个层面是我们原型设计的最后一步，一个半成品差不多就在这里诞生了。

PRD和产品原型设计到这里可以说是完成了最基本的撰写。至于这之后的内容怎么去完成，以及如何提升产品UI，UE我将会再下一篇文章告诉大家，这篇文章虽然没有告诉大家具体的文档目录，但是我已经大概的告诉大家应该以什么样的方式去引导自己的思路去形成自己的产品说明书，谢谢大家支持。

本文由 @Pm_cosmo 原创发布于人人都是产品经理。未经许可，禁止转载。