好的产品文档不同的公司对产品文档的要求不用,差别也会很大。 在大公司,可能改一个小的功能都要经过BRD——MRD——PRD的流程,文档统一流程化;而在创业公司,可能产品文档只需要产品原型搭配上产品逻辑以及相关功能细节。 我们不能评判形式的好坏,在不同的项目使用最适合的文档形式才是最重要的。 什么是好的产品文档呢?往往不能给出一个明确的定义,我觉得只要能够顺畅推动项目前进,在产品开发和测试过程中能够大幅度减少工程师和产品经理反复沟通的文档,就是优秀的产品文档。 想达到只提供一份产品文档而完全不需要沟通,这也是不现实的,毕竟在产品的研发过程中会出现很多让我们前期想不到的细节。 “大幅度减少工程师和产品经理反复沟通”只是作为检验产品文档优劣的一个校验标准。其实,产品文档的作用就是为了高效地传递产品经理对产品功能的描述的。 基于上述的校验标准,好的产品文档应该具备以下的几个特质:
好文档背后的逻辑上面讨论了好的产品文档应该具备的特质,那么如何做才能促使一个好文档的诞生呢?这背后往往会涉及到一些逻辑,好的产品文档就是基于这些逻辑呈现出来的。 产品业务流程的逻辑产品的业务流程始终在支撑着整个产品,产品的最终交付也是要基于业务流程去实现的。 业务流程指的是实现产品所提供的功能或服务的具体流程步骤。有很多的产品都有很多的功能,用户使用这一个功能往往会涉及到很多的步骤,这背后的业务逻辑/流程是我们要梳理清晰的。 这里可以借用编程的两种维度去分析业务流程的逻辑:面向过程和面向对象。 面向过程: 面向过程是指,要完成一个功能,中间会涉及到很多的操作步骤,而在这些操作步骤中要整理出健全的操作流程,逻辑要清晰并且不要有遗漏。 比如,在电商产品中,用户要实现下单的功能,此时会涉及到的大流程包括:浏览商品——查看商品详情——加入购物车——进入结算中心——结算——产生订单,这只是涉及到的大的操作步骤,其中还会涉及到:编辑/删除购物车中的商品、商品库存的判断、优惠券的编辑/删除/状态判断、第三方支付平台的对接、第三方支付订单数据的返回、订单状态的更改等等。 在这里,我们一定要用流程图去绘制整体的流程,有必要时要加入泳道、角色等关键信息,直观地展示出在哪里要处理那些信息等关键要素。 面向对象: 产品中的对象是对具有完整生命周期的一类的描述,比如,飞机大战游戏中的飞机是一个类,敌机是一个类。一个对象的生命周期就表示一次完整功能的使用。这个对象一定是要具有生命周期的。比如订单,从生成到完成中间会有很多的状态,每一个状态都会涉及到哪些操作?哪些流程?都要用状态图或流程题来描述。 信息架构的逻辑具有复杂度的产品,清晰定义它的信息架构是十分重要的。 如果不去清晰划分其结构,使用者的分工就无法开展,相关的功能也就无法定义。 比如涉及用户端和企业端的产品,普通用户和企业用户都在产品上工作,所以必须要清晰划分产品的信息架构,提供清晰的责任分工和协作流程。 在规划产品的信息架构时,可以采用先拆解再整合的逻辑。 拆解: 拆解就是要把产品涉及到的所有功能枚举出来,拆分成相对独立的一个个模块。 比如,我之前负责的一款创客类用户和企业类用户共同使用的产品,就要针对创客用户端和企业用户端分别拆分出对应的所有功能模块。 整合: 接下来,我们就要把已经拆解好的功能予以整合。 根据不同用户端的功能,将琐碎的功能点整合到一个个的模块中去,比如个人中心模块、登录注册模块、充值模块、VIP专区模块、软件模块等。 有了整合后的信息架构,我们就对不同类型用户的产品结构一目了然了。未来如果迭代功能,就可以在相对应的模块中为功能找到对应的位置。 任何产品在处理信息架构时,都可以采用类似的“拆解——整合”的方法,为产品整理出对应的模块划分。 产品功能的逻辑对于产品的功能逻辑,我们在描述一个功能点的方案时,有时无论多么谨慎也会出现有遗漏的地方。所以,我们在描述产品的一个功能点的方案时,一定要捋清逻辑,把涉及到的所有情况/内容都要有条理且完整的描述清楚。 比如,我在之前负责的一款项目中,会涉及到管理员端变更用户端数据后显示的情况,而且会涉及不同的显示类型,我采用的就是用表格的形式澄清所有的情况: 采用这种方法,对于研发人员来说,这就是具体的、清晰的。针对不同的类型,不同的情况去处理就好了。 在进行产品功能的描述时,可以从以下几方面去实施:
最后产品的文档没有统一的模板标准,公司里能提供既有的模板固然是好的,可以有助于公司的文档管理。 如果没有模板,用一页原型 逻辑描述能清晰说明功能也是可以的。最重要的还是团队之间的协作方式,文档的终极作用还是要能够大幅度减少工程师和产品经理的反复沟通,增强彼此的工作效率。 #专栏作家#流年,人人都是产品经理专栏作家。互联网产品设计师,4年互联网产品设计经验。擅长用户体验设计,喜欢钻研需求功能背后的技术实现方式;在成为综合型产品设计师的道路上不断努力前进! |
|