用数据说话

No Comments

精益创业的环路中,人们往往最重视设计和产品化,会做一些评估,但往往会不自觉就忽略数据在决策中的重要性。这对产品开发来说是很危险的。

leanstartup loop

Airbnb早在推广期,曾经有一个点子——为房主提供专业摄影服务。这项服务后来成了Airbnb的一个亮点。这个点子的设计很简单,当有专业拍照请求时,创始人拿着自己的专业相机去发布房间信息的人家里帮忙拍照并上传。

airbnb

当然,创始人团队意识到这里有一个假设——专业的摄影师可能会帮到房主更好地销售自己的房间,从而促进Airbnb的商业。

点子宣传出去后,2012年2月,有超过5000的摄影请求。大家认定这是个不错的点子值得继续投资。

如果注意的话,这里的5000这个数字是强有力的证据。试想,如果没有这个数据,做同样的事情,很可能会得出如下结论:

data_tells

仔细留意一下对比,没有数据的帮助,我们很可能把因果弄反——排名靠前,很大原因是因为照片拍得看起来不错。请看看你的产品,是否真的让数据在说话?还是刻意回避这个问题?

用户体验之旅

No Comments

在数字时代,设备种类越来越丰富,而用户体验逐渐变成跨设备,跨网络,甚至每一步体验都是发生在不尽相同的场景。为了达到目标,用户在不同的场景下的交互行为更加多样化。

这样的场景下,系统的定义不仅仅只是一款软件、一个应用程序、一台设备;把这些离散,非线性的点连接成一个整体才构成系统。要分析这个系统如何能帮助用户达成自己的目标,并不容易;系统如何组织?用户的行为如何分析?用户与系统的接触点在哪里?

用户体验建模
建模的第一步是发现系统中的各个组件,并通过可视化手段展现。以数码相片的拍摄及使用为例:
2014-05-06_11-27-32
可以看到,个人电脑可以连接到各种设备;为了提供灵活性,它通常需要超越公司的边界。比如,iPhoto软件,能管理照片,还能分享照片到Facebook和Flickr。个人电脑这部分在用户使用过程中,涉及到照片的摄取,管理,编辑和发布到不同的媒介。通过分析,能看到用户的行为与系统之间的联系:
2014-05-06_11-31-54

有了上述连接,我们可以定义一些场景:
2014-05-06_12-13-56

我们把用户的行为以及他们跟系统的“接触点”排列成下面图的:
2014-05-06_12-39-54
根据不同的场景和用户目的,把这些点连成线,比如
2014-05-06_12-47-34
而对于一个喜欢晒宝宝照片的新妈妈,她会有不同的跟系统交互的方式:
2014-05-06_12-51-32

上面的例子只是简单展示了用户体验建模这样的工具如何能给用户行为与系统的接触点联接起来;这种联接能帮我们揭示现有方案与用户目标直接如何匹配的。当然,在项目中,也可以用这种方法把新的设计与用户的行为进行联接,从而验证我们所理解的用户的需求。

参考链接:http://www.slideshare.net/frogdesign/brugnoli-system-ux-1061731#

点点投票法

No Comments

你应该还记得意启前不久发出的文章《引导师工具箱—收敛的秘诀》中,教了大家收敛的原则与方法,如何从大量报事贴的点子中抽取最有价值的信息。

而实际操作中,我们见到有的团队在收敛的时候会陷入混乱。曾经见过有引导师,收集到了大量团队的想法,然后自己从里面挑了3条,告诉团队,后面需要去实施这三张报事贴上的内容。

往往一个引导师,如果碰巧引导团队讨论一个自己熟悉的话题的时候会不自觉地陷入这个陷阱——虽然让团队参加了讨论,但最终没有让团队决定。这时的引导师已经开始变得不中立。

意启在团队头脑风暴的时候,经常使用的一个比较有效的方法是:点点投票法。

Vote-sticky

材料:圆点贴纸

步骤:

1. 每人取3个圆点
2. 轮流在展示的卡片中选出自己最看好的条目,贴上圆点
3. 引导师选出点数最多的一条或两条跟团队,有团队确认是否接受最终结果

dot-voting

 

小贴士:圆点粘性较大不宜直接贴在玻璃或白板。

除了点点投票法外,调动整个团队还有另外一种变形:大拇指投票法。这是一种更快速的投票方法,适用于团队快速决策:

 

thumb-vote

在意启的工作坊中,Ace会在开始前跟大家确认:“我们12点准时结束吃午饭,同意大拇指向上,不同意大拇指向下,随大流大拇指横着,一二三,一起出!”于是2秒钟内就能确定是否大部分人认可12点准时吃饭。

点点投票法实际操作简单,但是能调动所有人,是引导师在引导团队中很好用的一种工具。

傆型的指标 – 上套指数 Initial Level of Interests

No Comments

不久前在意启部落的网站上,推出了傆型系列文章。这几篇关注在如何设计傆型以及各类傆型使用场景及实际使用的案例。意粉们会觉得傆型更多的是一种实践,而缺少一种指导原则指导,比如何时运用何种模型?本系列将给大家剖析傆型背后的理论模型。

传统的产品设计中,通常做法是先开发出来产品,再通过销售推广,最后从销售业绩中寻找产品正确的证据;而90%的产品销售业绩都不理想,有人把销售 业绩不理想全部归因于销售人员,而没有意识到其实是产品本身是错误的产品;可以想象,为了证明这类“错误”产品的正确性,公司会选择一次次更换不能胜任的 销售团队,直道公司难以支付甚至破产。而且随着互联网逐步发展,市场日趋细分,这样做产品的失败率会逐步升高。

针对这样的局势,傆型的理念是,大量投入把事情做对前,先想办法低成本找到对的事情。

傆型如何回答产品是否正确的问题?
意粉们是否还记得Dropbox如何起家的?在《精益创业》这本书里面曾经提到过这件事——Dropbox的解决方案需要花费很多去解决其技术上在各个平 台上同步的问题;而Dropbox起步的时候并没有选择直接解决这个技术问题,而是制作了一段视频,放在极客社区,一夜之间竟然75000人等着体验 Dropbox的试用版。凭借这个,Drew Houston知道,Dropbox值得继续做下去。

傆型《看门人》http://innolauncher.com/pretotyping-concierge/ 就 是这类傆型。这种方法,并没有在产品中投入过多,而是制作了一个无生命的版本,通过在实际场景中的应用,让用户感受问题被解决的体验。在开始开发某功能 前,先问问用户是否有意向,并收集有意向的用户的电话;最后收到1000多留下电话的用户,这说明感兴趣的人还是占比重很大的。

关键指标 – 上套指数(ILI)
当一个产品还没真正上市就受到广泛关注,这说明这个产品值得继续投入;相反,如果一个产品最靓丽的一面都不能引起足够的注意力,这是一个警告我们需要先暂停继续往前的信号。

我曾经碰到产品经理,给他讲解这个指标的时候,得到的回答是,“我现在很难让客户一下子就了解我整个产品的想法,只有等他看到真正的产品了,我才可以把故事讲出来,所以上套指标对我来说没有帮助”;我会追问到:既然现在都不能产品的想法抽象出来,提前跟用户验证,如何能希望更复杂的软件产品能够回答这个问题?

上套指数是这样一个指标:选定目标人群中的一部分,给这个样本人群展示产品点子,获取想要真正尝试的人数所占比例:

equation_ili

 

在计算这个指数的时候,需要提前知道被“测试”的用户群体人数规模,同时这群人能够某种程度上反映真实目标人群的情况。

 

ili

如图所示,目标人群中选取1000人,如果有750人表示愿意尝试试用版,说明这个产品值得继续投入;而这时候是不是就要开始数据库设计了呢?请关注《傆型的指标(下)》

讲故事的魔力

No Comments

他和朋友一起过夜。睡觉时做了一个十分真切的梦:一个小偷破门而入,拿走了屋里的一切,然后有小心翼翼地摆上了完全一样的复制品。
“我感觉特别真实。”早上他对朋友说。
朋友们十分震惊,也十分不解,他们说:“可是你是谁?”
——摘自《全新思维》

意启曾经有一篇文章,介绍讲故事对产品设计的帮助。如果我们仔细回想,故事能够把人和周围的世界连接起来——放学回家的小朋友会兴致勃勃的跟妈妈讲述幼儿园发生的故事;媒体工作者向世界展示自己发现的故事;CEO给员工讲述一个恢弘的故事,从而向他的团队展示自己的愿景…你会发现,故事几乎无处不在。

相比而言,数据往往能够深刻揭示一件事情背后的定量因素;而故事能够帮助人们体会事情背后的人的情感。比如关于应届毕业生就业后半年的失业率,有一组数字说明失业率总体有下降的趋势。

charter

而讲故事的方法会这样诠释,这张照片中的学生,将有3个人会在毕业半年后或许需要靠父母的帮助才能养活自己。

students

意启的工作坊《从想法到产品待办事项列表》最后会有一个最终演示的环节,有的团队通过讲故事的方式把自己的产品设计诠释得很透彻;而有的演示只是讲述功能的堆积,相比而言,这样的演示往往会让听众犯困。

那么到底如何讲故事呢?好的故事如同一部好电影,其实是有套路的。完整的故事通常包含这些部分:
1. 背景交代:背景介绍能够帮受众快速建立起来对场景的理解,这里同时会包含一些对问题的介绍。即便是如开篇的短故事,也会一句话交代故事的背景:他和朋友一起过夜。
2. 挑战:扣人心弦的故事往往都会抛出一个出人意料的挑战。
3. 英雄人物:英雄人物的出现,能够把问题化解。我们的工作坊的故事中,英雄可能是一件设计的产品,产品的出现有效解决了前面遇到的挑战。
4. 结果:也是故事的收尾——比如,王子和公主快乐的生活在城堡里面。。。有的故事结尾意味深长;有的则总结经验;有的戛然而止。

回到文章开头的小故事,这是一篇曾经很流行的微小说体,只要一小段文字,就能把一个略带恐怖气氛的故事渲染出来;故事虽小,却具备了从背景交代到故事结尾的各个环节。

下面TED ED视频许多精彩电影中的故事的模式提炼出来,推荐给大家:

今朝侬想吃点啥?

No Comments

每到周五周六晚上,热闹的上海的小吃夜市就开始了。熙熙攘攘的人群,手上或拿着奶茶,端着生煎,章鱼小丸子… 民以食为天,这里面蕴藏着巨大的商机。有个朋友在一个热闹的夜市中租了个5平米的门面,销售台湾风味的炸鸡块、鸡肉等。随着口碑日益传播,小店每个月都略有盈利,也有不少人会索要名片点外卖。

小店老板也是深度移动互联网用户,微信公众账号/微信服务账号都已经有了不少粉丝,平常用于跟粉丝互动,听取客户对食材食物的反馈等。入冬后,外卖的需求增加,有粉丝反应,晚上经常会发生外送电话打不通的情况。有人推荐老板开通电话等待服务,但考虑到这样会浪费很多等待时间。作为微信深度用户的小店老板,决定尝试微信点餐业务,这对很多小店都是一个很新的东西,而年轻的粉丝也比较喜欢尝试新鲜的东西。

经过讨论,老板觉得,最好的办法是能做到端到端,提供微信菜单,并让用户可以经过两次点击就能点餐;而小店里面,一旦有订单,就自动计入到点餐系统,并入账,同时自动打印点餐单。这一整套系统,跟小店的财务管理软件、点餐软件结合,肯定能够带来很多便利。不过 —— 有一个比较现实的问题:开发这样一套系统需要投入的资金比目前所有外卖收入的资金还要高出很多,聪明的老板并没有急于一下把整套系统做出来,取而代之的是,他找了开发团队,实现了下图的功能。从用户的角度看,如果需要点餐,只要两次点击就能看到各类菜单;点餐菜单只要选种点餐,再选上相应的美食就可以了。从小店角度看,在柜台上能看到微信管理界面中的点餐记录,收银美眉会在堂吃客户点餐空隙把外卖记录录入系统中,而微信系统只需自动回复给用户,“订餐要求已经收到,30分钟内会送达”。

screenshot-20131231-033723下午

在店里,每当有客户点餐的时候,老板都微笑着说:“今朝侬想吃点啥?”,并告诉她扫描关注微信点餐服务号后,就可以用1块钱换一杯珍珠奶茶(基本上就是成本价)。这样的做法确实很聪明,对宅在家连电话都懒得打的80,90后还是挺惊喜的,小店竟然能与时俱进,不但食物好吃,还能够跟紧年轻的客户脚步,提供便利的点餐服务。

对老板而言,微信点餐给年轻的客户比较深的印象,但是微信点餐暂时还没有带来过多的订单,如果有一天微信上面的外卖订单量超越了人工能够处理的上限了,或许就是时候开始考虑真正投资做微信点餐跟店里的点餐软件集成了。

或许读者还记得意启前不久发的一篇叫做 傆型实战之-看门人http://innolauncher.com/pretotyping-concierge/  的文章。小店老板正是用看门人的做法,在资金有限的情况下,用可控的风险换取渠道的拓展。

如果你现在路过那家小店,还是能看到老板微笑着说:“今朝侬想吃点啥?”,并给你推荐新的点餐渠道。

你觉得靠谱的事情真的靠谱吗?

No Comments

云计算是近年来说很火的一个概念。各个产品都在想把自己的产品移到云端。潮流不能不紧跟啊。

有一个产品线,老大对Cloud的理念非常的Buy-in,因此决定在把自己的产品通过定制之后放到“云”里面去。做这个决定的依据是,跟相关的资深人员开过讨论会,有了较为深刻的理解。云计算能够帮助客户减少IT的维护成本,特别是中国客户,“云”了之后他们甚至不用自己设立一个专门的IT部门。这对客户的成本来说,绝对是大大降低了。客户听说IT成本能降低,也很高兴,几乎要跃跃欲试。于是项目轰轰烈烈的开始了。走完了立项流程,于是一个响亮的名字腾空出世——按需定制的云端财务计划。

于是乎,100条精壮的汉子,历时一年,虽然做出来跟一开始想像中的产品略有出入,但是“按需定制的云端财务计划”也已经基本成形了,最初设计的核心理念也相对完整的体现了。领导很高兴,发布节点过去后,举办了一次规模宏大的庆功派对,大家开香槟相互庆祝,为这一年的辛劳相互鼓励。

你可能已经猜到结果了“按需定制的云端财务计划”在中国遭遇了滑铁卢,不但没有大卖,反而乏人问津。问了当初信誓旦旦想要削减自己IT经费的那些客户,客户摇着头说:“是啊,我是要削减我的IT成本,不过让我把我的收入和未来规划相关数据放到一个不受我控制的的服务器上,我哪里放心啊;我宁愿多养一些人,把我的这些数据保护好。”

看到了吧,100个人一年时间就这样打水漂了。但凡是一开始能够问个最基础的问题:客户真的会用这个吗?你觉得靠谱的事情它真的就靠谱吗?

想起意启的一篇文章 傆型, 原书里面还有另外一个IBM的声转文的故事

几十年前,因特网和个人电脑初现曙光,IBM那时候最富盛名的是巨型机和 打字机。那年月,只有极少数人会打字,其中大部分是秘书,作家和一些程 序员,而绝大多数打字都说用的“一指禅”。

IBM想当然的认为,他们需要充分开发电脑技术和打字机业务,所以需要发 明一个声转文的机器。有了这个设备, 不用敲键盘,人只需对着麦克风说 话,而他们说的东西就神奇的出现在面前的屏幕上。这里有很大的市场前 景,IBM认为该赌一把。

不过,这里还有几个大问题。那时电脑跟现在比起来,性能差、价格贵,而 声转文需要占用很多电脑资源。即使有了相应的处理能力,声转文在计算机 科学领域是个难题(到现在也没很好解决)。解决这个问题需要巨量投资,

即使是对IBM这样的大公司也不容易,而且研发周期需要数年。每个人都想 过要这么个设备,应该来说是个稳赢的点子吧。让我们来一探究竟。

虽然所有人和公司都说他们想要,并且一定会买,IBM有些员工并没有完全 被说服。这些员工担心公司投入数年时间无数金钱研发出来的东西不会有太 多人购买,那将是一场商业灾难!用榞型话说:他们不确定声转文究竟是否 是对的它。毕竟,没人真正用过这样一个声转文的系统,他们怎么会如此确 信他们会想要这么个东西?IBM想要先测试测试这套设备的商业可行性;然 而最基础的原型都需要数年时间,他们想出来个绝妙的办法来实验。

他们把声转文系统的潜在客户,也就是那些号称一定会买的人请到一个房间 里面,房间里装了一台电脑,一个屏幕,还有个麦克风,但是没有键盘。 IBM告诉这些人,他们已经做出来这么个系统了,只是想测试一下是不是真 的有人喜欢用。测试用户兴高采烈的开始对着麦克风说话,发现他们说的话 一字不漏的显示在屏幕上了,几乎没有延迟,而且没什么错误!这些用户完 全被Hold住了:是在是太完美了!

事实上怎么会是呢?在没有声转文的机器,甚至原型都没有的情况下,这个 聪明的实验是怎么做到的?房间里面的电脑其实只是个摆设,而房间的隔 壁,其实是一个熟练的打字员,听到麦克风传来的用户的声音后把文字和命 令敲到键盘上,其实还是老的那种方式。打字员敲出来的东西显示在用户的 屏幕上了;这样的假象让用户感觉像是屏幕上显示的东西是通过声转文机器 生成出来的。

好了,IBM从这个实验里得到了什么呢?

下面是我听到的:一开始的惊艳之后几个小时,大多数号称要买的人开始改 变主意了。虽然有人模拟的快速并接近完美的翻译,语音输入多一点的文本 开始初现问题了:一天下来人们的嗓子都哑了,而且这么做工作环境会很 吵,机密材料不能用。

基于以上实验的结果,IBM继续在声转文技术上投资,不过没有做得那么 大,达到把整个公司都堵上。

时间终证明这个决策是正确的。相比其他输入方式,键盘输入还是不可替代 的。30年前,大多数人都不会打字;但是现在看看,办公室里(咖啡厅)各

年龄段各行各业的人都在自己的笔记本电脑上敲字。对于那些不能用全键盘 的设备,比如手机,声转文或许是正确的“它”,但依旧离不开键盘。键盘才 真的是“正确的它”。

IBM的方法真是令人拍案叫绝,但是这中方法该怎么讲呢?里面用到的声转 文的做法算不上是一个“合适的原型”,它的其实就是个打字员在敲键盘—— 当然,除非他们真想弄个打字员藏在电脑里面。IBM没有原型化声转文系 统,他们只是假装做出来声转文的原型了,然后用这东西来测试用户对产品 的真是反应。通过这种方式,他们能够收集到真正有价值的市场数据,而不 是仅停留在个人的主观想法上,而且他们投入的时间相当少。

在开始前,问问这事是不是靠谱,再决定是否值得投入大量精力去实现。做个傆型,对初创团队,可能决定生死。对大公司来说,可能就决定了数千万的钱是否打水漂。

现在,回去看看你自己的产品,你觉得靠谱的事情,他真的靠谱吗?

附:

傆型(pretotype),是Google主管Alberto Savoia提出的,请参考:http://www.pretotyping.org/

意启Innolauncher上可以找到Pretotype相关的中文资料:http://innolauncher.com

How to Be a Coach

No Comments

How to Be a Coach

This is an article after series sessions coaching the coaches with several colleagues.  In these sessions, we discussed the topics related to coaching, include different types of coaching, Techniques of Coaching, A normal framework of coaching. Here we share with you the content, hope you like it.

What is coaching?

Coaching is probably one of the buzzwords this year; anyway, what is a coaching? Does Coaching mean you sit together with a coach who is very experience that she teaches you something?

 

First of all, let’s look at people in coaching – Coachee, he is the one who called a coach to support him solving a problem; the Coach, she provides coaching service to coachee when required by coachee. Coachee and his coach will sit together to start a coaching session.

 

Now you understand, that a coach supports coachee in finding a solution with her coaching skills; and a coachee is responsible for the content. So, a coaching session is solution oriented, coaches help coachee self-reflection and find his own solution.

Why people need coaching?

I can see a question mark above your head; we have a lot of senior people that have strong experience, why we need a coach that can’t provide content wise support?

 

Check out this charter, as coach asking/listening more, coaches doing more self-reflection. Pure coach don’t have too much experience in the problem that coachee is holding, and it’s better that he expertise don’t have too much overlap with the coachee. Because coaches can ask questions that won’t make the coachee feel uncomfortable, she asked the questions because she does not understand the situation.

 

Types of coach

Think about you own circumstances:

a) In a presentation, for example, a keynote speech in a conference – the presenter will do most of the talk;

b) During trainings, the trainer will deliver the training content, though an experienced trainer will have interaction with trainees, the trainer will drive the delivery of content;

c) What is A functional coach? It’s coach that facilitate the execution of a strategy, for example, Design Thinking Coaches, Lean Coaches – they holding coaches skills to coach team, but the goal is to make sure the strategy executed successfully. They will listen to the teams, but they still have to deliver content.

d) Mentor, as mentor of someone or a whole team, mentor support the team with his expertise, he can help solve the problems that mentees are having, to understand the situation better, he listen carefully and give his solution.

e) Manager as coach, a coaching style manager can support team solve problems they encountered, manager might not give too much solution because the teams were empowered, but sometimes manager will still have to jump in as he is responsible to help team running smoothly and do not break company policies etc.

f) Pure coach (business coach), business coach have strong coaching skills, she helps coachee self-reflection with coach techniques, she listening carefully, asking questions to dig deeper, and encourage coachee to try out solution he found out himself.

 

There’s a formula regarding the person excellence,

 

Performance=Potential-Interference

 

It means we believe that a person has great potential to make him excellent, and we need to remove the interference that is currently annoying him. Sometimes, a senior person can give suggestion, but as business situation become more and more dynamic, the suggestion sometimes not the most suitable one. It’s better that the coachee himself find out the solution based on his own understanding of the situation. We think with more complicated business situation, a coaching style is becoming more and more important.

How To Coach a Person?

Already excited to be a coach? How should I start we facing a coachee? There are many frameworks when coaching a person as a coach. But the basic idea is not too different.

 

Normally the process of coaching session looks like this:

steps

 

First, you setup a goal with the coachee. Just like ICR team was doing recently, the goal need to be S.M.A.R.T. Consider these questions when setting up goal:

-       What specifically do I want?

-       Where and with whom do I want it?

-       When do I want to achieve it?

-       What will be different when I reach it?

 

What will I see, hear and feel?

-       How would I know I was on track for achieving this outcome?

-       What resources can I activate to get this outcome?

-       What resource might I need to acquire/to achieve this outcome?

-       Who do I need to support me and what do I need them to do?

By setting up the goal and asking powerful question, the coachee will re-think his problem.

 

Second, if the coachee setup the goal, then coach can help him dive deeper into the problem. The listening skill is very important here. She must listen carefully and ask questions to uncover problems. At the beginning, the coaches might jump to different topic with the coachees’ thought. Until some point, the coachee touches the essence of the problem, coach can dig deeper into it by ask question:”can you tell me some detail on the xxx you just talked about?”. The purpose of this pahse is to work towards the goal.

 

The coaching session will look like this:

 

Coaching Session

Coach Tips

At closing phase, clarify goal and actions, ask the coachee if anything else. When the session touches the coachee deep in heart, it will be a succeful one.

 

What Coaching Techniques Can I use?

There are a lot of coaching techniques that can be used, but as a coach, you don’t have to familiar with all of them. Instead, you can take some of them and master them as your coach toolbox. We list the ones that we discussed in the sessions.

Open questions

Open questions are questions with open answer instead of yes/no answers. It helps the coachee to think instead of just answer yes/no.

 

Circular Questions

The goal of this type of question is to help the coachee to think from another perspective.  By asking circular question, the coachee put his own feet into another one’s shoes. With the perspective switching, he might see the facts that he didn’t realize in his own point of view.

Scaling Questions

Scaling question is a simple tool, that you have the coachee to evaluate his goal quantified.

 

Draw a scale on the paper, ask the coachees to give a score of his current level.

 

 

 0 Scaling10

 

Ask him if he to think about in the past, what’s the level of worst situation. If he gives a lower score, then ask him to think about the key learning through that experience. Ask him to give the target level score, ask him what specifically does that score mean, and guide him to take actions toward the score.

 

Paradoxical questions

Paradoxical question (the so called Leave Pattern) can bring unexpected surprise when used sometimes. It can brings the coachee to the contradict perspective and think about the blockings he is going to encounter.

 

The question can be:

“How could you best hinder yourself from reaching the goal?”

“Assume your problem will be solved tomorrow, how could you activate it again?”

Aggravation questions

It brings the coachee into negative thinking. Help the coachee to think deeper into the situation.

 

The question can be:

“How could you make your situation even worse?”

When the coachee find something, then ask him “what do you learn?”.

Except questions

It’s the solution focus coaching. Ask the coachee to think about the past when the problem didn’t exist. It can help coachee find out the point of conflict.

Copy questions

This question is resource-oriented questions. Try it with the coachee by asking: “Which possible solution you haven’t tried before? Who could help you?”

And guide the coachee with the question:” think about the prople in your network, maybe even in another country?”

If the coachee can think of someone to help, then guide him to take action by asking:

“what will you do next?” “When will you do it?”

 

Try it out yourself

In the end, do remember, always trying these ways:

 

a)    To activate the resource, have the coachee to take action with resource he was thinking of.

b)    Trying to switch from problem focus to solution focus. If no solution derived, how should the coachee proceed with his own derived actions?

c)    Activate the coachee to learn from his past, trying to guide him apply his learning to solve his current problem.

d)   The coachee always initiates a coaching session. if he didn’t call for a coaching session, it implies he might not have desirability to make the change.

 

 

 

Kata接力

No Comments

Jackson 在微博上面发起了#Kata接力#的活动。我写的Kata视频在这里。

本次Kata解决的问题是:

100 doors in a row are all initially closed. You make
100 passes by the doors. The first time through, you
visit every door and toggle the door (if the door is
closed, you open it; if it is open, you close it).
The second time you only visit every 2nd door (door
#2, #4, #6, …). The third time, every 3rd door
(door #3, #6, #9, …), etc, until you only visit
the 100th door.

Question: What state are the doors in after the last
pass? Which are open, which are closed?

这个问题如果直接硬着头皮写也能写出来。用测试驱动开发的方式,采用数学归纳法的思路。我第一步,先验证开始的时候所有门都是关闭状态。这样能够帮助我推导出最基本的类的行为接口。为了让问题变得简单,我先解决一扇门的问题,再解决有两扇门的问题,然后是三扇门的问题。同数学归纳法一样,到了三扇门之后,算法就完善了。

 

我的心得:kanban里面最常说的就是限制WIP,我把WIP上限设为1,一次只做一件事情。在对问题的分解上,我把问题分解成一件一件很小的问题,然后逐一解决;在代码演化上,我有时增加或者重构测试代码,有时增加或重构产品代码,但不会同时增加/重构测试和产品代码。

只关注小问题,能够帮助我有效进行思考。一个大问题怎么拆分成一系列小问题呢?通过练习逐渐适应。这里的拆分思路在我写Bowling Game的Kata和PrimeFactors的Kata中就有所体会。

庖丁解牛法拆解用户故事

No Comments

我的朋友郑立-Ali在2012年敏捷之旅青岛上讲了一套“庖丁解牛”法拆分用户故事,通过庖丁解牛的类比,详解拆分用户故事的几大招数。

梁国达人秀

良庖歲更刀,割也;族庖月更刀,折也。今臣之刀十九年矣,所解數千牛矣,而刀刃若新發於硎。

神兵十九年不坏的秘诀: 游刃有余,目无全牛

imageimage

imageimageimage

用户故事之牛

好厨子并非看不见全“牛”,而是在切“牛”的时候,眼中看到的,脑中想到的,都是“间”,以无厚入有间,必定游刃有余。虽然了然于胸,当碰到复杂的经络时,也要全神贯注,小心下刀,直到各个部分分解完毕。

根据多方总结,好的PO和团队也有类似的经历,虽然脑海里能有产品的全图图,然而当在用户故事分解的时候,眼中看到的,也全是“关节”和“经络”结合部位。

image可以想象,牛的表皮和肉是UI,脊柱是产品的框架,关节是关系

用户故事的经络与骨节

Ali总结了这么张图。通过观察系统中需要建模的角色,类型,实体关系,操作,状态,数据能够帮助拆分找到线索。

image

示例1:在线支付功能的拆分,需要支持VISA,Master Card,中国银联

image

直观上,第一印象,应该是拆分成3个并行的用户故事:

US1:As a shopping carte user, I would like to pay my bill by VISA card

US2:As a shopping carte user, I would like to pay my bill by Master Card

US3:As a shopping carte user, I would like to pay my bill by China Union Pay Card

看起来挺合理的,不过要注意,这三者之间是有关联的。

———————————此处比较血腥,慎读 :P ——————————————————

想象当牛还是头整牛,想要取出牛百叶,牛心及其他内脏,通常做法是先把外表整个切开,再取牛下水;很少有厨子会先从表面开个口取心脏,再开个口取牛肝。

————————————————————————————————————————–

回到我们的例子,道理是相通的,三种支付方式后面都是有关联的,他们都可以基于一个共同的用户故事:One type of credit card + Basic payment support, 接下来才是实现additional credit cards。

示例2:在线订购功能

作为用户,我希望在订购信息界面,进行搜索、付款以及取消订购的操作,这样我可以随时了解和修改我的订购信息。

这是一个Epic,早期的厨子这么干:

image=>image

现在一般厨子会抡起斧子,砍成几大块:

US1:显示预订列表

US2:搜索功能实现

US3:订购付款

US4:订单取消

这里问题在于,各个功能之间是有千丝万缕的联系的,强行切割会,难以开发,难以测试,难以排优先级。引此,需要对关系进行更加深入的分析。

image

通过分析,用户信息是比较重要的,而显示一条预订记录的功能被付款,取消订购,显示所有记录依赖,另外搜索功能和显示所有记录的功能又有直接关联,而搜索等功能的性能调优又需要依赖与搜索功能。

这么看来,切割需要优先实现一条记录创建与显示,所有记录显示和付款;其次才是搜索,订购取消,性能优化。

这样看来,若要游刃有余,必先打通关节才行。

附:用户故事拆分独孤九式

image这里介绍一些招式怎么把一个复杂的问题拆解成粒度较小的用户故事。所有招式背后都尽量遵循两个原则:

1. 一次只做一件事

2. 让这件事尽量小粒度

PS:下文所用的例子是一个公共事业费缴费系统,系统跟一个网站连接,并连接到各家各户的智能抄表系统

 

 

第一式:切割操作流程步骤

找出达成用户目的所需流程中的步骤,通过增量的方式一步步拆解

image

拆解示例:

As a utility, I want to update and publish pricing programs to my customer

拆解后:

…I can publish pricing programs to the customer In-Home display

…I can send a message to the customer’s web portal

…I can publish the pricing table to a customer’s smart thermostat

第二式:观察业务规则变化

有些用户故事,咋一看很简单。但是随着进一步的分析,业务规则会比直观上看起来更复杂。这种情况下可以考虑按照业务规则的复杂性,把大用户故事拆分成若干个小的

image拆解示例:

As a utility, I can sort customers by different demographics

拆解后:

…sort by zip code

…sort by home demographics

…sort by energy consumption

第三式:挑明主要次要分界

有时候,一个用户故事通常可以拆分成多个小的,往往其中第一个的实现会耗费较多的力气,而剩余的相对比较简单(考虑前文提到的信用卡支付的例子)。

image

拆解示例:

As a user, I want to be able to select/change my pricing program with my utility through my web portal

拆解后:

…I want to use time-of-Use pricing

…I want to Pre-pay for my energy

…I want to enroll in Critical-Peak_Pricing

第四式:分解简单复杂场景

有时候,团队讨论一个故事,故事可能会变得越来越复杂,通常是这样发生的:如果这么弄,那xxx怎么办?考虑过xxx的问题吗?这是问题变复杂的一个征兆;停下来问问PO和大家:“最简单有效的场景是什么?”。把这个简单版本记录下来,作为一个独立的用户故事,接下来再把可能的变数和复杂的场景记在不同的用户故事中。

image拆解示例:

As a user, I basically want a fixed price, but I also wnat to be notified of Critial-Peak-Pricing events.

拆解后:

…respond to the time and the duration of the critial peak pricing event

…respond to emergency events

第五式:罗列所涉数据变化

数据与资源的变化是另一种带来复杂性的因素,这时候,考虑先构建一个简单的版本,后续再及时补充新的用户故事完善需求。

image拆解示例:

As a utility, I can send messages to customers

拆解后:

…in English

…in Spanish

…in Arabic, etc.

第六式:演化输入展示体验

有时候复杂性更多是源自用户界面而非功能需求本身。这时候,可以考虑先拆分一个故事并用最简单的界面实现,接下来再构建比较华丽的界面。

image拆解示例:

As a user, I can view my energy consumption in various graphs

拆解后:

…using bar charts that compare weekly consumption

…in a comparison chart, so I can compare my usage to those who have the same or similar household demographics

第七式:降低较贵任务质量

有时候,初步的实现远远没有结束,更加重要而且开销更大的任务往往是让系统更快,更稳定,或者更精确,或者更易于伸缩。然而,团队可以从实现基础功能的过程中学习到很多东西,而这个基本实现对用户也是有帮助的(如果没有这个功能可能用户都不能完成自己的任务)。这时候,可以考虑把大故事依次分解成几个小的。

image拆解示例:

As a user, I want to see real-time consumption from my meter

拆解后:

…interpolate data from the last known reading

…display real time data from the meter

第八式:顺从数据操作定义

“控制”“管理”等字眼往往是拆分用户故事的着眼点,这里面一般暗藏着多种操作;根据这些操作,可以把大问题拆分成小故事。

image拆解示例:

As a user, I can manage my account

拆解后:

…I can sign up for an account.

…I can edit my account settings.

…I can cancel my account.

…I can add more devices to my account

第九式:延伸已有用例场景

有些用户到系统或者系统到系统的需求是很复杂的,这时候如果已经写好了用例,那么用户故事通常可以按照用例中各个场景拆分

image拆解示例:

I want to enroll in the energy savings program through a retail distributor.

拆解后:

Use case/Story 1(happy path): Notify until that consumer has equipment

Use case/Story 2: Utility provisions equipment and data notifies consumer

Use case/Story 3(alternate scenario): Handle data validation errors.

除了以上九式,还有一招“万佛归宗”

如果发现前面九招都不是很适应,就先拆分一个“Spike”吧。道德经说:“道生一,一生二,二生三,三生万物”,所谓“万佛归宗”即是最朴素的方法,这个方法通过实践总结,定能衍生出前面所说的九招甚至更多。

Spike最早是极限编程中引入的,它是一类特殊的用户故事,由这个用户故事挖掘出不确定性和潜在的风险,并派生出新的比较明确的用户故事。技术类Spike可以用于探索和评估不同的技术对解决问题的作用。功能类Spike用于演讲系统如何跟用户交互等功能性问题,这方面的Spike可以通过原型等方式进行探究。

有时候两种Spike都是需要的,而且可以结合使用。举个例子:

As a consumer, I want to see my daily energy use in a histogram, so that I can quickly understand my past, current, and likely near tearm, future energy consumption.

对这个故事,可以先创建两个Spike:

技术型SpikeResearch how long it takes to update a customer display to current usage, determing communication requirements, bandwidth, and whether to push or pull the data.

功能型SpikePrototype a histogram in the web portal and get some user feedback on presentation size, style and charting attributes.

Spike使用指南

Spike跟普通用户故事一样,需要一起进行计划和估算。Spike的结果却跟用户故事不同,通常,它产生的是信息或者知识,而不是产品代码。通常Spike会以一个决策,一个原型,一组串联的故事或者是一件半成品。

Spike应该是可以估算,可以演示,并且团队乐意接受的。Spike结束后,结果应该给团队演示。跟一般用户故事一样,最终PO会根据验收标准决定是否接受Spike的结果。

因为Spike通常是有不确定性及风险的,在同一个Sprint里面计划Spike及其结果会带来更大的风险,当然如果Spike比较小,而且比较明确的话,也可以考虑在一个Sprint里面。

参考:

Older Entries