Feedback

如何访谈用户并收集有用的反馈 (下)

上篇:如何访谈用户并收集有用的反馈 (上) 访谈技巧 #3: 不要问要什么,多关注为什么 如果我们的客户或潜在客户直接告诉我们他要什么以及愿意付多少钱,这不是非常棒么?当然很好,但是你最好不要依赖这点。你的客户不会告诉你你需要做什么。这是你的工作。所以,作为创业者,我们需要学习问正确的问题。 什么不是问题。为什么才是问题。 访谈对于预测未来行为没有太多帮助,特别是未来的购买意愿或者了解价格预期。 所有这些都是关于上下文的。你不能假定你的客户会把你的产品当作一个生意。他们不会的。对他们来说,这只不过是解决需求的一个方案。你的客户完全是以自己的需求为中心的。这就是为什么他们最终会买你的产品,那才是你需要寻找的。 我们的目标是真正理解我们的产品如何解决客户的问题的。当我们理解为什么他们需要它的时候,我们会很快意识到他们的需要。 访谈技巧 #4:

Feedback

如何访谈用户并收集有用的反馈 (上)

当我的合作伙伴和我勾勒我们下一次创业的时候,我们知道我们在做一些令人兴奋的事情。现有市场几乎没有一个好的博客编辑日历,我们觉得我们独特的方式能与用户产生共鸣。除了兴奋之外,我们还要验证我们的想法。我们开始通过用户访谈收集反馈。 我的第一个产品失败的教训之一就是我需要更多的关注如何收集反馈。过去的经验告诉我:我对如何获得好的反馈有根本性的误解。 对于新产品,我决定加大投入把这事做好。我买了Steve Portigal的Interviewing Users学习访谈的艺术。买这本书绝对是这次成功创业的关键之一。甚至更重要的是,这不是谁都可以复制的。 访谈在制造者和客户之间建立了连接。它使问题更实际和人性化。 回到现在,你会听到我说,没有什么比访谈你的用户更有价值,更令人兴奋。作为一个天生内向的人,我们花了不少时间理解并接受这点,但是学着去克服自己的缺点给用户打电话确实在我们收到的反馈的数量和质量上带来了巨大的变化。 我们不仅仅能和潜在客户建立连接,我们还能理解他们的真实需要。访谈是一门艺术,但是你必须虔诚地对待。 访谈技巧 #1:

Impact

创业与创新

这些年接触了不少的公司,创业团队和想创业的人。特别是今年办了创业周末之后,我发现很多人没有弄清楚到底什么是创业,什么是创新,他们之间有什么关系。 创业即影响。创新则是另外一件事。许多创业者使用创新来造成影响。解决一些困扰用户许久的问题,改变了某些人的生活工作习惯等等这些都是影响,这些影响一定会涉及到用户,受众和市场,这就是产生价值,生成利润的来源。但至于产生影响的方式则取决于你的解决方案,你可以去切水果,实现移动支付,做智能设备等等,这些以前没人用过的解决方案就是创新;但你依然可以用已有的方式来产生你的影响,比如做外包项目,为客户作IT实施,去做家政等等。 很多人说他们有不错的点子,那么你能用这个点子造成影响么?创业(其实很多事都这样)说白了就是:认识问题,确定解决方案,验证解决方案,不断的迭代这一过程。

Refactor

单元测试与TDD工作坊

继上次单元测试工作坊之后,我和Joseph在此基础上持续迭代,融入测试驱动开发,将工作坊扩充成一天的工作坊。 在这次的工作坊中,我们将继续探讨什么是单元测试?怎样才能写好的单元测试?如何在实际工作中编写优秀的单元测试?掌握单元测试自然而然就会想到测试驱动开发,到底测试驱动开发是怎样的一种开发方式?如何利用单元测试做好测试驱动开发?我们将融入代码道场与大家一起切磋。这里没有说教,我们只用代码沟通,快来尽情体验吧。 这次我们依旧不限制语言,所以带着你熟悉的开发环境一起来玩吧。 地址:上海浦东新区银宵路39弄(浦东世纪花园二期)3号楼1002室(Odd-e办公室) 时间:10月20日上午9:30~下午6:00 费用:500元/人(含培训午餐) 报名方式:http:

Agile

单元测试工作坊

我和Joseph一直以来想把更多的工程实践分享给更多的人,和大家一起朝着软件工匠的目标前进。一直以来我们做过Coding Dojo,Code Retreat以及Kata接力等等,现在我们想采取更直接的方式——工作坊。 我们选择单元测试作为第一次工作坊的内容。到底什么是单元测试?怎样才能写好的单元测试?如何在实际工作中写优秀的单元测试?我们将在工作坊中一起寻找答案。当然我们选择工作坊这种形式,也是贯彻我们一贯高互动的方式。不写代码如何学会写代码,这也是我们不断提高的唯一方式。不过要小心哦,我们设计了不少的坑等着你来跳。 另外我们决定这次不限制语言,所以带着你熟悉的开发环境一起来玩吧。 地址:上海浦东新区银宵路39弄(浦东世纪花园二期)3号楼1002室(Odd-e办公室) 时间:9月28日下午1:00~6:00 费用:200元/

Conversation

沟通是需求管理最重要的部分

需求如同迷雾一般抓不住,捉摸不定,内在往往被表象所蒙蔽。可需求又总是不断的在人与人之间流动传递,这个过程十分容易造成所有人的对需求的理解是不一致的。这会产生大量的常见的浪费:来回的返工、修Bug;PO和团队前期调研不足,对需求没有充分认识,在迭代中频繁的变更需求导致一个功能反反复复的做等等。 那么到底需求的本质是什么?并不是我们常在需求文档中看到的各种解决方案。而恰恰是这些客户或者PM表达出来的解决方案掩盖了用户的真实需要(need)。这些need可能是某个用户的问题,可能是用户想要达成的目标等。Need如同宝藏一般,需要我们去挖掘。因为大多数时候,大家表达自己的需要的时候,往往通过具体的解决方案来描述的。直接把解决方案拿来当做需求往往会导致用户的问题迟迟不能被真正解决,还可能会带来负面效果。其实用户有问题来找我们解决,是因为我们是这方面的专家,可我们却没有针对用户的问题设计解决方案,反而使用用户告诉的解决方案。这本身就不符合逻辑。 还有很多时候,用户自己都不一定清楚自己真正的需要。我们需要通过访谈,观察等形式和用户一起来挖掘他们的真实需要。

Agile

被我们工作影响的人

上次说到我们需要一个明确的目标,那么实现目标最重要的是什么?人!人是第一要素,我们需要最先考虑的。 在实现目标的过程中,我们需要改变哪些人的行为?谁能帮助我们产生我们想要的效果?谁又会阻碍我们实现目标?谁会被我们工作影响?如果我们是在做产品,那么哪些人是客户,哪些人是用户也是需要我们想清楚的。在我们决定开始做什么功能之前,不妨先把这些问题回答一下,看看我们是否能得到一份清单。现在大多数需求都忽略了这点,大家都更多的专注于我们的软件应该做什么,而不是哪些人可以从中受益,哪些人的情况会变得更糟。 我们的祖师爷Gerald Weinberg曾经将质量定义为“对某人的价值”。如果一个功能没有给任何人带来价值,这个功能做的再华丽,再完美有什么用呢?软件不是在真空中独自运行的,它总会涉及到一些人。这些人都有各自的需要,目标和偏好。如果我们真的想要达到我们的目标,应当先考虑这些人,而不是只想着交付什么软件功能。

Kata

[视频]质因数 Ruby版

这次Kata练习做的是求质因数,这个练习比较简单,适合初学TDD的同学练习。在给刚接触TDD的同学介绍TDD的时候,我比较喜欢用这个练习,可以给大家展示TDD的效果,帮助大家建立TDD的信心。 但是这次练习只是给大家做个演示,这种TDD的做法做的比较顺畅其实是一个巧合。解题思路完全是被case牵着走,在别的情况下前进是十分艰难的。解题之前需要对问题有比较深的认识,自己设计一步一步的case,知道case能把我们带向哪里,逐步向目标前进。 今天的这个视频过程十分的坎坷...各种手误,还不小心关了编辑器。根据上次的反馈,这次我增加了些解说,整个过程有些刻意放慢,时间拖到了20多分钟。其实这个练习大家自己做的时候也就10多分钟。 上次使用ScreenFlow自带的快捷键显示工具,感觉显示了很多多余的按键操作,这次使用了另外一个开源工具:KeyCastr。 使用的工具: Ruby 1.9.3 RSpec

Coach

期待惊喜

第一次见识到Ripley神奇的Graphic Recording是在2011年一块年会上,第一次了解到还可以这样画画,图像可以用来引导。后来我们就把Ripley邀请到11年的Scrum Gathering Shanghai,为大会作Graphic Recording,令许多人叹为观止,成为那一届大会的亮点。 然而,我对自己绘画能力还是有自知之明的,这个东西离我还是太远。当听说Ripley要开Workshop的时候,我就迫不及待的报名了。虽然我看了课程介绍依旧有点不明所以,但之前参加一块年会的经验告诉我,抱着期待惊喜的心态准没错。 一去现场,果然和一般的工作坊是不同的。空空的场地,大家围成圈坐在地上,中间白纸上整齐的摆着一圈彩笔。大家都各自在纸上画画用来介绍自己,果然画画的工作坊各种环节都离不开画,checkin当然也不会例外。此时我依旧不清楚我这两天能收获写什么,纯粹还只是抱着体验的心态,好奇接下来还会发生什么。 接下来的环节是大家每个人在墙上的大白纸上随意画出自己的线条。当时,我就在琢磨这是在干嘛。

Discovery

为什么

“为什么?”估计是我这几年问的最多的问题了。PO跑过来告诉我们要做一个新功能,我的第一反应就是“为什么?”“我们为什么要做这个功能?”“做这个功能对我们的业务有什么提升?”,PO可能会说这个是客户要求的,“那么客户为什么需要这个功能?”……总之就是打破砂锅问到底。我们办社区活动的时候,我都会先问为什么要办这个活动?这个活动可以给我们带来什么?给社区带来什么价值?哪怕是我在想新的话题或者培训的时候也会问一个为什么,我想给听众、学员带来什么。现在在产品线做教练,PM抛出来一个新的功能想法,我依然会问为什么,了解这个功能可以给我们带来什么。以至于在家里老婆大人说我们买房子吧,我也第一反应是为什么- -# 其实很多时候我问为什么就是想理清楚我们的目的到底是什么,而不至于被这个具体的解决方案给绑架了。人在描述需求的时候往往都会用一个自己的解决方案来表述。比如,小孩说我要吃苹果,那么她的需求是什么呢?有可能是饿了,或者是渴了,或者是想吃甜的东西,

Ruby

[视频] 罗马数字Kata Ruby版

最近这两个月一直在坚持每天做Kata练习,有不少的收获。我会挑一些比较有意思的做成视频发出来,也算是Kata接力的继续吧。 很巧这次做的Kata练习依然还是罗马数字,只不过上次用C#,这次换成了Ruby。另外,这几天学习了一种新的解法,不同于之前的递归,代码也相对简洁。 以前的做法多是放弃提取1到10之间的规则,直接使用字典。这个做法就是尝试发现1到10之间的规则,将4和9作为特例处理。充分利用了罗马字母叠加的逻辑。 在TDD过程中,不断使用愚蠢的办法制造重复,然后再重构的过程中,通过不断抽象重复推进代码演化。这个练习中Case的选择并没有体现出来,只需自然的顺着数字前进,因为数字顺序与逻辑演化方向是大概一致的,所以不会出现case路径选择问题。   第一次在Mac上录视频,还第一次献“声”,有点小紧张。 使用的工具: Ruby 1.9.3

C#

又见斐波那契

之前公司在找人面试的时候,我几乎必问的题目就是斐波那契数列,题目很简单,就是求斐波那契数列第n位的数值。很多教科书都会使用这个题目来做例子。每次我都是给面试者一只笔和一张纸,让他写出来,基本上不会给任何限制,随便使用任意语言,任意解法。之所以让我这么爱用这个题目的原因是,这个题目虽然简单,但是有一些小坑需要处理,可以和面试者讨论这些坑的处理方式,执行过程中发生了什么,探索一些不一样的解法等等,可以比较好的了解候选人的思维。然而,让我诧异的是,没有几个人能思路清晰的写出解法来,并说出思路以及里面的坑,好容易有写出来的却没法说清思路以及改进方式,甚至有许多工作多年的“资深”工程师都写不出来。 一般最常见的写法就是简单的递归实现: public int Fibonacci(int n) { if (n

ATDD

你什么时候翻薄饼?

你什么时候翻薄饼?我们知道好的薄饼是什么样子的。两面有些棕色,边缘一圈白色。当你从一坨面糊开始,而整个餐馆坐满了饥饿的伐木工时,你怎么才能让你的薄饼达到这些需求呢? 这些需求非常明确,棕色的两面,白色的边。还有比这更简单的吗?下面让我们设计一个开发流程,能顺利得到符合要求的薄饼: 开发人员倒入面糊。 开发人员按时间表翻薄饼。 开发人员把“完成的”薄饼扔给墙那边的QA。 QA检查薄饼。把不合格的薄饼扔回给开发人员去“修复”。 很明显,除非开发人员十分擅长估算,否则这个流程的结果就是一大堆浪费的薄饼,推迟的早餐,愤怒的客户,还有担心成本的财务会建议采用外包来开发薄饼。 好吧,让我们设计另一个不同的流程。观察做薄饼的过程,我们发现翻饼的最佳时机是最上面的泡刚破,表面开始开起来有点干的时候。 开发人员倒入面糊。

Coach

Refactor之痛

实践敏捷开发这么多年来,我十分清楚重构重要性,不断清理代码,如同吃完饭要洗碗清理厨房,要经常打扫房间。然而实际上我并没有经常打扫房间,虽然我“知道”要经常打扫,结果只是偶尔想起来做一下。直到有一次出差了一段时间回到家发现,桌上灰层实在是太多,键盘,鼠标,鼠标垫上都是厚厚灰层。我无法忍受了,都不愿意碰鼠标和键盘了,对于我这个“技术宅”这事可大条了,我得去清理了。拿起抹布开始清理桌子,发现地上也很脏,扫地拖地吧。再出现这样的情况我可受不了,得预防一下吧,那就定期做一下清洁工作吧。我还是比较懒的,那就一个星期做一次吧。我突然意识到我现在的教练工作不也是同样的道理么。 教练不是上来就解决问题,反而要通过一系列迫使他真正意识到自己的问题(“你们的代码太垃圾”

Coach

这是谁的问题?

“我们这里有些问题,教练来帮我们解决一下吧。”有的团队会自己意识到问题来主动找教练。问题往往来自于期望和感受之间出现了落差。团队期望的工作方式或者结果和他们实际感受到的不一样,每次团队都期望这次应该没问题,结果还是质量问题,项目延期,需求变化,多次返工等等。 他们来向我求助的时候,往往隐含着他们理解的“敏捷”就是解决方案。当我看到团队的一些问题的时候,有时我心里也会想着,做了这个实践就可以改善这个问题,做了那个实践就可以避免那个问题。然后开始和团队一起着手实施,过程往往困难重重,结果也不太理想。所以,不要把问题的解决方案当成是问题的定义——尤其是当解决方案是有你自己提出的时候。 在团队中有时会观察到“Scrum每日站会总不准时开”,“几乎不开回顾会议”。然后我和团队提出我的观察,然而团队却反应平平,或者不觉得这是问题。我自己反思过这到底是谁的问题?这些都是教练的问题,不是团队的!

Agile

敏捷,传播,改变

今天微博上对Daniel的敏捷转型教导(Coaching)话题狙击手原则(iSNIPER)有很多的评论:很多人似乎觉得搞敏捷的就喜欢整一大堆的术语,不太靠谱。 这里面其实包含了三个概念:敏捷,传播,改变。我经常碰到有人认为敏捷包含这三个意思。敏捷这个词已经被用滥了。 敏捷:或者叫作敏捷软件开发,一个涵盖性术语(umbrella term),代表着一组基于迭代递增开发的方法(参考维基百科)。敏捷不过是个词而已,追究你是否“敏捷”一点意义都没有,关键在于你如何思考,如何做。如同你穿的衣服上的商标一样,管你是CK,还是班尼路。真正做敏捷的不会到处说他在做敏捷,只是说他是怎么做的,怎么思考的。 传播:

C#

[视频]Kata接力 - 罗马数字

上次在Global Day of Code Retreat上,和Joseph@姚若舟提了Kata接力的想法,Joseph去做了个Java版的罗马数字http://www.tudou.com/programs/view/jr-iJXpqIR0。实在不好意思拖了这么长的时间,才花时间做了这个C#版的视频,同样也是罗马数字。 我的想法是罗马数字唯一的逻辑是每一位的数字转称罗马数字并拼接,其它的一律作为字典处理,因为逻辑1到10之间的规律不值得抽出逻辑来,直接字典来的比较直接。由于罗马数字最大也就3999,所以十位,百位,千位也直接用字典了,如果还有更多,那么就该提取逻辑了。 我在实现的过程中,中间有几次打断。转递归的时候卡了一下,其实是这里的重构步子迈的大了些。

Change

说服力

我们在平常生活工作当中经常会用到说服这个技能,比如和同事家人商量、讨论问题的时候,销售人员向客户销售产品的时候,教练改善团队工作的时候等等,有非常多的场景。那么如何有效的提高你的说服力,也就是影响或改变对方的想法呢? 首先,毛爷爷说过:不打无准备之仗。做好准备是至关重要的。预先要想好你想达到的目的,如何做,如何回应对方的提问或疑虑,何时应该停止说活。做过演讲的都知道,不管你在台上说的多么生动有趣,听众的心思仍会四处飘荡。这是人类的天性。你的目的就是尽你所能控制对方的注意力。准备做得越充分,表达越流畅;准备得越好,对听众的控制力越强。 要有亲和力。也就是一个十分显而易见的道理:人们都愿意被自己喜欢的人说服。当一个人带着愉悦的心情想人们靠近时,人们会减弱他们的戒备心理;这个人应表现得热情,而且没有明显的不可告人的动机;而且具有一种讨人喜欢的品质。

GTD

《时间管理》读书笔记

有人推荐我看这本《时间管理》,因为形式是以漫画为主,只需花2个小时就可以读完,正好我也需要对个人系统进行整理,所以买来看看,也许能解决我的一些问题。 下面是书的最后列出的要点,几乎可以概括整本书了:  自我意识是先决条件 意识到如何支配时间,才能管理时间 记一个星期左右的时间日志。观察哪些方面可以重新分配时间支出 目标设定是第一步 如果连朝哪个方向都不知道,那么这是在盲目的旅行 选择是艰难的 时间管理最终是关于作出选择的 每天24小时,每星期168小时。如何使用这些时间,选择权在自己手里 目标达成就是作出艰难的选择——在许多需要付出时间、相互竞争的需求中作出选择 你可以“创造”时间 寻找方法将非生产性时间转变为生产性时间 通过运动和健康饮食增加能量。每个小时里精力月充沛,这个小时对实现目标所发挥的作用越大

Coach

Impact Mapping

最近做了几次Workshop都用到了Impact Mapping(也叫Effect Map),上个星期的Meetup也讲到这个技术。 Impact Mapping可以帮助分析思考问题,甚至行动乃至沟通。可以类比Simon Sinek的Golden Circle模型 Why - 为什么我们要做这事?我们的目标是什么?希望对这个世界产生什么影响?一切都是从这个出发。 一般目标需要满足SMART特性,需要有度量标准,帮助我们定义怎样才算达到目标,同时可以不断检查我们是否在朝正确的方向前进 度量标准不是目标,只是从某一维度对目标的衡量。比如,提高产品质量时目标,Bug率降低10%是某阶段目标的衡量指标,Bug率是度量标准。但不能以Bug率降低10%作为目标,否则本末倒置 Who -

Global Day of Code Retreat 2012 -- Shanghai

12月8日全球有将近160个城市一起参与组织了Global Day of Code Retreat 2012。上海站在创新工厂,由我和姚若舟Joseph(@姚若舟)一起组织。这次网上报名有60人,实际来了35人,已经是历次编程活动参与人数最多的了。之前在Scrum Gathering Shanghai 2012中Open Space的环节做了一次Code Retreat,感觉不是很正式。这次是完整一天的Code Retreat,感觉十分不同。这次还和同时区的其它8个城市一起视频连线,试了把Google Hangout,十分酷。 Code Retreat是一个一天的集中练习的活动,专注于软件开发和设计的基础。通过给开发人员提供专注练习的机会并远离完成工作的压力,CodeRetreat这种形式已被证明是提升编程技能的有效方法。通过练习模块化和面向对象的基本原则,

工作坊:从想法到Sprint Backlog

曾经有个项目在预算的一年之内按时完成,大家都说这个项目很成功。可是一年之后,这个项目还是没有客户。在产品开发过程中,最重要的并不是“把事情做对”,而是“做对的事情”。如果从一开始产品的开发方向错了,哪怕开发做得再好,结果还是失败,浪费。当你有个想法,如何发现目标客户?如何发现这些目标客户所需要解决的问题,从而找到正确的“事”?如何保证这些想法可以转化成需求,形成产品 backlog?接下来又该做什么让高优先级的需求可以在两个星期内被实现,从而可以直接从客户那里获得真实地反馈?整个过程的好坏决定了项目的成败 在这个工作坊中滕振宇和张博超一起帮助大家从一个真实的项目中来体验包括产品经理在内的开发团队一起合作把想法转化为产品Backlog,再到Sprint backlog的整个过程。 这次工作坊不会设置统一的价格,由参加者根据自己的收获评估工作坊的价格,就好比去同事婚礼送红包,“这些内容值得我付出月收入的5%”。强烈建议不要超过个人的承受能力。 人数:

Agile Tour

AgileTour Nanjing Retrospective

AgileTour南京终于结束了。在回上海的途中,我们在高铁上对这次活动的第一天做了一次Retrospective。由于行程只有一个半小时,所以这次的Retro必须是强制的TimeBox。这次Retro历时1小时左右。 参与人员:滕振宇,张博超,齐微,冯欣,黄灵,麦天志 具体过程如下: 写出关于第一天还记得的任何场景,事情或细节 每个人把自己些的PostIt贴在窗户上,并做简单介绍 按照各环节的时间段进行分组 大家对各个环节给出Comments 下面是各个环节的Comments 上午9:00 9点了南大都还没有人 Check-in互相介绍 ScrumGathering讨论 沟通出现问题(ScrumGathering营销,还是讨论?) 没有Agenda 临时安排了Open Discussion比较好的解决了上午的讨论 下午的准备工作和上午的活动重叠

Agile

用敏捷的方式翻译敏捷经典《User Stories Applied》(三)

厄…一不小心,这最后一部分拖了这么久才写,得先自我检讨检讨。这最后的部分其实是此次翻译中最重要的一部分。这篇我将分析为什么这次翻书会比较成功。当然,这个成功的定义来自于出版社的反馈,较高的质量以及如期的交付。 首先,我们是一个分布式的团队。曾经有段时间我在美国出差,Bill也经常在国外飞来飞去,而且我们都是兼职来做这个翻译,几乎不怎么见面。那么我们是怎么解决沟通协调的问题呢? 我们使用了看板,其实也就是一个Excel表格。但是就这么简单的一个东西提供了一些项目的可见性,更重要的是它帮助我们协调任务。我们可以很容易的避免两个人做重复的任务。 每周的同步会议。从中我们可以知道,现在项目的状况。同时,大家要对未来一个星期做出commitment,即下个星期要做什么。然后是提出遇到的困难,大家一起沟通商量解决方案。其实也就是Scrum中Daily Scrum每个人要回答的三个问题。最后就是Retrospective,回顾一下我们现在项目中有什么需要改进的。

ibus

一款Ubuntu中不错的国人输入法sunpinyin

使用Ubuntu当然免不了要用输入法,可是系统自带的那个输入法实在不好用,而且貌似还和firefox冲突。Google输入法ubuntu版又完全没有音讯(有兴趣的可以尝试github上的一个开源项目SCIM-GooglePinyin,这是将android上的Google输入法移植到linux上的)。于是我只好找其他的输入法,有两款输入法进入了我的视线范围:sunpinyin和小企鹅。小企鹅还没有试过,等以后使用了再说。 sunpinyin最早是在twitter上从一帮苹果fans那听来的,口碑不错,都说好用。有次偶然想起,在Google上搜索看有没有linux版,结果还真发现有linux版的ibus-sunpinyin。安装起来不是那么方便,毕竟不是发行版,得自己编译。这是我第一次在ubuntu上下code自己编译安装。 首先要在ubuntu中装一些编译环境和类库: sudo apt-get install build-essential libtool libibus-dev libsqlite3-dev intltool 剩下的事当然就是拿代码,编译安装了。可以选择git或mercurial拿代码,