软件开发能力评估

1、软件开发能力评估在 IBM Bluemix 云平台上开发并部署您的下一个应 用。开始您的试用 不同种类的评估已经成为一个能够更好地理解开发组织的 需求的商业工具。评估可以有多或少的细节，它可以集中在 过程架构，或者配置和变更管理环境上。当需求的领域跨越 多个项目时，很多组织需要确定努力的优先级，即使他们知 道在那里开始。这个两部分的文章可以帮助你理解项目级的 评估转换到到组织级的评估的理由，引入的复杂度和提供什 么样的价值增值。我们的素材基于我们在一些 IBM Rational 在金融、 电信、 IT 、医药工业等的客户那里已经完成的评估。 在第一部分， 我们讨论动机， 引入关键的概念； 在第

2、二部分， 我们给出如何完成评估的路线图，这个路线图基于我们在 IBM 软件开发平台上的解决方案上的经验。 编者注释：本 文最早准备作为 IBM Rational Brand Services 给 IBM 用户进 行软件爱你开发能力评估的指导。在保持原有目的的同时， 作者扩大了它的范围使得任何组织都可以自己进行评估或 者请外部机构进行评估 什么是软件开发能力评估？ IBM Rational tech rep toolbox 已经提供了相当多种类的评估。 有些 评估可以做为现货服务产品，女口： metrics assessment package,Rational ClearCase admini

3、stration assessment package, 和 software development capability assessment package.1 软件开 发能力评估的概念来自于为用户在组织范围内改善它们的 开发能力的工作。评估的原因有很多，下面是一些我们碰到 较多的情况：新技术 新的技术（例如从 COBOL 环境转到 Java和J2EE）将迫使组织重新思考他们的开发过程和工具 环境，人们将构建他们的组织以学习新的工作方法。评估可 以帮助定义哪些实践或者组织的哪些部分最需要变更，以及 变更活动的优先级。快速成长 软件开发组织在相当短的时 间内快速成长，习惯于使用的非正规的软

4、件开发环境已经不 再适用。组织需要了解如何恢复对他们的开发能力的控制， 然后转到更进一步的改进。 （这种情况以前经常在 dotcom 领 域出现，现在很罕见了）合并 商业并购需要开发组织进行 合并，这就意味着需要合并不同的和有时互相冲突的开发实 践。需要创建通用的开发环境，但是经常不清楚应该首先引 入哪些变更。采购 开发组织的项目是采购项目，或者需要 考虑是否采购。组织通常希望能够改善评估和管理供应商的 方法。如果供应商在海外就需要更多的挑战。能力改善 组 织通常需要改善总体的软件开发能力。组织需要理解它的强 项和弱项，找到快速回报的方法。组织可以不需要通用工具 集的标准化，但是评估可以指出采

5、用标准化的益处。市场驱 动的过程改善 一些组织需要改善它们的软件或者系统开发 过程以满足市场竞争的需要。合适的认证（如服从公认的质 量标准如 CMM, ISO, FDA, 等等）通常是在特定市场寻找机 会的强制标准。系统和产品 在一些工业领域（国防、电信、 航天等等），系统从过去简单的机械和电子的简单组合增加 为复杂的软件系统。系统开发组不同部分的协作在采用新技 术时通常是一个挑战，并且增加系统的复杂度。一个改善的 方法是不同的组使用通用的标准和通用的开发架构。产品线 的开发 组织可以开发和维护一条软件或者系统产品线，而 不是单一产品。这一般意味着高水平的产品线的重用，过程 可以在产品线的每个

6、产品上重用，自动化开发可以帮助控制 开发成本。这些产品线上的重复的开发周期也产生了对改善 和开发过程持续优化的要求。与软件开发能力评估对比，项 目评估是改善一个特定项目组的软件开发能力，它不需要考 虑跨组织的标准。这里需要处理的相关人员比较少，考虑的 问题也较少，因此对哪些问题需要解决容易达成一致意见。 专门技术评估 可以是组织范围的，但是它们集中在专门的 技术领域。例如，一个评估可能集中在组织怎样进行度量以 确认项目的进展和质量方面。回页首大范围评估的标准让我 们假定组织想要进行大范围评估而不是项目级或者专门技 术评估。那么完成组织范围的软件开发能力评估的标准是什 么？这种范围的评估需要一个

7、组织和评估员的有意义的委 托。例如，对于除了他们的软件开发能力之外没有稳定的理 由的组织，可能是不值得进行评估的，因为获得评估结果的 价值是很困难的。下面是一些在你决定是否开始评估时需要 考虑的：商业驱动 商业驱动是什么？它是成本节约？达到 更高的质量？或者能够更快交付？它们的优先级如何？驱 动是否强烈得足够有一个变更的委托？如果有的话，委托是 否与组织水平对应？涉众 你的涉众是谁？确保你有不同的 组织的观点。一个风险是你花费了太多的时间讨论拥护者 一个人的观点容易得到，但是谁也不可能有对所有位置的观 点的描述。组织的状态 组织的状态是什么？它的成熟的和 可接受的变更是什么？在讨论时有哪些失败

8、出现？这些与 软件开发能力有关 （我们可以帮助） ，或者与其它事情相关？ 软件开发能力是否是组织的关键？是否有以前的成功的变 更的例子或者改善的进展？价值机会 变更的价值看起来是 什么？项目平均有多大，它们一般运行多长时间，开发组织 有多大？软件开发能力的改变如何影响商业结果？组织如 何依赖它的软件开发能力？是否应该进行组织范围的评估 依赖于几个标准。基于上面的描述，这里给出几个建议：应 该有强烈的商业驱动和迫切的变更需求 - 其它的建议都不 应该考虑，不值得做这样的评估。组织范围的评估应该领导 变更。在评估时你需要在你的团队包括正确的人。你与这些 人的关系应该是稳固的，与客户组织的关系也必须

9、稳固。你 应该给出评估的预算，它与任何考虑在开发工具上的全面投 资相比都应该相当小。应该给组织的管理层一个远景，其中 应该包括构建强有力的软件开发能力。组织应该通过创建管 理层的领导变更的协作以展示承诺。回页首什么是评估的价 值？组织范围软件开发能力评估的主要目标是给被评估的 团队提供价值。由外部人员进行的评估能够提供组织强项和 弱项的外部的观点。它可以协助发现问题，基于最佳实践提 供改进建议的先后次序。评估过程也将给关键人员提供一个 阐述和讨论想法的机会，而他们以前没有时间充分地展示他 们的想法。它在组织中构建对变更需求的理解。主要的一点 是开发组织必须提供商业的价值。更好的软件开发将带来更

10、 好的商业结果。能力的评估意味着价值的改善。评估的结果 将帮助激发对变更的投资， 以及帮助构建变更的策略。 最后， 评估将作为阐述在组织中实现一个建议的解决方案的很好 的基础，这个方案在评估期间完成需求的确定。涉众和结果 因素有大量的因素影响商业结果，但是软件开发能力评估仅 仅集中在那些与软件或者系统开发活动有关的方面：换句话 说，那些因素可以由 IBM 和 IBM Rational 解决方案实现， 并能够增加客户的商业价值。因为因素和期待的结果的数量 通常很大，在评估的早期确定合适的涉众对评估结果的期望 是很关键的。图 1 给出了客户端的涉众对商业结果的期望： 图 1 ：评估过程的涉众正如图

11、 1 中显示的，在一个视图中有 很多不同的涉众对评估成果的看法：行政管理( Executive management) 关注与商业前景和商业策略，包括 IT 策略相 关的结果。结果应该创建对于变更的紧迫需求，包括与商业 驱动、角色定义、组织变更管理、风险管理、通信、和投资 回报等相关的看法。财务( Finance) 关注成本驱动、合同 管理、价值链的费用、 回报率、维护费用。供应商管理( Supplier management) 考虑 COTS 使用，例如 B2B 、子承包商管理 和离岸开发的集成。生产制造( Production ) 关注工业过程 自动化， 控制和质量。 销售和市场 ( Sa

12、les and marketing) 关 注用户关心的 (如 CRM - 客户关系管理) ，支持，在线服务， 供应链集成， 后勤， 仓储和销售渠道。 运作( Operations) 关 注商业过程和性能，过程集成，自动化和系统支持，过程和 工具支持， 质量管理， 和跨操作架构的内部关系。 IT 关注组 建策略， COTS ，过程，工具，重用， Enterprise Architecture Integration (EAI) ，采购策略，标准，技术，遗产，维护费用。 开发人员( Developers) 关注更好的软件开发技能，动机， 公司文化，创造性，职业发展，授权和团队凝聚力。产品管 理(

13、Product management) 关注通过产品策略产生收入，布 置，包装，定价，技术，架构，质量约束，顺从标准，重用 策略，质量图景，用户满意度，市场时机，细分，产品和操 作的技术，覆盖的人群，创新管理。所有涉众关注的内容都 是相关的，并且相互增强。他们在一个组织中给出不同的观 点，并帮助评估组组织评估问题和答案。并不是所有的观点 都能够在单一的软件过程能力评估中展现出来，但是我们在规划这样一个评估时要牢记组织的架构。回页首能力评估框 架在介绍评估路线图之前，我们首先讨论在评估活动中能够 提供的指导框架：四个成功项目的协作领域 - 基于对不同 的 engineering discipli

14、nes 如何互相协作的调查简化的软件经 济模型 - 例如，基于 COCOMO II 六个软件开发的最佳实 践 - 基于对工程实践的调研最佳实践的框架在某种程度上 通常更加适合于那些已经采用了 IBM Rational Unified Process, RUP, 和 Rational 技术的组织， 否则你可能更加适合 使用软件经济学模型或者四个实践领域。你也可以选择它们 的组合。因为最佳实践的框架与更多的技术相关，你可以使 用那些开发者和项目经理已经很熟悉的 Rational 技术，在与 高层管理者交流时使用软件经济学模型和四个实践领域。为 什么我们没有提及 CMM/CMMI 作为框架之一？ C

15、MM/CMMI ，一般来说，集中在组织中过程是否被使用和 改善的过程成熟度上 - 换句话说，这是一个开发组织的质 量的标识，可以用来给它们的客户建立信任。我们这里讨论 的评估更加集中在理解什么开发实践在使用，它们在哪里和 怎样被改善以影响开发效果上。 2 四个协作领域如果评估在 组织水平上进行，讨论的框架就集中在可以显著帮助的关键 协作领域上。这种类型的框架支持一个好的开发基础架构， 它推动跨开发项目所有领域的协作。 IBM Rational 的 MurrayCantor 和 Lynn Mueller 已经定义了这样一个框架，在本文 中称为“四个协作领域” ：工程，程序 /项目管理，业务集成

16、和开发供应商管理。 这些协作领域都可以用在 IT 应用开发， 也可以用在产品开发。每个领域可以分为一系列的实践，我 们评估每个实践意味着对组织成熟度的理解。每个实践的具 体细节依赖于评估的开发组织的类型。工程讨论下面的实践 可以让我们理解在产品 /应用工程领域团队如何协作： 采用面 向对象的系统架构和 UML 以获取逻辑和物理设计使用需 求、设计、数据库模型，而不只使用文档使用通用的集成库 保存系统工程产物和产品数据使用基于管理和专门领域（如 硬件，电子等） 的设计工具程序 /项目管理讨论管理实践提供 对组织、计划、成功度量和结果如何监控和通讯的洞察：团 队按照逻辑和物理组件划分，而不是功能单

17、元系统架构组维 护整个项目生命周期基于风险选择，降低完成费用的偏离组 织使用基于能力的，use-case驱动的迭代开发有一个通用的、 组织范围的集成的程序状态、稳定性、质量和财务的度量集 合挣值依赖于可论证的结果，而不是费用花费有正在进行的 系统和部件的集成测试业务集成大部分商业操作依赖于计 算机系统，而评估组织考虑的范围和把系统开发作为集成的 商业过程是至关重要的。理想情况下，系统开发应该反映组 织的特性和商业策略 - 例如，开发能力（按时间和预算交 付高质量的产品的能力）应该考虑作为商业成功的关键因 素。在这个协作领域，我们评估下列实践：保证所有商业管理过程映射到工程和管理实践使用通用的跨

18、产品线的基础 架构可以帮助优化操作环境 （Service Oriented Architectures - SOA - 可以有效地优化商业过程到发布、 集成和重用。 它还 可以帮助降低开发费用。 ）开发供应商管理在最后一个领域， 我们评估供应商如何更有效地与项目生命周期集成，以及如 何更有效地管理合同：与供应商的合同映射到项目管理过程 和开发生命周期模型（而不是反过来） 。使用共享的工程协 作基础架构使用集成的管理基础架构上面描述的四个协作 领域的每个的成熟度都可以描述为 1到 5级，如下所示： 1 = No capabilities （无能力的） 。 使用不同的方法和过程，几乎 没有跨开发组

19、织的集成 2 = Aware （有意识的）。现代开发过 程已经在知道这些方法的价值的项目组单独使用 3 = Capable （有能力的）。现代开发过程已经在一些商业产品线 的多个项目组使用， 但是没有计划配置跨企业的集成过程 4 = Mature （成熟的）。企业已经开发了配置现代开发过程的计 戈i,已经在选择的产品线上配置。5 = World Class（世界级的）。 企业已经在企业和它的供应商范围采用和配置了现代开发 过程。结果可以表示为一个矩阵 （15 x 5）,但是我们认为它 更容易表示为一个可视化的radar chart,如图2所示。图2 的例子显示了现在的情况和组织将来要达到的目标

20、。（点击放大）图 2：开发组织的程度度越高,在图上覆盖的面积越 大。由蓝点覆盖的区域表示当前的能力,由红点覆盖的区域表示期望的能力目标简化的软件经济学模型一种描述软件 开发能力是否达到它们的商业目标的方法是，从软件经济学 有关的角度看产品开发项目是如何完成的。为了评估能力和 给出建议的目的，我们使用简化的 COCOMO II 模型，它由 四个关键的软件开发性能参数组成： Software Development Effort = (Complexity)(Process)(Team)(Environment) 这些参数 对软件开发成果有以下影响： Complexity (复杂度)。 构建 的大

21、小，可以表示为人产生的素材的多少，包括技术素材， 如源代码，也包括其它技术产物。因此评估应该寻找降低软 件方案大小的机会， 例如，通过增加重用程度来降低。 Process (过程)。 过程的成熟度和效率，以及过程避免增加不应该 增加的活动的能力，如返工，过多沟通等。当过程系数大于 1 时， diseconomy of scale3 将显著增加。 评估应该找到是否 有机会改善过程的成熟度和提高过程执行的效率。Team (团队)。 软件开发技巧，经验和团队成员的动力，也会影响团 队的能力。评估应该寻找机会加速软件开发、最佳实践和开 发工具的熟练程度。 Environment (环境)。在软件开发能

22、力 中，它表示用来自动化软件开发过程的工具和技术。评估应 该寻找机会改善使用集成工具、引入现代工具技术、自动化 最佳实践和改进团队协作的环境。六个最佳实践的框架对比 组织当前的实践和已经证实的软件最佳实践，是另外一个有 用的理解组织当前能力的方法。下面列出的六个最佳实践是Rational 在软件工程能领域的学习经验的结果。它们集中描 述了帮助理解如何处理软件工程复杂性的领域：迭代化开 发。 为了减轻风险，项目组应该增量地开发软件，使用迭 代的方法。每次迭代的结果是一个可执行的版本。架构被验 证，早期的迭代被基线化。评估应该找到增进风险和计划控 制的方法， 其中的一个解决方案是引入迭代开发。 管

23、理需求。 需求总是会变更，因此项目组应该使用一些方法，可以让他 们有效地和你的涉众之间促进需求变更和有效通讯，并维护 同客户的约定。评估应该研究诸如需求是否在控制之下、修 正、高质量和可测试性等。 需求的解决方案可以包括引入 use cases等。使用基于构件的体系架构。在基于架构的过程中，目标是尽早地产生一个面对需求变更仍然很灵活的架构。评 估应该寻找架构如何可视和存在于开发工作中，架构如何描 述，架构能够做到怎样的稳固程度。可视化建模。可视的模型将提高抽象的等级，并使得对规格、架构和设计的通讯 变得容易。评估应该寻找任何组织通讯的问题，这些问题通 常可以通过引入更有效的可视化模型技术来弥补

24、。持续地质 量验证。 在发布后发现和修复软件问题通常需要千百倍的 成本。在整个生命周期进行验证和质量管理是在正确的时间 完成正确的目标的基础。要使用那些可以把软件进展和有形 的质量报告给你的涉众的技术。评估应该寻找这些问题，例 如，被评估的开发组织是否有对质量是什么的定义，以及是 否有验证质量的策略，测试活动如何被集成到其余的开发活 动，测试人员和分析人员是否协作以保证需求的可测试性。 管理变更。 使用那些让你控制项目资产的所有者、状态和 一致性的技术。变更控制不仅仅是检入和检出文件。它包括 管理变更需求、工作空间、并行开发和集成及 Build 。评估 应该研究组织通常使用哪些变更和配置管理的

25、方针。例如， 应该有对变更请求的程序的很好的理解，和对项目资产的更 好的控制它们的状态和关系。建议的解决方案一般包括 定义变更请求的程序，或者实现组织级的变更和配置管理的 计划。回页首操作框架即使一般不是软件开发能力评估建议 改变组织架构的目标，评估组也需要理解一个组织的目标以 便给出评估的建议范围和在评估完成后提出可行的解决方 案。并不是所有的软件开发活动在从一个组织到另一个组织 时处于同样的重要程度，这依赖于组织的架构和它的商业因 素。每个组织都有它自己的描述它的操作框架或结构的风 格，我们在这里给出一个通用的框架，用来讨论和达成对组 织范围的软件开发有关的活动如何和在哪里完成的更好理 解

26、。让我们考虑一个通用操作的四个步骤项目级产品线级业 务单元级公司级这些级别的定义必须准确调整以对应特定 的组织，特别是产品线级包括大部分商业的种类。图 3 显 示了一个组织的框架，嵌套的团队和能力的范围从项目级到 公司级。如果评估仅仅处于项目级 ，我们在项目评估考虑它。但是在某些情况下客户需要对它们的组织进行更多的理解，我们可以与几个项目经理谈话，也可以在 产品线级上 进行，甚至可以到更高的业务单元级。在有些情况下我们可 以参考组织级评估，尽管这种情况可能导致混乱，因为我们 仅仅看到了软件开发能力的方面。图3： 组织框架现在，让我们学习如何进行图 3 中每一步的评估过程。项目级框架 中最低的等

27、级是项目级，组织中这个级别一般是进行独立的 开发项目。项目级是一组同分配的预算到软件的发布之间的 活动。它不仅包括发布零售系统和公司使用的系统，也包括 任何在一个和几个产品线使用的系统。图 4 显示了在项目 级别通常包括的活动和它们的相互关系。项目级别的评估主 要集中在以软件最佳实践为基准的软件开发项目的有效性 的理解和评估上。这个级别的评估发生的最多，因为它们的 成本很低，评估结果的影响也很容易理解。项目评估通常非 常集中在找到帮助项目成功跨越里程碑和最后期限上图4：项目过程产品线级更高一层的组织框架是产品线级。它阐述 了使用商业水平的框架和扩展到俘获那些最适合公司的单 一产品线有效操作的活

28、动和相互关系上。对于那些没有软件 开发产品的组织，而开发支持组织自己的系统的组织来说， 依赖于系统的复杂程度，这个级别可以存在也可以不存在。 如果存在，它可以成为“ IT 策略” 级。很多在产品开发组织 看到的问题仍然存在，但是它们的重点不同。例如，构建支 持特定商业过程的能力在这种类型的组织中可能更重要一 些。图 5 描述了通常包括在产品线级的通用的活动和相互 关系。产品线级的评估主要集中在：理解作为产品线、产品 开发、产品和供应链操作导入软件开发相关的活动的完成情 况。对照基准评估实践的有效性。不同的包括在产品线级的 商业过程的数量可能相当大。在这个级别，操作的架构和集 成是主要的焦点。强

29、的集中架构是有竞争力的产品线策略的 必须。重用方法影响产品和操作软件。评估将强调特定的架 构策略。产品线级跨越组织架构如销售，开发组织，基础架 构，产品， 供应， 和其它与产品线活动相关的组织。 图 5: 产 品线过程业务单元级更高的级别是业务单元级，对应于特定 市场部分。从公司级独立和不同的操作依赖于特定的商业和 公司历史，成熟度，和大小。操作根据公司策略可以有很多 变化，在一些公司文化中，策略给出一个重要的角色，这将 导致在同样的问题方向和问题根源上很难得到一致。评估组 必须小心识别正确的角色，给出客观的位置，以保证在分析 和评估发现时考虑所有观点。业务单元级的评估与公司级有 相同的目标：

30、理解商业过程，商业驱动和策略，与软件开发 费用有关的活动。公司级框架的最高层是公司级。它包括这 些活动：定义策略，方针，和指导公司所有组织化的操作的 策略。一些组织有选择的团体方针如： 供应商、 过程、 工具、 标准、方针和标准架构。它们在组织中按照商业、成熟度、历史、公司文化和地理分布而变化。也有一些特定的团体拥 有团体方针，例如过程和工具组或者质量组。在公司级，评 估集中在理解当前商业策略， 商业驱动和 IT 策略上。 组织被 分析以理解与软件开发活动有关的商业过程和费用。回页首 问题分析框架一般的分析软件能力的方法都基于通过它们 的症状识别问题，研究问题的根源和建议的实践。从评估的 观点

31、，你应该试图给出两种信息的分类：症状(Symptoms)或者痛点 ( pain points)。 这些事情经常折磨人。 例如典型的 问题是：我们已经两年没有碰到最后期限了，或者，用户一 直抱怨我们产品的质量，或者，我们不能控制我们的需求， 它们任何时候都会变化，因此我们不能碰到我们的最后期 限。导致症状的行为，根本原因( Root Causes)。 这些是人 们每天要做或者不做的事情。引导会见的正确的专门技能和 组合是保证收集正确的信息的基础。典型的例子是：我们缺 乏通用的变更请求过程，或者我们没有通用的质量的定义。 图 6: 跟踪到问题根源的症状一旦你理解的问题的根本原 因，你就需要排出优先

32、级。总是有上千个问题你可以改善， 但是并不是所有的问题都有大的成果。要确保你理在你评估 的组织层面理解症状或者痛点的影响它们的成本，如果 你什么也不做的话结果是什么。通常，得到一个确定的数字 是很困难的，因此你可以用粗略的标准，看多少人碰到过这 些症状。要确定根本原因的优先级，你可以看多少症状似乎 相关，症状有多严重。一个理解优先级的技术是看看在组织 的不同级别痛点和根本原因是如何强调的，以及它们如何增 强补充的。你可以发现在更高级别的根本原因在较低的级别 上是痛点。这里我们引入组织的痛点，图 7 给出一个示例。 图 7: 痛点和相应的根本原因的例子。确定优先级是很复杂 的工作，IBM研究人员

33、和咨询人员已经共同开发了一个商业 的价值模型工具，包括可操作的财务度量。这个工具已经用 于软件开发能力评估，它包括 COCOMO II 成本度量，在前 面提过的四个协作领域， 共有 5个级别， 从“无能力” 到“世 界级”。痛点和业务评价建模工具你都可以用在评估中，以 帮助找到能够帮助改善你的组织的商业价值的建议。一旦你 已经排出了根本原因的优先级，你就可以可以针对这些根本 原因给出解决方案。在这里，指出你用来收集评估数据的框 架是最好的框架是很重要的。分析的一部分是理解客户如何 思考，理解，和组织它们的问题。你揭示的是需要用作用户 描述的框架，或者你可以找到用户思考和理解的模式实际上 是为什

34、么他们与实际的问题斗争。例如，软件开发组织的绊 脚石经常是在开发流程之间进行通讯。在这种情况下，使用 最佳实践作为解决方案的框架可能是不合适的，因为实际的 问题不是最佳实践本身，而是它们的界面。你可能会问：为 什么我们需要进行这些冗长的分析？在我们已经有最佳实 践的时候，为什么我们不简单地建议客户使用？这有两个主要原因：客户需要看到他们自己改变的动机，以及看到它们 不改变将会发生什么结果。很少建议一次采用全部的最佳实 践。改变应该仅仅从最需要的领域和最可能成果的领域开 始。因此，一个完全的图象，将给出所有领域的能力，允许 你确定需要改变的优先级。分析框架的三个单元应该与操作 框架的水平相关。症

35、状，根本原因和最佳实践在每个级别看起来都不同。你需要保证不同级别的涉众能够识别他们的 看法。在这些涉众不同的理解之间可能得到一些有趣的结 论。回页首把它们放在一起我们已经介绍了多种软件开发能 力评估的框架和工具。在评估时，你可以按照以下意见使用 这些框架：在早期与客户的讨论中，通过集中在商业操作框 架上（从项目级到团体级）来确定评估的范围，以及评估的 结果将产生哪些影响。确定组织中你需要找出会见的人。引 入能力评估框架（协作区域，软件经济学模型，最佳实践区 域），并基于客户的意见，确定哪个或者哪些是最有用的。 使用选择的能力评估框架和头脑中的问题问题分析框架，明 确在你会见以前需要回答的问题。注意这里不建议你按照严 格的脚本进行会见，你想要与会见者进行自由谈话，你可以 深入钻研你没有准备的领域。但是有一个简单的问题计划可 以帮助你确保能够揭示正确的问题和得到做你的分析所必 要的信息。按照分析框架分析你收集到的信息描述你建议的 解决方案