如何摆脱支持，开始偿还技术债务！

我有一个朋友”。是的，我知道是个好的开始，但老实说，这不是我！

基本上，他已经在一个成功的项目上工作了大约4年，困难之处在于技术债务已经赶上了，他发现几乎不可能停止对产品的支持（对此进行反复讨论）并实际进行实际开发。

我提出了各种建议，记录您的所有时间，创建故障单，不回复电子邮件等。与此相关的问题是，这似乎只是在提醒他，他没有完成任何“有用的”事情。

之所以发生技术债务，是因为首先要给产品带来很大的好处，即接受用户的请求和电话并迅速实施它们。

我想知道的是，有没有人建议他如何摆脱这种发车状态，其中很大一部分将改变用户的看法，以使他们不会以为自己会发声并期望得到一些东西。然后在那里做。

最好说计划得更好，尽管我知道考虑到支持的需求和用户的相对压力（见上文），很难计划实际的开发。

您朋友的组织迫切需要某人进行变更管理。该人员或小组将接受变更请求和错误修复，并根据业务影响和所需的工作量来确定优先级。这样，对于整个组织而言更重要的任务将首先完成，而不是对目前困扰您朋友的人更重要的任务。

编辑：作为这将如何工作的一个示例，大多数组织都有严重性等级。最高严重性级别是无法正常工作的关键业务应用程序或功能。如果企业可以采取某些措施来解决此问题，则可将严重性降低到一个新的水平。如果应用程序不是关键业务应用程序，则严重性会更低。通常，对新增强功能的请求会单独优先处理。

让其他人接听电话，并更改线路

我们马上解决。

至

很好的建议。我将创建一个功能请求，以便尽快开始处理它。如果您想跟踪请求的进度，可以在此处进行跟踪：[链接到案例跟踪器票证]。将来，您也可以采用与我在此处相同的方式提交期货请求：[链接到案例跟踪器]

我认为这可能是最简单，最有效的方法。最后一点试图减轻此人随时间接听电话的压力。

您在当前的“优先级”系统中遇到的问题是，当一切都优先时，什么都不是优先级。为此，您的朋友迫切需要听@Larry Coleman的建议-与开发部门隔离的人负责管理变更请求。理想情况下，您的朋友甚至不应该知道功能请求，除非该单独的小组同意应优先处理该功能。甚至有可能是这个新人，现在他们会优先接听电话，只要他们了解业务并了解发展即可。

我本人也经历过类似情况。该产品建立在鞋带上，并在投放市场时首次出现在市场上。最初是成功的（对于独奏企业而言），但我认为从2003年到2007年，任何事情都奏效。我试图为其配备人员，但是却学会了艰难的方法，即聘用好的人员既昂贵又绝非易事。我认为您的朋友也有类似情况。

以我为例，很早就知道事情会在某个时候走下坡路。该业务仍在增长，但竞争加剧，市场似乎在萎缩，有迹象表明（2006年中期）经济放缓即将到来，等等。基本上，许多因素导致了这种情况。我决定产品最终会消失；越晚越好（对于客户和我自己）。

回想起来，我可能做出的决定与坏的决定一样多，但这是一个简短的总结：

1. 妥善及早地安排人员。如果需要，请获取资金。（不寻求任何机会是我最大的错误。）如果您有销售，就可以找到钱。

2. 使用版本控制/单元测试/所有与最佳实践相关的hoopla。在大学任教时，他们看上去都很傻/荒唐/无趣，但出于充分的理由，它们通常是最佳实践。

3. 雇用至少一个销售/营销人员，尤其是如果您是技术类人才。（因为这样，即使拥有会员网络，您也会自然而然地将更多的时间花在技术上而不是营销上）。

4. 众包您的支持。设置一个论坛，以便用户可以自助。设置票务系统，并邀请您的专家用户（通常是论坛用户）作为虚拟助手进入一个特殊的部分。让他们照顾需要这些仅需几美元就能完成的这个小任务的众多客户，以便您可以专注于更大的前景。

5. 尽最大努力减少提供的支持量。您所获得的支持越少，您要做更多有趣的事情的时间就越多。到产品过时为止，客户将不胜感激，您的销售和支持人员也将不胜感激。

6. 让实际的开发人员提供一些支持（每天一两个小时，这样他们就不会失去与现实的联系），并给予他们自由的建议，如果他们愿意的话，可以对产品进行重新设计/更改（UI，功能）找出可以使他们减少支持时间的事情。这个想法是，如果由于相同的原因而一再被用户困扰，他们将希望尽快修复问题，以便摆脱支持电话。而更聪明的人实际上就是这样做的，这正是您想要的。

7. 如果您觉得产品快要死了，请决定在这里和那里杀死它，然后继续下一步。真的让它死吧。摇钱树是摇钱树；当达到其目的时，将其发送给屠夫。这样做（对客户而言）要轻柔，但如果维护开销使您的竞争对手受益于后来者并积累了一些技术债务，则一定不要让它的延长生存时间占用太多时间，将以比您更快的速度实现新功能。

一次一行。每次修复都需要花费更多时间，清理漏洞并随时添加自动化测试。通常，正确完成某件事比添加另一个修补程序要快得多。如果管理层像您经常喜欢做的那样促使您的朋友更快地工作，他应该长出一层厚厚的皮肤，并进入“完成后”模式。

关键是他周围有什么样的开发方法来在某种程度上屏蔽他？例如，在Scrum中，存在一个想法，即完成的工作通常不会在冲刺期间更改。因此，对于即将要做什么以及可能不会立即做什么有一些规则。另一个问题是管理层在多大程度上支持他不想成为支持者？这也可能很重要，因为冷漠的管理对于您朋友的项目可能是个丧钟。

最好的办法是停下巴士再回头看看。你的朋友应该

• 编写系统中每个问题的报告以及它们为什么不好的原因。设计问题应突出显示，并需要大量重构。
• 应该给出粗略的时间表来解决问题
• 该报告应提供给他的经理，然后再提供给系统中的利益相关者
• 在修复期间，应停止所有功能开发。

许多项目都这样做。如果不能使管理层确信这是一个失败的案例，但是如果他们同意，从长远来看，该系统就可以重塑。