共计 2922 个字符,预计需要花费 8 分钟才能阅读完成。
蔡建斌 - 国际物流公司亚洲 IT 交付团队经理
导语
敏捷是一个很流行的一个词语,但是在敏捷里面,包括很多团队也是刚开始用 Scrum,怎么让质量成为敏捷的一个助力而不是拖累,这个是我主要想谈的。
关于质量的定义,我前不久接触到一个文章,里面有一个图讲到质量的五个维度,但是我做了一些微调,改成了四个。接下来就从我定义的 4 个维度的质量分别探讨一下。
1. 基于价值的质量,交付影响而不是交付产品
在 IT 业有一个很著名的人叫做 温伯格 的咨询师,他提到质量的定义叫做 质量是对某些人的价值,价值是什么意思?
福特问客户想要什么,他说要一匹更快的马,但是福特提供给了客户汽车。马和汽车是提供给客户的产品,价值是什么?客户可能有天天从各个城市飞来飞去需求,他希望有更快的马来助力,这个就是价值的意思。客户的需求往往是方案,它很少告诉你这个东西背后是什么目的。所以 User Story 的背后,就是价值。
在工作上,我认为我们不是在交付产品,而是是交付影响力,就是交付对用户的影响。你让我开发一匹更加的马,我要问这个马用来干什么,对你有什么影响,因为我交付的是影响而不是产品。
Impact Mapping 通过 Why Who How What 得到一些想法:我们做产品是为了什么?影响哪些人?
- 如果说一个咖啡馆老板,他想赚一个亿,谁能帮助他达成这个目标?
- 如果说顾客可以帮助他达成这个目标,那怎么帮助他达成?
比如 顾客(who)买了咖啡之后,觉得不错然后会 推荐给其他朋友(how),所以顾客通过把咖啡店推荐给好友的行为可以帮助他 赚到一个亿(why)的小目标,但是需要注意的是,这个 ”who” 可以很多。
有了前面的铺垫后就能得到 ”what”
为了鼓励顾客去推荐好友这个行为,我可能会 开发一个“推荐赚积分积分换咖啡”(what)的功能系统。我们开发 Story 不是 Story 本身,产品本身不是我们直接的目标,我们的目标其实是为了影响“顾客去推荐好友”这样一个行为,这个影响,最终达到业务目标,就是这个 why。
我们跟产品合作,他们给我们做了一次 what,他会说你给我做一个积分换咖啡的功能,其实背后这些功能会带来什么样的价值,才是更需要探讨的。但是这样的思想框架并不是真的去问 why、who 等等,而是告诉我们真正需要交付的东西,而不是真正的产品。所以说提出一个可能符合背后目标的更好的 what 出来,这才是框架的一个根本目的。
2. 基于产品的质量,利用反馈
例如,我们要研发更快的马,或者研发一辆汽车,这个就是产品本身,定下来仍然有质量因素在里面,就是怎么把东西做对。
Cynefin 模型:
simple:你要解决问题很简单,你有一些最佳实践套用就可以了,如果你的公司,你的研发在这个象限上,其实是恭喜你,其实是非常舒服的
complicated:比较繁杂的场景,这个场景下你的解决方案可能有多个,可能不存在最佳实践,又或者可能有多个实践,可能找几个专家来帮你搞定,这个是一个场景
complex:没有办法简单找几个专家来研究得出结论,这个应付的东西是各个维度,有可能是质量出问题,加上预算有限,加上产品方向不清,需求不清,产品跟架构师之间合作不来,各种交织在一起,但是有一个目标需要推进。
chaotic:就是混乱,如果碰到这种,这个挑战确实是非常大,可能不是一般的管理者能够应付得了,需要 CXO 坐在一起给出方向。
disorder:管理者把解决问题分解成多个子领域,分解成多各个情境来逐个击破。
产品研发大部分属于第二和第三象限,这两个维度的实现就是先做,然后再反馈。反馈有一个原理:越早的反馈越便宜。
举个例子
在产品研发中,有一个很大的问题,就是你的技术团队和产品经理的鸿沟。这个鸿沟很常见,但是在我自己的工作场景里面这个鸿沟不常见,我一直是技术领域的人,但是我在产品上或者需求上跟产品经理一直是通力协作的,用实时的反馈来跨越反馈,而不要等产品经理已经设计了两个月,然后给我们开发完上线后,再提出需求不对,这样就比较被动。
如果反馈能做到实时,下面就是实践。在新的产品研发开始的时候,我与技术人员产品经理会一起先把概念模型画下来,因为一个团队有很多的角色,包括架构师、开发、US、甚至外包人员,不同的角色怎么确保理解的一致,最后明白如何做自己的工作。你怎么确保这份活动基于统一的理解,没有共识就比较容易出现鸿沟。把概念模型画下来就是为了现实上的例子,可以很简单,我们有什么业务对象,他们之间关系是什么样,把这些东西画下来,大家基于一份共识去做各自的活,这个鸿沟会少一点。
3. 基于产出的质量,定义完成,以终为始
我自己是研发出身, 研发质量产出是什么?就是需要建立条目化,短周期之内可以交付的东西,这个是产出,第一个产出是代码,尤其在软件行业,代码占了 80% 的产出,怎么把代码写对,就是第三个维度。
代码质量 有一个心法叫做 定义完成;
举个例子,很多程序员你问他这个 Story 做了没有,他给你的答案是什么?度量 BUG 是为零,程序员做完之后交给 QA,QA 告诉开发有没有 BUG。你的 QA 下一道工序是我的客户,我应该告诉你有没有 BUG 或者有多少个 BUG,而不是反过来。
需求质量 也是很重要的产出;
你要保证你的产品经理做的需求是不是符合,是不是条目化,是不是按照优先级,你是不是做最重要的事情。你有三个团队,每个团队都在按照优先级来做事,但是三个团队是不是有统一的优先级,很多团队是没有做到的。
有些需求你不做用户会不高兴,但是你做了也不会很高兴,就像我们的实践一样,项目大的时候不做实践会很惨,但是做了项目也不一定会成功。
工作中当你问程序员说这个做完没有,很多程序员告诉你 90% 完成,或者完成了但是没有测,或者有几个 BUG,或者需要重构一下,这种心态是不好的,但是没有反馈。
我们叫做以终为始,用户故事只有两种状态,只有完成和没有完成,没有但是,没有完成你要把它完成掉。程序员会说这个做了 90%,然后去做下一个故事,结果是没有一个可以工作。而我们倡导的是把一件事情全部做完,才做下一个。
4. 过程质量,拆
有这样一句话,如果你用同样的方式去烤面包只会得到相同的面包。
过程质量就是写代码的质量,这个心法就是拆,拆成小的东西,拆成一个可交付的东西,其实写代码也是需要拆的。
举一个例子,很多程序员写代码,一天下班的时候代码还没有编译,我们写代码方式应该是这样, 很多程序员写代码是东写一点,西写一点,这个意味着什么?没有透明度,他不知道写哪一个,这样的过程想代码质量好是不可能的。
总结
我们已经讲了四个维度的质量,价值和成本,可很多团队的人没有办法控制价值的部分,有些人却可以。我们是一个技术负责人,产品都不是我们能控制的。你要考虑定制权在哪里?影响权在哪里?你能控制的东西就是你的成本,你不能控制的地方就是你不能提供的。
谁为质量负责? 如果开发工程和 QA 之间出现问题,最后辛苦开发出来的功能,用户抱怨难用,就是价值和质量出现了问题,现在分工越来越细,在很多团队集中在某一层,比如程序员关心写代码,不关心价值和产品,产品经理只关心价值,不关心技术实现,这些鸿沟会影响整个质量。
文章来源:Worktile 敏捷博客
欢迎访问交流更多关于技术及协作的问题。
文章转载请注明出处。