从定制化的开发过渡到COTS开发公司

Question

目前，我们的组织生产的一个主要应用程序将被视为定制软件，因为它是专门为一个特定的客户组织设计的。

然而，我们特别保留了该项目的智力资本，而不同国家(拥有不同语言和字符集)的多个组织现在看来都想购买我们的软件解决方案。我们目前的开发方法通过了Joel测试的9.5，并且正在改进。然而，我们的方法是满足特定客户端的需求，并快速响应他们的需求(不管是bug还是更改请求)。

如果我们想要在一个共同的代码基础上，向多个客户组织--而不仅仅是一个客户组织--提供更多的“无货架”方法，那么我们需要意识到哪些主要差异和缺陷，才能成功地实现这一转变？

Answer 1

应该制定一些有意义的组织和体系结构更改，以成功地开发满足所有客户特定需求的公共产品。

在组织上，您需要从直接交付客户的请求转变为开发团队向公司内的产品所有者交付请求的情况。一旦你这样做了，开发团队就不再为公司的客户工作了，对开发团队来说唯一重要的客户就是你公司的产品负责人。

产品所有者必须从多个客户端收集需求，并确定一组共同的需求，这些需求将使大多数客户满意。开发团队只需要为使产品所有者高兴而担心。

在架构上，它有助于设计具有广泛客户需求的产品，使其成为可配置的、可扩展的、解耦的、可扩展的、可扩展的和逻辑上可能的组件。

要做到这一点，一些好的方法是获取许多不同的需求池，并找出哪些部分在所有需求中都是常见的。这些共同的需求将构成您的功能重置的核心。任何与核心稍有不同的东西都可以被确定为一个可配置的特性、设置，或者是一个与核心分离的完整的独特特性。使这些独立的特性尽可能的组件化，并很好地规范它。

您的客户可能会查看当前安装产品时禁用的不同功能，并可能会意识到他们可能实际上也需要该功能。

最后，在不违反YAGNI原则的情况下，尝试成为一个“防御性设计师”。这可能是一条很好的路线，但很有可能某些架构和设计假设会导致您自己陷入困境，从而导致需要在将来的版本中进行重大重构。假设是非常重要的，应该在您的技术规范中进行详细和仔细的检查。一个不正确的假设可能会让你以后付出沉重的代价。一个很好的方法是，“我知道客户很确定他们会希望这个组件以这种特定的方式工作，但为了以防万一，我将保留这样的选择，即这可能在未来发生改变，而不会导致需要进行重大的改造。”有时，这就像正确的组件化和解耦一样简单，而其他时候，它可能会开发出没有被请求的特性。你必须对你的处境做出判断。

Answer 2

因为您将有多个客户端，所以您的构建/测试/部署过程需要更加健壮。如果您已经有了强大的工程实践，那么这应该是可行的，尽管它仍将是一个过渡。但这是最简单的部分..。

现在只有一个客户，您的业务中面向客户的部分非常简单。然而，对于许多客户端，您需要能够独立地处理它们。你将需要一个服务台，可能需要一个公共问题跟踪器等(大公司有“支持”工程师的原因；这是一份全职工作。)

在商业方面，你需要提高你的销售和营销水平。你需要培养新的销售领导，并跟踪现有客户的满意程度。因此，如果您想要增长到足够大，这可能意味着使用CRM或其他自动化解决方案。你还必须“把你的产品的消息说出来”，这可以通过公关、广告、技术会议等来实现。

因此，您的产品建设过程将需要变得更加“专业”，是的。但销售的产品将是困难的部分。祝好运!

Answer 3

您需要处理的最大问题之一是定制。由于您可能不再对单个请求作出响应，而是对服务很多的产品进行更改，因此您需要决定如何处理某些客户端(尤其是习惯于请求自定义解决方案的初始客户端)对自定义信息的需求。

您还需要学习如何根据产品需要的内容来筛选更改请求，这是一家公司所需要的。

在定制方面有几条路要走，您需要决定哪一条：

• 不允许定制--可能会失去一些顾客，甚至是你的第一位顾客。
• 在关系数据库中创建EAV表，以便允许大量定制-flexible，但查询速度慢且难以查询
• 在键表中创建一些未定义的列，以允许有限的自定义--如果您已经设计了真正需要的95%，则可以工作。
• 使用no sql数据库进行自定义信息--对于不需要事务完整性的事情很好。
• 为每个客户创建单独的实例，并为定制(特别是自定义报告)收取一支arm和一条腿的费用-可能非常昂贵，难以管理。
• 将所有定制请求视为所有客户都会得到或提供的附加功能(模块化开发定制，以便人们可以选择和选择他们想要的特性)--根据当前软件的结构和功能，可能能够以这种方式处理大多数开发。

您需要认真考虑这些问题，因为定制错误可能会使您的软件慢得令人难以置信，或者可能导致更多的程序员需要定制，而不是没有定制。您还可以考虑使用这些技术中的几种。所有这些都有优缺点。