“定制软件公司”如何处理技术债务？

Question

什么是“定制软件公司”？

所谓“定制软件公司”，我指的是那些主要通过建立定制软件来赚钱的公司。比如代理机构或中间件公司，或者像Redify这样的承包商/顾问。

“定制软件公司”的对立面是什么？

与上述业务模式相反的是专注于长期产品的公司，无论它们是可部署的桌面/移动应用程序，还是SaaS软件。

--建立技术债务的可靠途径：

我在一家试图专注于一套SaaS产品的公司工作。然而，由于某些限制，我们有时会屈从于某些客户的意愿，并结束构建只能用于该客户端的定制软件。

这无疑是一种招致技术债务的方式。现在，我们有了一些软件来维护，这对我们的核心产品没有任何帮助。

如果定制工作是建立技术债务的可靠方法，那么代理机构如何处理它？

所以这让我思考。那些没有核心产品作为商业模式中心的公司，他们总是做定制的软件工作。他们如何处理技术债务的概念？如何才能不把他们推向技术破产呢？

Answer 1

如果你能把特定于用户的需求转化成对每个人都有用的东西，那就太好了。如果客户愿意为该功能支付持续的支持费用，也很不错。但是如果你是一个很小的团队，你发现自己很难支持你的所有特性，那就只能对你最不需要的特性做出一些艰难的决定，然后花点时间把它们从你的代码库中找出来。

SaaS使您能够很好地收集使用情况统计数据。如果您还没有准备好您的特性，您应该考虑一下，这样您就可以跟踪谁在使用什么。我们的经验是，最惯用的顾客通常也是最不正常的；那个踩着脚屏住呼吸直到你给他一个出口到微软的按钮的人可能已经一年多没有使用过它了。尽管只有一个客户在使用这些功能，但有些功能仍然有效，因为该客户很大声，每次有不满意的事情发生时，他就威胁要把业务转移到别处。停止该功能现在可能会花费您一名客户，但支持该功能所花费的时间可能会使您多年来损失数十个客户。这是衡量你的管理团队的质量，不管他们是否愿意做出这样的决定。

当你停止使用某项功能时，一定要提前向你的客户(至少是那些受影响的人)宣布这个决定，任何六个月到三年的时间都是合理的。事实上，如果您发现自己同意构建特定于用户的特性，您可能会尝试让您的销售人员从一开始就构建一个到期日期。把它称为“支持生命”，并明确表示他们想要的时间越长，花费的钱就越多。尝试为您的客户端提供解决方案，以便它们在功能消失时不会陷入困境，例如，将导出的XML文件转换为MS-access格式的脚本，或者关于选择更好的RDBMS的一些建议。

作为一种预防措施，对我们起作用的是每月从我们的销售团队那里得到一份报告给我们的开发团队和管理层。这份报告涵盖了来自客户的反馈--哪些功能最受欢迎，哪些功能是最需要的，哪些提议的功能是最受欢迎的。如果您是一名开发人员，这是很有趣的，但真正的好处在于销售团队，他们现在更多地考虑更大范围内的每个特性，而不是发送无休止的特性请求，并根据哪个客户端是最大的优先顺序。这样做的效果是让我们的销售人员在谈判中遇到新的功能要求时更加挑剔，因为他们更清楚每一项功能在我们产品的整体价值主张中的位置。

当您对产品中的特性进行黑客攻击并再次对其进行黑客攻击时，有大量自动化测试的模块化代码将对您有所帮助，但最终这不是一个编程问题，而是一个管理问题。写代码做买卖是个愚蠢的游戏。

Answer 2

当我面对定制的开发请求时，我会通过凉爽的过滤器过滤它们，该过滤器将请求分成3堆：

1. 令人敬畏的东西，对每个人都是有用的，并且相对容易实现。
2. 令人敬畏的东西，对每个人都是有用的，而且很难实现。
3. 愚蠢的一件事--只有这一种客户才需要的东西，不管怎么说，都不需要它们

• 类别1在当前开发周期中实现。
• 类别2将在下一个开发周期中实现。
• 类别3得到的报价为1个月的开发时间，之后大多数客户意识到他们的要求是不值得的。

老实说，这从来没有失败，我不认为我们最终实现了任何类别3的功能。当然，没有一个顾客走了(销售人员不会让我这样做，否则:)

(这是一家ISV公司的经历)

Answer 3

由于某些限制，我们有时会屈从于某些客户的意愿，并最终构建只能用于该客户端的定制软件。

您的问题不在于您正在创建只用于一个客户端的代码。问题是，您正在将只用于一个客户端的代码合并到一个产品中，该产品将出售给许多不需要该功能的其他客户端。

那些没有核心产品作为商业模式中心的公司，他们总是做定制的软件工作。他们如何处理技术债务的概念？怎么才能不把他们推向技术破产呢？

他们提供产品。然后他们继续前进。当你在合同下开发一个产品时，你在这个项目上所做的一切都是为了那个客户。在开发过程中可能积累的任何技术债务都会在合同结束后成为客户的问题，开发人员将为另一个客户转到另一个项目。

当然，这并不意味着做一份糟糕的工作是可以的。你的首要目标是让你的客户继续和你一起工作，而做高质量的工作是达到目标的方法。这也不意味着技术债务不是合同开发者的问题。即使你一直自己写干净的代码，你也有可能在某个时候被雇佣从事一个已经积累了大量债务的项目。这可能很好(客户端想付钱给您清理混乱)(客户机不知道代码有多糟糕，也不明白为什么“只是”添加一些特性要花这么长时间)。