前言

前言

长久以来,软件开发工作和它所支持的组织的其它部门是相互割裂的,少有例外。组织的其它部门经常不理解软件;开发团队也常常不能很好地与公司的其它业务协调一致。沟通有困难,一方面经常导致构建的东西是错的,或者至少是不那么正确;另一方面,它让管理和控制耗费极高。敏捷方法提供的帮助就在于它建立了快速反馈循环,能让我们在预算耗尽前有机会纠正错误。

我们需要一种能够让开发部门成为其它领域完全合作伙伴的方法,能够让大家共同努力使客户满意,并带来业务成功。共同参与要以高效和有效的沟通为基础,但是各个部门有不同的视角甚至不同的词汇,这使得清楚的沟通变得十分困难。我们需要一种方法,能够可视化协作解决的问题,而其可视化的方式要便于人们从各自所处领域的视角就同一问题做出贡献。敏捷方法使用“可工作的软件”作为可视手段——快速地实现一小批用户故事,让软件开发之外的部门就其做出反馈。然而,虽然可工作的软件可以验证选择,但是它在发现和选择哪些满足用户以达成总体目标的用户故事上却帮助不大。

很多阻碍有效沟通的因素的出现,是因为假设没有被共享、检视和证明,不同领域有不同的假设。如果这些假设能够被清楚地建立、并加以检视和证实,我们就可能更快地得到更好的解决方案。这正是影响地图发挥作用的地方,它们可视化地呈现了我们所面对的问题的四个方面:为什么(WHY),谁(WHO),怎么(HOW)和什么(WHAT)。

就像公路地图呈现了市镇以及连接它们的道路一样,影响地图展示了我们要构建的东西,以及它们与人们使用方案解决的问题之间的连接。公路地图的首要任务并不是提供关于市镇的详细信息,而是清晰展示它们之间的连接;它的次要任务是帮助我们发现替代线路。

讨论影响地图上的节点,以及如何连接它们的不同假设,可以让不同领域的人高效参与进来,发现创新和高效的解决方案。它为做出决策和揭示不确定性提供了明确的情景,并且可以在随后被验证。就像道路可能封闭或正在修建中一样,假设有时候也会是不成立或者是错误的。我们把它叫做公路地图而不是目的地地图,它所提供的帮助是可视化那些能够被证明和验证的假设(道路)。

我们看到了从推动到拉动的根本思维转变,以及相应的,从指令性控制到适应性控制的转变。推动意味着人们需要被告知做什么,而拉动从问题和机会出发,挑战跨领域的团队,让他们高效地理解和应对这些问题。这一根本转变还体现在,从关注“制造”用户订购的东西,到关注通过共同协作达成目标。这需要实现从外在激励(推动)到内在激励(拉动)的转变,正如Dan Pink给出的优雅解释:内在激励是由自治、专业和目标驱动的。

今天,实现我们目的的唯一有效方法,是组成一个包含所有必需领域能力的自主小组。然而,除非拥有共享的目的和目标,否则小组是不能成为高效团队的。共享的目标来自共享的故事,我们需要讲述故事,或者更进一步共同发现和创造故事。影响地图也是我们在概念上如何应对目的和目标的故事板。它太重要了,我们不能只寄希望于“用户”或“产品拥有者”把它推向团队。

影响地图方法帮助我们专注于理解和演进式地应对即使是“怪异的问题”——如今我们不得不更多地面对它们。这本书主张不断地重复检视每个元素并验证假设,这正是今天所需要的。即使一开始选择的影响、效用、目标或目的是基于对组织和市场状况作出的假设,也需要随着解决的步骤加以验证。

设计就是要找到并尝试可能产生期望影响的方案,关键部分既不是原因也不是效果,而是验证连接两者的假设。被真实实验产生的数据验证的假设让我们能够创造真正的价值。一个影响地图连接了备选的原因和期望的影响,它是连接原因和效果之间的假设的地图。它帮助你找到正确的问题,这比找到好的回答要困难很多。

Tom Poppendieck

目录