• CSPO+A-CSPO直通车
  • 敏捷领导力(CAL E+O / ALJ)认证培训
  • Five_reasons_three
  • Hardware-agile-practice-20231012
  • Clp_20220108
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • CSM A-CSM一站式培训
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • ShineScrum捷行出版书籍
产品待办列表PBL与产品需求文档PRD的本质区别

最近与一个客户接触时,该企业的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

· 法律合规文档等等

我们支持简洁的PRD,即Minimum Viable PRD概念。冗长的PRD会大大减慢MVP的产出速度。PRD不应该有150页之多。MVPRD回答类似这些的问题,为什么要构建该产品,为谁服务,重要的功能是什么,如何测试开发构建了真正所需的内容等。

最后重申一下,产品需求文档PRD不应该成为“传话”或“传递”需求的工具。产品待办列表(PBL)是Scrum框架下最重要的一个工件,PBL的最重要的功能,就是作为团队,PO,干系人“对话”的基地和开启。


——Jim Wang王军  

写于2022年11月11日


参考资料:

(1) CSPO 教材

(2) Is the Product Requirements Document Dead? https://uservoice.com/blog/is-the-product-requirements-document-dead

(3)Product Hunt’s stripped-down PRD