本书介绍由外到内的软件开发方法，定义了利益相关者特定的分类和实用的方式。本书介绍了易用性以及实用的技术，以评估和改进产品的快速有效部署、使用和支持的能力。本书还介绍了要与利益相关者的目标保持一致、用利益相关者的术语定义成功，应用由外到内的开发技术和成功采用已验证的方法，增加成功的机会。.
本书可供从事软件开发工作的业界人员参考。
一个理想的开发项目会准确地交付客户所需要的东西，并获得广泛、快速和热情的采用。它是由一组高效率、高士气的软件专家设计和构建的。使用本书讲述的“由外到内”方式进行软件开发，你的下一个项目就会是这个理想的项目。
在本书中，Carl Kessler和John Sweitzer，这两位最受尊敬的IBM软件领导向你讲述如何识别和决定项目实际价值的利益相关者，如何围绕他们的实际需要调整每一个决策，以及如何才能交付获得广泛、快速和热情采用的软件。
这两位作者介绍了一个端到端的框架和实际的实现技术，对于任何项目类型或范围，任何团队都可以快速地从中获益。使用已验证的方式，可以提高与客户交流的效率，更可视和更清晰地定义优先级，还可以确保你的所有代码递送最大的业务价值。
本书内容包括..
●理解利益相关者和他们所处的组织和业务背景。
●澄清项目将满足的短期和长期的利益相关者目标。
●更有效地把项目预期映射到成果。
●构建比较“易于使用”的软件：比较容易部署、使用和支持的系统。
●持续地保持与利益相关者目标的一致性。
●在交付产品之后，一直帮助利益相关者管理持续的改变。
●掌握驱动由外到内开发所必需的领导技术。...
设想你的下一个开发项目正好成功地满足了客户的需要，而且是通过一个高效率、高士气的团队构建完成的。你的产品在使用初期就获得了广泛的应用、积极的引用和评论。
这听起来很吸引人，难道不是吗？
这是由外到内的软件开发模式对你的承诺。使用本书介绍的由外到内的开发观念和实践指导，你可以把这种情形变为现实。
本书是为谁准备的
本书是为想要提高开发产品质量的人准备的。
掌握了这个方法，你会成为一名领导者。
也许如今你已经担任了这样的职位，或那是你渴望得到的东西。也许你的同事已经把你看成领导了。也许你并不关心这一点，你只想开发出更成功的产品，开发出对你的客户来说真正有特色的产品。
假如你是这样的人，那么你就是我们要服务的读者。
由外到内的开发方法适用于所有的开发职能。本书适合的读者非常广泛，包括经理、管理和非管理角色。由外到内的开发技术适合于编码人员、测试人员、技术文档编写人员、设计人员、支持工程师、架构师、用户界面设计人员、性能压力测试人员和其他各种各样的专业人员，包括市场、销售、经营战略、产品管理、业务发展、产品定价、财务和售后服务。
假如我们遗漏了你的角色，那是无意的。
成功的软件产品开发不仅是创造没有缺陷的代码。成功的产品可以让使用这些产品的组织获得成功。这些成功的产品是由高效、多职能的团队构建的。
假如你觉得自己属于这样的团队，那么本书很适合你。
如何阅读本书
本书使用了人称代词你或我们，偶尔会用名字John和Carl。这种方式相当简单：无论你担任的是什么角色，“你”代表的是读者。
“我们”代表的是作者。而John或者Carl代表的是我们两个人中的一个。
我们也经常使用一个通用的术语：客户。这个术语代表产品的任何可能的消费者。表1呈现了称谓的简单对应关系。
表1 本书中的称谓
称谓 你 我们 John或Carl
用特定的标题引起读者的注意
我们希望通过使用本书提供的材料，激起同事们进行讨论的热情，并能够把由外至内的开发概念快速引入到项目中。为了达到这个目的，我们采用了一些方法。
每一章结尾都包括要点综述部分。
第2~7章还包括关键术语的回顾。
在每一章都有一段，标题为：在……中的领导者的角色。这是写给有兴趣抓住机会帮助团队的人。
阅读时试验一些概念和技巧
下面介绍阅读本书的技巧。当阅读完一章后，列出要点清单，这样你就可以开始和同事进行交流并立即使用这些技术。
从要点部分开始，想象如何把这些实践应用到自己的环境中去。接下来，你可以在团队内部乃至自己的工作项中试验这些技术。
不必等到阅读完整本书，就可以把这些由外到内开发的概念用到会话、会议、客户评审等任何地方：我们确信你会对这种方式在实践中的自然运用而感到惊喜。
为什么写这个主题
我们编写本书是因为客户需要能够帮助他们的业务取得成功的软件产品。
我们知道客户能从许多渠道获取软件，而不仅是从我们所在的公司。当我们的产品满足客户真正的业务需求、使他们快速和高效地取得业务成功时，我们双方都会获利。
然而在大多数情况下，跨行业的团队关注生产代码的处理和方法，却没有足够地关注谁会使用它或为什么需要使用它。
由外到内的软件开发分享了我们以及许多同事的经验和实践，还介绍了一个概念性的框架以便软件开发团队可以容易地理解、应用和获益。最后，这意味着使用软件产品的公司将收获更多。
内容概览
本书共包含7章。第1章介绍了由外到内开发（OID）的基本概念。
接下来的四章介绍了由外到内开发的基础知识。其余几章介绍了一些实用的、已证实可行的方式，这些方式可以帮助你在开发中成功实现OID。
下面是本书的内容概览。
■ 第1章，介绍由外到内的开发。
概括介绍由外到内的开发（outside-in development，OID）思想和期望它能做什么。
■ 第2章，理解利益相关者。
由外到内的开发定义了利益相关者特定的分类和实用的方式，详细阐明你将服务哪些利益相关者，他们的目标是什么以及如何用你的产品实现那些目标。
■ 第3章，了解组织的背景。
揭示你的潜在客户当前组织的方式和他们将来应该组织的方式的技术，提供有助于和他们的目标进行对话、有助于有效调整设计和开发以满足那些目标以及有助于成功交付软件产品的见识。
■ 第4章，使产品易于使用。
介绍了易用性这个术语以及实用的技术，这种技术用以评估和改进产品性能，使之可以快速和有效地部署、使用和支持。
■ 第5章，与利益相关者的目标保持一致。
不断地提高你对利益相关者的目标和产品有效地满足这些目标的理解。交付一个能使客户达到他们的业务目标的产品，需要许多优秀的实践和不断地改进；由外到内开发的实用方法包括许多已被验证的技术。
■ 第6章，用利益相关者的术语定义成功。
由外到内的开发方式并不认为软件交付给客户时产品开发就结束了。相反，软件的生命周期延伸到生产周期，开发团队有责任渡过生产周期的三波活动。
■ 第7章，成为一位由外到内的开发人员。
在产品周期中的任何时候都可以应用由外到内的开发技术，成功采用已验证的方法会增加成功的机会。
可以跨行业使用由外到内的开发
由外到内的开发方法不仅适用于像IBM这样的大公司。
虽然我们能够通过提取和精炼来自数百个规模不同的大小项目的技术而受益，但是，学到的经验既适用于小的、地方化的团队，也适用于大的、分布于全世界的团队。
或许大小团队之间的最大区别在于角色重叠：在一个小团队，单个人担任多个角色。例如，产品经理领导一个小项目，同时也领导程序员或市场人员。
正如先前所述，当我们说“你”而没有进一步详细说明的时候，我们希望读者把材料应用于特定的角色（或多个角色）。关键是这里不局限于大公司。
每个人都可以使用由外到内的开发观点。
不依赖过程和方法
所谓每个人都可以使用由外到内的技巧，是指你可能使用各种各样的开发过程和方法。我们花了一年多时间，交付了大型瀑布式项目，在这个项目中使用过由外到内的开发，在按四个星期固定迭代交付的更精简、更敏捷的项目中，我们也使用过由外到内的开发。本书讲述的不是开发过程。
广泛应用的企业到企业（B2B）
我们从软件供应商（为企业消费者构建产品）的角度编写这本书，但是还有更多角度。
假如你进行内部应用程序的开发，为开源项目、政府机构或非盈利组织工作，或者仅出于爱好构建软件，你会发现这些材料也适合你。
无论你出于什么原因构建软件，都应该阅读本书。是的，本书的例子将成为你的软件供应商同行。
除此之外，本书的内容对于每一个想要构建好的软件产品的人来说都很有用，确实很好。
感 谢
本书的两个作者都就职于IBM公司，多年来，IBM的许多产品一直采用由外到内的开发方法。很庆幸，大部分资深的领导倾向于使用重型的客户驱动，所以由外到内的开发思想对于他们来说很自然。因此，大部分工作已经统一，而且扩展实践也已经在使用，这使它们更易于被开发中的软件产品使用。
这个项目在Carl和Alfred Spector（那时候他是IBM软件组策略和技术的副总裁）进行了一次会谈后就开始了。那次讨论的主题是如何帮助客户和合作伙伴构建更成功的软件。我们中的小部分人被派到世界各地，在小团体中共享我们的经验，这样做几乎不能扩展。另外，当IBM有组织地通过收购稳步地增加自己的开发人员时，同样需要一种途径有效地影响分布在世界各处的很多人。Alfred认为本书能做到这一点。
20世纪90年代初，当Al Zollar要求John担任一个“集成和可用性项目”的架构领导时，John开始考虑这些问题。这次委派引起了一系列协作，其中包括John的设计实践从由内到外发展转到由外到内，而这些是基于一些同事的影响，例如Joe Pesot、Tony Temple、Carol Jones、Robert Uthe、Rod Smith和Charles Hill。
我们正在一个强大的经验基础之上进行构建。Tony Temple、Dick Berry、Julian Jones、Carolyn Brown和Karel Vredenburg引入了这个术语—由外到内的设计，并将其作为在用户界面开发的工程学科中的下一步。Bernard Kreppel、Craig Zabell和Bob Biamonte发展了关于消费记分卡片和业务手册的使用的见识，而Bill Woodworth、Scott Will、Paul Gibson和Ted Rivera确定并共享了质量和测试改进的成功经验。
正如你对任何大型组织所期待的一样，由高级经理来确定推动团队文化和行为的基调。在IBM，我们使用由外到内的思想，一开始就具有巨大的优势：我们的三个企业价值观中的第一个就是“成就客户。”它的核心当然就是由外到内的开发。但是，这一点都不令人惊讶。我们的老板和同事强烈鼓励基于利益相关者的思想已经有好多年了，尤其是Steve Mills、Danny Sabbah、Robert LeBlanc、Ambuj Goyal、Al Zollar和Kristof Kloeckner。他们都值得称赞，因为他们构建了一个成功的全球性的软件开发组织，该组织的主要口号是接受客户至上这一全球性的观点。
我们要特别感谢Danny Sabbah和Kristof Kloeckner在引入大规模开发项目的易用性的概念并把它引入实际运用方面所做的工作。我们还要感谢同事和经理的支持，尤其是Suzanne McKinney和Lee Roberts。
业内有令人感动的友情，我们从中受益匪浅。非常感谢Tom Poppendieck、Per Kroll、Ted Rivera和Christine Draper，他们检查了本书早期的手稿并提了许多非常有价值的建议。我们无法用言语来表达我们的感激，我们还要申明本书的任何错误都和他们没有关系。
据说，银弹对付狼人非常有效。然而，几十年的经验表明，管理软件开发显然没有银弹。在当代的软件开发组织中，我们能拥有令人自豪而满意的工作的美好希望甚至比狼人还少。
艾伯特·爱因斯坦认为：“我们当前的思维水平所创造的世界产生了相同的思维水平不能解决的问题”。值得思考的是，把软件开发看作一个将需求转换为有价值软件的不可思议的过程，这可能实际上比我们寻找解决办法更困难。即使构思精妙、没有缺陷的软件本身，实际上也只有很少的实用价值。产品的设计或者软件内嵌的业务流程决定了它的潜在价值。当这个产品满足某些需求时，它的价值才会体现出来，软件的任务才算完成。
从未满足的需求或目标的初始概念到通过使用新产品或业务流程而实现这些目标是一个价值链，当我们对其进行检查时，很显然软件仅仅是其价值链的一部分。对这个价值链标准的思考力争避免导致下列情形的局部优化：软件的设计和实现与产品或过程（需求）的设计分离；软件等设计和实现与软件嵌入式产品的布署、支持和实际使用分离。任何一部分所作的决定都会明显地影响其他部分。与对一部分的优化影响其他部分相比，对价值链的优化达到平衡可以使我们的团队得到最大的价值。
依赖软件的组织维护了一整套虚拟的产物、管理过程、需求过程、软件开发过程、销售和市场过程、操作过程等。每个过程都是强壮的、完善的并不断地和其他的过程相交互，传递对组织的发展或用户的价值来说不必要的信息。优化任意一个流程的银弹通常会影响其他流程。
价值链的每一部分，从概念到持续的现金流，都由人来执行。人是必需的，因为设计和开发基本上是学习活动，不是生产。我们必须和熟悉各个领域的人充分、清晰和频繁地沟通这样可以做出同等和一致的设计、实现和递送决议，这些决议是他们可以共同快速递送的最好成果。跨职能的团队为自己能够递交很好的产品和有效的业务流程而深感自豪。
纯粹的软件实践是必需的，但只有这些还不够。我们必须把价值递送问题认为是由外到内进行的。本书中，Carl Kessler和John Sweitzer提供了一个有用的方法来确定问题范围，这个范围是从识别决定最终结果实际价值的关键利益相关者开始的。他们指明了产品开发团队该如何做决定来顾及每种利益相关者的背景和通常的利害关系。
虽然由外到内的思想对团队正采取的实际的软件实现方式进行了补充，但是它改变了衡量成功的方式。一个成功的由外到内的团队要学习许多知识，而不做过多推测。灵活的软件开发过程强调频繁的反馈，可能交付所有的利益相关者真正重视的解决办法。但是，如果没有由外到内的背景，即使我们将灵活的软件开发过程执行得很好，也要冒“技术上的成功”的风险，这只是业务失败的委婉说法。
由外到内的方式是一种系统思考的方式。把端到端的价值链看成一个价值递送系统，这不但不会毁掉我们的虚拟产物，反而会使它们能够像一个平衡的生态系统那样运作。要想实现这一点，需要结合一个组织的所有层面的努力以及严谨有序的工作。这种思考方式比沉溺于对另一个银弹的迷恋更高级。
—Tom Poppendieck
Carl Kessler，John Sweitzer：暂无简介
蔡黄辉; 沈晓霞：暂无简介
非软件行业的人们是如何看待软件的呢？他们希望怎样才能从软件中获得期望的价值呢？在考虑采用新的软件时，他们比较关注的问题是什么？什么样的软件在他们眼里是成功的软件？软件除了实现功能性需求之外，还需要关注哪些内容？在软件开发过程中，如何才能做到结合实际情况开发出能满足各种用户需要的软件产品？
这些问题一直困扰着我和软件行业的很多同仁。这本书从利益相关者的角度出发，系统地介绍了软件开发过程中需要注意的问题，包括利益相关者的分类、组织的背景、怎样确认软件产品是否成功、如何开发出一个成功的软件产品，还介绍了当同时拥有多个产品时需要关注的内容，最后结合两个极端的瀑布式开发方式和精益六西格玛开发方式，介绍了在实际应用中如何使用这种由外到内的开发技术。
无论你是打算进入软件行业还是刚刚进入软件行业的新手，或者是资深的软件项目管理人员，只要你思考过前面介绍的问题或对软件行业感兴趣，那么这本书就可以帮助你，给你一个新的视角来考虑软件开发过程中一些需要注意和可以改进的地方。
由于时间仓促，加上译者水平有限，书中难免有翻译错漏或不妥之处，敬请广大读者和同行不吝指正！
感谢我的妻子沈晓霞，她在我翻译这本书的时候对我提供了无私的支持，同时她还参与了第2、3、4章的翻译。
参加翻译的还有蔡德平、陈品珍、沈斌、张红、蔡红健、张建时、陈品菊、陈凯金、陈品琴、王建平。
蔡黄辉
2008年9月
译者序
序
前言
第1章 由外到内的开发方法概述 1
1.1 可能需要一些挑战 1
1.2 考虑一种不同的软件产品开发方法 2
1.3 还需考虑一些已验证的技术 2
1.4 带领整个团队走向成功 3
1.5 了解利益相关者 3
1.6 了解组织的背景 4
1.7 使产品易于使用 6
1.8 与利益相关者的目标保持一致 6
1.9 用利益相关者的术语定义成功 7
1.10 成为一位由外到内的开发人员 7
1.11 由外到内的开发中领导者的角色 8
1.12 要点：从现在开始 8
第2章 理解利益相关者 10
2.1 理解利益相关者概述 11
2.2 识别利益相关者 14
2.3 理解利益相关者的目标 16
2.3.1 描述利益相关者目标的技巧 18
2.3.2 识别讨论中出现的约束 19
2.4 四个利益相关者组 20
2.4.1 负责人 20
2.4.2 最终用户 21
2.4.3 合作伙伴 24
2.4.4 内部人员 25
2.4.5 考虑利益相关者之间的关系 26
2.5 和利益相关者进行对话 27
2.5.1 理解负责人利益相关者的目标 27
2.5.2 理解最终用户利益相关者的目标 32
2.5.3 理解合作伙伴利益相关者的目标 33
2.5.4 理解内部人员利益相关者的目标 33
2.6 使客户的讨论与利益相关者的目标一致 35
2.7 理解利益相关者中领导者的角色 37
2.8 要点 37
2.9 关键术语 38
第3章 理解组织背景 40
3.1 组织背景概述 41
3.1.1 由于组织背景不同而相互矛盾的反馈 43
3.1.2 现实中的组织背景差异 44
3.1.3 用组织的设计意识选择软件市场 46
3.1.4 组织背景差异的其他方面 47
3.2 处理不同的客户需求 49
3.2.1 不可能使所有人都满意 49
3.2.2 一个用户形不成市场 50
3.3 利用组织背景理解利益相关者的立场 50
3.4 使用组织背景中领导者的角色 56
3.5 要点 56
3.6 关键术语 57
第4章 使产品易于使用 58
4.1 产品易用性概述 59
4.2 识别易用性元任务 64
4.3 使用易用性计分卡指导投资 66
4.3.1 在计分卡中使用易用性元任务 68
4.3.2 构建计分卡 73
4.4 选择需要强调的易用性元任务 75
4.4.1 验证易用性数据 76
4.4.2 把真实世界包含在计分卡中 77
4.4.3 在计分卡中包含完整的产品组合 78
4.4.4 计分卡之外 79
4.5 容许更多的人使用产品 80
4.5.1 全球化 80
4.5.2 可达性 81
4.6 使产品易于使用中领导者的角色 82
4.7 要点 83
4.8 关键术语 83
第5章 与利益相关者的目标保持一致 85
5.1 与利益相关者保持一致的概述 86
5.2 关注利益相关者的利益 87
5.2.1 利益相关者的所有问题 88
5.2.2 反馈的质量取决于显示的内容和对象 92
5.2.3 获得关于产品基础结构的有效反馈很困难 94
5.3 设计与利益相关者保持一致的能力 96
5.3.1 面对构建响应能力的挑战 97
5.3.2 构建映射到开发方法的能力模型 98
5.3.3 切记共享自己的贡献 99
5.3.4 制定计划能力时提出的问题 100
5.3.5 谨慎使用简化能力 101
5.4 最小化交付物中的噪音，赢得利益相关者的积极反馈 101
5.4.1 对团队投资 102
5.4.2 把缺陷引入与利益相关者的目标保持一致的
讨论的原因 103
5.5 帮助确保质量 103
5.5.1 协作 104
5.5.2 自动化 105
5.5.3 对于未答复的缺陷要小心 105
5.5.4 从缺陷中学习 108
5.5.5 把利益相关者的世界引入你的工作 109
5.5.6 把利益相关者本身带到你的工作环境 109
5.5.7 让团队成员体验真实 110
5.6 为产品成功而预演 110
5.6.1 为产品的预演制定计划 112
5.6.2 欢迎批评意见 112
5.6.3 将预演应用于任何开发方法 113
5.6.4 邀请合作伙伴利益相关者参加预演 113
5.6.5 在预演中邀请尽可能多的内部人员 113
5.7 与利益相关者目标保持一致中领导者的角色 115
5.8 要点 116
5.9 关键术语 116
第6章 用利益相关者的术语定义成功 118
6.1 利益相关者在产品阶段获得成功的概述 119
6.2 第一波：一切为了负责人利益相关者获得成功 120
6.2.1 为产品设置成功的目标 120
6.2.2 确认是否已经达到目标 122
6.2.3 对第一波客户使用反向驻留 122
6.2.4 保持正常的心态 124
6.2.5 制定计划支持第一波获得成功的能力 125
6.3 使用从第一波中积累的经验 125
6.3.1 了解产品的运行情况 126
6.3.2 注意影响第一波客户的缺陷 126
6.3.3 迫切地为利益相关者提供更多的功能 128
6.3.4 使用适当的交付机制交付后续的功能 129
6.4 第二波：一切为了对客户的长期承诺 131
6.4.1 提供清晰的支持模式 132
6.4.2 计划动态地调整产品 132
6.4.3 从第二波利益相关者那里获得反馈 133
6.4.4 利用获得的反馈影响下一个版本 133
6.5 第三波：帮助利益相关者处理新旧版本 134
6.5.1 考虑现有的客户如何移植到新的版本 134
6.5.2 提供移植帮助 135
6.5.3 支持利益相关者 135
6.6 在定义成功中领导者的角色 136
6.7 要点 136
6.8 关键术语 136
第7章 成为由外到内的开发人员 138
7.1 如何采用由外到内开发的技术 138
7.1.1 利用由外到内的技术建立以利益相关者为
基础的文化 139
7.1.2 文化的改变来自组织结构图的两端 140
7.1.3 适当地展开由外到内的开发 141
7.1.4 应该如何着手 142
7.1.5 存在多个领导机会 142
7.1.6 存在积极地推进的环境吗 143
7.2 洞察由外到内开发的效果 144
7.2.1 为团队计划增量地采用由外到内的开发技术 144
7.2.2 选择恰当的初始负责人利益相关者 145
7.2.3 如何对多个软件项目使用由外到内的开发 147
7.2.4 由外到内的开发如何适应瀑布式项目 151
7.2.5 由外到内的开发如何适应精益六西格玛项目 152
7.2.6 由外到内的开发如何适应精益敏捷项目 154
7.3 采用由外到内开发中领导者的角色 156
7.4 要点 156
7.5 关键术语 157
