新浪博客

『网课笔记』NO.15:产品需求文档(PRD)撰写方法与技巧(下)

2014-10-22 13:18阅读:


授课人:刘文智,产品100创始人 @im刘文智;
课程链接:http://www.duobei.com/room/course/8431482113


1、 全局功能说明:由于接下来我们要比较详细的表述每个类与每个子类的功能说明,所以这里就要把那些不能放到子类里面去的全局性的东西说清楚。

2、 例如:用户交互统一说明:
本客户端在用户触发操作后,应优先加载用户界面,同时在界面中加载数据的位置使用风火轮提示用户数据加载中。
本客户端的时间显示,建议使用人性化提示,例如:20分钟前,一天前,三天前,超过7天的,则显示为具体时间,如:3301755分,超过一年,则显示12
3301755

3、 UML:统一建模语言,是一种面向对象的建模语言,它是运用统一的、标准化的标记和定义实现对软件系统进行面向对象的描述和建模。

4、 用例:用例就是一种描述系统功能需求的方法。

5、 用例图:用例图表述的是系统的外部参与者与系统之间的关系,是由参与者与用例组成的示意图、用例图的组成要素。

6、 用例图的组成要素:参与者(可以是人,也可以是另一个系统,也可以是其它的东西,是相对的)、用例、关联线、方框。
『网课笔记』NO.15:产品需求文档(PRD)撰写方法与技巧(下)


7、 用例说明:

『网课笔记』NO.15:产品需求文档(PRD)撰写方法与技巧(下)

8、 上面这个表格,只是一个基本格式,关于用例在业内并没有一个成为和固定的专门供你套用的东西,一切都已你团队的默认习惯和达到那你的目的依据来写作用例。

9、 详细功能需求描述的基本结构:
产品的整体用例图
功能板块1需求
功能板块1的子功能1
功能板块1的子功能1的元素1说明(用例描述)
功能板块1的子功能1的元素2说明(用例描述)
功能板块1的子功能2
功能板块1的子功能2的元素1说明(用例描述)
功能板块1的子功能2的元素2说明(用例描述)
功能板块2需求(用例文档)
功能板块2的子功能1
功能板块2的子功能1的元素1说明(用例描述)
功能板块2的子功能1的元素1说明(用例描述)
功能板块2的子功能1
功能板块2的子功能1的元素1说明(用例描述)
功能板块2的子功能1的元素1说明(用例描述)

10、 MECE,是Mutually Exclusive Collectively Exhaustive,中文意思是“相互独立,完全穷尽”。 也就是对于一个重大的议题,能够做到不重叠、不遗漏的分类,而且能够藉此有效把握问题的核心,并解决问题的方法。

11、 MECE只是一种思考方式,当PRD文档撰写交付研发以后,其实多少还是会存在没有考虑到位或者需求调整的情况,所以:
撰写PRD文档前一定要保证思考到位了,产品结构本身短期内不会有重大改动;
需求分类与表述方式要参考MECE原则;
这样即便是在交付后,出现调整或需要优化的地方,也不会出现重构的情况;
重构需求,重新调整产品结构等,对已经处在开发过程中的团队来说是灾难性的
需求撰写,更多的是考验耐心,思路,经验,但产品架构的确定等更是考验一个产品经理对产品的规划与把握能力;
不要害怕,不要迷信;

12、 优秀的PRD文档应该具备的特点
正确:确保文档中的表述与产品经理的思路是对应且正确的
无歧义:文档的表述方便阅读理解,不会产生歧义
完备:MECE原则尽量保证对产品功能需求表述的系统完整
一致:文档中用词用语一致,对于同一事物的表述应该一样,避免混用同义词
具有优先级:产品的功能性需求是有先后主次的,对于一次性规划叫多功能的PRD,应该注明功能性需求的先后主次
可验证:对于功能性的描述,是可以进行测试的,而不是不发测试,无法定性的东西,例如:效率高,交互完美等词语,都是无法验证的
可修改:PRD文档利于后期的修改与升级
可追踪:每个功能性需求的来源应该是清楚明白的

作业:
1、 把上节课没完成的MRD文导航完成。

刘文智:QQ邮箱:5740928@qq.com
新浪微博:@im刘文智
产品经理学习群:122391574
170544091





尾注:
大家好,我是止滔,网名可以理解为停止浮沉、回归沉稳;也可以理解为女娲的聚芦灰以止滔水的远大理想;还可以理解为正在修行止学中的(我)。在自己的人生路上,我正在不断探索与修炼,历经荆棘,等待花开。

新浪微博:@止滔
我的微信:ablefan
本博客内容为博主止滔心得体会或名句摘录,期待能与大家有更多的分享和交流。
个人标签:知行致远、幸福行动、自我管理、早起团、GTDer、正能量传播、阅读写作、嵌入式电子工程师

我的更多文章

下载客户端阅读体验更佳

APP专享