客户是您当前开发项目的中心吗?


如果您正在进行数字转型计划并计划下一次发布,请停下来!我希望你花点时间问问自己:“我的重点是什么?”它是确保技术人员忙碌还是交付真正可衡量的客户价值?

为客户价值优化

一个组织的主要驱动力是向客户交付价值,所以再次问自己:“我的转型计划是否真正专注于实现客户价值?更重要的是,我的下一个版本是什么?”

我相信你以前听过这个:你的敏捷交付应该是快速的。你的冲刺计划包括确保每个人在接下来的几周都很忙,并且你的待办事项的优先顺序主要是由上述因素决定的,或者说是由上述因素决定的。退一步问,“什么在推动交付?”会对你如何实现每一个冲刺计划和项目的整体成功产生重大影响。

我认为公平地说,今天的组织理解确保所有流程高效的重要性,并且他们专注于以最具成本效益的方式向客户交付价值。然而,在许多行业中,这促使组织以更少的成本实现更快、更高质量的交付——这一承诺并不总是经得起考验。

总的来说,这种不经意间确保人们忙碌的动力以及功能不能更快或更好交付的结果来自于注意力分散;当团队不完全理解交付的内容和原因时。

从“忙碌”到“受益”

传统敏捷——是的,我认为我们现在可以用这个术语——围绕架构的组件设计团队,通常被称为组件团队。这种方法使得人们和团队很难理解每个组件对最终用户的影响。由于跨领域的功能,它也很难计划,并且由于依赖关系,很难部署或运行。这种方法的真正问题是缩放破坏了它,并且Brook's Law(更多的人不工作)快速交付全部功能是难以置信的困难。

在停下来从项目的外部观察之后,我们意识到,通常在管理团队(结果)、解决方案的设计及其组件(包括交付的哪些元素给客户带来好处)之间存在不一致。随着他们试图完成的任务的复杂性增加,这些问题在大多数项目中变得更加突出。业务价值贯穿整个组织,影响多个组成部分。

请记住,敏捷是关于创新的,应该用于解决复杂的问题。当潜在的解决方案在开始时是未知的,范围没有明确定义,并且跨职能部门的协作是至关重要的时候,就应该使用它。合作的需要只是强制要求团队更好地理解他们试图达到的结果和他们要达到的最终目标或问题。

将敏捷交付转变为注重确保每次都建立客户价值的模式,需要一种新的软件设计方法,重新组织交付团队,并确保企业理解它试图交付的价值。

需要考虑的3点

从组件团队转移到功能团队

Afeature team本质上是一个跨职能、跨组件的团队,一个接一个地开发众多端到端客户功能。这听起来并不容易,但对组织来说这是一个巨大的变化,如果做得正确,将使每个人都清楚地了解为什么要构建特性,它们会给谁带来什么价值,并确保交付中的每个特性都有明确的端到端所有权。

关注仍有待实现的价值,而不是迄今花费的时间

传统上,报告是一种回顾性的行为,让管理层知道团队没有取得什么成就,以及花费了多少。历史信息有助于了解,但不能让你衡量企业在实现结果方面取得的进展。将焦点转移到剩余价值(一旦定义)上意味着如果价值或结果得以实现,一些项目可以提前完成。

确保每个人都理解您试图交付的整体模型

给交付团队一个清晰、简洁的业务领域和项目目标价值的视图,是帮助人们理解和优先考虑需要交付的功能的好方法。这种方法可以帮助产品所有者消除直觉,帮助确定优先级,并确保每个人都了解对客户或渠道的影响。