产品需求文件必须消亡 “产品人员-产品经理,产品设计师,UX设计人员,UX研究人员,业务分析师,开发人员,制造商和企业家 May 05 2016 真正 PRD,产品要求文档,要求,规格, 注意产品 介意产品有限公司 914 珠三角必须死 产品管理 3.656

产品需求文件必须消亡

通过 ON

珠三角必须死I’从事产品管理已经很长时间了,我非常清楚地了解处理产品需求文档(又称PRD,市场需求,业务需求,功能规格等)的感觉。但是我最后写的是2005年,’s not because they’做很多工作(确实如此),但因为他们只是不做’t 工作.

除非你’re building a nuclear reactor or similar high risk, capital intensive product then 需求s documents are simply the worst possible way to bridge the gap between the customers’需求以及正在尝试构建解决方案的团队。

为什么?让我来计算一下…

为什么产品需求文件很烂

1 浪费。 实际上,产品中几乎不需要什么,并且通过将所有内容设置为要求,我们可以混合优先级并为功能膨胀(而不是客户解决他们的实际需求)奠定基础。此功能的肿是对工作和资源的极大浪费,例如Standish Group Report等研究可追溯到2006年–即使在成功交付的项目中,也从未使用过45%的功能!

为什么要提取产品需求文档-功能无法使用“这个词被误导了软件开发‘requirement,’在字典中定义为强制性或强制性的东西。这个词带有专制和永久的含义–阻碍变革的因素。这个单词‘requirement’完全是错误的。”
–Kent Beck,极限编程讲解

2 他们专注于解决方案,而不是问题。 我相信产品’s job is to 专注于定义和优先考虑客户’问题,不是解决方案。这意味着一旦在设计和工程团队中获得成功,您就可以共同努力,提出适合该项目范围或预算的最佳解决方案。但是,根据定义,PRD迫使您开始预先记录功能和需求(解决方案)。

3 它们是在某个时间点写的–并且与编写它们所花费的时间已经过时了。 大家都知道我们在技术领域的运作速度有多快,但是市场,我们的客户甚至我们的公司也是如此’战略!到时候我们’编写PRD几乎总是过时的,导致无休止的更新需求周期,而不是生产产品。

4 他们只和他们的投入一样好。 垃圾进不散去福音。这里的问题是,几代利益相关者已经学会了集体讨论,他们认为他们可能只是某天所需要的需求,从而保证了他们在实践中确实不需要真正指定的大部分功能。但是既然他们’re all 需求s –他们仍然被建造。

5 他们可以接受解释。 阅读它们并对其执行操作的人通常不是编写它们的人,因此您’基本上在您的产品上玩电话/中国耳语。从编写者到实施者再到测试者,对需求的解释中的累积错误是灾难的根源。

6 他们推卸责任。 任何软件项目中最困难的部分是确定要构建的内容– so engineering teams ask for specs, product teams write 需求s, and everyone thinks they’我们已经完成了自己的工作,只是客户永远不会使用该产品。

“构建软件系统中最难的部分就是精确地决定要构建什么。” –弗雷德·布鲁克斯(Fred Brooks),《无银子弹》(No Silver Bullet)(1987)

7 他们限制了您的产品。 这是违反直觉的,但是通过使用需求,您可以用那些需求有效地限制可能的结果,然后在您开始用尽资源或时间时,从那里不断缩小范围。这意味着通常会首先丢弃所有本来要使您的客户满意的东西,以便提供任何功能。

什么’s the alternative?

像往常一样,我认为’回到第一原则,并与研究,设计和工程团队作为一个团队合作,为您的客户设计合适的产品,这一点很重要。由于我们试图做的是尽可能有效地弥合客户与产品开发团队之间的鸿沟,因此,这就是您应该做的,而不是在浪费时间编写产品需求文档(借鉴那些 敏捷宣言):

1 个人与互动。 高带宽通信无法替代。与其依赖于编写规范并将其扔给工程学,不如说是协作协作以利用团队中每个人的洞察力和创造力进行的迭代过程。无论你’在执行用户故事映射,设计冲刺或任何其他技术时,协作将产生更快,更清晰的结果,因为它们是通过相互交谈实现的。

2 工作软件(或硬件)。 原型,原型,原型。无论’用户在便条纸,纸上素描的页面或有效的交互式原型中进行的流程,将展示实际经验的东西放在一起,并在您细化构成产品体验的数百分钟决定时可以在内部进行讨论,从支持它的后端基础结构到精确的用户流。

3 客户协作。 离开建筑物!与您的客户交谈,了解他们真正的问题所在,然后将他们带回团队。然后,一旦您有了一些原型,就对其进行测试–一遍又一遍地–不仅可以改善用户流程和可用性,还可以 理想性 的产品,因此在市场上具有可行性。