如何让开发、测试一致称赞你的PRD？.docxVIP

如何让开发、测试一致称赞你的PRD？ PAGE 1 如何让开发、测试一致称赞你的PRD？ 稍微有点经验的产品经理，基本上都会写好一份PRD，那到底要具备哪些特点，才能让开发、测试一致称赞你的PRD？如果你去采访几个周围稍微有点经验的产品经理：“你认为你写的PRD是一份好PRD吗？”答案可能会高度统一：“Yes,it is！”在产品经理岗位上耕耘这些年，我的PRD收到了来自开发GG和测试MM的不计其数的建（pi）议（dou），终于收获了长足的进步，最近一年写的PRD在开发、测试团队中获得了一致的认可。所以如果你要问我这个问题，我的答案也会是：“Yes,it is！”但如果再追问一下：“你认为什么样的PRD是一份好的PRD呢？“这个时候答案就会千奇百怪了，“思路清晰，排版整齐……”每个人可能都巴拉巴拉列举一大堆的特征。在我看来，在一个真正的产品经理眼里，世间万物，只要是人造出来的，都是产品。产品上市之前，PRD就是产品经理交付的第一个产品。对这个产品经理交付的第一个“产品”，至少应该具备以下4个特点，才能算是一个好的产品（PRD），即：价值明确、考虑全面、可读性强、修订留痕。一、价值要明确能帮助用户解决问题，则产品是有价值的；而有价值，是一个产品诞生的原点。产品是为了解决用户问题的，PRD是为了打造帮用户解决问题的这个产品而编制的。那么，你的产品最终要解决的是用户在什么场景下的什么问题？要实现的定性目标是什么？定量目标是什么？在你的PRD当中把这些内容写清楚，一方面，可以让自己更加清晰地理解和审视项目价值；另一方面，也让开发、测试同学知道自己要做的工作是有价值的。这有什么意义？ 这么说吧：有工资拿，我做到朝九晚五；有价值感，我自愿朝九晚九。让团队知道他们做的工作是有价值的，并且让他们知道能实现什么样的价值，是凝结一个团队克服重重困难，滚滚向前的最为重要的力量。因此，一份好的PRD，一定会有关于它的项目价值的清晰描述。二、考虑要全面衡量一个产品经理PRD功力的最为关键的指标，就是看他是否考虑得足够全面。我将产品经理考虑全面的功力分成三个段位：第一级：模块内全面在这个段位上，产品经理能考虑到在正常情况下，所设计模块当中可能的应用场景，每个场景下有哪些分支流程和处理逻辑。比如：在下单流程中，能考虑到针对接口返回成功、失败的各种场景的处理逻辑；同时，也能考虑到在正常场景或流程之外，有哪些异常场景，并设计对应的处理方式。比如：下单流程中，接口响应超时场景怎么处理。第二级：模块外全面这个段位上的产品经理，不仅能考虑到所设计模块的各种正常、异常场景，还能考虑到这个模块的调整会影响到的其他系统模块，并在PRD当中给出相应的应对策略。比如：当你在门票的下单流程中调整了游玩人信息的处理逻辑，你能否考虑到对酒店品类的下单流程的影响。第三极：扩展性全面到了这个段位上的产品经理，不仅能对当下的模块内容的场景考虑全面，还能考虑到未来三到五个迭代版本之后可能的产品形态。他在自己的设计方案中预留产品扩展空间的同时，也在前期PRD当中对可能的扩展需求进行标注，以提醒开发人员在代码层、数据结构层预留充分的扩展空间。比如：你负责了一个旅游平台订单重构的项目。在第一个版本中，你只对门票的下单流程进行了重构，但你在前期的方案设计阶段，除了对现阶段门票订单的重构方案进行全面的设计，还能考虑到未来1年之中，对酒店、线路品类进行重构时的主要场景需求，并在产品方案中预留出扩展空间以供未来扩展。三、可读性要强这一点应该很好理解，PRD全称Product Requirement Document，即产品需求文档。因此，它的本质还是一份文档，对于开发、测试团队成员来说，还是一份需要仔细研读的文档。对于需要研读的团队成员而言，一份可读性强的PRD可以节省大量的时间，有效提高开发和测试的工作效率。那么，啥叫可读性强？我认为可读性强的PRD包括三个特点：1. 一个文档覆盖完整需求这是对于文档可读性的最基本的要求，刚做产品那会儿，沉迷于各种所谓的PRD模板和绘图工具，大致就是用Xmind画脑图、用Axure画原型，用visio画流程图，然后再用word写PRD。尽管也会在PRD中把重要的界面原型截图放进去，但有时候，Word无法很好地呈现一些交互效果，或者比较大的visio图在word里面看不清的时候，开发、测试团队就需要html原型文件、word、visio几个文档一起看，并进行来回切换。有时候也会出现开发人员嫌来回切换麻烦，干脆直接就简单看看原型图，之后就按照自己的想法开始coding了。很显然，从阅读体验来看，用word来写的PRD很难一个文档覆盖完整需