产品文档发布规范

2021-08-03 by uino 27 规范 文档 产品

1.概述

产品文档是指与技术性产品、软件或服务有关且伴随其全部生命周期的所有技术信息的传递和交互。技术传播涉及的内容及表现形式包括各类产品使用说明、技术资料、宣传资料、信息查询解读等。这些不仅是产品和服务不可或缺的技术说明文件,也是体现生产者的技术能力和服务水平的市场名片。 为了避免输出低劣的文档交付件,从而严重伤害企业的品牌形象。需要规划一套完整、合规、精准、高效方便的产品文档,来帮助实施伙伴更快的上手产品,用户更高效的理解产品。

2.发布的内容

根据优锘科技历史的文档发布规则,以及优锘科技产品的特点,总结规划出一套产品文档发布的内容(框架),详见下图: image.png 随版发布的文档分为四大类:研发、售前、售中以及售后(实施&交付)。

2.1.研发

研发资料主要分两大块,一块是开发配套资料,包含需求报告\方案、立项报告、产品设计文档、发布/升级公告以及产品功能清单;一块是测试配套资料,包含测试方案、测试用例以及测试报告。交付件输出形式有Word、Pdf、Excel等,主要责任人为产品经理、研发组长、测试负责人。

2.1.1.开发配套资料

2.1.1.1.需求PRD

需求PRD:

  • 设计人员进行产品设计的输入源;
  • 开发人员对产品功能开发的依据;
  • 测试人员编写测试计划、案例的输入源;
  • 产品经理检查产品实现程度的依据;
  • 项目团队外人员进行沟通的外部接口,用于他们评审和理解系统;
  • 产品初验和终验的参考; 需求报告\方案的输出格式一般为Word或者Pdf格式,编写责任人为产品经理。 立项报告

2.1.1.2.立项报告

立项报告决定项目的开端,先是介绍项目概况背景需求等,然后确定拟建项目进程计划、项目预期目标、人员资源的分配等,输出格式一般为Word或者Pdf格式,编写责任人为PO。

2.1.1.3.产品设计文档

“产品设计文档”是项目立项后,开发人员把需求分析得到的转换为软件结构和数据结构等,指导整个开发的方向和重点,输出格式一般为Word或者Pdf格式,编写责任人为研发组长。

2.1.1.4.发布\升级公告

“发布\升级公告”是项目经理提交发布申请后由专家评审(产品/开发/测试/架构/技术总监)审批后发布的公告,说明所发布/升级内容、时间的文件。“发布\升级公告”的输出格式为Word,编写责任人为PO。

2.1.1.5.产品功能清单

“产品功能清单”详细的罗列此次发版产品的功能,包括功能点以及相应的功能描述,输出格式为Excel,编写责任人为产品经理。

2.1.2.测试配套资料

2.1.2.1.测试方案

“测试方案”描述需要测试版本产品的特性,测试的方法,测试环境的规划,测试工具的设计和选择,测试用例的设计方法,测试代码的设计方案,从技术角度进行规划测试计划和控制测试进度。 测试方案的输出格式为Word,编写责任人为测试负责人。

2.1.2.2.测试用例

测试用例”是对进行测试任务的描述,体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,最终形成文档。测试用例的输出格式为Excel,编写责任人为测试负责人。

2.1.2.3.测试报告

测试报告是对整个测试过程的总结,一般包含:测试结论、测试环境、测试范围、用例执行情况、严重缺陷、遗留情况等,测试报告的输出格式为Word,编写责任人为测试负责人。

2.2.售前

售前资料包括技术白皮书、技术方案/产品方案、产品介绍以及产品单页\彩页。交付件输出形式有Word、Pdf、JPG等,主要责任人为项目的产品经理、文档工程师。

2.2.1.技术白皮书

“技术白皮书”属于“技术营销”的文件,适合客户方的CTO、技术总监、技术专家之类的高层决策人士阅读,让他们通过“大局观”的方式了解整个技术概况。技术白皮书的重点在于让客户深刻理解采用此技术将为他们带来多大的利益。 技术白皮书的输出格式为JPG形式的彩页,也可以是Pdf格式,编写责任人为产品经理,文档工程师协助。

2.2.2.技术方案\产品方案

“技术方案\产品方案”是明确产品方案和市场需求状况,确定拟建项目的产品技术及功能:

  • 为什么要做:产品提案、提案目标,商业价值等;
  • 什么时候做:项目时机,为什么现在做;
  • 怎么去做:核心功能点,产品架构图,进度计划,产品路线图等;
  • 用户描述:目标用户群,目标用户特征,需求痛处,使用动机,场景,频率;
  • 市场描述:市场规模估计,竞争对手分析,SWOT分析(优势、劣势、机会和威胁);
  • 需求描述:功能与非功能。 “技术方案\产品方案”的输出格式一般为Word格式文本,编写责任人为产品经理,项目经理、文档工程师协助。

2.2.3.产品介绍配套文档

产品介绍配套文档,辅助售前人员更好的去介绍和展现产品,主要包含产品介绍、产品单页\彩页、标准功能清单、项目成功案例。

2.2.3.1.产品介绍

产品介绍,即从公司层面介绍产品的主要实现技术及功能,产品介绍的输出格式为PPT或者Word,编写责任人为产品经理、文档工程师。

2.2.3.2.产品单页\彩页

产品单页\彩页是一种用图文结合的方式,最直观的一种对外展示产品的途径,产品单页\彩页的输出格式一般为JPG或者Pdf格式,编写责任人为产品经理理、文档工程师。

2.2.3.3.标准功能清单

“标准功能清单”罗列产品的标准功能模块以及相应的功能描述,输出格式一般为Excel格式,编写责任人为产品经理。

2.2.3.4.项目成功案例

“项目成功案例”介绍此产品已实施的成功案例,输出格式一般为Word或者PPT格式,编写责任人为产品经理。

2.3.售中

2.3.1.公开报价工具

报价工具是销售人员对产品报价的一个参考,也是让客户明白产品的型号价格,便于购买。报价工具的输出格式为Excel,为统一模板输出。

2.3.2.产品演示脚本/视频

将客户重点关注的功能的通过创建若干简单的演示步骤生成一个可用于交互演示汇报的演示脚本\视频,演示脚本的输出格式为Word或者Mp4格式,编写的责任人为产品经理。

2.3.3.投标技术要求

“投标技术要求”标准化的列出产品的技术要求,包含总体要求、平台要求、功能要求以及商务要求等,用于销售人员后期类似项目应标的技术性参考。“投标技术要求”输出格式为Word,编写责任人为项目经理。

2.3.4.调研问卷表

“调研问卷表”好似为了更好的收集项目需求信息,作为给出最终实施评估的标准。交付书为统一模板输出。

2.4.售后

售后资料主要分两大块,一块是实施运维配套资料,包含工作范围说明书、产品操作手册、实施指导手册、产品培训PPT&录像以及常见问题FAQ;一块是交付验收配套资料,包含交付书和验收报告等。交付件输出形式有Word、Pdf、PPT、Mp4等,主要责任人为项目的文档工程师。

2.4.1.实施运维配套资料

2.4.1.1.工作范围说明书

是一个技术指导性文件,用于说明我司该产品在某项目中所需完成的工作范围和职责。编写责任人为文档工程师,输出格式为Word。

2.4.1.2.产品操作手册

产品的操作手册要包含版本功能操作使用说明,可视情况分详细操作手册和快速操作指南。输出格式为Word或者Pdf,编写责任人为文档工程师。

2.4.1.3.实施指导手册

“实施指导手册”是截至正式使用前的所有安装、部署、调测等操作步骤指导,完成后用户即可正常使用操作。可视产品特性按照实施步骤具体细分为多个精细化短篇幅实施分类文档。输出格式为Word或者Pdf,编写责任人为文档工程师。

2.4.1.4.产品培训(PPT\录像)

将产品的大致介绍、标准操作形成图文或者视频来给客户作为培训参考:输出格式有Word、PPT、视频等格式,编写责任人为文档工程师。

2.4.1.5.常见问题FAQ

“常见问题FAQ”是指针对此次随版发布的产品在实施、操作使用、销售过程中可能遇到的问题,提出解答和解决办法的一种帮助文档。设计的问题和解答都必须是客户经常问到和遇到的。为保证FAQ的有效性,首先要经常更新问题,回答客户提出的一些热点问题;其次是问题要短小精悍,对于提问频率高的常见的简单问题,不宜用很长的文本文件,而对于一些重要问题应在保证精准的前提下尽可能简短。 “常见问题FAQ”输出格式为Word,编写责任人为文档工程师。

2.4.2.交付验收配套资料

2.4.2.1.交付书

交付书为统一模板输出。

2.4.2.2.验收报告

验收报告为统一模板输出。

3.文档的开发过程

image.png

3.1.需求了解阶段

文档的需求了解阶段,即与项目的需求、开发阶段重合。待项目立项时,项目经理、产品经理以及文档工程师根据此次待发布产品的特性与共性,确认好此次随版发布的文档需要包含哪些,并根据开发的计划来设定文档开发的计划,确定好每一步交付件输出的时间点。 过程参与人:产品经理、开发负责人、测试负责人、文档工程师。

3.2.文档开发阶段

文档的开发阶段,随版本转测开始起。根据各个阶段需要输出的交付件,责任在计划内完成文档的编写。 过程参与人:产品经理、测试负责人、文档工程师。

3.3.文档评审阶段

初始的文档完成后,需要一个review的过程,此过程检验文档完成的准确度,以更好的完善随版发布的文档,review的过程中也能更深层次的理解产品,了解此版的缺陷及下版发布的建议。 由文档工程师发起评审,根据不同阶段输出件,评审的轮次可视实际情况,一般要经过至少两轮的评审。 评审的流程如下图: image.png 每一轮的评审结束后,由文档工程师总结,并督促各阶段交付件的责任人进行修改优化。

3.4.文档的发布

经过评审、修改、再评审、再修改等过程后,由文档工程师发起,协同产品经理、项目经理等,确定随版发布文档的最终版。

4.文档的发布

产品文档的发布随版本一起发布,个别销售类的交付件可视情况延迟。发布后统一上传优锘网盘,保存在相应版本下的链接。

5.发布后的维护

文档一经发布,除“常见问题FAQ”可以进行有效的更新,其他文档原则上不得修改。项目经理、产品经理、销售经理等还确定各阶段交付文档的可读权限,明确好哪些文档可以由哪些人查看。

6. 附件

6.1.产品文档框架

见链接:产品文档发布框架

6.2.文档编号命名规范

image.png

  • 产品文档大类:01研发类,02售前类,03售中类,04售后类。
  • 产品文档交付件序号:按照产品文档的框架中大类里按顺序由1开始编下去。
  • 产品名称:例如IBV、DCV等。
  • 产品文档交付件名称:是该文档具体内容名称,例如需求分析报告,用户操作手册等。

6.3.文档版本规范

产品文档的发布版本,体现在文档的封面,和第一页的文档说明中: image.png image.png 从新建开始,随第一次版本发布以V1.0开始,后根据版本发布如文档有修改,则以V1.1,V1.2...往后编,并随产品版本一起发布。

6.4.产品文档评审报告

见链接:产品文档评审报告

6.5.产品文档格式样板(Word)

见链接:产品文档格式样板