敏捷开发的PRD自然应该符合敏捷开发的需求。
首先产品经理需要有敏捷开发的意识,将大需求拆成一个一个小的需求安排到每一个版本的迭代中,以适应快速迭代。
在敏捷宣言遵循的原则中明确说到:“不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。”
在敏捷开发中, PRD应该是与同事充分讨论后的记录文档,应该是一种补充。
压力山大……
交互+说明+标签吧
不过这种开发模式,一定要让整个开发团队加入到项目初期的建设中,有关于为什么要做这个,怎么做这个,这个做给谁用,一般什么时候用,用了又有啥用,对咱又有什么好处……等一系列问题最好在初期建设中尽量让开发团队就了解。在实际开发的时候,如果原型的交互、说明已经标签足够ok,还是能够避免不少问题。
so,粗略聊聊问题。其一在于,pm自己要对自己的业务非常清晰了解,业务流程啊逻辑啊什么的,应当是用工具模拟过N次的。其二,每一次思维的迭代需要找个地方记录下来,有据可循,其实长篇大论的PRD也会出现类似问题,前者的风险在于无迹可寻,后者的风险在于要从一堆内容里去找所谓的迹。其三,就是最大的问题了,一般来说,没有详细的PRDor业务说明文档,团队里一旦有人员更迭,真是苦啊……新加入团队的哥们几乎都会一脸懵逼.jpg,这个鬼团队在开发什么鬼?尤其是,pm自己离职orLeader离职,简直爆炸……
所以,敏捷归敏捷,该写的不省,能写的就找业务和沟通之余的时间补一补吧。
强烈反对上面几个人的说法,敏捷开发不是让你少写或不写文档了。PRD该怎么写就怎么写,一个PRD一天就能出了,你是多快的敏捷开发连个写PRD的时间都没有?实在没有PRD,原型图总有吧
文档还是必要的,只不过文档详细到什么程度要视团队而定。在敏捷或者题主所说的小步快跑模式中,可以用产品原型代替PRD文档,注意产品原型应包括但不限于如下信息:
1. 变更记录:用来记录每次修改的内容;
2. 版本说明:记录每次迭代的更新说明;
3.产品的信息架构:直观的反应产品层次机构;
4.流程图:用来说明业务逻辑;
5.交互说明:可以采用注释的方式,清晰的标识页面之间的跳转等信息即可;
6. 状态信息:某些控件,数据,文本等的一些状态。
7. 操作反馈:交互的跳转,用户操作的提示信息等等;
欢迎补充。