产品待办列表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，都希望能开发。如果干系人有这个那个需求，先写上去再说。我接触过一些产品经理，为了避免后