- 当我们不太了解客户需求时,提前计划太多细节可能会浪费时间
- 当我们发现客户真正需要什么时,过早的决定会导致浪费
- 许多项目都经历了在项目开始时不可能知道的“涌现”的需求
- 我们不能只靠写文档假想需求
- 我们不能把文档扔到墙上就万事大吉(扔给开发团队)
- 我们需要“刚刚好”的文档
E: 拥抱需求变化,PBL的事项列表条目PBI可进可出,不需要走传统的需求变更(change request)的流程, PO有最终的决定权确定PBL的内容和顺序。
P: 排优先级,即排序,注意没有并列项的PBI。


- 以用户为中心的设计思维(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
- 法律合规文档等等


——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
本文来自投稿,不代表TobeAgile立场,如若转载,请注明出处:https://tobeagile.cn/2022/11/18/%e4%ba%a7%e5%93%81%e5%be%85%e5%8a%9e%e5%88%97%e8%a1%a8pbl%e4%b8%8e%e4%ba%a7%e5%93%81%e9%9c%80%e6%b1%82%e6%96%87%e6%a1%a3prd%e7%9a%84%e6%9c%ac%e8%b4%a8%e5%8c%ba%e5%88%ab-%e5%8e%9f%e5%88%9b%ef%bc%9aji/