——《精益设计》读书笔记 & 团队协作的思考
几乎国内大一点的互联网公司都会设立独立的用户体验团队,虽然名称上各家稍有差别,不过在协作上多数还是传统瀑布式流程:设计部门从上游产品部门获得需求,完成交互和视觉设计之后,再交付给技术和测试等下游环节,交付完成后再来应付下一波产品需求,要是遇到些问题还需要反复修改的话,下游的进度也会一并耽误。
这样的协作流程把整个流程中各个部门的职责分的很开(包括办公位置也是),所以各个部门的人也会理所当然的给自己部门画出一个隐形的「职责边界」:产品只负责产出需求、交互负责产出原型、技术只负责开发… 每个人只对项目中的一个环节负责,对职责边界以外的事情就放手不管了,于是整个团队中只能看到只对自己的环节负责的人,却找不到对整个产品负责的人。
在这种协作模式下,很多时候遇到职责边界不那么明确的事情,又没有及时沟通,就很容易出现各部门互相推诿的情况。即使这次的问题被明确到某个部门的职责边界中,下次出现个其他不明确的问题,这样的情况依然会往复发生。
那么问题出现在哪呢?公司的产品是按照「项目」划分的,但是却不是按照项目整体推进的,完成项目的方法是一环接一环的传递,参与项目协作的人也分散在各个部门,所有人对项目并没有整体的概念,例如项目的目标、价值、成员所做事情的意义等等。而且项目成功了并不带来好处,失败了也不会影响绩效,所以大家只能埋头做好自己的分内工作,就好了。
把产品协作的各个环节作为独立部门,会带来很大的浪费,包括冗长流程带来的效率浪费,还有各部门对项目缺少整体的理解带来的沟通浪费。
Lean UX 就是为了减少这两部分浪费提出的。
协作的本质是沟通,环节越长、团队越分散,沟通成本就越高,就不能保证信息传递的准确性和及时性,Lean UX 就是通过精简环节、注重沟通来提升效率。
Lean UX 的精髓在于跨职能小团队和集体决策——确定项目后,把参与项目的成员聚集在一起,建立跨职能小团队。小意味着快,因为沟通的环节减少了,沟通的成本下降了,效率自然会提升,然后通过团队集体快速决策 、简化流程和交付物等方法使协作的效率最大化。而且以「项目」驱动的小团队更能明确集体目标,会有更强的参与感和责任心,也会让团队成员有更强的意愿参与决策,产品在做之前团队成员就已经达成了一致,而不像瀑布式的流程开发中经常出现的下游环节对上游决策的质疑。
这样的跨职能团队一定是以目标驱动的,团队有权力直接针对业务问题设计解决方案。也就是说,由团队自主决定用哪些功能来实现公司的目标。产品需求也必须从成果的角度来谈:我们希望通过这个产品达成什么目的?设计也是如此。
Lean UX 涉及到的另外两个概念是精益创业的 MVP(最简可行产品)和敏捷开发中的 Scrum 方法。
精益创业法使用了“开发-评估-认识”的反馈环来降低风险,让团队可以快速开发和认清现实。精益创业团队开发出最简可行产品(MVP)之后,就迅速把产品推向市场,以便及早地认识市场。
Scrum
一种敏捷方法论,推崇限时迭代,自行组织,具有高度团队责任感。Scrum是运用最广的敏捷方法论。大多数Scrum团队都把两周算作一个 sprint,sprint 的目的是交付可用的软件。
建立跨职能小团队后,融合 Scrum 工作方法进行快速迭代,然后通过 MVP 快速验证产品方向,然后根据用户的反馈继续调整方向,开始下一个迭代……
另外 Lean UX 也是有理论依据的,罗伯特·戴利(Robert Dailey)在20世纪70年代末做过一次研究,称为“论团队和任务特征对于研发团队协作式问题解决和生产效率的作用”(The Role of Team and Task Characteristics in R&D Team Collaborative Problem Solving and Productivity)。在这次研究中,戴利发现团队解决问题的效率和四个因素有关,他称之为“四个预测因素”:任务的明确度,任务的独立程度,团队的规模,团队的凝聚度。
所以你看,落实到团队协作中,Lean UX 提到的工作方法基本也是以上几点的延伸。另外说一句,虽然介绍 Lean UX 这本书叫《精益设计》,不过里面的方法多数是围绕团队协作展开的,推荐阅读。
如果懒得翻书,就先看看我的书摘吧。