@lsmn
2015-06-27T08:44:46.000000Z
字数 3399
阅读 2439
精益
敏捷
流程
如何获得良好的流?在软件公司中,一个常见的场景是同时进行的工作太多。我们需要转变思想,从关注资源效率到关注流效率。本文给出了如何实现流的具体例子,包括限制在制品、减少等待时间和筹建跨职能团队。
引言
如何在流程中获得良好的“流(flow)”?近日,我在瑞典斯德哥尔摩参加了一场“精益咖啡”会议。在会上,有个人描述了他们的情况,一个有四名开发人员的团队需要服务于四名不同的产品经理的需求。她说这种情况太分散。这引发了我对于这种我认为非常常见的情况以及精益和敏捷如何帮助解决这个问题的思考。
一个有瓶颈的流程
这是一张通用的流程描述图片。它可以描述任何类型的流程,请求从流程的一端进入,交付物从另一端输出。流程中有多个增加价值的步骤。如果流程没有增加价值,那么就没有存在的理由。所有流程都存在瓶颈/约束形式的限制[1]。
“最窄”的瓶颈决定了流或者整个流程的生产能力。精益的一个关键概念是kaizen,它的意思是应该对流程进行持续改进。当一个瓶颈消除了,另一个就变成了“最窄”的,因此,你需要继续kaizen工作,永不结束。流程是一个公司所拥有的最有价值的东西,比其产品和服务(会随时间变来变去)更有价值。希望流程改进可以一直持续下去!
遗憾的是,我从软件开发行业中得到的经验表明,我们更关注我们做什么(产品和服务有一定的不稳定性),然后是如何做(长远来看,流程将最终决定公司的成功)。希望在软件行业中,我们可以改为更关注后者。要获得流,就需要专注。
过度分散是一种常见情况
我认为,这是一种在许多软件公司中都非常常见的情况。注意力分散“各处”——公司提供的多种产品和服务。我们常常做点这个,做点那个,以免错过可能成为“下一个大事件”的东西。由于我们一次做许多事情,所以工作变得太“稀疏”,所有任务间的上下文切换[2]使我们产出的实际价值越来越少。由于无法预见事情什么时候可以完成,所以我们不得不提早开始,这进一步增加了在制品数量。在制品是指你同时进行的所有工作。最终,你进入了一个恶性循环。在软件开发中,没有天然的在制品限制(所有的工作都发生在我们的头脑中或者服务器上)。在工厂中,有物理上的限制,比如有限的地面空间。
事实上,缺乏专注更可能使我们不成功。在史蒂夫乔布斯的自传[3]中,有一个章节讲述了一次所有苹果高管都参与的异地会议。如果我记得没错,高管们大概有100个不同的想法,他们认为那些想法会成为“下一个大事件”,并希望公司支持和资助。通过在几天的会议中比较和讨论各个想法,他们最终将它们归结为三个。现在的好处是,整个公司都支持那三个想法,他们可以非常非常专注。
我们希望使流程更加合理,增加生产能力
下面是我们希望实现的目标:
一个良好的流的例子——接力棒
我是个体育迷,包括田径运动。在世界锦标赛或奥林匹克运动会中,4x100接力赛通常是一项非常有趣且激动人心的赛事。
当前的世界记录为(男子):
虽然迈克尔·约翰逊是有史以来最好的运动员之一,但来自牙买加的团队创造的接力赛记录比他的400米记录快了15%。为什么会这样?有两个原因:
因此,在这种情况下,1+1+1+1不等于4,而是大于4!我们如何将这种情况转化为一种与我们的环境相匹配的描述?
“一体式(One piece)”连续流
精益的真正目标“Nirvana”是一个一体式连续流。这里的一体式是指在工作流程中增加价值的步骤之间没有任何等待时间或库存。就像接力棒!我们开始时可以从上述哪个原因入手?当然你可以(并且应该)雇用最熟练的人,并让他们尽力而为,但最有意思的是运动员之间的交接棒。事实上,一个国家,即使它的运动员不是最好的,只要他们将交接棒的过程练习到完美的程度,那么也可以在奥林匹克运动会或世界锦标赛中取得好成绩。在决赛中,经常出现那样的情况,其中一个可能夺冠的国家因为交接棒犯规而被取消资格。
在你的组织中,你们会练习在流程的不同步骤之间交接吗?或者你们只关注流程步骤?
我们姑且将我们的“运动员”描述为:分析师、开发人员、QA&部署人员。分析师和开发人员之间的任务(需求)交接是如何进行的?开发人员在接到需求之前就已经“提起速度”了吗?
为了确保交接过程没有遗漏,分析师同开发人员“一起跑”了吗?我猜,在大多数情况下,任务都在排队(比如在一个跟踪系统中)。
学习接力棒的例子
我们能从这个例子中学到什么呢?首先,我们需要练习交接,使交接过程尽可能顺利。在竞争模式(比如:做日常工作,交付给客户)下,这是不可能做到的。我们需要后退一步,反思我们的行为,然后做出改变,获得持续改善。其次是专注和信息共享(如果你愿意)。所有的“运动员”都完全清楚要做什么以及何时做。他们有所有需要的信息,所以能够俯瞰“整个比赛”。
如何实现流
在软件企业中,如何实现良好的流?对于许多组织而言,思想的转变是必须的。现在,我们往往专注于高资源效率(人们一直很忙)。相对于高资源效率,我们还有高流效率(工作在流程中快速移动)。我们必须做的是,暂时停止关注高资源效率,留有冗余(资源变得可用),那样,流被优先考虑,然后改善流程(kaizen),资源因此更高效。通常,总提前期中只有1-5%的时间增加价值,20%增加价值是个很高的数值了[4]。
我们希望创建的是覆盖整个价值流、包含所有所需职能/能力的团队。这样做,我们就可以确保交接工作尽可能地顺利,因为它们发生在彼此了解而又向着共同目标努力的同事之间。有三件事可以成就一个伟大的团队:自主性、掌控性和目的性[5]。
例子:如何获得流
下面是一些有关如何在流程中实现流的例子[6]:
小结
在这篇文章中,我已经讨论过,所有的流程都受瓶颈限制。在软件开发公司中,一个常见的场景是同时有太多的工作在进行,导致工作太分散、太稀疏。4x100米接力赛中的接力棒是流的一个很好的例子。在文章最后,我描述了思想转变,从专注于资源效率到专注于流效率,然后给出了一些获得流的例子。
关于作者
Tomas Rybing居住在瑞典斯德哥尔摩,自1996年开始从事IT工作,最初是名顾问兼程序员。从2007年开始,他的关注点转到了团队领导、项目领导、产品管理和开发方法。他有一个妻子和两个孩子。他的主要爱好有运动、音乐和旅游。你可以通过电子邮件、博客或者Twitter同他联系。 |
参考资料
[1]约束理论
[2]上下文切换——头号公敌?
[3]《史蒂夫·乔布斯传》,Walter Isaacson,ISBN 978-1451648539
[4]悖论:忙碌的蜜蜂
[5]《Drive: The Surprising Truth About What Motivates Us》
[6]《Kanban in Action》,Marcus Hammarberg & Joakim Sundén