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

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

所谓“定制软件公司”，是指主要通过构建定制的，一次性的软件来赚钱的公司。例如代理商或中间件公司，或像Redify这样的承包商/顾问。

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

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

确定技术债务的可靠方法：

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

这是招致技术债务的肯定方法。现在，我们需要维护一些软件，这对我们的核心产品没有任何影响。

如果定制工作是增加技术债务的可靠方式，那么代理机构应如何处理呢？

所以这让我开始思考。没有核心产品作为其业务模型中心的公司，他们总是在进行自定义软件工作。他们如何应对技术债务的概念？怎么不使他们陷入技术破产？

如果您可以将特定于用户的需求变成对每个人都有用的东西，那就太好了。如果客户愿意为此功能支付持续的支持费用，那也很好。但是，如果您是一个很小的团队，并且发现自己在努力支持所有功能，那么，除了对最不需要的功能做出一些艰难的决定，然后花一些时间将它们从代码库中扎根之外，这无济于事。

SaaS使您处于收集使用情况统计的良好位置。如果尚未使用功能，则应进行工具设置，以便跟踪谁在使用功能。我们的经验是，最惯用的客户通常也是功能最弱的客户。那个踩过脚并屏住呼吸直到你给他一个“导出到MS-Access”按钮的家伙可能一年多没用过了。即使只有一位客户正在使用某些功能，这些功能仍然有效，因为该客户声音很大，并且每当不满意的情况下都会威胁将其业务转移到其他地方。停止使用该功能可能现在会花费您一个客户，但是多年来支持该功能所花费的时间可能会使您花费数十个客户。它衡量您的管理团队的素质，

当您确实停止使用某项功能时，请确保提前六个月至三年的合理时间向客户（或至少受影响的客户）宣布决定。实际上，如果您发现自己同意构建特定于用户的功能，则可以尝试让您的销售人员从一开始就确定失效日期。将其称为“支持生命周期”，并明确表示他们想要的时间越长，花费的资金就越多。尝试为客户提供变通办法，以使客户在使用某个功能时不会陷入困境，例如，将导出的XML文件转换为MS-access格式的脚本，或有关选择更好的RDBMS的一些建议。

作为预防措施，对我们有用的措施是每月将销售团队的报告发送给我们的开发团队和管理层。该报告涵盖了来自客户的反馈-最受欢迎的功能，最受要求的功能，最受关注的拟议功能。如果您是一名开发人员，但是这才是真正的好处，那么这对于销售团队来说是真正的好处，他们现在正在更大范围内考虑每个功能，而不是发送无休止的功能请求并根据优先级进行排序在哪个客户端上声音最大。这样做的结果是使我们的销售人员在谈判中对新功能的要求更加刻薄，因为他们更清楚每种功能可能适合我们产品的整体价值主张。

当您将功能窃取到产品中并再次将其再次窃取时，拥有带有大量自动化测试的模块化代码将为您提供帮助，但这最终不是一个编程问题，而是一个管理问题。编写代码进行销售是傻瓜的游戏。

当我遇到自定义开发请求时，我通过很酷的过滤器对它们进行过滤，该过滤器将请求分为三堆：

1. 很棒的事情将对每个人都有用并且相对容易实现
2. 很棒的事情将对每个人都有用，并且很难实现
3. 愚蠢的一件事情，只需要这个客户端，但实际上并不需要

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

老实说，这从未失败过，我认为我们最终并没有实现任何第3类功能。当然，没有客户走（销售不会让我把它拉下来：）

（此经验是在ISV公司获得的）

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

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

没有核心产品作为其业务模型中心的公司，他们总是在进行自定义软件工作。他们如何应对技术债务的概念？它如何不使他们陷入技术破产？

他们交付产品。然后他们继续前进。当您根据合同开发产品时，您在该项目上所做的一切都是针对该客户的。在合同终止后，开发过程中可能产生的任何技术债务都会成为客户的问题，开发人员会为另一个客户进行另一个项目。

当然，这并不意味着可以做一份cr脚的工作。您的首要目标是使客户希望与您保持合作，而高质量的工作就是达到目标的方法。这也并不意味着技术债务对合同开发商而言不是问题。即使您自己始终编写干净的代码，也有可能在某个时候雇用您从事已经产生大量债务的项目。可能是好的（客户想要付钱给您清理混乱）还是不（客户不知道代码有多糟糕，也不知道为什么“仅仅”添加更多功能会花费这么长时间） ）。

我不同意这样的前提，即保证海关工作会产生技术债务。避免技术债务并不意味着避免某些种类的功能，而是意味着避免不必要的僵化，依赖性问题以及使代码库难以更改（即，代价高昂）的事情。自定义功能并不意味着其中任何一个，它仅意味着该功能的基础很小。因此，他们的关键是从实现中考虑尽可能多的通用，可重用逻辑，而将定制的一次性内容留作自己的独立模块，可以为请求客户部署。

例如，假设您有一个交付品，它是一个内部Web应用程序，客户可以将其安装在Intranet上。有一天，如果您为客户制作的版本具有“富客户端”桌面应用程序而不是浏览器界面，那么一位客户就会提出并开满钱将一辆卡车运到您的公司。好吧，如果您的系统具有良好的体系结构，并且对依赖项进行了很好的管理，那么在创建新的表示组件时，只需重用域，数据访问和服务组件即可。即使您只有一位希望回到1999年并为此使用桌面应用程序的客户，也不必考虑技术债务。

这是一个需要回答的复杂问题，因为就像许多事情一样，它实际上取决于项目的情况，合同方公司的控制级别，定制软件是否在整个生命周期内都由合同方公司管理，访问代码库的其他人的“干扰”，所有相关人员的态度，项目的复杂性和所使用的方法...我真的可以继续。

所有系统都有一定程度的技术债务。在某些情况下，由于开发人员一直努力保持干净的代码库而付出的努力可能并不特别明显，但是，没有一个系统是完美的，重大的重新设计可能使看似无辜却长期存在的问题变得显而易见。那么签约公司该如何处理呢？

在许多情况下，它们不是。通常情况下，软件将由一家公司编写，然后由另一家公司修改，而且通常情况下，由于合同规定的每家公司都在紧迫的期限内完成工作，因此代码库被真正弄乱了，这并没有证明保持代码整洁的时间是合理的（有时甚至未经测试）是否意味着他们可能会错过最后期限的风险。

在其他情况下，您会发现不仅可以很好地管理其合同项目的公司，而且还能以某种方式找到使现有代码库处于比其发现的状态更好的状态的时间。他们经常通过仔细计划，确定技术债务的来源（通常是那些对新工作影响最大的债务）来做到这一点，并且他们设计策略以提供测试用例和修改，从而有助于管理技术债务并将所有这些因素纳入项目进度。

作为定制软件，与编写核心产品相比，是否保证了技术债务？简短的答案是否定的，但是，如果不积极处理，很可能会累积技术债务。这与任何其他软件项目相同。如果您在整个项目生命周期中完全控制项目，那么您就有更好的机会来处理技术债务。如果没有，那么您将需要处理以前的公司留下的代码中可能产生的技术债务。

另一方面，如果您的问题是要问编写与业务模式无关的软件是否构成技术债务的保证。答案是绝对的。真正的问题是任何公司如何处理技术债务。是让它按计划的时间累积和处理，还是以持续的方式管理干净的代码库，以便尽快还清技术债务？答案取决于公司的个人优先事项，以及产生的技术债务在财务上是否相关。

定制软件不是对技术债务的保证，但可以为两个主人服务。

一家定制软件公司将构建完全适合手头任务的软件，进行交付，并在必要时进行维护。真正的定制软件通常不需要经常添加的新功能。

此问题描述的问题是产品公司将自定义功能构建到其他通用产品中。如果产品是完全定制的，则只有在一位客户的需求发生变化时，产品才会移动。如果产品是完全通用的，则只有在添加新功能以使其更具吸引力时，它才会移动。但是，如果您在其他通用产品中具有自定义功能，则会有两个紧密联系的代码块，它们以不同的速度移动。就像引起地震的构造板块一样，这些代码块之间的接口是一个“热点”，已经成熟了很多问题。