我最初在90年代后期开始概述团队实践和项目中的这些差异。从那时起，我发现这些实现的复杂性有了巨大的飞跃。尽管打包软件的需求分析和实现分析没有太大变化，但出错的风险却大大增加了。

需要改变的思维方式，而不是技巧

对于传统项目和打包软件项目，BA角色保持不变：保护和优化利益相关者和组织价值。可以使用许多相同的技术，但是BA的思维方式以及如何记录和促进这些思维方式可能会发生变化。

担心契合度，差距和变更管理

在处理软件包项目时，适应/差距分析的心态至关重要，同时还要密切关注用户世界的变化方式以及对这些变化的同情。
广管局需要研究一揽子计划如何“适合”期望的结果和过程，并确定一揽子计划职能与当前状态职能之间的差距。广管局应该与利益相关者合作，确定是否需要“弥合”差距—我们可以在一揽子计划中运作，还是需要调整流程或技术来满足我们的需求？

记录此合适/差距决策过程是关键的BA角色，包括促进各种选择和替代方案以最小化差距。即使实施“开箱即用”，此过程和分析对于成功也至关重要。 “开箱即用”通常是指某个地方的过程或操作更改，BA负责确定更改将在何处发生并为用户准备这些更改。

唐’t force the templates

一旦BA进入了适合/差距的思维方式，则他们需要确定如何有效地记录打包软件项目。

我经常看到BA团队在紧紧抓住模板的过程中苦苦挣扎，试图使它们适用于打包软件项目。许多典型的模板不能很好地适应软件包软件项目。典型的模板采用自定义开发方法，并且迫使BA使用这些模板给打包软件项目带来很多痛苦和挑战。

因此，请在参与软件包软件项目时挑战传统做法和模板。您仍然需要需求，但是时间安排和详细程度/抽象程度必须适当。

请注意不要将时间浪费在组织当前状态的详细文档上。供应商通常具有该软件包的当前状态文档，在大多数情况下，它将成为将来的状态。着眼于未来的状态以及未来将要发生的事情，只有在我们需要确定要继续的细节时才回顾详细的当前状态。另外，项目发起人可能购买了该软件包以提高效率并更改流程和业务运营-他们并不需要确切的当前状态副本。

而是在功能级别上管理您的工作。在选择配套之前，演员要完成的工作和规则很重要。选择程序包后，参与者的未来状态和“如何”完成它作为试点，测试，培训和实施的变更管理部分就变得很重要。

我们不想记录已经构建的功能。当供应商通常将此文件打包时，打包中的确切操作方式可能会多余。因此，请避免对重复功能说明和已构建软件设计的软件包的文档要求。

唐’t rely on the vendors BA 100% for the BA role

您需要一个内部BA（或BA团队）来支持软件包软件项目。如果仅依靠供应商BA，则不会成功识别和弥补功能差距。卖方BA了解产品，但不完全了解您的环境-您的系统，流程，文化，政治，痛点，异常处理，集成问题等。

供应商和内部BA都对成功至关重要。内部BA无法完全理解产品，因此需要供应商BA来验证功能并填补空白。

无论是两人还是两百人，内部团队和供应商团队都需要像拼图一样团结起来，互相学习，建立信任并解决问题。

升级需要学士学位

听到团队说打包软件升级不需要BA或要求很普遍。

挑战这个假设！升级几乎总是会影响用户或至少会影响用户。如果用户使用系统，则有要求！

无论是较小的更改还是技术更改，都应咨询知识渊博的BA。即使在其他几个站点上成功进行了升级，升级仍然有可能对您组织的独特配置或系统集成产生负面影响。

因此，向耐需求团队成员提出一些问题，例如：为什么我们要花钱进行升级？用户如何受益？如果不做会怎样？帮助他们了解潜在的影响以及广管局如何为所有项目带来价值。

有关配置的注意事项

大多数现代软件包都可以通过数百种影响软件功能的设置进行高度配置。

如果您的项目团队以前从未使用过高度可配置的软件，请为整个项目生命周期中的新一层复杂性做好准备。

• BA在编写业务规则或详细要求时可能需要考虑配置设置。
• 项目可能需要一个单独的阶段，即“配置测试”和试行该软件包。
• BA可能需要对测试人员进行有关配置设置的教育，并帮助他们排除问题/错误，以确定错误是配置错误还是系统错误。

未来，BA将支持更多的软件包软件实施。如果您还没有打包软件项目的经验，很快就会准备好。

唐't forget to leave your comments below.

上面的涂鸦由Dan Wagner提供。通过向他发送电子邮件来了解有关丹的涂鸦艺术的更多信息 [email protected]