版权
超越需求：敏捷思维模式下的分析
• 著 [美] Kent J. McDonald
译 霍金健
责任编辑 杨海玲
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
内容提要
超越需求：敏捷思维模式下的分析
项目成败的关键在于是否在“做正确的事情”，而本书正是从分析的角度帮助项目来做到这一点。本书中分析活动是指对人（利益相关者和用户）、情境（人所处的环境）、利益相关者的需要以及解决方案的分析和理解，同时，分析活动要贯穿项目始终，将敏捷思维模式应用在所有分析活动中，才能助力项目成功。本书共分4个部分15章，内容涵盖将敏捷思维模式应用到分析中会涉及的理念、案例分析、技术和相关资源。本书并没有将太多篇幅放在解释那些已被证明的技术上，而是更注重实用性，注重如何选择合适的方法进行需求分析。
本书非常适合正在对项目进行分析工作的人员阅读。这些人员可能是业务分析师（或由此派生的职务）、产品负责人、产品经理、项目经理、测试人员或开发人员。
版权声明
超越需求：敏捷思维模式下的分析
Authorized translation from the English language edition, entitled BEYOND REQUIREMENTS: ANALYSIS WITH AN AGILE MINDSET, by MCDONALD, KENT, published by Pearson Education, Inc., Copyright 2016 by Pearson Education, Inc.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.
CHINESE SIMPLIFIED language edition published by PEARSON EDUCATION ASIA LTD. and POSTS & TELECOM PRESS Copyright 2017.
本书中文简体字版由Pearson Education Asia Ltd.授权人民邮电出版社独家出版。未经出版者书面许可，不得以任何方式复制或抄袭本书内容。
本书封面贴有Pearson Education（培生教育出版集团）激光防伪标签，无标签者不得销售。 版权所有，侵权必究。
推荐序一
超越需求：敏捷思维模式下的分析
唯一不变的是变化本身。
人们通过持有智能设备快速了解周围事物，了解认知的变化，实时洞悉身处所在。先进技术的使用已是众所周知，早有“旧时王谢堂前燕，飞入寻常百姓家”之势。在今天，技术不再是稀有专业领域的制胜法宝，它已经由原来的专业人士专属时代进入大众共享时代。技术相关的项目（我们在这里简称IT项目），更是如雨后春笋般地涌现。相比之前，这些IT项目更加日常化、资本化、大众化、极速化。然而，它们的失败概率更高了。一方面竞争加剧，竞品追赶，更多的时间被花费在机会抢夺战上；另一方面用户思维、场景故事不断演变，跟随着“人”这个最核心的入口不断调整策略。
近几年，我有机会接触上百家技术团队并伴随他们一起成长，见证了他们从原来的传统研发模式发展到云化研发模式，以及迭代速度与工程效率的极致变化，给大家带来巨大挑战的同时，也带来了发展机遇。其中，不乏优秀突出的卓越者，以及维持业务的护航者。他们对组织战略的理解和核心项目（或产品）的“需求”把握，以及“需求”升级演变中如何高效研发、发布等问题，都有着非常出色的文化支撑和一系列配套工具。
中秋节前拿到这本《超越需求》（Kent的《Beyond Requirements》）的译者发来的样章，试看了几章，我感同身受。Kent认为需求管理不是简单的收集、分析、传达，而是和设计站在同一战略视角解决问题、达到预期结果，在思维和文化上达成共识。同时，围绕敏捷环境下的迭代需求，如何使需求分析活动伴随在敏捷开发、测试和部署中间，自然而然适应变化的问题，Kent花费了比较多的笔墨，知其然并知其所以然地进行了结构化的分解，并引入了大量手绘和工具模板，以阐述不同程度阶段带来的变化，他称此为—技术。
希望本书能帮助读者在这个充满变化和机遇的今天，超越需求，抵达彼岸。
刘付强
麦思博（msup）有限公司首席执行官
推荐序二
超越需求：敏捷思维模式下的分析
半个多世纪之前，温斯顿·罗伊斯（Winston Royce）在其论文中第一次提出了“瀑布模型”（Waterfall Model）。在之后相当长的历史时期内，“需求分析－设计－实现－测试－运维”的顺序式进行就成了大家追捧和遵循的经典流程。后来罗伯特·库珀（Robert Cooper）提出了“阶段－门限”（Stage-Gate）的方法，在阶段中开展工作，在门限上进行评审，一切看起来是那么完美和优雅。
诚然，完善的流程极大地提升了软件项目的规范性。然而，为了保证项目“铁三角”（范围、时间、成本、质量的平衡）的约束性，真正的客户需求和价值往往受到忽视。在一轮又一轮的过程改进的洗礼中，项目交付成功率的提升效果甚微。
当时间进入21世纪，敏捷开发的大潮汹涌澎湃地奔向我们。价值驱动交付、迭代开发、交互协作、检查和适应等一系列崭新的理念，促使我们重新思考软件项目实施的方式，探索新模型和已有模型的融合与发展。
在产品研发中，得需求者得江湖，超越需求者得天下！
我们从来都不缺少体系和模型，如需求分析领域著名的业务分析知识体系（BABOK）和业务分析核心概念模型（BACCM）。而且在我开展的咨询项目中，大多数客户都会说：“把这些实践梳理成体系吧”。遇到这种情况，我的回应是：“试点项目是探索实践的过程，过早引入体系会带来约束。”但同时我也会解释：“流程体系的梳理可以在组织规范期逐渐建立，在组织成熟期有效使用。”
在这个观点上，我与本书作者Kent的理念完全吻合。当谈及“项目”时，Kent说，由于瀑布模型采用“项目”这一术语，给大家的印象往往是约束性和临时性较强，以至于敏捷社区对“项目”一词非常排斥。其实这完全没有必要，当我们谈到“项目”时，应该“承认它的价值”。Kent在书中完美地诠释了在敏捷模型下如何进行需求分析，但他并没有提出一套新的“分析流程”，而是站在“体系”的视角沿着项目生命周期进行，用这种融合的思想处理需求分析的问题这一点在本书中体现得淋漓尽致。
本书的看点颇多，值得大家细细品味。这里我简单分享一下自己的感受。第一，作者是站在敏捷模型视角下，把需求分析作为一项工作而不是一个角色。从业务分析师、PO、产品经理、项目经理、开发和测试人员多个角度描述分析能力的培养和活动的执行。第二，本书第二部分所描述的案例生动翔实，很具代表性，甚至很多场景都是我们现实工作环境中发生的，让读者很容易产生代入感。“敏捷联盟的投稿系统”的案例，让我想起了多年前在读研究生时，也曾想用软件系统实现论文投稿管理（并且我真做了一个），甚至让我有种“重操旧业”的冲动，想要借助本书中的理念和技术再去进行需求分析和系统完善。第三，书中提到了多种用于需求分析的技术，从人员、环境、问题、方案、执行等多个维度进行了立体化的描述，这部分内容对于读者进行落地实践极具指导意义。第四，本书译文逻辑清晰、行文流畅，秉承“信、达、雅”的翻译原则，充分展示出译者多年项目管理和需求分析的功力！
最后，我想说的就是，本书的名字—《超越需求》—取得特别好。我在带领团队进行需求分析和产品开发时，经常要求团队：“需求不仅仅是用来实现的，更是用来超越的。”我想这也是Kent的书中要传达的理念吧！
推荐大家阅读本书，祝大家阅读愉快！
李建昊
光环国际董事副总裁
敏捷开发和产品管理资深专家
译者序
超越需求：敏捷思维模式下的分析
终于见面了。
2016丙申猴年春节前夕，看到这本书的英文原版，竟然有种“相逢情便深，恨不相逢早”的感觉。本书内容居然与我们研发的一门最受欢迎的课程有50%以上的重合，而且整体逻辑也基本一致，有鉴于此，岂能错过？联系出版社表达了希望翻译的意愿，居然已经有两组人在试译，马不停蹄地利用春节小长假提交了试译稿，终于在3月确定了合作。
项目成败的关键在于是否在“做正确的事情”（do right thing），而本书正是从分析的角度帮助项目来做到这一点。本书中分析活动是指对人（利益相关者和用户）、情境（人所处的环境）、利益相关者的需要以及解决方案的分析和理解，同时分析活动要贯穿项目始终。
看到本书的目录，我已然喜不自胜，书中大部分内容都有相同的感受。有两个失败的项目至今想来仍然历历在目。第一个是几年前负责的一个项目，针对某款手机操作系统，提升内建质量，遗憾的是当项目目标将要达成时，整个产品却被喊停。另一个项目是一款移动App，产品经理设计了几个酷炫的功能作为卖点，可用户并不认同，最终产品被砍掉。“错误的方向，越努力，离成功越远。”本书就试图解决这个问题，而这也是我这些年一直在摸索并尝试的方向。
让我们把视角扩大到整个软件开发项目，结果更加触目惊心。2015年的Chaos报告显示，从2011年到2015年软件开发项目的失败率并未显著降低（2011年为22%，2015年为19%），但对项目规模进行详细分析显示小型项目的成功率（62%）远远高于大型项目（2%～6%）。对于大型项目，使用敏捷方法的成功率是传统瀑布方法的6倍（18%对3%），失败率是传统瀑布方法的一半（23%对42%），但无论采用敏捷方法还是传统瀑布方法，都有超过5成的大型项目遭遇了严重挑战。而影响项目成功的十大因素中跟人相关的因素（高层支持、团队合作、用户参与）高居榜首。本书针对利益相关者提供了两类技术：第一类技术有助于你理解你正要满足他们的需要的这些人——也称作利益相关者分析；第二类技术有助于更好地理解真正使用解决方案的人，称之为用户分析。
“春江水暖鸭先知”，身处互联网行业已有5年，我对行业的变化感受颇深。PC互联网经历了18年的增长周期，而移动互联网自2012年至今只用了大概4年，移动互联网初期发展主要得益于人口红利释放，但最近2年用户规模增速在明显下降，产品的挑战越来越大。这从2015年苹果公司的App Store排行榜的数据可见一斑。2015年共有1933款不同的应用先后进入iTunes免费应用排行榜中，前3%的应用长期占据榜单，很少发生变化。但中位数只有2天，即有一半的应用在榜单中出现的天数在2天以内，更不用说还有大量没有进入榜单的应用。用户的选择增多，如何有效获取用户注意力，是项目成败的衡量指标之一，而项目要取得成功必须要应对巨大的挑战。本书从分析的角度提供了一个解决框架，有助于应对移动互联网时代的巨大挑战。整体框架从产品愿景和目的（用户的真实需要）出发，对齐组织战略，明确各种活动的价值（校检活动、差异化活动和合作伙伴活动），并确定合理的目标。知易行难，本书通过几个研究案例前后呼应，在帮助读者理解的同时，也可以用做实际落地时的参考。
不但互联网企业需要面对巨大挑战，传统企业亦如此。尤其是在“互联网+”作为国家战略提出之后，传统企业纷纷提出转型之道，希望互联网和每一个行业、每一个企业结合来提升运营的效率，从而推动企业持续高速增长。战略转型、企业转型、产品转型、团队转型、组织转型，各种转型纷至沓来，但如何确保转型能够成功？当今世界已经进入了反复无常、充满变数、错综复杂而又模棱两可（Volatile、Uncertain、Complex、Ambiguous，VUCA）的时代。在VUCA时代，复杂问题的解决能力、高效的分析决策能力、快速迭代的研发能力和低成本的试错能力已经成为企业必要的生存技能。本书从分析的视角出发，将这4点贯穿打通，形成整体框架，从项目的分析阶段和交付阶段入手，详细介绍适用于不同阶段的技术和方法，并对如何进行选择和使用提供指导原则和注意事项。
雷·库兹韦尔在《奇点临近》中收集了很多关于信息相关技术明显加速的经验数据，并提出了加速回归理论，以论证在宇宙的总体进展中，技术和进化将以指数级的速度向前推移的趋势。技术的进步除了为技术人员带来便利，也带来了挑战：在什么情况下应该选用什么技术，有什么成本和收益，都需要综合评估。对于这些问题，本书介绍的理解解决方案的技术能够帮助进行决策。
“形兵之极，至于无形”，本书首先从无形的价值观开始，提出了7个重要的指导原则。第一部分的结尾给出了项目全生命周期的分析框架，从而明确了每个阶段要解决什么问题以及需要什么技术。在介绍具体技术之前，第二部分先给出了几个研究案例，以故事讲成果，令读者更容易理解情境，从而更容易参考使用。第三部分介绍具体技术时，遵循统一的格式：
定义；
例子；
何时使用；
为什么使用；
如何使用；
警告和注意事项；
附加资源。
对于读者而言，这种格式兼具可读性和查找的方便性。希望这本书中所提供的方法，能够帮助企业走上适合自己的成功变革之路，从容应对未来的挑战。
最后，感谢家人对我的支持，让我奢侈地利用了大量周末和晚上的时间来完成译稿；感谢付强和建昊，你们的鼓励让我内心更加踏实；感谢责任编辑杨海玲老师，你的耐心和支持是我前进的助推器；感谢我的同事们，从你们身上我学到了非常优秀的实践经验。
前言
超越需求：敏捷思维模式下的分析
本书的内容
我写作本书旨在描绘IT项目分析的全貌，并在敏捷思维模式下应用这些分析技术，以使这些项目更加高效。鉴于这一目的，我认为分析活动涉及：
理解利益相关者[1]；
理解情境；
理解需要；
理解解决方案；
组织并持久保存解决方案信息。
正如我在第1章介绍的，利用敏捷的思维模式进行这些活动，那么团队所处的位置就是满足利益相关者需要的最佳位置。因此，我假设人们以敏捷的思维模式进行工作（这取决于每个人都采用这种模式）而且他们也在使用敏捷技术。当然，我介绍的大部分技术也可以在其他环境中使用，但这些技术和敏捷方法结合使用时能够发挥最大效用。
本书适合的读者
如果你正在对一个项目进行分析工作，以便确保项目在交付正确的事情，那么本书就是为你准备的。此时你可能会发现自己是业务分析师（或由此派生的职务）、产品负责人、产品经理、项目经理、测试人员或开发人员。
我选择的目标受众是执行分析活动或具有分析能力的人，而不是作为分析师角色的人，或者以分析师作为职业的人。虽然具有分析技能的人大部分都是作为分析师角色的人，但我不希望在本书中出现类似这样的建议，如“分析师做这个，开发人员做那个，而测试人员做另外一些事情。”因此我宁愿描述为什么以及何时这个技术是最合适的，而把确定谁是执行各种活动的最合适人选的工作留给你和你的团队。在很多情况下，最终团队中的多个人都会进行分析活动，以便充分利用强大的技术和业务知识。
业务分析师的角色之所以存在，主要是因为过去有些组织使用了一种预先规定的基于阶段的方法来进行软件开发。在这种方法里，项目中有一个阶段的主要工作是获取并记录需求。因为按照项目运作的方式安排软件开发团队的组织结构是合理的，于是在分析阶段工作的所有人员都集中在一起，并被称为业务分析师。但收集并记录需求并没有为做这件事情的人带来足够的职业自豪感。于是当分析社区的成员看到项目经理的成功并可以享受项目管理职业的成就时，他们也选择了同样的路。
由于业务分析的“职业化”运动，出现了很多好的事物，这包括考虑要对分析技术进行更多的培训和投入。然而，由于要证明需要一个单独的职业来获取、记录并管理需求，导致了过度专业化，从而也削减了其所带来的好处。所以把精力花在弄清楚如何运用分析技术帮助项目成功，才是更好的办法。
但这并不能改变一个事实，即你有一个业务分析师的头衔，而且你已经花了相当多的职业生涯磨炼业务分析技能。但这意味着什么呢？把分析作为活动而不是角色、头衔或职业来看待的话，就意味着你可以使用分析技术的深入知识，帮助团队用正确的方式解决正确的问题，同时在可能的时候也可以帮助项目的其他活动。
本书适用的场景
本书侧重于IT项目中的分析活动。IT项目是指任何产生解决方案的项目，往往会涉及软件，以便于支持内部业务流程，自动化人工流程，或简化当前的流程。例如，实现系统用以支持会议投稿流程，实现系统计算并交付佣金，报表和数据仓库的解决方案，或实现解决方案以便为非营利学校跟踪学生信息，这些都是IT项目。
我之所以这样选择，有以下几个原因。第一，业务分析活动和业务分析师角色在IT项目中看上去比在产品开发活动中更普遍。第二，在分析领域有大量书籍都假设是在产品开发的情境中，而组织中的IT部门的情境受关注度如此之低，这种情形让我很吃惊。第三，可能也是最重要的原因，我的大部分经历都在这里，因而聚焦于这个主题让我有机会写出实际的经验。
当我介绍如何在IT项目中以敏捷思维模式进行分析时，我不会深入介绍那些成熟的分析技术。因为已经有足够多的资源介绍了这些技术，而且那样做会让本书失去焦点。相反，我会重点关注那些技术为什么有用以及什么时候使用最合适。我也从其他技术圈中选了几个技术进行介绍，这些技术在分析领域并不常见，因而我在介绍如何使用这些技术时，进行了详细的描述。对于所有这些技术，我都提供了推荐的参考资料以便读者了解更多信息。
“项目”这个词在敏捷社区中受到歧视。那些歧视这个词的人往往会觉得使用“项目”这个词就意味着以瀑布方式管理项目的那些缺点。
因而，项目这个术语通常意味着：
项目的临时性的本质也适用于在项目中工作的人。人们被派到项目中进行工作，而不是工作被分配给不同的团队；
由于需要项目启动和全面的计划以便预测未来6～12个月的情况，这就要花费一定的时间来完成这些环节；
尽管项目是临时性的（可能正是由于这个原因），一旦启动就很少中途停止。项目发起人和团队往往对项目非常不舍，尤其是项目持续时间越长，他们就越不情愿结束它；
项目的资金预算流程可能会鼓励把多个小的变更组合起来，以便证明支出的合理性，但这增加了变更交付给利益相关者之前的等待时间。
虽然这些问题确实存在，但仅仅使用“项目”这个词并不会确保这些问题一定发生。由于大部分人对项目有所了解，当解释这些模式都是反模式并且能做成完全不同的样子时，使用“项目”这个词就非常有用，而不是选用一个新术语来描述已有的概念，因为那样会导致非常大的混乱。正如我的一位编辑Deanna所建议的，当谈到“项目”这个词时，我应该“承认它的价值”。
本书要解决的问题
“分析”经常被描绘成“获取并记录需求”，这个术语听起来就像在问人们他们想要什么，然后记录下来。关于分析的深入思辨的讨论往往集中于捕获需求的最好方法：“我应该使用用例，还是使用用户故事？”需求确实很重要，但它们只是到达终点的一种手段，而不是终点本身。正如我前面介绍的，分析是理解利益相关者和他们的需要，并在特定的情境中确定满足这些需要的最佳解决方案，然后针对解决方案建立共识。需求在这项工作中发挥了一部分作用，尤其是描述需要的部分，但它们显然不是最终产品。
本书试图解决的一个基本问题是如何确定你的IT项目是否在做正确的事情，以及分析如何帮助你做到这一点。这就把分析的目的从需求收集和获取转变为解决问题并建立共识。随之团队看待需求和设计的视角也带来了一个巨大的变化，它们不再作为交付物扔给流程中执行下一步的人。现在需求和设计都是团队可以使用的工具，用来针对他们要交付的解决方案建立共识，从而达成预期的结果。
本书试图解决的第二个基本问题是展示如何在敏捷环境中做分析。由于许多团队首先采用敏捷方法，他们在确定一个可行的解决方案和过早描述该解决方案的太多细节之间艰难地寻找平衡。本书的目的就是告诉你如何以迭代的方式进行分析，从而你可以充分地利用在开发、测试和部署过程中发生的学习活动。与此同时，本书也说明了许多分析技术适用于敏捷的环境，只不过何时以及在多大程度上使用这些技术会有所变化。我试图解决这个问题，因为许多采用敏捷方法的团队认为分析是没有必要的，从而导致他们最终建造的解决方案不能解决原来的问题，或者根本没有解决任何问题。
本书的组织结构
为了更便于阅读，本书分成3个主要部分。第一部分“理念”涵盖敏捷思维模式以及敏捷思维模式和高效分析背后的一些关键原则；第二部分“案例研究”包含4个研究案例，展示如何在各种情况下实际地应用这些理念；第三部分“技术”深入介绍一些在敏捷环境下对分析非常有帮助的技术。
第一部分 理念
第一部分介绍几个核心理念，我认为在敏捷环境下进行高效分析，这几个理念是必不可少的。这包括描述敏捷思维模式的概念，还有传统分析思维之外的一些概念，这些概念对典型的分析技术形成了补充。最后，基于这些理念，我建立了在不同情境中使用分析技术的方法。
第1章 指导原则
当我帮助团队采纳敏捷并加强分析方法时，我发现采用适当的思维模式远比掌握一套具体的技术更重要。利用正确的思维模式和很强的自律精神，团队就能够使用最少的流程取得成功。如果没有合适的思维模式，团队会发现他们不得不持续地增加流程以加强合作。但对于拥有正确思维模式的团队而言，合作是自然而然的事情。
什么是正确的思维模式呢？对于这个问题有多种不同的观点。敏捷思维模式的最初定义是由“敏捷软件开发宣言”和相应的原则定义的。有人扩展了这些最初的理念以描述敏捷思维模式，而我也做了同样的事情，并把重点放在鼓励构建正确事情的这个方面。我通过7个指导原则来介绍我对敏捷思维模式的看法：
交付价值；
合作；
迭代；
简化；
考虑情境；
明智决策；
反思与适应。
第2章 有用的概念
我会在这一章介绍几个概念，这形成了后续章节的概念基础。这些概念包括：
需要和解决方案；
结果和产出；
发现和交付。
第3章 精益创业的影响
这一章会探讨精益创业的几个概念，并介绍这些概念在IT项目的情境中如何高效地运用。这些概念包括：
客户开发；
创建－评估－学习；
度量。
第4章 决策
这一章会详细讨论决策制定，特别是决策的结构，真实期权的概念，以及会阻碍高效决策的认知偏见。
第5章 交付价值
在这一章中，我会讨论几个跟价值交付密切相关的概念，包括特性注入、最小可行产品和最小可市场化特性。
第6章 敏捷思维模式下的分析
虽然我不是要提出一套新的“分析流程”，但我希望给出一个整体介绍，来描述沿着项目的生命周期如何进行分析。这一章在项目生命周期的合适位置加入了将在第11章到第15章介绍的技术。
我没有花费太多时间讨论这个具体的流程，因为对于每个项目而言，它都不一样。但遍历一次整个流程有助于以正确的视角看待这些技术，同时也有助于解释为什么有些技术在一些情境使用比在其他情境更合理。
第二部分 案例研究
在本书第二部分，我会与读者分享4个故事，用来介绍现实世界的分析活动。这些故事展示了各种IT项目，而这些项目用到了第1章到第6章介绍的各种理念和后续章节将要介绍的技术。虽然我无法覆盖所有的情形，但我希望这些研究案例覆盖的各种环境足够广泛，以便你可以从中发现熟悉的场景。另外，这些案例既描述了在不同情况下可以使用相同技术的想法，也介绍了可以根据当前情境调整所用方法的理念。
第7章 案例研究：会议投稿系统
这是为Agile2013和Agile2014大会开发并维护会议投稿系统的故事。它是一个相对简单的项目，但也为在合适情境中使用几个不同的分析技术提供了机会。
第8章 案例研究：佣金系统
这个案例介绍的是一家医疗保险公司在进行一个替换多套佣金系统的项目时发生的故事。它针对使用现成软件的项目和镀金的倾向探讨了一些有用的技术。
第9章 案例研究：数据仓库
这个案例讲述的是一个项目要整合一条新数据源到已有的数据仓库的故事。这个故事探讨了在商业智能项目中的分析活动，说明了这样的环境也可以从敏捷思维模式中受益。
第10章 案例研究：学生信息系统
这个案例探讨的是如何在非营利环境下执行分析活动，并将重点聚焦于最初考虑开展一个项目时需要做出的决策。
第三部分 技术
在这一部分，我会介绍一系列技术，并使用我提出的简单格式。这些技术在很多不同的环境中都很有用。我使用的简单格式覆盖了每项技术的如下几个方面：
定义；
例子；
何时使用；
为什么使用；
如何使用；
警告和注意事项；
附加资源。
第11章 理解利益相关者
这一章介绍的一些技术有助于了解正在和你一起工作的人。前两种技术有助于你了解自己正要满足其需要的这些人——也称作利益相关者分析。这一章介绍的另两个技术有助于你更好地理解真正使用解决方案的人，我们称之为用户分析。这一章介绍的技术包括：
利益相关者地图；
承诺量表；
用户建模；
人物角色。
第12章 理解情境
理解情境意味着要理解业务的本质，并和团队其他人分享这个信息。你希望从整个组织的视角来看待项目，并确定项目要做的内容。如果项目和组织战略或日常运营并无关系的话，就不要开展这个项目。
第12章介绍的几项技术可以用来理解整个组织的战略并使用这个信息来指导项目的决策。这一章介绍的技术在分析师社区中常常被称为战略分析（之前称作企业分析）：
基于目的的对准模型；
六个问题；
情境领导模型。
第13章 理解需要
IT项目的一个非常关键但却经常被忽视的方面是找出需要满足的真正需要，并确定它是否值得满足，然后和整个团队分享这个信息。如果这些活动经常进行，那么这个IT项目的未来无疑会更加光明。
在这一章，我会介绍一组对于完成这些活动非常有用的技术：
决策过滤器；
项目机会评估；
问题陈述。
第14章 理解解决方案
一旦我们理解了要满足的需要并确定了它是值得满足的，我们就要开始调研各种可能的解决方案。这里的“解决方案”指的是多种解决方案。项目团队往往会过早地把自己限制在一个可能的解决方案上，而不是尽量保留各种可能的选项。而在很多情况下，其实有多种选项。
在这一章，我会介绍多种技术，能够用来探索多种解决方案并描述看上去最好的解决方案，这里所使用的方式对于项目中的每个人都是有意义的：
影响地图；
故事地图；
协同建模；
验收标准；
实例。
第15章 组织并持久保存解决方案信息
这一章介绍的技术可以帮助团队可视化进展，还可以帮助他们可视化解决方案正在构建的部分，并持久保存解决方案的关键信息供将来参考。这一章中所描述的技术包括：
发现看板；
就绪的定义；
交付看板；
完成的定义；
系统文档。
第四部分 资源
在本书的最后这个部分，我对全书的核心定义和参考来源进行了总结和汇集。
术语表
为项目建立共同语言是一个良好的实践。由于我希望在谈论一个概念时它的含义是非常具体的，而且我也乐于“吃自己的狗粮”，所以我决定为本书建立一个术语表。这能够帮助我在使用这些概念时保持一致，或者如果我使用不一致的话，至少能给读者一个机会发现。术语表中的每个词在正文中第一次出现时会显示为粗体。
参考文献
在本书中，针对我讨论的主题，我参考了大量文献的信息。参考文献部分给出了所有参考文献的一份清单。花些时间来看看这些文献吧，这里有不少好东西。
beyondrequirements.com网站上除了收录本书中的这些资源，还包括有关敏捷思维模式下的分析的更多思考、新技术的简介以及本书中内容的更新。
[1] 本书中凡是以黑体字呈现的词语在书后的“术语表”中都有对应的词条说明。——编者注
致谢
这不是我写的第一本书，但它是我第一次独自一个人写的书，至少在刚开始写时我是这么认为的。不过最终证明，虽然我被列为唯一作者，但如果没有好几个人的帮助，这本书是不可能完成的。
为了让这本书有更好的观赏性和更强的可读性，有两个人发挥了重要的作用。Jeff Rains为本书创作了所有的手绘图形。重要的是，这些图形加强了在白板上展开对话的理念。Jeff出色的工作使我能够传递这个信息，同时又让你能够看到这些图形。Deanna Burghart是防止我写出糟糕的英文的第一道防线。我与Deanna共事多年，她曾负责编辑我在Project Connections.com上的内容。当我几年前开始写这本书时，我就知道我需要她的帮助。而她，一如既往出色地完成了工作，帮我完成了本书的大量工作。
在我的职业生涯中，我有幸与一群才华横溢的人共事并交流。他们看待事物的角度不同，而且也毫不吝啬与我分享他们的见解。其中好几个人在本书写作过程中发挥了重要作用，但我这里要特别感谢3个人，能够跟他们3个人讨论不同的理念和方法是我莫大的荣幸。在编辑阶段，Gojko Adzic提供了大量审阅意见，对我帮助巨大，让我从完全不同的更好的视角看待事物。Todd Little在最后的编辑阶段，审阅了本书的大部分内容，并且一如既往地提供了实用而又富有见地的建议来帮我进行修改。Chris Matts一直以来都是我在分析领域获取最前沿同时又非常实用的思想的一个主要来源，他非常深入地探讨了本书中的几个想法，而且是其中几个重要想法的源头。我对分析和IT项目工作的深入理解，很大程度上是因为有幸认识这3位从业者。
我还非常幸运地收到了大量专业人士的反馈。特别感谢Robert Bogetti、Sarah Edrie、James Kovacs、Chris Sterling和Heather Hassebroek阅读全书初稿并给出评论。他们的评论对于我形成并提炼最初的想法非常有帮助，从而使我的想法更加连贯。同时也非常感谢Diane Zajac-Woodie、Deb McCormick、Brandon Carlson、Mary Gorman、Julie Urban、Pollyanna Pixton、Matt Heusser、Tina Joseph和Ellen Gottesdiener，他们也对一部分书稿提供了有用的评论。
最后，感谢Chris Guzikowski，作为Addison-Wesley的特邀编辑，在我旷日持久的写作过程中对我非常有耐心。也非常感谢Jeffrey Davidson，让我抓住这个机会，但又没有唠叨我尽快完成本书。Jeffery，我不知道Chris是否要你催促我，但我猜如果你那么做了的话，无论如何他都会很高兴。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
目录
前言
第一部分 理念
第1章 指导原则
1.1节简介
1.2节交付价值
1.3节合作
1.4节迭代
1.5节简化
1.6节考虑情境
1.7节明智决策
1.8节反思与适应
1.9节总结
1.10节切记
第2章 有用的概念
2.1节简介
2.2节需要和解决方案
2.3节结果和产出
2.4节发现和交付
2.5节切记
第3章 精益创业的影响
第4章 决策
第5章 交付价值
第二部分 案例研究
第7章 案例研究：会议投稿系统
第8章 案例研究：佣金系统
第9章 案例研究：数据仓库
第10章 案例研究：学生信息系统
第三部分 技术
第11章 理解利益相关者
第12章 理解情境
第13章 理解需要
第14章 理解解决方案
第15章 组织并持久保存解决方案信息
第四部分 资源
术语表
参考文献