头脑风暴之奔驰法(SCAMPER)

很多产品创新团队已经掌握了头脑风暴,利用团队成员集体头脑风暴来对问题和方案进行发散收敛,建立共识以及最终方案。如何将头脑风暴向前推进一步?一种方式是采用奔驰法(SCAMPER)。与普通的头脑风暴相比,奔驰法为头脑风暴提供了更加结构化的指导。SCAMPER其实是七个单词的缩写,分别是: S = Substitute(替代) = 是否有取代原有功能或材质的新功能或新材质?能可以和原有功能整合?如何整合与使用? A = Adapt(调适) = 原有材质、功能或外观,是否有微调的空间? M = Magnify = 原有材质、功能或外观,是否有微调或更夸大的空间? P = Put to other uses(其他用途) = 除了现有功能之外,能否有其他用途? E = Eliminate(消除) = 哪些功能可删除?哪些材质可减少? R = Reverse(翻转)或者Re-arrange(重排) = 顺序能否重组? C = Combine(合并) = 哪些功   如何使用SCAMPER可以参见下面视频。 ​ 对于引导SCAMPER头脑风暴来说,每个环节的问题很重要,下面是一个具体每个环节可以使用问题的列表。 更多内容参见意启部落之引导者工具箱

Share

用户体验建模 – 反例

四月份以携程推出的接送机服务为例子分享了用户体验建模。最初体验相当不错,但是两个多月下来,决定放弃,原因同样是用户体验。从用户角度,整个接送机分为四个阶段,分别是下单 -> 当天服务 -> 售后服务&支持 -> 异常情况。   正如四月份文章“用户体验建模”,提到的,从整个乘坐航班、接送机到酒店场景来说,该体验相当不错。但是从接送机服务的细节体验来看,问题相当多,主要集中在后两个阶段:售后服务与支持和异常情况处理。 售后服务阶段主要处理的是发票寄送和投诉。问题相当不少。发票并不是与机票同时寄送,哪怕是从订单确认页面,选择了快递方式,租车发票也是另外通过平信寄出,而且多数情况忘记寄送发票。更大的问题是,投诉无门,因为租车业务小组没有单独的售后支持电话,很多时候需要机票小组转接。 飞机航班取消时,相应的租车服务理应同时取消,但是携程并不会及时把租车款项退还,而是默认用户已经享受过租车服务。 从整个用户体验的维度,找到用户的痛点其实并不难。  

Share

ODDE的Product Backlog

产品待办事项列表(product backlog)是敏捷软件开发中用得较多的一项实践了。而在跟团队一起工作的过程中,我们发现虽然大家都在用Product Backlog,但是却没有完全发挥Product Backlog的最终作用。意启部落整理了一系列产品待办事项列表中的臭味,并给出了相应的建议。 好的产品待办事项列表(Product Backlog)应该具备下面的特性: 1. 排好序的(Ordered) 早期的Scrum手册中使用的词是优先级。对于不同的backlog是有优先级的(Prioritized)。随着经验的积累,人们发现,优先级并不能完全描述待办事项孰轻孰重。你或许还记得,上次团队问你,A和B,哪个要先做?脑子里浮现出客户A和客户B期待的表情,你回答:“同时进行吧“。同时进行意味着,你要同时聚焦在两件事情,甚至是多件事情上面。Scrum手册第二版出现后,把优先级换成顺序。A和B需要Pk出来一个唯一的顺序,这样,虽然根据团队的实际吞吐率,可以同时进行A和B,唯一的顺序让孰轻孰重变得更加明确。这样也有助于作为PO的你对需要解决的问题进行更深入的探索。 我们发现,在真实的开发团队中,很多用户故事具有相同优先级或者根本没有优先级的产品待办事项列表,这是 臭味一:无序(亦或是那个都重要) 2. 动态的(Dynamic) 产品设计本身也是一个对问题和解决方案探索的过程。在用户需要,技术可行,经济回报方面不断寻找平衡点。这个探索过程是动态的,是随着知识增加不断调整的。 而有的Product Owner会习惯性的全面考虑,希望把产品设计成一个大而完善的解决方案,于是他的Backlog有了臭味二:冗长 3. 细节适中(Detailed Appropriate) 如前面所说,好产品是一个探索的过程,正如夜间开车,既有目的地,也需要开车途中时时留意车前的状况,同时还需要经常注意远处路况;看不清近处或者只看远处都有潜在的安全隐患。 我们观察到产品设计中有类似的状况:即使是高优先级的用户故事都只是粗粒度的描述,也就是臭味三:近视眼。也有老板会敦促PO把产品待办事项列表(Product Backlog)整理到电子工具,方便出报表;或者PO在Backlog中关注于过多不重要的细节;于是导致了臭味四:远视眼 4. 有相应的估算(Estimated) 如何对项目的风险进行评估?团队在经历若干次迭代后其速率(Velocity)能保持在相对稳定的状态;速率同时也给PO对后续的迭代计划提供参考,同时是对风险进行评估的很好的参考数据。当团队里没有人关注风险,没有人关注速率时,就产生了臭味五:无估算(亦或是免费)。 产品待办事项列表的实践并不仅仅只是准备一个TODO-list这么简单,它应该是一个符合上述四条(简称ODDE)原则的。这些原则就像一面镜子,让你发现待办事项列表中的问题,然后去除臭。正如臭味的处方中提到的,它应该是由一系列的敏捷实践支撑的,这些实践是对敏捷价值观的实践。

Share

箱子(Boxing)的魔力

为了这个想法,公司投入了一百多号人,半年的时间,可是在市场上来一个水花都没有。 来自许多国家的科学家分析人类DNA,很多年过去了,还是没有令人惊喜的发现。 创新与科技领域大家总是有一个幻觉,投入的金钱或者精力越多,越有可能获得成功。可是除了登月计划及曼哈顿计划(研制原子弹)等少数几个项目,极少有科学发现或者创新是来自于大量的投入。不幸的是这少数的几个项目,给大家这样的错误印象,促使更多的政府、企业、科研院所去投入更多。 创新或者科技突破其实更多来自于偶然的、不经意地观察与刻意的思考,这样的例子不胜枚举: 牛顿发现苹果往下落 微波炉是雷神公司的低级别工程师佩尔西。梅斯宾塞,他发现微波能够让巧克力了融化 青霉素的发明 莱特兄弟发明飞机 达尔文的《进化论》也给我们类似的启示。 It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change. In the struggle for survival, the fittest win out at…

Share

Teach It

Introduction Instead of just teaching people, I usually encourage and support my client to teach. Teaching is a far more effective way to learn than typical learning methods such as reading and practicing. There are a lot of benefits: Teaching itself is a reflection exercise….

Share

团队教头

介绍 作为唤醒者,在团队中我一般不直接教团队成员。我的一般做法是指导其中一位同学,然后帮她成为团队这方面的教头,然后由她负责把大家教会。因为“教是最好的学习方法”。以教代学有很多好处: 学习过程的设计和引导本身就是一个反思练习。自身的学习会在学习过程设计过程中获得极大地深化。 把大家教会能够产生不小的满足感,这是进一步学习的很好激励。 学习的设计与引导过程中可以发现更多的学习机会。经常在设计培训中暴露现有知识体系的不足之处。在培训中,学员提出的尖锐问题通常也会给指出我们一些新的研究方向。 让同事来教会比作为外来顾问的我更具有说服力、阻力也会更小。 故事 Nancy在团队中负责测试工作。她的绝大多数工作是手动测试她们基于页面的应用。有一次她见到了我正在和团队中一个开发人员结对写自动化测试,她立刻展示了强烈的兴趣。Nancy在微博上@我:“@Daniel, 下次你来的时候,我们能不能结对一下?”。机会来了,在接下来的几次拜访中,我每次花了一部分精力与Nancy一起加了一些UI自动化测试。一两个月下来,Nancy已经能够写出不错的测试,该是时候把她的经验传播到整个团队了。我帮Nancy设计了一个小培训: 事先准备 找到一些还没有被覆盖到的测试场景。这些场景的实现难度不高,而且能够在一个半小时内完成。 为大家准备一些小抄,包括一些基本知识以及小技巧。这样大家就不需要去Google了。为了这次培训,我们准备了如下几个小抄: 如何安装配置Capybara环境,包括Capybara、Ruby、Cucumber、RSpec、Rake环境 Capybara的简单介绍以及最基本使用方法 一些样例代码,方便大家复制/黏贴 课后作业 培训中 简短介绍 – 20 分钟 Capybara简单介绍、Cucumber原理以及如何使用脚本 一些已经完成的测试用例 小抄及其使用方法 组队以及认领任务 – 10 分钟 把所有人分成2~3人一组 简要介绍待测试的场景 每一组分别认领某个场景 完成任务 – 1.5 小时 小组内讨论测试用例,并用Capybara去自动化。 Nancy和我提供现场支持 分享与总结 每个团队展示最终的代码并分享这过程中学到的东西 比较各组的脚本并总结出注意事项 布置作业 介绍课后作业 学员重新分组,并认领作业 培训后 让Nancy分享在引导培训过程中做得好的、有待提高的要点…

Share

激发用户反馈

敏捷开发以及精益创业都会鼓励产品团队与客户的互动,迅速、及时而准确地从客户那里获得反馈是产品成功的必要条件。在产品开发之前“了解你的客户是谁?”,“他的工作环境如何?”,“他们的痛点在哪里?”会给产品团队一个足够的信息去启动产品开发,但这远远不够,为了取得成功,需要持续与客户协作,从客户那里获得第一手信息,并根据新的信息去调整计划和产品。 与客户协作的方式有很多,而且不同的方式会有不同的适用范围,必要时需要结合结合几种不同的方法以获得对于客户更全面的认识。下面是经常使用的几种与客户协作的方式及其相互比较。 需要注意的是,与利用不同的方式与客户协作相比,产品团队同样要重视与客户互动的频率。

Share

用户体验建模

最近喜欢上了携程的“接送机”服务。每次出差去深圳而在携程订机票的时候,随手就可以把接送机的出租车一起订了,这样就不用担心下飞机后还要排队等出租车了。携程的传统业务是酒店和机票,但是从客户整体体验来看,这两个点不是连续的。携程提供了不错的酒店和机票预定服务,但是坐车的体验可就很一般了,经常采用的方式,比如出租车等待时间长、车况比较差、可能会被宰。其他公共交通对于旅客来说又不十分便利,从客户场景来说这是一个痛点。 太多的产品功能是因为团队掌握了某种技术,或者团队擅长于某种业务,很少从客户的整体场景体验入手,找到场景中的痛点,然后针对痛点给出方案。忽视客户场景的后果十分严重,客户不会为你能做的事情买单。 为客户场景建模的方法很简单: 第一步:选定某客户场景后,让所有的参与者独立把客户在这个场景中的操作记录到报事贴上   第二步:参与者互相分享自己写的客户场景操作 第三步:共同把报事贴分类,去掉重复,并替每个分类一个类名 第四步:选择一个顺序把分类好的报事贴串起来 第五步:讲故事,并注意是否有场景缺失和遗漏 第六步:大家共同标注客户场景中的High Point和Low Point 第七步:根据High Point & Low Point选择团队下一步的主攻方向。   好处是: 1. 与传统的闭门想车相比,更加从客户角度考虑问题,思考客户的痛点 2. 团队会建立对于客户问题的共同认识

Share

傆型 – Pretotyping

精益创业中给出的A/B测试以及灰度发布已经是互联网公司里很常见的验证方式。但是这些方法很大的问题是需要实现功能才能获得验证,为了实现功能,必须要开发、测试,从而造成验证成本增长以及反馈周期过长。我们的同事Daniel Teng和Jackson Zhang一起参与了在一些项目中发展并实施了傆型,并把傆型宣言引入到了国内。 大量投入之前,先问问你的“事”这些问题: 关于行为:人们会调整自己的行为来适应它吗? 关于外观:做成这样人们会喜欢吗? 关于环境:人们会在自己所处的环境用吗? 关于定价:人们会接受怎样的价格? 关于功能:如果不能实现X,人们还会用吗? 关于渠道:他们会通过这个渠道购买吗? 这些问题最终归结到傆型宣言: 创新者重于创新点【创新点不如创新者】 傆型重于原型【原型不如傆型】 客观数据重于主观评价【主观评价不如客观数据】 实际动手重于 夸夸其谈【夸夸其谈不如实际动手】 简单重于 复杂【复杂不如简单】 当下重于 以后【以后不如当下】 承诺重于 呈阅【呈阅不如承诺】 Daniel和Jackson在意启部落发布了傆型的系列文章,包括 仿真门 看门人 探索者 匹诺曹 改头换面 试点区

Share

引导师工具箱 – 收敛的秘诀

前回讲到(”引导师工具箱 – 发散的秘诀”),说到团队过程以及创新的过程其实是一个不断发散和收敛的过程,而发散时需要注意一些要点。今天我们需要讨论一下引导师如何引导团队进行收敛。 发散型思考会产生大量想法,很容易让人吃不消。很多人的直觉反映是抓住其中一个想法,然后催促团体把讨论焦点放在那个上面,这种反射动作几乎一定会让团队陷入动荡,因为不同的人通常会想要把讨论焦点放在不同的项目上。因此引导师需要帮助团队找到共同关心的兴趣点。 第一步 – 信息分类 长清单会让绝大多数人吃不消,因此需要把清单缩短,减少到人脑可以处理的程度,很多人认为归类是组织资料的最简单方法。团队一起创造类别意味着一场哲学讨论,因为每个人对于选用的词汇在意义上有不同的看法,有的人细节导向,有的人擅长整体思考。要整合彼此的信念和定义会让大家感到不安、挫败,会抗拒。但这是形成团队决议的必要过程,这可以帮助团队增加对于彼此的了解。 分类会涉及两种不同的心理任务,创造类别和依类别将项目归类。 创造类别有两种方式 从头开始创造类别 – 类似于意启前一阶段发布的文章“静默分组法”,从信息中发现并提炼类别。 每个人轮流移动便利贴,把彼此相关的想法集结成主题 鼓励类别的合并以及其他变化 列出所有类别后,开始讨论 根据预先定义的条件创造类别 - 与团队事先讨论好类别。 一起选择一个或者多个条件,比如急迫程度、可行性、成本等 找几个人,将清单项目归类到选定类别中 一项一项的把清单项目归类 说明一个项目可以归类到超过一个类别 归类完毕后,一起审视 第二步 – 聚焦 对信息完成归类之后,需要从里面找到需要关注的类别,可以有如下一些方法: 测试性投票 每个成员有三票,可以随自己意愿分配 允许成员将所有票投给同一项目 不必把票都投完,尽管不鼓励 选择票数较高的几项 N/3 每个人分得相当于总条目数/3的选票 每个人可以按照自己的选择分配选票 选择得票排名前三分之一的选项   选出真心值得做和真的很便宜选项 每人分别有一票投给从长期来说真心应该做的条目,性价比超高的条目 收益矩阵 根据效果大小和实现难易建立一个矩阵 让大家把条目分别移到相应的象限 选择性价比高的条目   时间箱…

Share