综述
产品开发说明书可以有多种形式，如Word、Axure、PPT等等。一般PPT格式较适用于在企业产品评审会议上进行演示和评审。产品开发说明书体现了产品负责人对产品开发内容的深刻把握，必须有着严格的逻辑性，能够一阵见血地指出主要问题，同时给出解决问题的具体方案和实现路径。同时作为企业内部评审文件又必须言简意骇，干净有力，突出重点，避免冗长繁杂内容增加沟通理解成本。
一份产品开发说明书一般分为以下几个部分：问题、原因、解决方案、产品架构说明、产品开发路线、产品原型预览、需要协调说明。
1.问题产品经理是解决问题的职位，产品开发是基于问题所引起的需求而来的。一个企业面对的问题往往纷繁复杂，每个部门或管理层都能在自己的位置上提出各种问题，同时也制造各种问题。作为产品经理必须透过现象看到本质，抓住主要矛盾和当前最大的瓶颈并予以最优先解决。
实际案例中，之前企业各个部门提出过各种功能要求，但由于目前企业所做的一部分数据和操作并没有在系统中完成，数据未在系统沉淀，导致所提的功能需求都成为无缘之木。所以当前最关键的问题是实现所有数据线上化。
2.原因
凡问题的产生总有其原因，了解问题的原因有助于明白问题的本质，从而在产品开发目标上达成一致，更好解决问题。需要注意的是，在讲述问题时尽量避免“公司某个部门不配合或操作不当”等等说法，避免将产品开发评审会开成问题的追责会议。
实际案例中，为什么没有实现所有数据线上化是因为业务开展比产品上线更先行，导致用户养成了用户习惯。且之前产品开发的主要精力是业务功能开发，对于数据线上化这一块没有在前期完成。
3.解决方案
针对关键问题的解决方案，也是产品说明书的重点内容。如何运用各种技术和工具，出具完善的解决方案，并开发新的产品或新的功能模块来解决问题体现了公司产品部门的核心能力。由于产品开发的原则是快速上线，更新迭代。先满足可用性，再迭代升级用户体验。所以解决方案一般要分阶段进行，每个阶段都有每个阶段的产品目标并具有业务可用性。
实际案例中，解决方案第一阶段实现审批流程和数据录入校验流程的完全线上化，这时具备业务可用性。第二阶段完成历史数据迁移及以后线下出单数据线上化方案，分别解决历史数据问题和以后可能新产生的线下数据问题。第三阶段再建立数据监控和数据模型开发。
4.产品架构
产品必须围绕着公司战略，并在确定的范围内进行开发。关于战略层和范围层的概念和重要性在此不展开阐述，但作为产品开发必须谨记这一点，这样可以避免企业发展失去方向或者在不重要的方向上投入过多资源。对新产品或新功能在企业的产品架构中所处的位置，以及后续的产品规划开发进行说明，能使参与产品评审会的人员明确此次产品开发在战略层上的意义，并取得各部门一致的认同。
实际案例中，目前企业的战略是保险行业助贷产品的研发。通过对产品架构的讲解，产品评审会上的人员都明确了此次产品开发对于企业战略的意义。（部分信息打码处理）
5.产品开发路线
产品架构从战略层高度描述了此次产品开发的意义，产品开发路线则给出了具体落地和实现的时间表。
注意这个时间表必须与技术部门经过多次沟通才能在评审会上给出，避免出现最终技术实现时间远远超出产品开发路线的情形。
另外，近期业务上较重要的其他产品开发需求，与此次解决方案所列出的开发路线有冲突的必须提前说明。这样其他部门业务人员在具体业务安排上可以做好准备，尽量避免产品开发一半的时候被其他开发需求打断的情形出现。
实际案例中给出了解决方案中三个阶段产品开发所需要的时间表。由于企业近期有开展佣金垫资业务的需求，所有佣金垫资也急需开发，在评审会上就几个产品开发做了说明和探讨。
6.产品原型预览
不管是文字还是语言的描述，总没有具体的图片或者原型更为形象。对于产品完成后的原型或者demo，最好能在产品开发说明时就进行展示。一方面企业其他部门对于最终达成的效果有个初步印象，方便开展业务时向客户说明。另一方面对于企业其他部门提出的意见可以进行记录，并在出具PRD文档时进行修正。
实际案例中给出了两个产品原型预览供在评审会上进行展示。
7.需要的协调和协助
最后，产品开发不仅仅是产品部门的事情。企业其他部门在产品开发的各个阶段的积极参与，对于产品最终成型和效果是大有裨益的。产品开发说明中需要其他部门进行协调和协助的地方也可以在开发规划中进行说明。
实际案例中，对希望市场部和风控部协助的地方进行了必要的说明。
结语：
以上是关于产品开发说明书的内容。笔者主要从事互联网金融产品设计，欢迎同行交流探讨。
作者：懒洋洋，微信公众号：pmyang
本文由@懒洋洋原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
