关于PRD撰写的一些见解与认知

以公司的现状,结合自身的一些理解,所撰写的相关见解和认知……

1. 我们需要什么样的PRD?

为什么需要写PRD这个东西,关于这个问题先看看知乎上高赞回答:

“在稍微大一点的开发团队中,产品经理未必能向所有开发人员,传达具体的产品开发需求。这时就需要一份文档来供所有的项目参与人员阅读。而产品经理又常常爱拍脑袋、容易变卦,所以文档也是开发人员约束产品经理的一项武器。在产品上线前的测试环节,测试人员也同样会拿产品需求文档来验收产品质量。当团队进入新人时,文档也可以让新人更快地了解产品”——知乎@甄龙。

从上述文字中我们可以知道,PRD针对“大的开发团队”,产品经理不能向所有开发人员传达产品开发的需求的时候,需要提供PRD,以便让开发人员了解并熟悉相关的业务场景。同时产品经理经常会对需求,原型,或者是流程图进行修改,那么就需要用一个东西来记录约束产品。还有一个作用是为了方便后续测试人员介入,然后可以根据文档熟悉业务同时进行验收。

根据上述的分析,结合目前WS(荣昇)的实际情况,我对PRD的撰写有以下一些分析:

  • 首先,WS的产品以项目组划分,每个项目组开发人员大概是4-6个,测试人员1-2个,产品1-2个,还有其他相关人员部分。由此可见,如果以项目组来划分的话,WS是属于小规模合作的开发团队,适用于「敏捷开发」流程,同时也意味着,对于文档或者说PRD来说,不需要太细,也不需要太繁琐,产品评审的时候可以所有相关人员都到齐,应该以效率为主,让开发有更加充分的时间进行开发,让产品有更多的时间进行业务的梳理和迭代的优化。

  • 其次,WS的产品属于B端产品,以稳定和效率优先,对UI和一些体验上的优化看得不太重,由此可见:更多的时间花在流程的优化和业务的梳理才是重中之重。也就是针对大多数的产品,要更加注重流程图和思维导图的分析,这部分会随着业务的变化而变化,也就是说这部分是拥有很多不确定性,变化较多的部分。而PRD更多的是文字的描述,显然就不太适合于对流程图和导图进行版本变化的追踪。

  • 最后,测试人员需要对产品进行测试,那么当他参与了产品评审和开发评审的时候,已经对相关的流程和一些业务有了了解,在PRD撰写的时候,对一些细节的测试就不需要写的太细,对业务逻辑和流程的东西也是在流程图上体现,而不是看重PRD的文字描述。

综上所述,目前适合WS的PRD需要的东西,应该是和市面上或者主流使用的PRD是有一些出入的,我们需要适合自己的PRD而不是正确的PRD。以下是我对适合WS的PRD所拥有的内容的一些理解和认知。

2. WS的PRD应该包含什么?

  • 完善的流程图

  • 随时沟通和优化的原型

  • 关键部分的逻辑说明和拓展

  • 异常流程的说明(极值或者异常情况)

  • 验收的标准和开发目的

  • 其他锦上添花且重要的东西

完善的流程图

完善的流程图是重中之重,它可能不太会体现在PRD中,但是我希望我们的PRD能提及他,因为流程图是在理想状态下对业务的梳理,如果理想状态都不能走通,那么这样的产品做出来肯定是问题很多,阻碍很多。流程图可以从Visio中截图贴到PRD中,也可以纯文字的描述,然后让相关人员去看流程图,最好是能达到,看流程图和描述就已经对项目有了初步的了解。

随时沟通和优化的原型

原型是在流程图之上,对产品进行实例化和丰富化的一个产物,对于原型来说要体现的可以粗也可以细致,但是根据之前总结的结论,适合WS的原型应该是简介轻便,随时可以沟通的东西。原型可以画的很精细,可以面面俱到,也可以粗糙,轻便,敏捷。但是我不希望让产品花太多的时间在PRD上去写“某某某输入框需要用什么字符类型,需要什么前置条件”,“时间的格式是2018-06-21这样还是2018年6月21日”诸如此类的,这些细节的UI上或者是操作交互体验上的东西,应该在原型上提示,例如给出示例,用标签标注的方式告诉开发和测试,这个地方需要用什么前置条件或者什么格式。总之,确保PRD只是赘述关键信息,非关键信息请在原型上进行标注,或者线下直接沟通,然后测试的时候自己参与这部分的测试。

关键部分的逻辑说明和拓展

这部分是原型中最重要的部分,也是最核心的部分。对于这个产品或者这次迭代来说,更改了哪些,它的逻辑是怎么样的,改完之后是怎么样的,我希望产品是以讲故事的一种方式娓娓道来,告诉开发或者是测试或者是其他人员,这次改动这个地方怎么变化了,有哪些不一样的东西。具体的格式要求可以根据实际的情况进行调整,这部分没有模板或者是标准,但是目的只有一个:让读者可以轻松的了解到这个产品有什么改动和优化。同时还需要标注清楚,哪些地方是具有拓展性的,后期可能这个地方需要做XX,那么数据格式需要注意XX,不能写死某些东西XX。关键部分可能有很多,但是为了控制篇幅和内容,建议以图文的形式来介绍这部分,俗话说,一图胜千言。这个时候就可以加上部分用例描述和用例图啦,注意要精简。

异常流程的说明(极值或者异常情况)

这种情况是产品中最常见的,也是关乎产品体验最重要的部分,因为正常的流程大家经常见,体验是很顺畅的。而异常流程和一些极值情况下的情况,是会打断用户体验,也会让用户感觉不舒服的地方,任何一次的迭代和设计,都需要把异常流程看得和正常流程一样的重要,同时在设计原型的时候或者是撰写PRD的时候,一定要加上这部分的描述。例如:当报错的时候,提示的语句是什么?当页面空白的时候,要给用户展示什么?当数值超过XX时,这个时候要怎么引导用户走到正常的流程。这部分需要在PRD中突出展示,同时也需要让测试人员重点关注的地方,也可以自己加粗或者标红,点名让测试注意这个地方。

验收的标准和开发目的

验收标准主要是为测试看的,当然开发也可以根据这个部分知道自己的目标是什么,测试人员可以根据你给出的验收标准进行测试,所以验收标准可以写的细致一点,而不是简单的说,可以完成xxx没问题,可以xxx完成任务。而是应该描述为:当处于xxx极值的时候,可以让用户回到正常流程;或者是当输入有误的时候,可以提示xxx;当条件不满足的时候,不可以进行xxx操作……

开发目的是启动项目的动力,同时也是一个引航点。当开发或者业务陷入困境的时候,我们要理解,此次开发的目的是什么,我们要解决的是什么问题,尽量避免陷入无止境的思考和担忧,而陷入一些不必要的漩涡之中。明确目的,明确此次迭代的要求和要达到的任务即可。

其他锦上添花且重要的东西

这部分放在最后说并不是说它不重要,以上提到的东西都是重要的,最后提这个东西是因为这个东西是最好规范和确认的,只要有模板,一切以这个为主即可。那么这些锦上添花的东西有哪些呢?

  • 开发背景、用户、使用场景、适用范围

对于大迭代可以写的详细和充分,对于小迭代,可以简单描述,因为有些内容是固定不变的,例如用户,使用场景等。同时也可以说清楚背景是什么,开发的目的是什么。

  • 版本说明,迭代日志,修改日志

关于版本的说明,迭代的日志等,其实是一个挺难搞的东西,因为很多修改都要追踪的话,那么多文档看起来就会花花绿绿的,但是还是建议关键修改和迭代需要进行标注,同时让所有人确认,当确认之后可以单独生成一份文件保存,例如取名:xxxPRD v1.3版,然后也同时保留v1.2版本不删除。

  • 后期迭代优化等

目前WS的系统还没有设计到数据埋点,运营优化的阶段,所以可以把这部分的注意力放在迭代优化上,当本次迭代已经进行中的时候,有一些内容不方便加在本次迭代中,那么就把这个东西写在PRD上,当然EXCEL也要记录,方便后续迭代的时候进行自检和对比。

3. PRD的格式及目录大纲

见下图所示:

image_1cmf24r8hroupi3oas6da17elp.png-13kB

具体撰写模板还未制定,以上还有遗漏或者需要完善的地方还需要再次制定,感谢阅读和指导!

--本文到此结束感谢您的阅读--
随缘打赏,佛系产品
0%