一 : 蔡文胜：选择产品的两个标准 用户需求是否真实

　　

 

　　互联网给人类带来的创新不言而喻，但更具冲击力的可能是它给传统行业带来的变革。在红杉资本和真格基金的一个分享会上，蔡文胜就互联网的演变和自己选择投资项目的一些标准发表了自己的观点。

　　针对互联网给传统行业产生的影响，蔡文胜认为：

　　几乎所有传统的东西，或者进入互联网化，或者会产生自己的困顿。去年，松下亏了102亿，索尼巨亏，这些情况会蔓延到中国来。

　　这与最近异常火爆的《降级论》中的观点非常相似，《降级论》作者通过自身多年创业的经历得出一个结论：用移动互联网的方式来改变传统行业将具有更多机会。而对于互联网的演变，蔡文胜认为主要经历了3个阶段：

　　商用互联网，以雅虎的出现为标志

　　当时最大的互联网是从分类信息开始，把一些相关的网站集中起来，再导出。雅虎的特色正是分类信息+人工编辑，比如在2000年的时候收录了中国的十大网站，和当时比较热门的产品。

　　Google的出现标志着互联网的第二个阶段

　　作为以域名起家的蔡文胜，在网站SEO方面同样拥有惊人的手段。他说2003年最高的时候，用几个域名可以带来几万的流量。由于在搜索显示中的排名太低，金融界上市的时候找到蔡文胜，蔡文胜将关键字改成需要的文字，一周内就让排名升到第一。在那个时候，做竞价排名的公司也可以拥有不错的前景。他透露当时有一家做竞价排名非常不错的公司卖给了雅虎，因此蔡文胜认为有时候未必需要上市才算伟大的公司，卖掉也是很不错的选择。

　　2005年Myspace以及后来的Facebook的出现标志着互联网的第三阶段

　　蔡文胜认为，Myspace阶段才到了互联网最有价值的部分：互动。因为这样可以让用户不断产生信息;而Facebook之所以能够打败Myspace，原因这在于Facebook把用户的关系也纳入了进来。而在国内，新浪微博的拐点开始于去年的10月。微信由于所有流量来自于手机，且是基于通讯录的牢固的熟人关系，因此会成为未来最大的入口。

　　基于以上的判断，蔡文胜从去年3月开始就决定只投资手机，不再考虑网站。因为互联网的第一个阶段改变的是信息的构成;第二个阶段改变了娱乐和电子商务的方式;而有了移动互联网和智能手机，对传统行业的改变刚刚开始。对于自己将来的投资项目，蔡文胜给出了两个标准：

　　用户需求是否真实

　　未来市场是否可发展：例如Web vs.移动互联网

　　或许，投资人看问题的角度有助于创业者在趋势上的把握，但真正的切入点还是需要创业者自己把脉。毕竟，你才是创业的当事人。

　　PS：感谢真格基金投资分析师顾三小姐的整理

　　除非注明，本站文章均为原创或编译，转载请注明： 文章来自36氪

二 : 产品需求文档的写作(五) – 用例文档(UML用例图、流程图)

在产品和技术领域里都有UML的技能知识，而对于产品人员的UML则更多的是指用例图，也就是我所称呼的用户流程图。在讲PRD文档写作的第二篇文章里，我提到了用户流程图的制作，实际上用户流程图是我在产品规则的初期对用例图的一种结构化的表达方式，由于以结构化的方式描述用例太抽象，缺少逻辑性表达，并且那篇文章更偏向于功能性用户流程，还不是实际意义上的用例，因此今天我补文一篇，细讲一下UML用例图和用例文档。

用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他是PRD中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。

用例文档中有两个关联文件，分别是用例图和流程图。用例图是UML的一种类图表现方式，是从用户角度描述产品功能，并指出该用户在产品各功能中的操作权限。流程图是通过线框图形的方式描述产品功能的处理过程，主要是描述功能的执行顺序、分支和循环的逻辑。

写用户文档的常用软件是Word，其中用例图和流程图的制作软件常用的是Visio，当然也有用Axure RP软件制作的，例如下面的第三步流程图就是用Axure RP制作的。

一份完整的用例文档分别是由以下三点内容组成，其中第3点的“用例”是描述功能逻辑的部分，根据功能的多少决定有多少个用例。

用例文档的大概组成部分如下：
1、修改记录：每次修改的备注记录，同PRD文档。
2、角色介绍：描述参与系统中的各个角色
3、用例：同下方步骤的第4步，其中第3步中的流程图是直接插入到第4步的流程图表格项中的。

用例文档的模板格式如同以上三点内容，通过Word文档绘制表格，在表格中撰写用例描述，表格的格式和样式参考以下示例图。

1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。（如下图）

2、第二步是以用例图的方式注明角色在前后端的用例关系。（如下图）

3、第三步是以流程图的方式注明角色在各个功能环节的活动过程。（如下图：以活动报名为示例）

4、第四步则是以用例文档的方式将以上三步整合到一起，并撰写各个功能环节的用例描述。（如下图）

表格说明：
4.1、用例名：此功能环节的名称
4.2、用例编号：在此产品中该用例的编号
4.3、行为角色：参与或操作(执行)该功能的角色
4.4、简要说明：用最少的文字描述一下该用例的需求
4.5、前置条件：参与或操作(执行)此功能的前提条件
4.6、后置条件：执行完毕后的结果条件
4.7、流程图：该功能的角色活动过程(处理过程)图（第三步中的图）

上面示范的用例描述相对简单，也是最常用和基本的用例描述内容，当然也有稍微复杂一点的用例文档，文档中会详细描述使用场景、事件流和信息字段，也有一些用例文档还会插入产品界面效果图。

使用场景主要描述行为角色在不同情况下使用产品时，根据情况或问题给出相应的系统反馈。事件流类似流程图，只不过是通过文字的方式描述角色的活动过程。信息字段主要是描述用例中所用到的数据字段。

这些更多的描述内容取决于个人的习惯，最终目的都是为了描述清晰产品逻辑，因此我的原则就是用越少的文字描述清晰越多的需求说明。（毕竟这些文档是产品开发中的执行文档，文字不在多，表达清晰即可。）

产品需求文档(PRD)的写作：
产品需求文档(PRD)的写作方法（文章的摘要介绍）
产品需求文档的写作(一) – 写前准备(信息结构图)
产品需求文档的写作(二) – 梳理需求(产品结构图和用户流程图)
产品需求文档的写作(三) – 原型设计(手绘原型,灰模原型,交互原型)
产品需求文档的写作(四) – 撰写文档(PRD文档)
产品需求文档的写作(五) – 用例文档(UM（www.61k.com）L用例图、流程图)

本文出自 产品经理唐杰

三 : PRD实用案例|「赶公交」App产品需求文档

赶公交产品需求文档V1.0

1.产品概述

1.1 背景说明

公交车坐位大众出行必不可少的交通工具，已经成为每个人日常生活的一部分。然而公交系统的运营资源是掌握在公交公司手中，人们无法获得公交车实时运行状况。而且公交车不同于地铁，相对来说具有一些状况上的不确定性，因此人们需要选择其出行时实时了解它的运行状况。

1.2 目标用户

从一线城市到四、五线城市都拥有公交车系统，每个居住在城市里的人都有需求选择公交车出行。

以2014年北京公交运行概况为例：

考虑到不同人群使用智能手机的情况，目标用户集中在20-40岁之间，以学生和上班族为主。

1.3 用户需求及使用场景

场景1：

“你忘了你曾经为了它而狂奔几十米，还差点破了自己的世界纪录”

所以–>你需要知道到站时间

场景2：

“你忘了你终于在人群中等来了它，而它心中却没有了让你容身的位置，或者你汉子气概全开终于挤上去却发现后面那辆居然有空座位”

所以–>你需要知道车内拥挤状况

场景3：

“你忘了你选择这趟公交车，却发现比你晚下班的室友在你前面回来了”

所以–>你需要知道道路拥挤状况

基于上面的场景分析，可以梳理出具体用户需求如下：

优先级1：

公交车到站时间，即“在哪里”； 车上拥挤状况，特色功能，但是在技术上实现是否有难度； 道路拥挤状况；

优先级2：

到站时提醒下车。一般公交车上都会有到站报站提醒，所以这里在考虑具体场景的情况下作为补充提醒。

1.4 产品功能结构图

1.5 主要流程图

1.6 全局说明

1.6.1 页面结构

1.6.2 交互说明

常用手势

页面切换规则

加载

编辑

输入框

打断

网络状况说明

2. 功能需求

2.1 登录页面

2.2 首页

在以下情况显示此页面：

正常首页

2.3 “我的”页面

“常用路线”页面

“我的里程”页面

2.4 “设置”页面

后话：

其实关于之前提到的显示公交车内拥挤状况，如何在技术上实现，这里有几个思路：

与公交公司合作，能否获得乘客刷卡上车数据，这样可以计算出所有站点之间的乘客人数。 给产品添加一个额外功能，能实现设备之间的互相通信。例如，在从上一站行驶到当前站（用户所在站点）之间，激活App此功能，形成公交车的局部网络，这样每部手机就是一个热点，而且距离在一个公交车范围内，没有相对移动（排除车外干扰），随机选取一部手机探测所有热点，每一个热点就是一个乘客，这样就可以知道车上乘客人数。当然，这个需要在大部分手机上都安装此产品。到这里突然想到，是否转换思维，进行微信公众号二次开发，然后利用微信的各项功能实现上述需求。 本文标题：产品需求文档prd实例-蔡文胜：选择产品的两个标准 用户需求是否真实
本文地址： http://www.61k.com/1109933.html