AAA教育

产品团队，通常会输出一套经过确认的全家桶，内含：

一份《交互原型稿》（可迭代），

一份《产品需求说明文档》（PRD，可迭代），

一份《功能开发清单列表》。

研发人员通过这些文档，就能够很清晰的了解产品的从宏观到细节。

一份好的产品需求文档，能够让产品人员全面的从整体到细节的，再次梳理和确认产品的重要步骤；

也能够让研发人员非常清楚的了解，项目的背景、预期、以及产品的细节，尽可能全面的把产品各方面实现的，可能存在的问题都列举做出说明，提高开发效率，节省不必要的频繁沟通。

刚开始做产品时，我总是以为只要原型一画，和大家开个会一说，然后研发们就开始搞起吧。结果你会发现，这之后你每天都陷入各种答疑解惑的忙碌之中（临时召集研发开会做说明，指望他们能在两三个小时里把所有细节都记住？别做梦了）。

有些开发也不好意思频繁的找你，就直接按照自己的思路做了，然后你就坐等验收的时候各种吐槽，提bug打回修改。

时间花了，还没达到你想要的效果，你不开心，开发也不开心。何不想想该如何解决呢？这时候，PRD文档的重要性就显现出来了。

PRD文档

文档的基本格式我在这就不描述了，网上一搜一大片，两点我重点说下：

一、文档具备可迭代性

铁打的文档流水的兵，一个好的需求文档就像一锅好卤，是越熬越香。

不论谁来接手正在进行中的项目，都能够一目了然的知道项目的前因后果：什么背景啊，每次调整都是为啥啊，哪个产品什么时间主导的啊……就像一份更新日志，记录着项目需求变更的每一次变化。

二、文档说明要尽可能的细致

产品模块以及细节介绍的部分，需要根据已有的原型稿有图有字的做出说明。文字部分主要针对某个模块或者界面详细的做出标注和说明。

如果描述性文字不足以理解，这里需要举几个例子给研发做出形象化的解释。

 

举一个我自己经历的反面例子：

当年刚到携程做产品，一心以原型为大。仿佛只要原型搞定了就没啥事了，结果导致立项会上产品由于严重缺乏全面思考，漏洞百出，没有通过。

这段经历给故作聪明的自己当头一棒，经过和同事的交流，我发现自己在产品的细节打磨和思考上没有不足够的深入。对于不熟悉的新业务：

流程上有没有明显的逻辑性错误？

每个界面的数据哪里来？什么接口获取？

接口有没有通？是否能够拿到产品所需的数据？

规则性限制是否已经考虑全面？…

这些基础工作是你在编写PRD文档之后第一个要去一一验证的事情，如果顺利才可以按照这个确认的需求下发开发。

另外说一点，要考虑到从客服、市场、运营等岗位角度对产品进行解释，以及他们在这个产品中需要注意的一些要求。（使用方和服务方都要全面考虑）

 

最后，文档毕竟是文档，虽然做到了迭代，但在实际工作中还是会出现各种难以理解的部分。这个时候就需要产品们及时和研发当面做出沟通和说明工作，积极推进产品研发进度。