我怎么看敏捷

去年11月份的时候,我进到了ThoughWorks实习,开始了我的TW生涯,从现在除去今年年初由于毕业论文断断续续的10天左右的请假,我已经到ThoughtWorks1年了,现在我想来我聊聊我眼中的敏捷和我对敏捷的看法。它是比较主观的看法。
首先,我必须得说敏捷并不是完美无缺的,当然也不是所有行业,所有软件项目都适合使用敏捷来开发和管理的。很明显的一个例子就是,你不能用敏捷来开发NASA的航天飞机的软件系统。从敏捷的理念我们会说,我们让开发航天飞机的起飞系统,然后交付给NASA使用,之后再继续交付降落等其他系统,显示这是行不通的,航天飞机不能在仅仅拥有起飞功能的时候就上天啊。敏捷里强调快速交付,快速响应,及时修复bug,因此我们会允许软件存在潜在少量bug的时候让其上线,使用。这在航天飞行系统里面也是行不通的,因为涉及到人的生命,航天飞行系统应该是不允许任何bug的。

但我依然会说,敏捷是一种很好的理念和实践,适合大部分IT企业使用,特别是互联网企业和运行互联网产品的企业使用。

在现在互联网时代,天下武功唯快不破。采用敏捷的实践,初期开发MVP(Minimal Valuable Product)产品,快速上线,根据用户的反馈不断更新、改进自己的产品,开发新的功能,这样周而复始,产品把用户最喜欢,优先级最高的功能永远都放在第一时间开发、上线。根据用户的反馈、统计数据的结果不断调整产品的策略,这样才能立于当今互联网。在我们身边也许Github、 Flickr等都是很好的成功例子。
下面是我对于一些是非的意见:

  • 结对编程能够明显提升代码的质量,让团队成员对代码的熟悉度大幅提升,但是我不赞成至始至终都是结对编程,应该留时间进行单独编程,这样虽然代码质量也许会有一些下降,但是如果伴以TDD对进行辅佐,是不会下降太多,单独编程有助于让dev独立思考,发挥创造力,很多时候会达到意想不到的结果。另外一点结果编程通常达不到两个dev独立编写代码的效率,就像在《人月神话》中讲到的那样,1一个人如果需要开发一个软件需要100填,那么10个程序员10天肯定不能完成任务的,因为期间还需要算上沟通的成本。
  • 关于TDD,确有遇到过几次绞尽脑汁也没想明白怎么测试的case。但是我们如果使用 隔离依赖(即mock依赖,stub行为,如使用mockito中的:given().willReturn();或者when().thenReturn()等)的原则来编写测试,绝大多数情况都会变得豁然开朗,就Java而言,遇到静态方法,我们可以通过间接的调用去测试,对于无返回值的方法(void)我们可以采用验证行为的方法去测试(如使用mockito中的verify()函数)。使用TDD的好处是不言而喻的,用测试代码描述你的需求,表达你想要的结果,既保证了质量也不用担心会做出多余的功能。不过在开发自己的小点子、小创意时,我通常选择Rails和Node.js进行开发因此TDD做得并不好,通产只是选择性的对重要的部分进行测试保证。
  • 沟通胜于一切,跟项目中所有的人频繁沟通,在实际项目中有一次是这样的,对于story中一个对于生效时间信息的描述有些模糊,我没有多想久自己认为肯定的全局的生效时间,但是不曾想到,当多个子产品出现时,就不能依赖全局生效时间,因为全局生效时间是其中最大第一个,而不一定是当前所需准确的生效时间,因此这个sotry在最后给BA 检查的时候才发现这个bug,试想最初如果我没有随便假设,而是马上给BA发邮件沟通,问清楚生效时间,也不会出现返工的情况。我个人认为良好、高效的沟通甚至比写好代码优先级更高。
  • 站会(stand up)既是一种对团队成员工作的可视化,了解彼此的进度等情况,也是锻炼表达能力、增强自信心的好机会。为何这样讲,因为在站会上每个人需要用几句话来概括自己前一天所做的一切,当你讲到你前一天做的一些进步时,团队为你真心叫好,难道不会让你你增强自信心吗?对于站会进行的方式,有团队会选择每个人依次讲解前一天的工作内容;也有人会选择采用按照故事墙的方式来进行,依次对每个列(analysis, ready for dev, in development, test, sign off等)进行浏览等,当讲到自己的那个story时,每个人需要更新自己前一天在这个story上的工作,这样的好处是可以对每个story的情况进行可视化。但是我个人更喜欢前者,这样更加自由,但是目前在工作中基本尝试的都是后者。
  • 另外一点是尽早集成,这点感触很深,大三的时候在一家公司实习,当时做一个原型系统,两三个人做一个模块,到最后快要演示的时候,才把几个模块尝试连到一起做集成测试。结果就是,所有人坐在一起进行的进行各种接口的连接、调用,bug修补。一旦连接成功就兴奋到难以言表,仿佛很长一段时间的工作都没有这一下来得兴奋。系统可以集成后,一直都提心吊胆,担心其中某个东西会不会莫名挂掉,因为集成测试都是使用人肉测试的啊。在展示的时候,各种紧张,安排专人时时刻刻注意到服务器。在敏捷中,我们要求及早进行系统集成和和创建部署环境的脚本,每次CI的运行都是一次集成测试,都是一次服务器的部署。因此不用担心在realse的时候不能部署的情况。不过有一件事情是需要注意的,那就是数据库的迁移,在开发机器,测试服务器你还能每次部署的时候都干掉之前的数据库,重新创建,但是在部署到产品服务器的时候就需要小心了,在Java中我们可以用Flyway 达到类似Rails中的 rake db migrate的效果。

另外,我认为 switch pair(变还你结对同事)、 code review(团队成员坐到一起对团队前一天提交的代码进行浏览、解读),这些都可以让整个团队共享更多的上下文,还可以检查出不到的代码,学习好的代码。
也许明年这个时候我对敏捷的看法又有不少新的见解,到时候再来分享。

Share

如何建设全功能团队

简介

团队的开发人员撇开需求沉浸在想象中的“完美”程序中;测试人员迷茫的点击着按钮试图搞明白这到底是个什么功能;设计师造出了没有尽头的楼梯,更糟的是,客户爱上了这个设计;团队领导四处救火,力有不逮。种种迹象表明,我们得打破分工带来的壁垒,建设全功能团队——大多数人能完成大多数种类工作的团队。

在一次闲聊中,女友的母亲说起实习大夫必须轮岗一年才会进行分科学习,我质疑道:“对于致力于心脏病治疗的医生来说,他岂不是在不相干的学习上浪费了一年时间么?”,她母亲笑着说:“不这么做,你怎么确信病人的确患有心脏病呢?”。不知道为什么,我眼前突然浮现出这样的场景?测试人员在怯生生的询问:“这是一个缺陷么(而不是操作系统/浏览器的限制)?”。

亚当与大头针工厂

亚当·斯密于1973年在描述大头针工厂的专业化生产时提出了社会分工的好处:提高熟练程度、减少任务切换时的开销、便于机器的应用。我们似乎可以非常自然得推导出重复设计、重复编码、重复测试可以增加相应岗位员工技术熟练度,提升效率,并由此提升企业的盈利能力。

然而市场的不断变化让重复生产的美梦不在,切换任务变得越来越频繁。IT公司不是大头针工厂,知识工作者毕竟有别与体力劳动者,在劳动主体发生变化的过程中有两件事情的差异被放大了:一是局部优化与整体优化的差异,二是正确的做事与做作正确的事情的差异。

有一道数学题,假设每个开发人员每天可以完成一个功能,测试人员每天可以测试2个功能,团队由3名开发人员和1名测试人员组成,那么一周内通过测试的功能最多为多少个?

大多数人的第一反应是5(天)x2(功能/天)=10功能,下面的表格会告诉你,由于负载不均衡,测试人员在周一没有功能可测,团队其实无法在一周内交付10个功能。

周一 周二 周三 周四 周五 总计
开发人员 3功能 3功能 3功能 3功能 3功能 15个功能
测试人员 0功能 2功能 2功能 2功能 2功能 8个功能

(表一) 那么我们改变一下条件,假设团队中有4个开发人员,并且开发人员可以参与测试,结果会怎样呢?

周一 周二 周三 周四 周五 总计
开发人员 4功能 4功能 3功能 2功能 0功能 13个功能
测试人员 0功能 0功能 2功能 4功能 8功能 14个功能

(表二) 我们最终能够交付13点,产量提高了60%, 如果我们只留下三名全能人员:

周一 周二 周三 周四 周五 总计
开发人员 3功能 3功能 3功能 1功能 0功能 10个功能
测试人员 0功能 0功能 0功能 4功能 6功能 10个功能

(表三) 居然比3个开发人员和1个测试的人员组合还多交付两个功能! 我们当然有理由质疑第二题的假设:“开发人员可以胜任测试人员的职位”。又或者继续讨论迭代二的数据变化。

我对此的回答是:

  • 第一,以我的观察来看开发人员之所以不进行测试工作,不是能力不允许,而是主观上认为测试工作是简单、重复而枯燥的,不愿意做。客观上开发人员们比较贵也更难于培养,组织层面不允许这样的“浪费”。 对测试工作的偏见客观上促成了大量不具备技术能力的人选择测试工程师作为职业,而技能不足则一步导致了测试工作倾向于简单重复。测试人员在很大程度上无法判断什么是正确的事情(作正确的事),从而更倾向于熟练的按照脚本进行操作(正确的做事)。
  • 第二,我的关注点不在交付8点还是10点,我希望这个例子能够引发大家对于均衡生产的思考。 软件的需求和实现可以被细化,但它毕竟不是大头针,需求和实现间往往呈现出关联与依赖,换言之,局部效率的增加无法直接转换为整体效率的增加。而整体效率的优化往往依赖于均衡生产(参考表三),即消除生产的波峰(过度生产)和波谷(生产不足),避免任务时松时紧,松时生产力浪费(周一时专职测试人员),临时加班加点,粗制滥造。 我倾向于认为亚当·斯密对劳动分工论述的假设是:需求稳定,简单生产。对于IT领域来讲,这些假设还成立么?

拧螺丝的卓别林

不难发现,对分工以及个体效率的迷信正在深刻的影响着IT领域。分工的端倪在招聘时就已经显现,即便对于差异不大的毕业生们,雇主也会根据其极有限的技能,用不同的标准进行测试(Java, .Net, PHP等),并在入职后将其冠以前端工程师、后端工程师、测试工程师、技术支持工程师等不同的头衔,甚至可能在其可见的职业生涯中专门负责某个文件的维护。

整体效率的优化要求IT团队消除技能壁垒,培养多面手,根据计划的变动,弹性调整任务,达到各角色和流程之间的平衡。对于IT企业来说,变化从招聘时就必须开始。找到拥有学习热情、学习能力、学习习惯的人变成了当务之急,员工是否掌握了某种算法、语言或者工具应当从准入条件降格为对于其学习能力和热情的一种(不是唯一一种)证明。

整体效率的优化要求员工必须持续学习、成长,兴趣无疑是成长的催化剂,然而丧失意义的工作却在不断扼杀人的兴趣。丹·艾瑞里在怪诞行为学里著述到: 劳动者与他自己的生产活动、劳动目标以及生产过程相分离。这就使工作成为非自发性的活动,因此劳动者就无法对劳动产生认同或者领略到劳动的意义,而缺少了意义,专业人员可能觉得自己好像电影《摩登时代》中查理·卓别林扮演的角色,一切都由工厂的齿轮控制,他们根本不会有全心全意工作的愿望 。 如果员工成长是必须的,那么,帮助员工认识到工作的全貌也是必须的。角色轮换是一个很好的解决方案。在项目内部通过角色互换,不限角色的结对工作,加强不同角色、不同模块间的知识传递,打破技术壁垒,帮助员工从不同视角理解项目,锻炼技能,进而增加团队均衡生产的能力。

在我看来,进行角色轮换的最大阻碍在于编程能力的普遍缺乏,大多数的测试、需求分析工作(鉴于大多数团队所处的地位,需求分析师实在言过其实,更精确的名字是需求整理师),迭代管理,简单的客户交流,学习曲线都非常低,任何成员都可以在师傅的带领下迅速掌握工作要点,然而编写程序却是个例外,即便对于基础良好的新人,在经验丰富的导师带领下,也需要2个月左右才可能写出比较体面的单元测试、较为面向对象的程序。在分工的体制下,用别的角色轮换开发人员几乎是个死局。

非常奇怪,IT领域如此的看重抽象能力和逻辑分析能力,可为佐证的是层出不穷的建模语言、模式、领域模型、架构。然而最能训练抽象能力和分析能力的一项活动,却仅仅有选择性的开展,这是不是意味着我们认为IT项目可以在大多数人无法(也没有能力)达成共识的情况下顺利展开并成功交付呢?在我看来,编写程序不仅仅是一项技能,一种思考方式,还承担着构造IT团队成员间共同经验区、提高交流效率的目的。

一个值得从其它行业借鉴的经验是首先展开基础素质培养,再进入领域培养专业素养,换言之,避免过早的分工,所有新人从编程开始职业生涯,在公司的体制层面促成每个新人都能经历力所能及的所有角色。在具有了一定的基本素质后,在员工对工作内容和自身兴趣有了充分的了解后,根据个人意愿进入领域发展专业技能,兴趣将成为员工成长的内在动力,而良好的基本素质将使员工有能力在专业岗位上施展自己的想法。 同时公司应当鼓励员工跨界工作,《应用Selenium和Ruby进行面向领域的Web测试》的作者是拥有卓越能力的开发人员,他曾经进行了相当长时间的测试工作,在其它人抱怨自动化界面测试难于维护时,他优秀的抽象能力、分析能力已经帮他提炼出测试模式,识别出缺陷,找到了优雅高效的工作方式并诞生了这篇优秀的文章。丹·艾瑞所言于我心有戚戚焉。

知行合一

我们曾在团队中进行了建设全功能团队的初步实践,在分享具体实践前,我希望下面的总结性数据能帮助你获得一些背景知识。 项目处理的是期货交易领域,使用的技术栈是C#, ASP.NET MVC。团队主要由八名开发人员以及两名测试人员组成(其中一名测试人员在项目中期加入),其中四位是毕业生,三位具备工作经验,但刚刚加入Thoughtworks,只有一位开发人员具备.Net开发经验。 下面是全部35周的燃尽图,黑色实线代表项目的范围,绿色实线代表开发完成的速度,蓝色实线代表测试完成的速度,每周为一个迭代。 image0 在这张图的大部分区域内,蓝色和绿色是重叠或者非常接近的,这意味着团队每迭代开发完成的功能恰好与测试人员的处理能力对齐。一方面,这归功于测试人员自行实现的自动化测试框架对效率的提升,另一方面,开发人员参与测试也起到了平衡开发和测试速度的作用。 让我们截取开发过程的一部分,观察每个迭代的速度,在下面这样图中,横轴代表第几个迭代,纵轴代表每迭代完成的功能点数。 image1 从项目经理的角度看,团队的交付速度很稳定,从15周开始直到项目的结束,我们都可以放心的使用12点每周的经验数据进行估算、计划工作。事实上团队在后期所处理的工作种类越来越多,包括了正常的开发任务、公式转换、性能调优、验收测试、支持等。在这种情况下,每个人都具备跨角色、跨模块工作的能力,才保证了可持续的交付节奏。 在这篇文章中我们一起回顾了分工历史,对于技术团队影响以及建设全功能团队的必要性 ,在下一篇文章中我将详细分享一些实践以及经验数据。

Share

优秀离岸BA的“十要”,你做到了几条?

离岸BA顾名思义就是工作在离岸项目(offshore) 上的需求分析师(business analyst)。离岸交付面临的挑战是很多的,比如语言,沟通,客户关系,客户业务等等方面。作为offshore项目的BA,要把握好以下的10要。

第一: 要和客户建立良好的沟通方式和节奏

离岸最大的问题往往就是沟通问题,有许多offshore项目都有时差问题,比如我所在的美国项目,和客户时差长达16个小时,沟通成了我们的主要问题之一。作为项目的BA兼IM(iteration manager)的角色,和客户保持紧密沟通成为关键。通过沟通澄清需求,汇报项目进度,风险管理等等。只有和客户建立良好的沟通方式和节奏,才能建立客户和团队间的信任,从而保证项目顺利进行。

沟通的方式有很多种,比如邮件,会议,各种即时聊天工具 (skype, slack, asana)等等。不论采用哪种工具,最终目标就是希望能够高效沟通。有了这些工具还不够,要真正和客户保持紧密沟通就需要时间灵活,比如美国项目,和客户时差有12-16小时,有时需要早上7点开会,有时需要晚上11点和客户开会。当然,为了提高沟通效率,我们要尽量避免邮件沟通的方式。对于简单的需要确认的问题,就直接和客户用聊天工具完成。如果复杂问题,尽量book一个时间统一解决。

沟通的节奏需要和客户协商,尽可能在项目之初排出每个迭代的会议计划。比如站会,story kickoff,showcase, story review 都在每个迭代的什么时间进行。如果客户时间允许,和客户的站会最好每日一次,风险评估会议最好每周一次。story review次数尽可能多,如果客户比较忙,那么就固定时间进行批量story review。

第二:要高效利用和客户每次开会的时间

由于时差问题,和客户开会的次数是比较有限的,所以需要提前做好充分的准备,高效利用每次的沟通机会去澄清需求,汇报进度,风险管理,分享反馈等等。

比如站会(standup) 不能采用传统的方式,客户并不关心我们每个人每天具体做了什么,而是关心每个迭代完成程度和我们遇到的困难或提出的问题/风险。我们可以利用站会的时间确认优先级,反馈问题,预报风险,甚至可以就关键的需求问题在站会上讨论。

第三: 要尽早分析需求和讨论设计方案

在敏捷开发中,BA的最终输出是story。在写story之前,要经过需求分析和详细设计,这中间需要多次和客户沟通才能完成。而且由于在讨论设计方案时往往会出现不同意见,需要经过几次修改或者讨论才能最终和客户达成一致。所以从分析需求到输出story,这中间可能要经历好几天,甚至几周的时间。为了不影响团队的开发进度,一般需要提前至少两个迭代周期开始分析需求和提供设计方案。

如果跟客户时差比较小,并且一天之内有多个机会和客户沟通的话,那么需求分析和设计的周期会短一点。但如果时差有16个小时(客户在洛杉矶),那么每天能够沟通的时间很可能只有一次。所以建议沟通细节需求之前,先根据大的需求画出线框图(wireframe),这个线框图体现了你的设计思路(包括对需求的理解),用这个线框图去跟客户聊会效率高很多。

第四:要及时确认以防止沟通失真

在沟通需求的过程中,需求信息通常要经过用户代表,产品经理,需求分析人员,设计人员再到开发人员,在这个信息传递的过程中,如果没有采取任何措施,那么在沟通过程中信息衰减可能的最大值高达60%。为防止沟通失真,要进行及时确认。

比如当客户阐述了需求之后,BA当场再用自己的语言重述一遍。如果和客户讨论的要点比较多,会议之后要发邮件总结确认的需求,进行再一次的确认。

第五:要有效控制需求变更

需求变更频繁是困扰无数软件开发团队的恶魔之首。从需求变更的根源来看,一是因为BA在捕获需求时信息不全面,二是确实是业务变化了。我们应该尽可能避免犯错误,同时加强对需求变更的预测。尽管需求变更是不能避免的,我们还是要想办法控制变更,控制变更的的目的是减少变更对开发工作的影响。可以从以下两个方面来有效控制需求变更:

  • 在进行需求捕获时,对于客户提到的未来可能的变化要引起重视,并且把这个重要信息记录在story里面供开发参考。如果忽略这个可能的变化,有可能会造成返工甚至要推翻整个技术框架来重做。
  • 对变更进行集中处理,选择正确的评估者对变更进行评估,分析变更对技术,项目带来的影响,并且确定优先级。比如如果客户说让我们改一个功能,我们不能立刻就去改。首先应该新建一张story卡,然后评估一下需要几天完成,跟客户确定优先级,最后把这张新卡排在某个迭代计划中。

第六:要善于借助团队成员的力量

在遇到比较强硬,难说服的客户时,要善于借助团队其他成员的力量来解决问题。

比如客户坚持某一个设计方案,但是这个方案的开发代价比较大。这个时候就需要拉上技术骨干和客户一起谈,帮助客户理解技术难度,同时给客户提供其他几个effort小的备选方案。

再比如,客户提到的方案技术实现没有问题,但是用户体验明显不好,这个时候BA除了自己propose几个方案以外,还可以和团队一起进行一次头脑风暴,争取找到最佳解决方案。

第七:要深入理解客户的业务

对于Offshore项目我们往往拿到的都是客户加工分析过的需求,根据这些需求,我们负责拆分story,完成详细设计。BA对于客户提出的需求要多思考,理解用户需求背后的业务场景,这样才能设计出对用户有价值的产品。不仅如此,平时还要注意积累客户的行业知识,深入研究客户的业务,这样才能给出客户更加有建设性的建议。

举个例子,在我们设计一个Tag功能时,很多网站的实现都是不区分大小写的,也就是说当用户输入一个大写ABC的tag时会自动转存为小写的abc。但是由于客户是医疗行业,有很多大写缩略词汇作为tag,这个时候如果自动变为小写显然不合适了。

第八:要定期和客户要反馈

我们常说要“知己知彼”,那么客户“对项目进展、产品质量是否满意”,“客户有没有其他期望或者是担忧” 诸如此类问题,我们都要定期地和客户进行沟通,了解客户的态度,识别潜在的风险,做到随时和客户保持一致。

有些客户如果你不问反馈,他几乎是不会主动给你说的,但是客户心里可能对某些事情已经有些不满了。为了避免未来可能的发生的冲突,也为了未来更好地合作,需要定期和客户开个小会聊一聊,我建议一个月至少一次。

第九:要管理好客户的期望

判断项目是否成功,是由客户说了算,要看是否满足的客户的期望值。而客户的期望是可以管理的,这里有几个小技巧:

  • 要知道我们能做什么
  • 要了解客户的期望,并且将这个期望分享给团队成员
  • 不要轻易给客户许诺
  • 定期汇报进度,预报风险

第十:要善于利用技术为客户创造全新体验

客户对技术解决方案永远都不是最擅长的,因此他们无法构想出对其工作产生变革性的解决方案。这就需要BA在对客户需求深入理解的基础上,选择合适的技术方案,创造出客户未梦想到的功能,从来带来全新的用户体验。

Share

在团队中如何带领新手

目标

通过引导、任务分配和沟通反馈等方式,让他逐步适应团队正常工作面临的压力、节奏和不确定性。对于一些心理预期过高的领导者,在此阶段应该明白,对于一个新手,还暂时谈不上能力判断和机会给予。

方式

创造良好的工作气氛:信任是第一位的。只有相互信任,才能把工作放手交给新手去做;另一方面,在他们失败的时候依然要给予信任,否则,所有的事情结束点就是“失败”。一个人所取得经验,最大的来源就是失败。良好的工作气氛,也包括各种非正式的交流与沟通,比如聚餐、聚会等等。

定期反馈:可以在每日、每周对新手的工作进行反馈,同时也让新手有一个渠道发出自己的声音。反馈应包括:做得好的地方,以及需要改进的地方。反馈中需要注意的是,虽然是新手,但已经是成年人,思维、行为模式大部分已定型;我们需要去识别对方的性格特点,合适的沟通方式,以及他们的动力来源,尽可能做到:了解他们的愿景,帮助他们做成他们想做的事,帮助他们成为他们想成为的人;切忌让他们被迫成为“我们”想要的人。

制定学习计划或任务:针对新手已有的知识体系制定短周期的学习计划,分配适当的任务给他们完成。在这个过程中,需要去检查并督促对方完成计划或任务。能够完成简单任务之后,逐步让对方感受到工作中的压力和需要随机应变的场景,给予指导,让他们逐步能独立适应工作。

障碍

带新人的过程中,往往会遇到不少的阻力,最终他们无法达到早期的期望。分几个方面来解读:

两只手表:在公司里非常影响工作的是权职受到牵制,带新人这种小事也不例外。如何新人失去了对你的信任或他更倾向于另一个人的反馈,那么你对他的指导是无法成功的,遇到这种情况,可以和另外的人,也许这个人就是你的上司,谈谈如何更好地带领这个人,或者放弃对他的培养。

沟通失败:部分虽然工作多年,但沟通经验不够丰富的人,可能无法在双方沟通中明白对方表达的真实意图,并无法识别对方性格上的偏好,导致沟通上的失败最后无法达成目标。有效的沟通,是需要双方都明白对方的意图,作为优秀的沟通者,更需要清楚地知晓在沟通之中,哪些“需求”是可以让步、放弃但又不影响全局的,这就是妥协:我们应当明确,当一方作出让步时,又需要对方相同地作出哪些方面的让步,以达到对目标的共识。在与成年人的沟通中,可能会出现多次的妥协,因为每个人有独特的背景和知识,这都导致了不同的认知和行动方式。

纠正行为模式:这种情况对双方都是痛苦的过程。并不是每个人都出生在良好的家庭,一开始就有优秀的父母指导如何做事。比如隋性、注意力分散、害怕挑战、防备心理等等。在这方面我也有不少失败的经验;所以我认为“改变”一个人几乎是不可能的,但我们可以采取一定的手段,将负面行为的影响力降低到最小。比如之前和其它人沟通如何让90后新人对自己的工作任务负责,不是在他们彻底忘记任务后批评责备,而是将他们的任务期限、状态醒目地展示在工作区域,多次提醒的结果明显大于事后究责。另外在需要一个人做出改变的,应当与他明确,他做出的改变是为了满足团队的共同目标,而非个别领导人的偏好;他做的改变是为了解决自身面临的障碍,而不是变成所谓的“完美之人”。

最后如果让我用较少的几句话来总结“带人”的经验,我会说:第一,带人时你有权力,但不可利用权力,你要明白权力“该”做的部分,而不是沉浸在“可”做的部分;第二,带人时对方会做一些你让他做的事,但不可把他当成你,甚至当成你可以去塑造的人物,他需要在这个过程中成为他的更好,你也需要在这个过程中成为你的更好,否则,你只是这事的附属品,你会费力不讨好,会委屈难受;第三,世上没有完美的人,你也不是爱因斯坦,调子放低点,会有更多人主动向你学习。

Share

从敏捷宣言理解敏捷交互设计

本文原文发表于InfoQ:http://www.infoq.com/cn/articles/xzc-agile-interaction-design

敏捷交互设计是敏捷方法论向交互设计领域的延伸,它提倡让所有相关人参与到设计过程中,迭代演进式地进行交互设计。从2010年开始,已经有越来越的团队在不同程度上使用敏捷交互设计的方法,而放弃了流程化的传统产品设计过程。

事实上,敏捷交互设计方法在很多方面都充分体现了敏捷价值观,因此,理解敏捷交互设计实践的最好方法是从记录在敏捷宣言中的价值观开始。

个体和交互胜过流程和工具

一个传统交互设计的流程一般分成以下几个步骤进行:

  1. 任务分析:任务分析基于功能列表(一般来自于客户的功能说明书)──在功能性需求的基础上拆分出人物流程和场景;
  2. 页面流程:根据任务分析的结果,为每一个大任务下的子任务中覆盖的功能制作页面流程;
  3. 信息建模:根据页面流程的设计出一套完整的信息框架,满足用户所有功能性需求;
  4. 原型设计:基于信息建模,设计出低保真原型,交给美工进行页面美化;
  5. 视觉设计:基于原型设计,对页面进行美化,最终产出高保真原型,同时编写设计说明;

在传统流程中,我们可以看到非常细致的分工──产品经理负责功能的拆解和分类,以及页面流转;交互设计师设计信息架构和具体交互行为;视觉设计师负责美化页面;前端开发人员负责高保真原型。

你是否体看见了传统瀑布式开发的影子?弊端显而易见:

  1. 分工造成的局限性──每个人都用自己的视角进行工作,无法形成统一的产品视角(Vision);
  2. 分工造成的“不可评价性”──你没权利对产品经理的功能拆解有异义,因为你不是这方面的专家;
  3. 需求在传递中产生了失真的风险──需要靠大量文档进行记录;
  4. 客户没法说不──当客户需要到整个流程的最后看到一个或者两个大而全的设计方案时,他无法提出任何有价值的反馈,这本身就是用一个贵重的半成品绑架客户;

跟软件交付中的敏捷实践一样,敏捷交互设计倡导全功能团队,避免过于明显的分工,和基于分工特有的流程。仅有的流程是基于产品逐步清晰化的过程,而非基于人员的技能,所有人都应该参与到这个过程中来。敏捷交互设计主要分以下几个步骤:

  1. 寻找产品方向(Inspire):抛开需求列表,从目标人群的期待体验出发,寻找可能存在的产品方向;
  2. 定位产品需求(Identify):定位本产品需要提供什么样的消费者体验;
  3. 设计产品体验(Ideate):对决定的目标体验进行设计;
  4. 验证产品设计(Implement):快速制作原型,并频繁进行用户测试,迭代式改进。

图1. 从体验中寻找交付范围,把功能列表放在一边

除了流程简化和分工融合,在工具的选择上,敏捷交互设计也与传统方式有所不同──对于交互的推崇高于对特定工具的选择。

所有在敏捷交互设计中使用的工具,都应该遵循一条原则:它必须推动设计团队成员间的交互,而不是简单提升单个成员的工作效率。

基于此,敏捷交互设计中推崇各种轻量级工具,而不是大型的第三方软件,例如纸质原型Paper Protityping而非Visio或Axure此类原型工具。过于精细的结果往往会增加协作和反馈的门槛,虽然可能提升单个成员工作效率,却达不到鼓励交互的目的。

图2. 使用轻量级的工具进行交互设计

可工作的软件胜过完备的文档

敏捷软件交付过程中,每个迭代的核心产出是不足够完美,但却满足一个完整业务场景的软件──端到端流程的可完成,而不需要面面俱到的完美。

而传统开发方式中在长时间内只是各个功能模块中功能的堆砌,无法在短时间内实现端到端场景,那么文档便成为串联各个功能保证有序开发的必需品。

传统交互设计也存在这个问题。往往一个标准交互设计阶段的文档分三个方面,它们是:

  1. 内容方面(Content):内容的层次和整体信息架构设计;
  2. 视觉方面(Visual):整站风格的视觉设计文档;
  3. 交互方面(Interaction):整站高保真交互设计原型;

仔细分析这些文档的生产过程,我们不难发现以下特点:

  1. 它们都是以整站为目标,试图覆盖所有使用场景;
  2. 它们的生产过程是线性的,直到三者全部完成才能够指导开发;
  3. 正因为每个环节的过程是孤立的,无法形成统一的认识,文档传递经常发生失真;
  4. 一个完美的东西很难得到产品方向性的关键反馈;

敏捷交互设计试图在解决以上问题。

敏捷交付的核心在于尽早地交付出可进行端到端测试的代码,而非完备文档,而敏捷交互设计的核心则在于尽早地交付出可以进行端到端可测试的原型,同样亦非完备文档。

而这里说的“端到端可测试的原型”包含以下含义:

  1. 端到端:必须设计出符合合理使用场景的端到端流程,这个流程会覆盖一个典型用户最核心的使用场景,所有的交互设计应该第一时间收敛在这个端到端场景周围,而非“整站”功能的分割展示;
  2. 可测试原型:不需要完美的原型,只需要所设计端到端场景中涉及到的原型,同时,原型的完备性上必须达到内容、视觉、交互三者细致力度一致,在测试中,三者力度的不一致往往会隐藏问题,例如,如果测试的原型视觉上过于完美,就会减弱用户在交互上的关注;

假设我们把交互设计的四周拆分成每周一个迭代,每周交付一个覆盖端到端场景,且在内容、视觉和交互方面都相对完备的原型收集反馈或进行测试,和传统项目相比,我们是否可以更早地得到客户反馈,是否可以让设计过程更透明,是否毋须完备的过程文档?答案自然是肯定的。

图3 逐步细化的原型,不停进行用户测试

当然,这样的过程必然需要多模块(这里的模块指技能的差别)之间的融合,实现全团队的运作。

你会问我,这是否意味着我们的交互设计师需要学会使用IIlustrtor进行视觉设计?或者视觉设计师需要学会HTML+CSS+jQuery制作高保真原型?

是的,在很多情况下,敏捷交互设计团队中的设计师确实需要具备多种功能的T型人才──他们有专业的技能,也可以在其他方面有足够的贡献。

分工的结果只能导致能力的停滞不前、产品视角的缺失、职能不可替代的风险、协作软的低效、沟通的浪费等等,而唯一的好处在于,可以更快和“更不被抱怨(如德鲁克说过程文档的价值在于管理抱怨)”产生一堆堆相互分裂且无法让客户挑错的文档。

客户协作胜过合同谈判

让我们举例说明在传统交互设计阶段出现的场景:一份标书、一份功能列表、一份到处使用的所谓用户体验调查问卷,在交互设计的开始阶段,我们和客户在一起进行“需求调研”,其实这些不重要,我们只需要对比我们之前的产品都有哪些功能可能有重复,类似产品有哪些可以借鉴,调研往往只是形式,关键还是未来的二至四周;

然后最后一次见客户也许就是最终文档提交的那天,给客户看一套精美的PSD文档,一般我们会做出A和B方案,其中不乏我们臆想出来的需求,有时只为让那个区域看起来不那么空,客户高兴地选择了其中的一套方案后,交付正式开始。

这就是基于合同进行设计的典型场景,谁也不知道合同中的功能列表意味着什么,而对于客户来说,它确实是购物单,真正交付时已忘记为什么需要。

但这不妨碍交互设计师进行设计,大部分时候他们并没有仔细思考这个功能真正的使用场景,而是把它“画”出来,让它看起来很美,却不管它如何实现和如何被用户使用。

这是基于合同进行设计自然而然的结果,在每个功能上,设计师都希望当成对自己的挑战,他们绞尽脑汁收集类似产品类似功能,尽可能取悦客户,说服他们采用更炫更丰富的交互方式,而作为不对交付负责的人他们毋须承担责任。

而敏捷交互设计希望打破这种基于合同或者换言之,基于功能列表的设计模式。它希望在设计的全过程将客户参与进来,让客户了解某个标书上的功能也许没有意义,或者不是当下应该解决的问题──一个交付项目范围的最好确定时机就是在交互设计过程中客户的全程参与。客户参与的优势有以下几点:

  1. 过程的透明化提升客户的安全感,随时保持对设计进度的了解;
  2. 最好的反馈模式就是让客户亲身参与设计过程;
  3. 了解最终用户和业务模式的是客户,客户是不可多得的资源;
  4. 当设计结果是功能列表的重新确认,对于合同中的内容便达成了新的共识;
  5. 客户参与的过程是建立信任的最佳机会,良好的信任关系应该在最开始就建立;
  6. 在产品设计方向上和客户达成一致,而不是仅靠标书或者访谈结果的支言片语;
  7. 提升参与感有助于培养更负责的客户,在交付阶段,之前的努力将会获得巨大的回报;
  8. 有效控制设计的变化,当客户亲身参与设计决定过程时,很多盲目的设计变化会减少很多;

拥抱变化胜过遵循计划

当你的设计不能和客户一起进行,你只是个标书需求列表的简单执行者,需求的变化便是理所当然的事情。

在有些传统交互设计流程里甚至出现“需求冻结”这样的流程──如果你已经对某个环节的文档进行进行签收,就不能在“需求冻结”后改变主意。这样的结果无非两个:一尽量不要签收那个环节的文档;二在需求没有冻结的时候抓紧机会改变主意。

从敏捷宣言的角度来看,之前的三句话是最后一句话的基础,如果不能做到对个体和交互的尊重,把可用软件当作产生核心价值的东西,并且努力和客户进行协作,谈拥抱变化只是空话。在敏捷交互设计中,遵循同样的道理:

对个体和交互的尊重──当需求发生变化时,因为在新的流程中对产品视角的重视,可首先对需求变化的价值进行判断,即它是不是匹配达成一致的产品视角;真正需求变化时,因为分工的模糊以及流程的简化,可更灵活地调配资源进行处理;再者因为大量使用轻量级的工具,修改成本大大降低;

关注可工作的软件──因为我们把可进行的端到端场景测试作为敏捷交互设计过程中最重要的目标,当出现需求变化时,可通过审视变化本身“是否包含在端到端场景中?如果不产生这样的变化,用户因此有何种损失”来判断需求变化本身的价值;同时,因为能够尽早的得到端到端场景原型设计,需求本身往往来自于用户测试的结果,这样的需求变化往往是有价值的,有理可依的;

客户协作的重要性──需求变化往往来自于客户的不确定性,很多情况下这种不确定又来自于一个新产品背后业务模式的不确定,客户协作帮助在设计过程中及早发现和解决这种来自业务方面的不确定,同时,客户协作对客户责任感的培养也大大减少了来自于客户不负责任的需求摆动。

这就是敏捷交互设计可以很好的管理用户需求的根本原因。

从敏捷推行到现在,在交付领域已经走向成熟,越来越多的团队开始采用敏捷方法进入开发,但从软件交付的全流程来看,早于交付的交互设计环节目前依然以传统设计方式为主。

随着消费型软件大行其道,用户对软件使用体验的要求越来越高,同时新产品的推陈出新对快速产品设计提出新的要求,这样的背景使得传统交互设计流程不得不做出一些新的调整以拥抱更加频繁的变化,这也是为什么很多交互设计团队开始努力尝试具有敏捷价值观的敏捷交互设计进行产品设计的主要原因。

最后,让我们来比较一下传统交互设计方法和敏捷交互设计方法的区别:

传统交互设计 敏捷交互设计
没有交付团队的参与;客户参与度低;设计团队中各职能分工明确; 交互设计师、用户研究者、视觉设计师、前端开发者、客户代表、以及开发团队代表都完整参与整个交互设计的过程,并只有能力区分而弱化职责分工;
客户需求文档中的功能列表是贯穿设计过程的主线; 基于终端使用者期待体验的设计过程,往往客户功能列表只作为参考;
各自有各自对产品的理解,无法达成共识; 对产品设计方向的形成共识是贯穿整个交互设计阶段;
使用大型的交互设计软件; 鼓励使用白板、海报、贴纸、手绘等轻量级的工具;
客户只在开始和结束参与项目; 客户全程参与设计活动;
主要以文档制作为主; 主要以Workshop工作坊活动为主,高互动过程;
设计师单独和封闭工作; 设计师合作式的工作,随时把工作的产出物展示,接受反馈;
设计师能力专一; 鼓励T型人才;
缺少用户测试; 在不同精细度的原型上快速进行用户测试,迭代式演进设计;
大而全的设计; 只设计足够的交互;
远离客户以避免变化; 和客户在一起鼓励变化;
不对交付负责,肆意发挥; 对交付负责,在成本接受的范围内创新;

感谢张凯峰对本文的审校。

本文原文发表于InfoQ:http://www.infoq.com/cn/articles/xzc-agile-interaction-design

Share