产品待办列表 PBL 与产品需求文档 PRD 的本质区别

2022-11-15
山西
本文字数：3864 字
阅读完需：约 13 分钟

最近与一个客户接触时，该企业的 VP 告诉我一个实情，在践行敏捷实践中，他们的产品需求文档 PRD 由最初的 13 页增加到了 100 多页，而且还有“增长”的趋势。主要原由是，PO 坚称有一个完整的文档作为保障，心里有底，担心如果不写下来，会丢失信息，缺乏“依据”或参照地方。敏捷倡导轻量级的文档，但该 PO 和团队成员坚持要构建一个“大而全”的文档，作为需求“规范”；最近捷行平台发布的“产品需求文档(PRD)必须消亡”一文引来了不少的关注。这两种不同的声音，让我有一种“冲动”，写一篇文章来比较 PRD 与产品待办列表 PBL 的本质不同，与大家共同探讨。

记得在 2006 年初，我加入一家 Start-up，我们有 MRD，PRD，业务需求文档，功能规格说明书(Spec's)，设计文档。这么多文档，一是花费好多时间写文档，二是要花时间去阅读这些文档。读的过程中要理解技术的语言，文档中有好多不同领域的术语，问题和解决方案混杂在一起。我记得整整用了一个下午阅读，头都大了，最后死活读不下去，关键是也记不住，更谈不上透彻理解。后来在项目实施过程中也偶尔“翻阅”一下这些文档，发现这类文档内容没有及时更新，内容已过时，文档成了“摆设”，因为它夹在文件夹里，还厚厚的页码。唯一的好处是满足心理上的一个“安全感”，尽管这种安全感是假的。

PRD 邀请需求范围蔓延(PRD invites Scope Creep)，写文档的人会一股脑儿的把想到的需求和功能都写在 PRD 里，PRD 变成了 wish–list，都希望能开发。如果干系人有这个那个需求，先写上去再说。我接触过一些产品经理，为了避免后期的需求变更(因为走需求变更的流程漫长而痛苦)，产品经理会把可能要做的需求，能想到的都“塞进”文档里，哪怕只有 1%的可能，这样做的策略是，避免后期走合同或需求变更的流程(change request process)，文档变成一个了“大杂烩”，Do more 成为可能，根本没有优先级的考虑。有的产品经理甚至担心项目结束后人员“解散”了，怕抓不到“资源”，就提前“预支”开发一些假象的未来可能的功能。

PRD 的存在会自然成为业务和研发沟通需求的唯一通道，说白了，变成了“合同”游戏。最可惜的是，写需求分析文档的时间占用了大把开发的时间。毫不夸张的讲，我经历的有些项目，预估 6 个月的项目周期，但是前 3 个月在准备文档报告，需求分析，开发人员只剩下 3 个月时间，“死亡行军”不可避免。这么做的背后有一个理论假设：因为项目晚期的需求变更的成本会更高，所以在项目启动时，最好把所有未来的工作都要彻底理解和规划，了解需要什么功能以及在项目开始时讨论如何交付实现，占用大量开发的时间做大而全的前期详细规划。通常以 SOW 或合同的形式固定下来，用“范围时间成本”的约束，即我们熟悉的项目制来控制风险。这种理论和方法仅仅适用于清晰或繁杂的环境和项目。它在复杂的环境中不能很好地起作用，Scrum 旨在复杂的环境。所以：

当我们不太了解客户需求时，提前计划太多细节可能会浪费时间
当我们发现客户真正需要什么时，过早的决定会导致浪费
许多项目都经历了在项目开始时不可能知道的“涌现”的需求

PRD 随瀑布式开发模式应运而生，敏捷开发需求在不断变化，敏捷对规格说明书(Spec)和文档的原则是：

我们不能只靠写文档假想需求
我们不能把文档扔到墙上就万事大吉(扔给开发团队)
我们需要“刚刚好”的文档

产品待办列表(PBL)是 Scrum 框架下最重要的一个工件(Artifact)。我认为 PBL 和 PRD 不应该共同存在，企业运行所谓的“Hybrid”流程和模式，增加了团队的负担和困惑。如果产品待办列表 PBL 取代传统的需求规格说明书 PRD，是否可行？有什么样好处和挑战？产品待办列表与 PRD 有什么不同？

（1）产品待办列表 PBL 符合满足“DEEP”（见下图）的特征。通常我们用 DEEP 来体检 PBL 的健康状态。

D: 需求的颗粒度有不同的层级，优先级高的需求更细化，未来不重要的需求放在底部，不需要我们当下去关注和细化它，PBL 呈金字塔型。传统的需求管理方式，我们在项目前期要做大量任务的分解 WBS(work break-down structure)，消耗好多时间和精力。

E: 估算 Product Backlog Item(PBI)的成本大小，规模估算。

E: 拥抱需求变化，PBL 的事项列表条目 PBI 可进可出，不需要走传统的需求变更(change request)的流程， PO 有最终的决定权确定 PBL 的内容和顺序。

P: 排优先级，即排序，注意没有并列项的 PBI。

（2）PBL 不同于 PRD 的一个最大特点：条目化的需求，即 Item by Item. 有两个好处：一是简洁化(Simplicity)，另一个是帮助我们排优先级。排优先级的方法，让我们开始关注那些先做，那些后做，那些不做。实际上是强迫我们关注价值，以价值交付为先，而不是被项目制的范围时间成本所束缚；PBL 转向产品思维，遵守 20-80 原则，一个产品 80%的价值体现在 20%的特性上。另外，PBL 的构建形式即条目化，帮助我们容易度量团队的 Sprint 交付速率。

（3）PBL 的内容大多是以客户和用户的问题或价值驱动，也就是对需求的描述专注在 what 和 why，而不像 PRD 过多重视 how 的实现。一上来就专注解决方案，会把我们陷入过多细节的技术讨论，而忘记这个条目是谁提出的，到底要解决什么问题，会给客户带来什么样的价值和影响。用户故事是 PBI 的一种推荐方式，会帮助我们思考业务价值和价值创立。理想情况下，PBL 的每一个条目都对用户或客户的产品带来价值。PBI 的类型有，特性和用户故事，改进项(enhancement)，bug fix，技术故事，知识获取项，文档(doc request)，等等。

（4）PBL 的一个最重要的功能，是作为团队，PO，干系人对话的基地(base)。PBI 是一个需求的占位符，它邀请 dev 和 PO 产生实时的对话。用户故事是 PBI 的一种形式，用户故事是指向需求的指针(user story is a pointer to a requirement)，用户故事它本身不是 requirement。PBL 格式的不同，会有利于支持或减少 PO 和团队之间结构化的沟通。PRD 文档很容易会被阅读者误解，需求文档成为“传话”的工具。有了 PRD，带给我们一个错觉，所有的东西都在文档里了，这是一个很可怕的假设。更糟糕的是，需求文档自然地成为“推卸”责任的工具。

（5）PBL 是针对一个产品目标对想要的工作(desired work)一个不断完整的清单，它是开发团队工作内容的唯一来源(single source)。PBL 的内容除了新产品的 PBI 以外，也可包括运维的需求，PBL 作为唯一来源，根本上解决了团队通常面临的工作多头管理，穿插打断，随意布置工作。团队的感受是一团乱麻，无头绪，没有成就感。通常情况下，最紧急的不一定是最重要的，最重要的也很少是最紧急的，PO 对工作内容按价值排序，团队不看管理者的脸色行事，如果企业能够真正落地执行这一条，我保证效率会翻倍。PBL 的透明性，增强了业务和研发的信任关系：因为工作内容的颗粒度小了，有优先级排序，价值很快会流动起来，产品增量也可见，透明带来了双方的信任，改善了关系。

（6）PBL 的实时性。PRD 是过去式，像是我们开车用后视镜看驶去的事物。我们面临的市场，客户，技术都在变化，需要前瞻性。我们必须响应变化，包括产品的策略调整，PBL 就是一个 PO 拥有的动态的围绕产品或服务的需求列表，它是开放的，实时的，涌现的，不是封闭的合同，需要我们在产品增量交付过程中及时反馈优化它。而且我们敢于面对和承认：在项目初期，我们对产品的理解，对产品的知识和经验实际上是最少的，企图把所有的需求提前都识别出来是不可能，也不现实。即使迫使我们的客户努力思考(think harder)和长时间思考(think longer)，也是徒劳无逸。总是有一些需求是事先难以预测的，即使我们把做计划的时间拉长，有些需求是在交付的过程中“涌现”出来的。对待这种“涌现”的需求，我们的策略是：① 多说少写，如果需要就请写一些 ② 向用户及时展示工作的软件或硬件增量，只有当用户看到实体或原型时才会说出所需的东西。客户的反馈会影响 PBL 未来的内容。PBL 一直在围绕干系人包括客户的反馈，检视和调整。

（7）光有 PBL 足够吗？ 不一定，正确的做法是，我们有一个轻量级的文档，邀请开发团队与 PO“对话”，Scrum 框架中设计的持续进行的产品待办列表梳理活动(PBR)就是一个落地的“对话”的实践。仅仅依赖于 PRD 文档，把文档扔给团队的做法是不可取的。正确的姿态，以对话为核心，灵活采用不同的技术和工具，补充丰富完善 PBL。可参考的敏捷团队具体实践有：

以用户为中心的设计思维(DT)，用户故事和用户故事地图(MVP)，影响地图
设计 Sprint(来自 Google)
Spec Tickets(有一定的模板参考)
交互式原型(UI prototype)，线框图，视觉模型(Visio diagram)，用户旅程，工作流(work flow)，流程图(flow chart)，故事板(storyboard)，Mockup，思维导图(Mind-map)
与用户实时交谈对话(前期的问卷和调研远远不够)
团队干系人 PO 团队讨论的录音录像和图片
Wiki Page 形式的支持文档(support doc)，简短的讨论文案，包括算法和技术要点
PBI 验收标准，客户满意条件，test plan 和 test doc
法律合规文档等等