1. 如何才能写出好的产品文档
一般来说,产品文档分为产品需求文档和产品使用文档两种。产品需求文档主要面向的是产品的开发、设计者,期望是产品的实际开发人员了解产品的细节,让开发完成的产品达到前期设计需求的预期;产品使用文档面向的主要是使用者,使其通过产品文档掌握产品的功能使用,也就是我们常说的产品使用帮助;如果不搞清楚文档面向的对象,往往写出来达不到预想的效果。类似这样专业的文档文案,其实是有一定共通性的;掌握这类文案的写作技巧,尤其对我们IT从业人员来说,是一项非常不错的技能。笔者从业这两年,跟此类文档打过不少交道,在这里跟各位分享一些经验。
1、对象要清楚
开篇就提到了,清楚文档面向的对象的重要性。对于不同的对象,必须使用不同的写作思路来对待,尽可能的站在对方的角度去思考。他需要看到什么?什么内容对他有用?我如何阐述给他?对于产品设计人员,他所需要了解的是产品的样式、界面、交互等情况,对于实际编码人员,他则偏重于产品的可实现性,你的内容则需要偏注产品的功能细节和内部处理。所以,文档面向的对象决定了文档的功能和内容。确定文档面向的对象才能做到有的放矢。
2、条理要清晰
文档的条理清晰不仅让你的文档看起来比较顺畅,更让阅读者能够很清楚的理解。所以,下笔之前就应当知道自己的文档内容大致分为哪几个大的模块、模块下又细分了多少个子模块,然后在大纲的基础上,再进行详细的内容填充。笔者之前的经验,往往在文档下笔之前认真思考了好几天,总希望在下笔之前就希望把所有的问题都想清楚。这对于写作者来说,是一件不好的举动。其实,东西在脑子里转悠,不如在纸上来的直观。大纲列出来之后,然后再来反复的添加、修改,比你按笔不动要来的有效率得多。对于写作来说,最难的也是开始。
3、逻辑要严谨
产品类的文档不同于平常我们书写的文档类型。对于内容叙述的严谨性要求非常严格。因为你的文档不单单是一个你对这个项目、产品的理解,它更是需要做为一个协作的载体让其他的同事同时使用,更可能成为其他同事工作方向的指引。因此,严谨是必须的。所以,在满足了文档条理清楚的前提下,仔细斟酌、思考文档可能会出现歧义、漏缺的部分,反复修改文档成为了一项必须的工作。在大家协调工作的背景下,你一个人不可能将所有的问题都考虑清楚。所以往往出现同事指出你文档中存在的毛病和漏洞。但是你还是应当在前期多做一些考虑,将问题尽量减少。
4、用词要专业
专业的用词不当可以帮助你提升文档的专业度,更可以帮助你提升效率,减少重复和不必要的沟通成本。既然是行业那就需要行业标准,使用专业的行业术语是一种职业化的表现,这样既可以很快和同事达成共识,又让别人觉得你很专业。我想,同事之前这样的协作才是有效率的。当然,对于新手来说,如何掌握专业的用词,这就需要平时多看多读了。多了解小众的博客,多认识一些前辈和朋友,无论是对写作还是对工作的认识,都是很有帮助的。
5、格式要规范
对于一个IT行业从业人员来讲,规范化、流程化的工作模式是非常重要的。对于需要经他人手的文档、或者需要进行存档的文档来说,格式的规范与否是一个衡量你专业化程度高低的重要衡量标准。当然,说到这个规范,你在第一次写作之前就应该了解这个规范是一个什么样的规范。是行业规范?还是公司内部的规范?这取决于你所在公司或所从事项目的情况。对于大公司,你所要做的就是找之前前辈们写过的同类文档进行拜读,了解这些规范。对于小公司或者新创的项目,之前没有过同类产品文档的情况。你所要做的就是沿用标准规范再加上项目特点,尽可能细致的书写。相信,经过你的努力的,你写的文档将会成为该类文档的案例,成为规范。
其实无论是产品需求文档(PRD)、产品策划书还是商业计划书,其实都是需要我们下功夫仔细研究的。毕竟中国互联网发展才十几年,很多细节都还不是很专业。对于一个会思考的互联网人,武装自己的头脑,丰富自己的技能才能找到更好的职业发展。
2. 手机软件测试产品文档怎么写
其实,你只要把软件的需求说明书给测试团队就可以了,不过,这个对需求说明书要求很高,所以不太看好
如果你自己写的话,主要要说明几个方面
1、所需要测试的软件功能范围,要有需要测试的功能描述,最好要有功能的操作简介
2、如果有流程的话,要说明流程的步骤
3、输入项对于填写要求,要有简要说明
4、对于性能要求的话,主要关注以下3个方面,时间特性(响应时间、传输时间等)、用户数情况(并发用户数、在线用户数等)、资源特性(服务器的CPU、内存、网络等使用情况、客户端的cpu情况、内存使用情况)
5、安全特性主要关注应用安全(包括功能性安全、权限安全等)、系统安全(软件是否存在安全后门等等类似)
6、兼容性关注不同手机的兼容性
7、易用性关注用户能否易于上手
有这几个方面,我想差不多够了,当然还有更细节的方面。
3. 产品经理应该怎么写BRD,MRD,PRD
首先你要清楚 这三个文档是用在什么地方 目标是给谁看 要达到什么目的
BRD一般是给投资人看 讲清楚定位 市场定位 产品要做成什么样 有多大的市场 有多大的盈利空间
MRD一般是给老板和董事会看 相较BRD要具体一些 讲得更细致 目标人群 产品的策略 与公司的策略怎么保持一致 也会涉及有多大的市场 讲讲产品的大概规划 (很多公司BRD和MRD是不分开写的)
PRD是给开发测试及运营的同事看 目标是让他们清楚要做成一个什么样的产品 为什么要这么做 怎么做 细节上具体怎么把握 安全性、兼容性、可用性有什么要求
按照这些需要做的 你应该就知道要写什么内容了
4. 产品设计师如何写文档
关于写文档的10点注意 1、写文档,一定要清晰明了,不在于是否写的多,在于是否真正说明了问题; 2、写文档,一定要学习竞争者的长处,可以把好的东西借鉴过来,吸取精华; 3、写文档,一定要落实到每个细节,需求都不完善,成品何来完善; 4、写文档,一定要自己多看,自己给自己找茬,把问题止步于自己; 5、写文档,一定要注意版本管理,并做好版本修订等工作。
6、写文档,一定不在拘泥于工具,在于思路;但用好工具,会使你的需求加速; 7、写文档,一定先定义流程,后定义交互原型,原型仅是需求交互的载体; 8、写文档,一定要划分好优先前后级,核心的、主要的需求先走,其它的可以缓后; 9、写文档,一定要基于可开发,不能天马行空。 (IDEA阶段可以天马行空); 10、写文档,一定要规范,目录、层级都清晰,写出来别人是要看的; 。
5. PRD怎么写
1、文件命名(编号)文件的编号很关键,因为产品迭代过程会有不同的文件版本,一般命名规则“公司名+产品名+PRD+D1.0”(以第一版为例),这7a64e59b9ee7ad9431333361326361样命名有利用版本号的迭代,如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”,如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”,当出现产品第二版时,可以命名为“公司名-产品名-PRD-D2.0”。
2、修订控制页一般有这么几项:编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序,文档版本显示的当前修改的内容是在哪个版本中出现,修订章节是具体到哪个章节哪个功能模块的修改,修订原因说明此功能修改的问题所在。
修订日期以修改当日的日期为修订日期,修改人显示修改内容模块的人,可能是当前用户也可能是其它产品人员。3、目录不建议自己去添加一个新的目录,你可以去其它的文档中拷一个过来,不考虑目录的内容,等写完PRD可以再去更新。
但建议用Mind manager来整理一下思路。4、请与以下部门讨论PRDPRD做为一个承接作用的“载体”,会与技术、运营、财务等人员的沟通,而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上,需要与相关人员确定“沟通内容”,这对于产品整体流程将是很重要的。
同时对于产品核心功能的提取也是一个重要环节。产品经理很重要的一个职能就是沟通。
例与客服中心:客服服务部,讨论的内容:预测客服成本、工作量;讨论客服如何支持;协助评估诈欺/数据窜改风险:欺诈/数据窜改风险、不正使用风险。这就是要写在与其它部门讨论PRD中的。
一个产品经理需要考虑如何与其它部门之间的沟通合作,文档很大一部分的功能是提醒你要做的工作,同时不断补充将要面临的工作。