《产品经理修炼之道》读书笔记

从老大办公室抢来的,老大允许我先读,吼吼;)

youxie neir不全是新内容,但从作者的角度重新整理了一下,感觉也不错,尤其是关于决策方法和实现目标的逆向思维方法。

每个产品都得不断的做“优化”吗?

一直很好奇,所有产品都得做优化吗?

它是真的被优化了,还是被越折腾越烂了呢?

产品的“监护人”是真心的想优化产品,并真的知道怎么优化,才去优化?还是迫于KPI和上级的压力,认为不做个大动静的改变就不能体现自己的价值?

就没有一个产品刚刚好够用,并以”慢发展”的姿态一路走完自己的生命周期吗?

改成烂产品的原因可能是自己品味真的很差,但至少心是好的,只是能力的问题;但如果是真正有品味的人迫于外部的压力,无法做到“简单”,无奈折腾个动静大的烂产品,那就着实不太爽。

//哦,周末参加个会,听嘉宾发言说很多功能可以不要都加到一个产品里;)

另外看到篇文章这样说 “目标只是组织内部的一种假设,相反,消费者需求总是表现为各种问题而非目标!组织目标只对内部员工有约束作用,而对于外部消费者无用!一般来说,消费者越是不满或抱怨,越是需要不断创新,相反,消费者已经很满意了,创新等同于画蛇添足!

【zz】彩色建模

培训的时候老师讲了彩色建模的方法,一直没理解透,今天看到这篇文章明白多了。

领域建模有很多种方法,对于同样的问题域使用不同的建模手段得到的模型可能也不尽相同。于是我经常听到这样一个问题:怎么才能保证建模的正确性?

这听起来是个合理的质疑,但实际上却不是那么有道理。首先我们需要明白建模的目的是什么?如果仅仅是为了描画问题,那么并没有什么对错之分——仅仅是立场和角度的差别;而如果是为了企业业务系统而进行建模,那么这个问题应该变为:如何保证模型能够支撑企业的运营?

我想用下面这个例子来简要的回答一下这个问题。

在开始分析和建模之前,我们需要知道企业业务系统的目的是什么;而企业业务系统的目的往往跟决策者或者管理的诉求相关。我们现在需要移情到一位管理者身上,看看他的诉求到底是什么。

现在假想你是一家在线电子书店的COO。突然有一天,有一位顾客向你投诉,说他订购的书少了一本,并且价钱算错了,他多给了钱。在你承诺理赔之前,你需要核对一下这位顾客说的是否属实。那么这个时候你需要知道什么样的信息才能做出准确的判断呢?

简单来说,你需要知道这位顾客订购了那些书籍,付了多少钱以及书店到底为这个顾客递送了那些书籍。不幸的是,由于科技不够发达,你无法直接驾驶时间机器回到从前去亲眼看看发生了那些事。但幸运的是,你并不需要这么做,你只需要看看这位顾客的订单,和网银的支付记录以及你们书店交给EMS的快递单存根,就应该知道这些信息了。

你找到了订单和EMS快递存根。发现这位顾客是在三天前订购的书,而你们在前天就已经将书邮寄出去了。并在订单上看到这位顾客一共订购了7本书,但是在EMS的快递存根上,并没有任何书籍的信息,只有地址,包裹号,邮费和重量什么的信息。这时候你觉得应该去询问一下配送部门,看看他们做了什么。

在配送部门你根据包裹号查到了那个包裹的信息,果然里面只有6本书。同时你在包裹部门发现了一张延期交货单。上面说明由于缺货,这位顾客另外一本书正在等待发货。

那么剩下的问题就是支付问题了,从网银的记录上看,客户不含邮费一共支付了132.5。订单上显示的价钱也是132.5,显然这位顾客并没有多付钱。

为了保证准确,你重新从网站上选了这7本书,想看看是否也会是这个价钱。但你却意外的发现,一共只需要128.3。仔细辨认后,你发现有一本图书现在是促销。那么现在的问题是,促销到底是什么时候开始的?

你到了市场部,市场部给了你一份近期促销计划。你发现那本书是昨天才开始促销的,也就是说在那位顾客在下订单的时候,促销还没有开始。

这个时候,你觉得应该给你的顾客打一个电话致歉,商讨如何后续邮寄的问题,并向他说明促销的事情。

你是否觉得这个COO当得有点累呢?这当然是虚构的。但是从这故事里面我们看到什么呢?

任何的业务事件都会以某种数据的形式留下足迹。我们对于事件的追溯可以通过对数据的追溯来完成。正如上面这个故事里,你无法回到从前去看看到底发生了什么,但是却可以在单据的基础上,一定程度的还原当时事情发生的场景。当我们把这些数据的足迹按照时间顺序排列起来,我们几乎可以清晰的推测出这个在过往的一段时间内到底发生了那些事情。

那么为什么这些数据形成的链条能够成帮助我们追溯业务的营运呢?

因为这些数据并不是随便挑选的。如果我们回顾一下你作为COO检查这个疏漏的过程,你首先选择了订单和EMS快递存根,换句话说,如果订单出现差错,或者EMS快递存根上说明你的确邮寄了7本书,那么这个疏漏的责任并不在你。所以这两个订单实际上这个你这个企业法律责任的起点和终点。

当你确定这个疏漏的责任在你之后,你选择审查一些流程执行的结果,比如包裹存根。从而验证一些主要的业务流程执行的结果是否正确。换句话讲,这些数据是支撑你运营体系的关键流程的执行结果

正是由于这些数据是流程执行的结果,它们才使我们可以在不了解流程细节的前提下,对某些突发事件进行追述和分析。

除了上面那个极端的例子(投诉),对于任何一笔正常的经济往来,我们都需要知道:

  1. 如果我付出一笔资金,那么我的权益是什么?
  2. 如果我收到一笔资金,那么我的义务是什么?

而这些问题都需要业务系统捕捉到相应的足迹才能够回答。所以企业的业务系统主要的目的之一,就是记录这些足迹,并将这些足迹形成一条有效的追溯链。

而作为业务分析师的你,则应该知道那些事件在运营上是需要追溯的,这些事件都留下了什么足迹。

这些足迹通常都具有一个有意思的特性,即它们都是时标性对象(moment-interval)。发现这些时标性对象就是建模的起点。对于这些时标性对象稍加整理,我们就得到了整个领域模型的骨干:

在得到骨干之后,我们需要丰富这个模型,使它可以更好的描述业务概念。这时候,我们需要补充一些实体对象。通常实体对象有三类:人,地点, 物(party/place/thing)。

在这个基础上,我们可以进一步抽象这些实体事如果参与到各种不同的流程中去的,这时候,我们就需要用到角色(role):

最后再把一些需要描述的信息放入描述对象(description)。

我们就得了应用四色建模方法(color modeling)建立的一套领域模型。

简要回顾一下上面的过程,不难发现我们建模的次序和重点:

  1. 首先以满足管理和运营的需要为前提,寻找需要追溯的事件。
  2. 根据这些需要追溯,寻找足迹以及相应的时标性对象。
  3. 寻找时标对象周围的人/事/物
  4. 从中抽象角色
  5. 把一些信息用描述对象补足。

由于在第一步中,我们就将管理和运营目标做为建模的出发点。因此,整套模型实际上是围绕这些“如何有效地追踪这些目标”而建立的,这样的模型可以保证模型支撑企业的运营。

附言

几位同事帮我审校这篇文章的时候,有人问了一个很有意思的问题:为什么你会以一个看上去像极端情况的例子来说明这个建模方法? 以我的经验来看,对于业务系统有两个东西是很重要的:可追溯性(traceability)和执行效率(efficiency)。这里的可追溯性是指责任的可追溯性(traceability of liability),而通常都是在一些不太好的事情发生之后,才需要对责任进行追溯。所以想一个相对负面的例子更容易帮助我们找到建模所需要解决的问题。

另外还有位同事说,你的四色方法与Peter Coad的四色法并不完全相同。是的,我所介绍的并不是Peter Coad的四色法, 我不敢说是发展, 仅仅是对于Peter Coad四色的一种变化吧

 

原文地址:http://www.kuqin.com/software-engineer/20111107/314522.html

 

【zz】什么是用户故事(User Story)

原文地址:http://www.scrumcn.com/scrumptc/html/?191.html

什么是用户故事?

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:

1.     角色:谁要使用这个功能。

2.     活动:需要完成什么样的功能。

3.     商业价值:为什么需要这个功能,这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达:

英文:

As a <Role>, I want to <Activity>, so that <Business Value>.

中文:

作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例:

作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。

Ron Jeffries的3个C

关于用户故事,Ron Jeffries用3个C来描述它:

卡片(Card) – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述,工作量估算等。

交谈(Conversation)- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

确认(Confirmation)- 通过验收测试确认用户故事被正确完成。

 

用户故事的六个特性- INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好的用户故事应该遵循INVEST原则。

独立性(Independent)— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划,确定优先级,工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性(Negotiable)— 一个用户故事的内容要是可以协商的,用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述,不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节,实际上限制了和用户的沟通。

有价值(Valuable)— 每个故事必须对客户具有价值(无论是用户还是购买方)。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。

 

可以估算性(Estimable)—开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。但是让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。

 

短小(Small)— 一个好的故事在工作量上要尽量短小,最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大,在安排计划,工作量估算等方面的风险就会越大。

 

可测试性(Testable)—一个用户故事要是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子:软件应该是易于使用的。

一个电话调查……

很久以前参加了某开发者大会,今天接到了电话调查,暂且称ta为隐形人:

隐形人:请问是小芳邓女士吗?

小芳邓:嗯

隐形人:您在N月N号参加过某开发者大会?

小芳邓:嗯

隐形人:好的,是这样,我是第三方调研机构,现在受委托想向您了解关于使用某开发平台开发应用的问题,我们不会记录您的个人信息,请您放心,您回答的内容最后也会以统计数据的形式提交给某公司,作为优化产品的参考依据。另外在您参与本次调查之后的30个工作日内,某公司会向您的手机帐号中充值30,作为答谢。您愿意参加这项调查吗?

小芳邓:嗯

隐形人:好的。请问您有使用某平台开发过什么应用吗?

小芳邓:没

隐形人:那好,再见。

小芳邓:嗯

……

这事儿过去几天了,现在想想好觉得蛮好笑,刚好准备给内部分享参加培训的内容,回忆起老师讲的如何优化流程,除了删掉无效的、整合依赖的、自动化繁琐的、简化高频的,调整流程的先后关系也应该作为一个方面。

比如隐形人的调查,这项工作很可能是按照拿到的有效样本数计费,那么隐形人设计问题时应该考虑快速过滤掉不会提供有效信息的调查对象(比如我这种),比如把“请问您有使用某平台开发过什么应用吗?”这个问题作为第二个问题,这是个封闭的问题,我只需要回答yes or no。这样的话他就不用再浪费时间介绍一堆调查的背景了,ta说着费劲儿,我听着还得费脑筋理解判断这是不是骗子。