产品经理第四周总结

• 文档和邮件是产品经理的第一个产品

• 尽可能地不逃避写文档，不写文档省下的时间都会在后面加倍还回来。

• 写产品文档的首要目的不是为了交流，而是为了自己思考

• 为什么要提前思考清楚，因为这时候还没有开始，最容易调整方向

• 而且人性的本质就是这样，在一个功能没有做出来之前，你去让开发做 A 还是 B 其实他心里不会有太多的感觉，但是假如说你让他已经做完了 A 然后又要改回 B 这时候处于人的本性他就会用尽力气跟你抗争为什么 A 比 B 好，你会遇到很大的阻力。

• 很多时候脑子里浮现的念头是飘忽，模糊，不具体的，通过产品文档将其具体化，使其具有可落地

• 说一群老鼠被猫每天吓得不轻，深受其苦，然后突然有天有只产品经理老鼠灵光乍现说：假如猫脖子上有一个铃铛，这样猫在接近的时候不就能提前知道了么？ 然后大家拍案称奇，高兴了半天，纷纷行动起来，找绳子的找绳子，找铃铛的找铃铛，还派出大队人马搜寻猫的踪迹，然而就在一切准备就绪之后，大家突然意识到一个问题——派谁去把铃铛系在猫脖子上呢？

• 假如那只产品经理老鼠能写好产品文档，这么多资源本不必浪费。

• 一定要花大量的精力跟开发解释清楚你做一个功能的目的，一定要让读者明确，我要做什么，比方说要在需求文档里写明白，需要客服部出一个客服人员跟我们对接。

• 林肯：实在抱歉，我没有时间把这封信写得足够短了

• 讲故事的本质并不是真的非得有一个故事，而是说要在读者头脑中营造出画面感。

• 持续更新文档是一件代价很高的事情

• 零售沟通即一对一沟通

• 发酵就是说写完的文档不要立即发出去，睡一觉或者等两天再看一眼，给自己头脑一个发酵的机会

• UC 属于产品文档当中比较小的粒度，描述的是参与者怎样去使用系统，具体的交互过程

• UML：用一套符号语言帮助工程师架构师对系统进行设计

• 用例：建模的方法，或者说我们认识系统和描述系统的方法

• 用例图不是用例，而是帮我们整理思路的工具

使用用例图和用例文档描述系统如何被使用，如何与 actor 交互

参与者 actor：以某种方式与系统交互的人或事，比方说对于一台 ATM 机来说，取钱的人，安装 ATM 机的人，搬运 ATM 机的人等等。利益相关者有很多是不直接跟这个系统交互的人比方说投资人，或者医院 HIS 系统中院长或者财务的角色，所以不是所有的利益相关者都是 actor，反过来 actor 因为都已经跟系统直接交互了，所以基本都是利益相关者。



用 ATM 机举例子：描述 ATM 机有两种描述方法：



一种方法是我们就描述 ATM 机本身的硬件和软件部分，例如硬件有主板，面板，出钞口等，软件有资金模块，用户模块，登录模块等等。这种角度称为实现的角度描述问题

另外一种角度是从外部去看，不是从白盒的角度去看，而是从系统外部的不同角色，比方说用 ATM 机的人，运营 ATM 机的人，甚至是运送 ATM 机的人跟系统的互动，去看这个系统。这个时候我们对它的描述就不再是这个机器有哪些模块，它的架构是如何设计的等，而是描述我们怎么去使用它，在使用的时候与这个系统的互动的过程是什么样子的首先我要做什么，系统返回什么，然后我再做什么。。。这是从黑盒的角度去看这个系统。（我很喜欢黑盒）



用例：系统为其参与者所执行的有价值操作

• 用例是一个完整的过程，它不是某一个功能或者交互，比方说滑动屏幕，敲击键盘，甚至它也不是用户登录，输入密码这样的交互，而是一定要包含一个对于参与者来说完整有意义的过程，比方说取钱的整个过程

• 用例解释了系统如何向利益相关者/参与者提供功能性价值

对于用户来说，登录不算功能性价值，输入密码不算功能性价值，取款才是，或者说查询余额才是功能性价值。

• 用例通过使用者的视角描述系统与其互动的方式，从而观测出系统实现。

用例可以直观地告诉产品经理用户在什么场景下以什么方式使用了这个系统

所谓特性就是产品的某种能力，提供的某项功能



用户故事·是更笼统和简洁地描述一个场景，而用例是要清晰具体到每一步流程。角度都是从用户出发，尝试描述和观测这个系统

用例：参与者、系统、有价值的动作

• 参与者不是人，而是角色，人可以在不同角色中间跳转。比方说内容审核，就可能是一个系统

• 时间也可以作为参与者

用例的粒度怎样最恰当？

• 系统为参与者提供的具备完整价值的服务（关注价值而不是功能）

谁在使用这个系统，他们的目标是什么？



思考：查看商品详情算不算用例？

我个人觉得算，虽然这个只是买东西的一环节，但是假如说我的目的就是想了解某一个或者一类商品呢，这就给我提供了一个完整的价值。

严格按照定义来说查看商品详情不算用例，就好像 ATM 的例子里用户登录账号密码不能算用例一样，因为取钱或转账或查询余额等对用户来说才是有完整价值的服务。不会有一个产品会跟你说，快来用吧，我们只提供查询商品详情功能！单独这个功能对用户来说这个价值是不完整的。



但是！

有的时候我们会违背教科书的定义把查看商品详情当做一个用例：

1.查看商品详情的过程中有很复杂的交互时，比方说用户可以在这里放大图片，跟评论交互，消费一些跟这个商品相关的内容等。也就是说当查看商品详情这个功能对用户的影响特别大的时候，或者有很多交互过程，交互流程，并且有明确的终点和用户沉淀的时候，我们可能会违背用例的教科书定义把它看成一个用例。

2.当我希望跟开发有更明确的沟通的时候（让开发更明确地意识到整个的流程）就会把本来是一个步骤，而不是一个完整的有价值的服务单独拿出来作为一个用例



怎么判断用例呢？

• 这个用例是一个完整的具有可销售价值的服务吗？



用用例：对参与者与系统的互动，而非系统自身的架构来观测，估计和逼近系统的实现方式



老板测试