小团队的详细产品需求文档(PRD)是否是必须?

[dangerbox title=”问题引子”]但是在一个小团队(10人以下),尤其是一个做微信小程序的小团队。大多数的需求点小而杂乱,甚至过多都是一个体验问题和小功能点,如果都需要去整理详细的PRD文档岂不是会大大的效率,本来团队需要简单沟通就能搞定的事儿,来了个产品经理反而降低了团队工作效率。[/dangerbox]

 

[title]什么是PRD,有什么作用?[/title]

抛开问题,我们在说产品需求文档(PRD)之前,首先溯源到市场需求文档(MRD)。通常通过MRD来阐述产品目标和愿景,涉及到的功能也是一个意向,不考虑实现的方法和细节。而PRD则是将概念图纸化、需要阐述详细的细节和实现模型。产品可以通过撰写PRD、梳理清楚方案实现过程中的各种问题和影响。

但是在一个小团队,尤其是一个做微信小程序的小团队。大多数的需求点小而杂乱,甚至过多都是一个体验问题和小功能点,如果都需要去整理详细的PRD文档岂不是会大大的效率,本来团队需要简单沟通就能搞定的事儿,来了个产品经理反而降低了团队工作效率。

在一个小公司,一方面PRD的功能通常是方便其他人理解需求请按照文档内容实现功能;另一方面产品经理需要梳理流程和细节。在大公司中PRD存在的意义则与小公司几乎截然不同,保证部门沟通有理有据避免工作过程中产生推诿;界定边界,避免扯皮;同时约束产品经理随意变卦(要求产品团队需要有强有力的决策力和版本规划);PRD同时也是考验产品的KPI之一;通常在大型项目中,也是通过需求管理文档来让需求变得有迹可循并且让整个项目形成规范化。

 

[title]用产品思维分析小团队中的PRD[/title]

由此可以断言,产品需求文档很重要,我们可以通过产品需求文档来量化产品到底做了哪些工作,甚至可以从一周的产品需求处理量上来判断整个团队的效率等问题。在协同工作中,开发、测试、项目经理能清楚的根据产品的需求文档明白这个项目的具体情况和团队的工作情况。但是对于快节奏和人员配备可能不齐全的小团队?到底适不适合?到底应不应该花费很长时间来写?

这也是困扰我许久的问题。既然我们是产品,则应该通过产品的分析方法来处理这个需求。小公司到底应不应该写产品需求文档?我将用需求四要素和需求三问的分析法来处理。

以下分析和场景适用于10人以下小团队,小团队的特点:敏捷开发、节奏快、需求变动可能相对会频繁、体验和小细节功能能较多、沟通成本小。

需求四要素分析法:

用户:产品经理

场景:在产品开发过程中

诉求:汇报工作?高效沟通团队?

任务:写产品需求文档

请注意这里的诉求,我们在写这份产品需求文档的时候一定要主意清楚,这个产品的需求文档是到底给谁看,是给项目经理和老板看量化成绩,或者是为了不在部门人员推诿中有迹可循?还是给开发看用于高效沟通的一个方式?所以在这里我觉得一定要搞清楚自己公司所处的环境状态,在这个环境状态中再判断应该怎么做。

如果只是为了给做简单汇报,说明这个周期我们做了什么取得了什么成绩。那么应该通过简单高效的汇报形成脑图、或者用office编辑表格、文档或演示文稿的方式来进行汇报。如果是为了给开发看,那么通过原型图+旁边的功能要点标注这应该是最简单高效的操作方式了。

 

[title]我的态度……[/title]

说到最后,我对产品需求文档的态度(也是一个决定),虽然在一个小团队,必要的规范化还是需要的。在时间够用的前提下应该要好好写产品需求文档的,这不仅是对团队和产品的负责更是为自己的角色而负责。

我一直推从的产品经理的需求文档应该是用Axure来写产品需求文档,并且可以通过Axure的原型发布共享功能来快速达到文档更新和迭代目的。下次有机会给大家分享我怎么用Axure写出高效(且具有逼格)的产品需求文档。

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
相关推荐
  • 暂无相关文章
  • 评论 抢沙发