什么是服务设计

近几年来,体验设计界有一个热门的名词,叫做“服务设计”。在第一次接触这个名词的时候,我有点摸不着头脑:

  • 它和体验设计有什么不同?
  • 它是一种新的设计方法,抑或只是对旧设计方法的一种包装?
  • 服务二字到底指的是什么?

抱着这样的疑问,我翻阅了很多书籍、文章,看了不少演讲,但非但没有让我对它更多了解,反而让我更疑惑了。似乎每个人都对服务设计有自己的解读,而且它似乎无所不包。

后来,我有一次住酒店的时候走楼梯下楼,看到坐在楼梯间休息的清洁师傅,突然明白了服务设计的意义。这次,我就跟大家谈谈什么是服务设计。

从一个用户到多个用户

作为体验设计师,我们最关注的是用户的体验。在我们看来,用户要使用一个产品,必然要达成某种目标,而我们则需要帮助他们以最快或者最舒适的方式来达成目标。

tumblr_inline_nfpbiki6BW1rxo9iy

:只有针对特定人群的设计才是体验设计

为了达到良好的体验,我们不断对用户群体进行细化,最后剩下了一个用户。我们专门为她来做设计,希望给她最佳的体验。问题在于,工具是一个人用的,但现实生活中的服务常常不止一个人参与。

比如说,“教学”这个服务就至少包括了“老师”和“学生”这样两种人参与。对于一个服务来说,二者都是“用户”,而他们的体验也都是我们关心的对象。除了教学之外,通常IT系统都存在管理员,比如以前论坛的版主,或者内部系统的网管等等。互联网产品也是如此,使用方,管理方,两种角色。

tumblr_inline_nfpc2ft9qP1rxo9iy

:一项服务往往有多个参与方

不过,虽然角色变多,但由于他们属于管理关系,相对独立,所以二者的体验通常不会有太多交集。管理者和使用者一般会使用各自的界面,也可以有针对性地地进行设计。

支撑服务的其他角色

现实生活中,要实现一项服务,参与的角色远远不止两个,而且相互之间常常会造成影响,不像理想中分割得那么清楚。

比如一个网上商城。从我们打开一个网站,找到一个商品,下单,支付,最后快递上门收到货物,其实中间要经历很多步骤,而且有很多人参与:

  • 下单之后,我们需要支付,这里面就涉及到和银行和支付机构的对接
  • 支付的钱要进入财务的系统,财务需要记账,并通知仓库备货和发货
  • 仓库人员收到货物之后,需要找到货物,打包,打印单据,准备发货,并更新库存
  • 物流公司会来取货,留下一个快递单号,仓库人员需要把快递单号和订单号对应,录入系统
  • 货物送到之后,快递状态更新,订单状态随之更新

这还仅仅是正常情况,如果要加上退货、换货的流程,或者加入赠品、套餐、促销、礼品卡等等概念,则整个流程会更加复杂。它的复杂不在于步骤的多少,而在于需要多次和第三方进行合作,用户的行为也不可控。整个流程中出现任何问题,都会对用户——那个我们称之为“最终用户”(end user)的人造成麻烦,导致体验变差。

tumblr_inline_nfpcs54wMZ1rxo9iy

:用户体验是服务最重要的部分,但也只是其中一小部分(粉色 = 用户体验相关;橙色 = 服务运营相关)

如果单从体验设计的角度来看,也许我们的目光会集中在商城的商品列表、展示、支付和搜索等等页面,大不了再加上管理端的设计。这样的设计也许看上去体验很好,但有可能会造成其他部分的麻烦,或者遇到实施方面的问题,又或者根本就无法落实。

所以,我们必须注意角色和需求之间的搭配,平衡,哪些地方该标准化,哪些地方不能标准化,使整个服务能够完善起来。

领域内外专家的配合

也许看到这里,你已经知道当时我是怎么“顿悟”的了。

我因为工作的关系经常都会出差,所以也常常会住酒店。作为一名住客,又是做体验设计的,所以我会对酒店的楼层、房间、装修、设备等等比较敏感。不过,我通常只会看到最后的结果,也就是我亲自会接触和使用的部分。

在楼梯间看到休息的师傅之后,我意识到:每天房间都会有师傅来打扫,但实际上并不是换个床单和洗漱用品那么简单。

tumblr_inline_nfpdc2DoHK1rxo9iy

:酒店房间的清洁这样简单的事情也需要一个服务体系的支撑

换下来的毛巾和床单如果要清洗,那么就必然涉及到一个洗衣房。这个洗衣房如果是内部经营,那么就还会涉及到大型洗涤设备、操作人员、洗涤剂、排污和环卫措施、设备维护保养,等等。除了洗涤,还有晾晒,还有储存,消毒等等一系列的工作需要做。如果是和外部合作,又会涉及到运输,等待时间,质量保障,财务来往,等等。

最后一步,才是给房间换上清洁的毛巾和床单。

洗漱用品也是如此。向哪家供应商订购,如何运输,如何确保质量,如何储存,库存如何清算……有了这些,才有最后师傅来更换的那一步。

所有这些都是整个酒店生态体系中的节点。虽然“客户体验”的重要性不言而喻,但它其实只是这个生态体系中的一个层面。要设计这样一个生态体系,就必须对整个生态体系和流程有比较深入的了解,也就是所谓的领域知识。

领域知识包括了有形和无形的经验。有形的经验,比如对流程的理解,对服务中各方的需要和诉求的理解,对行业标准和现状的理解等等。这些知识容易落成文字和传授,也相对容易学到。还有就是无形的经验,比如对异常状况的处理,对服务中各方“脾性”的了解从而能采取合适的行动,等等。

我们可以用个很简单的例子来理解无形的经验。在使用一款手机之后,我们往往会发现它有一些小问题,比如点击了某个图标之后,会有一秒钟左右的黑屏,但用久了之后就明白了它这个脾性。手机有脾性,同理,服务的参与方也有脾性。对这些细节的了解累积起来,就形成了深厚的隐式知识(tacit knowledge),难以言传,但是遇到之后却能够从容应对。

掌握充分领域知识的人我们称之为领域专家。要设计一个服务,有一个服务所在领域的专家是很有必要的,因为领域专家知道这个领域的基本原则和边界,可以及早发现问题。否则,做出来的设计很可能无法落地或者难以实现。

tumblr_inline_nfpdjnH6xp1rxo9iy

:他可不是专业做音乐播放器的,或者手机的,或者手表的,或者……

不过,由领域专家来牵头做设计也会有很大的局限性。领域专家一般在一个领域扎根,这就有可能导致思维的固化。我们可以看看各个行业的创新者,那些体验好的产品往往是“局外人”提出。没有了原来的既有观念和条条框框,往往能做出好的设计。苹果公司做音乐播放器,踏入了索尼 Walkman 的领域,做手机,又踏入了诺基亚和微软的市场,但都“搅局”成功,就是很好的例子。

总结

tumblr_inline_nfpdwxzCCp1rxo9iy

:服务设计意味着视角的转变和提升

在一开始,我们谈产品或者系统设计,站在产品、系统、服务本身的角度来看设计(“房间干不干净?”)。后来,我们开始谈体验设计,转换成用户视角,站在用户的角度来看设计(“肥皂是不是年轻客人喜欢的品牌?”)。继续发展下去,体验设计都跟上之后,就应该转向做服务设计了——站在上帝视角,俯视和规划整个服务的运转,以满足多方需求,使整个服务体系达到平衡(“酒店能不能持续稳定地兑现口号宣传的承诺?”)。

要设计好的服务,就需要领域专家和体验设计师以及其他非领域专家的合作。我想,这也是为什么我们经常听到平面设计师、互动设计师、体验设计师,却很少听到“服务设计师”——因为这事根本不能成为一个职业,必须由一个团队来做。

tumblr_inline_nfox9rB1561rxo9iy

:1988 年,十二届三中全会的代表参观北京第一家超市——京华超市

虽然服务设计听上去很有意思,真正把服务设计当成一个议题,是最近才开始的事——这也正常,因为服务设计需要成熟的用户体验文化,并需要有很多领域专家。要知道,中国出现真正意义上的现代零售业,是 1984 年的第一家超市。出现现代的快递服务,是 1993 年。也就是说,很多行业都还很新,而且还有很多古老的行业(比如酒店业)正在经历革新。用户体验也是上世纪 90 年代才提出来的理念。

经历了几十年的发展之后,领域专家开始出现。有了互联网和一众互联网公司的强力推动,用户体验的理念也开始铺开。二者结合之下,相信服务设计会逐渐迎来春天,成为接下来设计公司的重要业务。

Share

现代Web页面开发流程

通常来说,Web页面开发的流程大致是这样的:设计师(设计师不是美工,就像程序员不是码农一样)提供设计稿,通常是图片格式。然后前端的开发人员(在ThoughtWorks我们称之为UI Dev)来手工的将图片转换为对应的HTML+CSS,往往还需要在各个浏览器中调试等。

大多数时候,设计师会提供色卡,或者至少前景色/背景色/高亮色的值给开发人员。如果没有的话,开发人员会用到一些工具如colorpicker, ruler之类来确保最终的效果和设计稿是一致的。

如果你观察过UI Dev的工作流程的话,你会发现基本的上是这样的:使用编辑器(或者IDE)编写HTML代码,CSS代码,保存修改内容,切换到浏览器窗口,按F5或者Ctrl-R刷新,然后对比设计稿和实现,如果发现不一致的地方,再切换到编辑器中修改代码,如是往复。

避免手工劳动

纯手工的方式来编辑HTML/CSS会非常耗时,特别是作为标记语言的HTML,开发者需要时刻关注关闭已经打开的标签。比如一个标题元素,你需要:

1
<h1>This is the page title</h1>

几乎从一开始,人们就想到了各种办法来避免自己重复的键入,比如Vim的SuperTab以及Snipmate插件,可以通过输入标签名+Tab来补全所有的标签等,又或者DreamWaver提供的代码生成的方式来简化这一流程。

Sublime的编辑器上的著名插件Emmet可以帮助开发人员飞速的开发HTML/CSS,这里有一个小例子。假设我们需要实现的页面是这样的:

web-design-resized

那么对应的HTML结构可能会是:

1
2
3
4
5
6
7
8
9
10
11
<ul>
    <li>
        <div class="feature">
            <span class="number"></span>
            <i></i>
            <h4></h4>
            <p></p>
        </div>
    </li>
    ...
</ul>

使用Emmet,则只需要给出表达式,然后按一下Tab键就可以补全为上述的结构了:

1
ul>li*3>.feature>span.number+i+h4+p

上边的这条命令可以读作:”创建一个UL,该UL下有3个LI,每个LI下有一个class为feature的DIV(不指定元素名称的话,默认生成div),每个DIV内,有一个类为.number的SPAN,一个i元素,一个H4元素和一个P元素”

完整的技巧可以参看官方文档

避免重复劳动

上边提到的频繁的F5刷新,可以通过LiveReload+Guard两个工具的组合来解决。LiveReload是一个浏览器的插件,通过协议与后台的服务器进行通信。当后台文件发生变化时,LiveReload会自动刷新页面。

Guard会使用操作系统的API来感知本地文件的变化,当文件变化后,它可以通知LiveReload进行刷新,当然Guard可以做其他一些事情,比如等SCSS发生变化时,自动编译CSS等。

两者结合之后,就可以节省我们大量的时间,而把精力主要投放在开发这件事情本身上。

样板工程

我在Github上公开了一个样板工程,这是一个开箱即用的工程,其中提供了这样一些配置:

  1. SCSS的编译环境(使用compass)
  2. Guard配置(当你的SCSS文件或者HTML文件修改之后,自动通知LiveReload来刷新浏览器)
  3. 一个标准的HTML5样板文档
  4. 一个基本的style.scss

Guardfile的配置中,如果index.html发生变化,或者stylesheets中的css文件发生变化,或者scripts目录中的js文件发生变化,都会触发livereload任务(通知浏览器)。

1
2
3
4
5
6
7
guard 'livereload' do
  watch('index.html')
  watch(%r{stylesheets/.+\.(css)})
  watch(%r{scripts/.+\.(js)})
end

guard :compass

你只需要简单的将这个工程克隆到本地:

1
$ git clone git@github.com:abruzzi/design-boilerplate.git mydesign

然后在该目录中执行bundle install即可:

1
2
$ cd mydesign
$ bundle install

这里有两点假设: 1. 你已经安装了rvm 2. 你已经使用rvm安装了某个版本的ruby,即bundler这个gem

开发流程

我通常会启动两个终端,一个用来运行Guard,另一个用来运行HTTP Server,然后是一个浏览器:

workflow-resized

当在编辑器中进行编辑之后,保存文件,浏览器会自动刷新,这样的快速反馈可以告诉我下一步应该如何修改:将背景色调整的再淡一点,还是把会h2的字体变得更大,或者图片和文字的上边缘没有对齐等等。

这种开发流程和后台开发人员进行TDD的方式非常类似:实时反馈,小步前进!如果你的桌子上有两个显示器的话,那就更好了,你可以在一台显示器上显示设计稿,另一台上分屏显示编辑器和浏览器,这样就可以非常舒服的进行UI开发了:

two-displays-resized

Share

写作驱动学习

本周在公司做了一次内部分享,主要目的是鼓励大家写作。但是作为一个建的博客比写的博客还多的人,心里实在是没什么底气讲这个题目,所以就搜罗了大量的资料,看能不能从前人的智慧中吸取一些灵感,显得不那么无知,结果做下来,收获破多。

众所周知,写作有很多的好处:可以记录和巩固学到的知识、扩大自己的影响力、提升和推销自己等等,甚至很多人通过写作出书,成名,改变了人生的轨迹,这种例子很多很多。至少我每次听到这类的故事都会陷入深深的自省,痛恨自己没有早一天开始行动,然后痛定思痛,立即新建一个博客或是把之前落满灰尘的博客打扫打扫,重新发一篇《新的开始》,然后……就没有然后了。周而复始,自己也慢慢失去了对自己的信心。

所以问题的关键不在于我们不知道写作的好处,而在于我们做不到,就像大多数的鸡汤文一样,要知道“总有一天”是不靠谱的。对于放弃我们总能找到很多理由:没有时间,总有更重要的事情;反正知识已经掌握了;不知道写什么;觉得自己想写的东西不值一提,怕被人笑话等等。后来我想清楚了,归根到底就是四个字:觉得不值,假如有人给我500万让我写篇博客,我想上边那些理由就都不再是任何问题了。

那么什么样的事情是我们心甘情愿想去做的呢?为什么我们喜欢玩游戏而不喜欢写作业?那些我们根本不需要”坚持”就能一直做下来的事情都有什么样的特点呢?想来想去我认为一般要符合两个条件:快速的正向反馈、相对容易

我就曾经疑惑过学习与玩的区别到底在哪?玩游戏可以让我们相对容易的就能短时间内满足生理或是心理上的需求。但是学习首先不容易,有好处但反馈周期都相对较长,我们很难获得比较快的正向反馈。可是有些好学生就非常喜欢学习不是么?因为他们可以从每次考试,每次回答问题,从老师家长赞赏的同学羡慕的眼光中中得到很多正向反馈,而更重要的是这种反馈足够快,所带来的收益已经抵消甚至大过了在学习上投入的成本,这就是为什么好学生会越来越喜欢学习的原因。

我们常说要培养孩子的兴趣,这样他就能某一方面作出成就。我认为这个逻辑反了,应该是先促使或是找到或是暗示孩子在某方面的成就,让他觉得自己在这方面比别的小朋友强,他就能在这件事情上持续获得更多的正向反馈(例如夸奖,奖励,其他小朋友的羡慕),就会越来越喜欢做这件事情,兴趣自然而然的就形成了。

所以说学和玩本质上没有什么大的区别,主要是付出成本和短期收益的差别,甚至通过调整这两个维度学与玩是可以相互转换的。例如每个电子竞技选手每天都要在一个游戏(竞技项目)上玩(训练)超过10个小时,对每一个操作细节都要反复练习,而每提高一点点都非常的困难,每天要被教练训,在比赛中还很难获胜,需要承受着家庭和社会的压力,对于他们来讲,这已经不是在“玩游戏”了,虽然外人看起来没有什么差别。

很多牛人可以通过心智自我管理,推迟幸福感,用长远利益来驱动限制自己的行为。不过那是需要天赋和训练的,对于我等凡人,如果一定要坚持做一件事情我们认为需要坚持才能做到的事情,我认为可行的办法就是:能否找到一种适合自己的鼓励方式能让我们自己在做这件事情的时候能够得到持续快速的正反馈,并尽量把这件事情变得容易。

回到写作这件事情,抛开那些“总有一天”才能实现的好处外,眼前的好处无外乎就是帮助我们记录理解消化沉淀学到的知识了。不过我们的内心里总有一个声音反复出现:反正书看了,Session听了,感觉知识已经学会了,那还值得花时间写么?我用这个时间多学点东西不更好?

李光磊在《知行合一》中将知识划分为信息,知识和智慧。这解开了我很多对于学习的疑惑:为什么我看了很多书还是不会用某项技术?为什么我们听了很多Session,但是感觉却没什么用?为什么同一本书不同人看或是同一个人不同时期看会有不同的收获?原来我们之前所认为的学习只是获取信息而已,如果不思考,不行动,这些信息将一文不值,随时间消失,而浪费掉的却是宝贵的时间。而同样的信息,不同的人或是人的不同时期通过思考转化为的知识也是天壤之别的,所以说书只是一面镜子,我们读的看的其实是我们自己而已。

所以为了真正的学到知识,而不单单的是收集信息。我们需要用行动来将获取的信息加工吸收变为自己的智慧的一部分,而写作算是比较简单廉价的方式了,所谓写作驱动学习,正是如此。就像测试驱动开发中的测试一样,写作一旦完成,理论上就可以丢掉了,发不发布,有没有人看,写的好不好,都已经不是那么重要,它已经体现了它的价值。相信只要能体会到这种好处,不断地用写作来驱动学习,注重积累和推广,那些长远的好处也会自然而然的在某一天突然到来。

最后,不论你觉得上面这段文字有没有道理,它对你来讲只是一段信息,如果没有思考,没有行动,那就只是在浪费你的时间而已了。

Share

说起BDD,你会想到什么?

706-林冰玉-说起BDD你会想到什么

在刚接触BDD(Behavior Driven Development,行为驱动开发)的时候,我以为就是用Cucumber这样的工具来编写场景用例,从而实现自动化测试,甚至很长时间分不清BDD和ATDD(Acceptance test driven development)到底有什么区别。那么,BDD真的就是用来做自动化测试的吗?本文就来跟大家分享一下我理解的BDD。

 

为什么要BDD?

开发软件系统最困难的部分就是准确说明开发什么” (“The hardest single part of building a software system is deciding precisely what to build” — No Silver Bullet, Fred Brooks) 。

场景一:业务分析人员觉得自己分析的需求已经写的很清晰了,并且跟技术人员进行了足够的沟通,可是开发完sign off的时候,发现所开发的功能还是跟期望有差距。

场景二:开发团队辛辛苦苦开发完一个功能,满怀信心的去给客户展示的时候,才发现原来客户需求的功能不是这样的。

这些场景是不是似曾相识?为什么会这样?第一个场景是开发团队内部技术人员跟需求分析人员的理解有偏差,导致大家理解的需求其实是不一样的;第二个场景是开发团队没有真正理解产品经理/客户所提出来的真实需求,导致开发的产品跟需求不一致。其实,产生这两个不一致的真正原因是因为不同角色有着不同的领域知识,说着不同的语言,大家在沟通的时候,如果都用自己领域语言,必然会产生沟通代沟,导致理解的不一致性。

领域知识不同、语言不通导致沟通障碍,这个客观存在的问题该如何解决呢?BDD正是为此而生。

 

BDD是什么?

BDD的提出者Dan North强调BDD不是关于测试的,它是在应用程序存在之前,写出用例与期望,从而描述应用程序的行为,并且促使在项目中的人们彼此互相沟通。

要给BDD下个清晰易懂的定义很难,包括大师们也这么认为,这里试着总结以下几点:

  1. 关注的是业务领域,而不是技术:BDD强调用领域特定语言(DSL, domain specific language)描述用户行为,定义业务需求,而不会关心系统的技术实现。
  2. 不是工具,强调的是一种协作方式:BDD要求各个角色共同参与系统行为的挖掘和定义,以实现对业务价值的一致理解。
  3. 不是关于测试的:BDD源自TDD,但重点不是关于测试,所强调的沟通与协作可以指导更好的做自动化测试。
  4. 全栈敏捷方法:BDD促使团队所有角色从需求到最后的测试验证,进行高度的协作和沟通,以交付最有价值的功能。

 

BDD怎么做?

用例场景的描述格式“GIVEN… WHEN… THEN… ”对大家都不陌生,但用这个格式写出好的用例却是非常的难,尤其是新手。这里总结几点供大家参考:

1.业务层抽取,业务语言描述

根据业务层的数据流,在每个数据停留点进行纵切,抽取出一个个用例场景。描述语言一定是业务领域可懂的,不要涉及任何实现相关的技术细节。所描述的场景一定是从业务层抽象出来,体现真实业务价值的。

2.技术人员可懂,自动化友好

所描述的用例场景要能驱动开发,必须要让技术人员易于理解;要指导自动化测试,还得要求对于自动化的实现是友好的。这一点似乎是跟第一点有些矛盾,但我们严格遵守BDD的格式要求还是可以做到的。其中,GIVEN从句描述的是场景的前提条件、初始状态,通常是一种现在完成时态;WHEN从句是采取某个动作或者是发生某个事件,一定是动词,通常是一般现在时;THEN从句用“应该…(should be…)”来描述一种期望的结果,而不用断言(assert),后者与测试关联更紧密。

3.数据驱动,需求实例化

抽象的业务语言描述的需求,往往由于太抽象而缺失掉很多关键信息,导致不同人员对需求理解的不一致。想要既抽象又能包含细节信息,就需要采用需求实例来描述。简单说来,就是给场景用例举例说明。举例就会需要列举数据,如果在场景用例描述里边直接添加数据实例,那样的用例将会很混乱,可读性和可维护性都非常差。如果我们能够在描述场景的用例里边用一些变量来代替,把变量对应的值(数据)提取出来存为一个表格或者独立的文件,这样将会使得用例的可读性很好,而且也不会缺失细节信息(数据),后期的维护和修改也较为方便。这就是数据驱动的方法来描述实例化的需求。

看几个例子,大家体会一下:

场景一:检查收件箱,可以看出第三个清晰明了且能体现业务价值,比较符合上面的要求。
Scenario: Check Inbox
  Given a user "Tom" with password "123"
  And a user "Jerry" with password "abc"
  And an email to "Tom" from "Jerry"
  When I sign in as "Tom" with password "123"
  Then I should see one email from "Jerry" in my inbox
Scenario: Check Inbox
  Given a user "Tom"
  And a user "Jerry"
  And an email to "Tom" from "Jerry"
  When I sign in as "Tom"
  Then I should see one email from "Jerry" in my inbox
Scenario: Check Inbox
  Given I have received an email from "Jerry"
  When I sign in
  Then I should see one email from "Jerry" in my inbox
场景二:限制非法用户查看某些受限内容,BDD强调什么(What),而不是怎么(How),第二个写的比较好。
Scenario: Redirect user to originally requested page after logging in
  Given a user "Tom" exists with password "123"
  And I am not logged in
  When I navigate to the home page
  Then I am redirected to the login form
  When I fill in "Username" with "tom"
  And I fill in "Password" with "123"
  And I press "Login"
  Then I should be on the home page
Scenario: Redirect user to originally requested page after logging in
  Given I am an unauthenticated user
  When I attempt to view some restricted content
  Then I am shown a login form
  When I authenticate with valid credentials
  Then I should be shown the restricted content
场景三:添加图书到购物车并计算总额
Scenario: Books add to shopping cart with correct number and total price
  Given a book "BDD" with price "30.5"
  And a book "Cucumber" with price "25.8"
  When I select "BDD"
  And I click the add to shopping cart button
  Then I should see one "BDD" in my shopping cart
  And the total price is "30.5"
  When I select "Cucumber"
  And I click the add to shopping cart button twice
  Then I should see two books "Cucumber" in my shopping cart
  And the total price is "82.1"
Scenario Outline: Books add to shopping cart with correct number and total price
  Given book <name1> with <price1>
  And book <name2> with <price2>
  When I add <number1> book <name1> and <number2> book <name2> to shopping cart
  Then I should see book <name1> and <name2> in my shopping cart
  And the total price should be <total>
  Examples:
  | name1    | price1 | number1 | name2    | price2 | number2 | total |
  | BDD      | 30.5   | 1       | -        | -      | -       | 30.5  |
  | Cucumber | 25.8   | 2       | -        | -      | -       | 51.6  |
  | BDD      | 30.5   | 1       | Cucumber | 25.8   | 2       | 82.1  |

BDD的工具有Cucumber、JBehave、Twist、Concordion等,工具的优缺点和使用方法,网上都有丰富的文档可参考,在此不作介绍。

BDD有什么好处?

BDD的作用是把利益关系人、交付团队等不同方面的项目相关人员集中到一起形成共同的理解共同的价值观以及共同的期望值。它可以帮助我们:

  • 关注用户行为
  • 交付最有用的功能
  • 在团队内部维护一致的术语
  • 探究需求实例
  • 编写和维护需求
  • 创建活的文档
  • 消除协作与沟通障碍

 

什么样的项目适合BDD?

  • 简单的一次性项目,沟通交流成本都较低的情况下,没有必要使用BDD;
  • 业务比较轻量,重在技术方面的项目,可以只使用TDD,或者简单的白板上的BDD,不需要在BDD工具记录需求用例文档;
  • 业务复杂、团队成员较多的项目,沟通成本高,BDD很有必要。

 

常见疑惑

1.BDD与TDD/ATDD

TDD是测试驱动开发,ATDD是验收测试驱动开发,都是关于测试的,是与所开发的系统紧密联系的。而BDD则不同,前面提到过BDD不是关于测试的,着重关注需求、关注客户的业务价值,所描述的需求用例是可以独立于软件系统存在的,因为客户的业务是始终存在的,不取决于是否有软件系统来支撑。

2. BDD与SBE

SBE(Specification By Example,实例化需求)是在BDD之后由Gojko提出来的,也是关于需求的,主要强调通过列举实例发现需求中的缺失概念。BDD也是关注需求的,同样会使用实例来描述行为。两者的本质没有区别,只是概念的差异。

Share

在ThoughtWorks做BA是怎样一种体验?

BA,英文全称Business Analyst,也称业务分析师,或需求分析师。Linkedin上BA相关的职位不到产品经理或项目经理的四分之一。到本土的拉勾网、智联招聘等网站上,BA的职位就更少了。那么,

  • BA究竟做什么,有没有必要设置BA这一岗位呢?
  • BA具体会做哪些工作?一天会是什么样?
  • BA有哪些能力要求?BA的职业发展如何?

下面我仅就个人在ThoughtWorks的经历做些分享,可能不能代表所有BA,给大家一点参考。

 

BA做什么?为什么需要BA?

BA顾名思义,就是做业务分析。具体说来,就是能够把业务需求和用户需求转化为软件需求,保证最终的软件能满足用户需求,并带来业务价值。举个例子,

01

在软件开发过程中,大家都知道,需求信息要在很多角色中流转。没有BA的团队,需求大概是这样传递的:

02

大家知道,信息每传递一次就会衰减;况且在图上的每一个节点上,往往不是一个人,多人参与更容易失真。根据《组织行为学》中的相关数据,这样跨五层的传递,大约60%左右的信息能被完整无误地传递了。

而有BA的团队,需求则是这样传递的:

03

BA和每个角色都保持无缝的沟通,尽量在每一个节点向前验证需求,保证沟通的每个环节都是闭环,最大程度地减少需求失真。

目前在ThoughtWorks,90%的团队都会配置专职的BA, 只有少量规模很小的团队(如人数<=5个人),则会由其他角色兼任。

 

BA的一天,大概什么样?

如前所说,BA的工作主要围绕需求来展开。在ThoughtWorks的敏捷团队里,使用User Story(用户故事)来表达需求,所以具体的工作就是用户故事的发现、捕捉、拆分、设计、定义、Kick-off、预验收、演示和验收、上线及反馈等,这个过程中会与客户、用户、设计师、开发和测试沟通协作,确保大家做的是有价值的需求,并且对需求的细节有一致的理解。比如我现在的一天:

  1. 早上8:50到公司,看邮件,理一下今天的todo-list, 可能包括如下项(我当前这个组很特殊,会同时负责2个项目
  • 准备项目A在下周一的Showcase
  • 项目B下个迭代的故事卡 – 需要与另外一个BA再过一遍,确保卡上的细节准确无误
  • 项目A的两个故事卡Kick-off
  • 到客服中心去做用户访谈
  • 跟踪下昨天测试报告的外部服务接口好没好
  • 需要与设计师碰一下,把项目B涉及的UI改版的需求再梳理一下
  • ……
  1. 9:15和客户、团队一起站会
  • 更新自己负责的项目需求状态和变更信息
  • 认真听其他人的更新,及时发现有没有需要自己要澄清或跟踪的需求问题
  1. 9:30-9:45 给组里的新同事解答业务相关的疑问
  2. 9:45-10:15 处理一下紧急的客户邮件
  3. 10:15-11:00 与其他BA过项目B下个迭代的卡;
  4. 11:00-12:00 主持迭代计划会议 (怎么做,昨天已准备好)
  5. 12:00-13:00  午饭+休息,刷朋友圈
  6. 13:00-13:40  约到开发、测试,一起kick-off项目A的两张卡
  7. 13:40-16:00  出发去客服中心,用户观察和访谈
  8. 16:00-17:30  准备项目A的showcase讲稿,拉测试做一遍演练、检查外部服务接口是否好了
  9. 17:30 迭代计划会时发现了两个需求问题,发邮件跟客户确认一下
  10. 18:00 查看早上整理的todo-list,还好高优先级已经处理完

 

在ThoughtWorks做BA,跟在其他公司做BA有什么区别呢?

04

我之前也在一家通信企业工作过,属于PM兼BA的角色,对比下来,觉得区别主要在下面几个方面吧:

  • 在TW,我最常用到的工具是白板,PPT,卡片,便利贴;以前最常用的是Word和Visio。
  • 在TW,墙上贴得花花绿绿的,各种需求相关信息,开发测试问到需求,我也是随时随地都能解释;以前都是要翻出需求规格明书,对照着看,才能知道到底做什么。
  • 以前,基本上是做系统分析,到我手上的都是功能需求,有时候明知道做好了没有用户真正用这个功能,还是硬着头皮对照需求规格说明书逐条实现;现在在TW,会真正关注业务问题,用户场景,基本每一条在我手上经过的需求,知道它为什么要做,有什么价值。
  • 以前,几乎从来看不到客户,也不知道用户行为是什么样的;现在几乎天天跟客户打交道(只不过有时是在视频里),还有机会做真正的用户观摩和访谈、用户测试。
  • 以前,一年几乎只能看到1-2次产品上线;现在在这个组,每月都要有很多次产品上线,时不时能得到客户发的巧克力,T恤衫,还是挺受鼓舞的。

 

BA的职业发展怎么样?目前ThoughtWorks中的BA是不是仅能在内部发展?

以我自己的经验来看,BA是个综合技能要求很高的岗位,需求大局到细节的把控、提供业务方案建议、引导决策等等,尤其是大型的产品团队中,更需要综合的影响力和领导力。

之前的BA同事离开ThoughtWorks之后, 有的去做了产品经理,有的去做了数据分析,到其他大型公司里面做BA教练,还有的去创业等等。

在ThoughtWorks内部,有的BA想精专在某一产品领域,比如O2O, P2P还有金数据,实际上承担产品经理的职责,做需求分析的同时,还做售前、看市场和运营;有的则深钻某一个行业,去更多地做业务咨询、解决方案设计、数据分析师等。也有一部分,因为综合影响力和领导力得到了极大的锻炼,横向发展成为管理人员,比如目前我们的全球CEO办公室负责人,我所在组的大客户经理等。

ThoughtWorks是一个人才观非常开放的公司,在内部会鼓励大家“不设限”,主动去尝试很多不同的工作,创造新的“岗位”。

 

在ThoughtWorks做BA,觉得最好的一面和最坏的一面是什么?

最好的一面,是可以接触到各种类型、各种行业的客户,每次都能发现新鲜东西去学习去尝试;最差的一面,其实也是这个,因为有时候要短时间学习很多技能,压力很大。当客户老板说“五分钟之内把图画好”,我们说“好”的那一刻,万分紧张和忐忑;最终把事搞定之后,又是酣畅淋漓,痛与乐并存吧。

 

去TW做BA有什么具体要求呢?

还真没有硬要求,不讲专业,不需资历,也不需软件背景。大致说来,有这四点:

  • 有需求转换的能力
  • 逻辑思维好,清晰有条理
  • 沟通好,复杂的事情也能三言两语说清楚
  • 爱挑战,爱学习

还有的一些不是必须的,但如果能做到,就是加分项了:

  • 喜欢琢磨研究行业市场
  • 善于图形化表达信息
  • 懂敏捷和精益

 

以前没做过BA,但想试试,有书推荐吗

 

最后,以我们内部训练营的BA宣言结尾:

“Skill-set over Role; BA is Business Analysis rather than Business Analyst

角色不重要,真正有两把刷子才重要。大家共同学习,多多增长技能,才是重点。

Share