在开发应用程序和网站的印度小型软件公司中增加技术债务：谁负责？

我已经在印度软件服务行业工作了 10 年，在那段时间里，我见证了优秀的项目完成并创造了奇迹。 我见过骨干团队在痛苦的条件下不知疲倦地工作，以制造出受到地球另一端人们喜爱的产品。 虽然在这十年中从事一些了不起的项目有很多美好的回忆，但我也目睹了项目走下坡路，软件产品由于各种原因而变得一团糟。 它发生的次数比我希望在我周围和我这 10 年来认识的人周围发生的次数要多。

很多人都在谈论项目出错。 这些模因在互联网上充斥着整个等级制度如何像丛林中的食物链一样相互追逐。 有些人责怪程序员写了错误的代码，而另一些人则诅咒管理层做出了无法实现的不切实际的承诺。 有些人甚至指责客户不了解这个行业的技术先决条件和依赖关系。 但我几乎没有听到有人谈论技术债务或代码债务，并且以文明的方式处理这个问题，而不是互相指责。 我从来没有从我周围的人、我参加的活动或我阅读的本地博客中听到这个术语。

我是在阅读美国硅谷的博客和期刊时才知道这个词的。 这意味着大多数在印度中小型软件开发公司工作的程序员和软件主管直到现在才听说过这个词。 所以，让我先解释一下这个词本身。 技术债务或代码债务是软件开发中的一个概念，它反映了由于现在选择简单（有限）解决方案而不是使用需要更长时间的更好方法而导致的额外返工的隐含成本。

让我分解它以使其简单。 这是一个计算解决编程和设计问题的成本的概念，这些问题可能会因为选择构建特定模块或整个系统的简单选项而不是选择构建它的最佳和最有效的方法而增加。 在软件开发领域，这种你的懒惰和迟到又咬你屁股的现象比其他任何地方都更频繁地发生。 这几乎就像 Karma 得到了程序员讨厌的社会表征。

请不要误解我，我并不是将所有代码债务都归咎于程序员。 在印度的小型软件开发公司中，90% 以上的项目肯定会出现代码债务，肯定有多个实体负责。 让我尝试简要介绍其中的一些：

1. 不耐烦和过于聪明的客户

是的，我会从咬那只喂食的手开始，并且无情地这样做。 小型外包软件开发项目市场巨大且高度分散。 有一些真正优秀的公司可以完美地证明这个全球化市场的合理性，而另一些只是寄生公司，他们以这种完美的安排为食，只是因为它不受监管和不受控制。

这导致客户在根据自己的需求选择合适的公司合作时犯了错​​误。 虽然没有适当的审查技能不是他们的错，但没有人可以责怪他们没有基本的街头智慧来识别垃圾公司和真正的垃圾公司。 现在，一旦他们同意与一支天赋不足的团队合作，他们就会扼杀他们不切实际的期望和时间表。 不仅如此，他们中的一些人甚至通过在设计和编程中提出自己的建议来展示他们的聪明程度。 （#notallclients ）

如果您曾经是软件开发公司的客户，我谦虚地请求您让他们成为客户并让他们完成他们的工作。 试着去看医生或律师，告诉他们你在谷歌上搜索了什么以及它对你的问题的看法，看看他们脸上的反应。 没有哪个领域的专家喜欢被菜鸟推荐他们自己的领域。 软件工程师也不例外。

如果你找到了一个优秀的软件开发团队并且他们看起来很有希望，给他们空间，他们就不会有偷工减料的冲动，这会减少你项目中的代码债务。 猜猜看，大多数时候，是你们，支付代码债务的客户。 听说过“变更请求”这个词吗？ 我敢打赌你们大多数人都有！ 在理想情况下，你不应该在你的生活中听到这些话。 但这种情况很少发生。 你听到这些话的次数越多，作为软件公司的客户，你就越搞砸了。

2. 懒惰和狡猾的经理

当我在这里说经理时，指的是软件开发公司方面担任项目管理职位的任何人。 无论是项目经理、团队负责人、交付负责人还是公司老板，如果您曾经试图快速洗手项目只是为了结束它并收取您的付款，那么您就是派对也应归咎于您项目中的大量技术债务。

尽管这里最可悲的部分是你们永远不会支付巨额的技术债务。 要么是客户通过使用不合格的产品来支付费用，要么是实际支付更多的钱来清洁它。 如果不是客户，那就是可怜的程序员为此付出了代价，他们不得不无休止地工作，超出了他们的要求。 但几乎从来都不是这些中间人，因此根据我的说法，他们应该是这个技术债务主题中最负责任的实体。

如果你曾经雇用他们中的一个，他们应该具备的最大品质就是道德。 如果他们的道德指南针指向正确的方向，他们将承担责任并做出有利于该项目的正确决定，这最终将导致更少的技术债务积累。 这让我想起了马云的那句名言，他谈到选择为合适的领导者工作。 非常适合这里的这种情况。

3. 程序员

哦，是的，我也不会通过责备你们来结束这个话题！ 但是，嘿，#notallprogrammers 对吗？ 嗯，是的，但几乎 94% 的程序员。 至少 Tech Mahindra 的首席执行官 CP Gurani 是这么认为的，几年前他做出了令人震惊的发现，即 94% 的 IT 毕业生不适合这份工作。 我不知道他究竟是如何得出这个数字的，但作为印度工程学院的产物，并且在过去 10 年见证了整个 IT 工程生态系统，我可以说我倾向于同意 Gurani 先生所说的。

我不想争论它是 94%、90% 还是 80%。 但是打个比方，就像我们几乎所有人都知道我们需要面粉、水和一小撮盐来制作面团，以及擀面杖来制作薄煎饼。 但我们中很少有人能真正制作可食用的薄煎饼。 这是一个非常简单的过程，但仍然需要一定的天赋和大量的练习才能在这方面表现出色。 编程也是如此。 我们所有人都知道这个食谱，但很少有人真正卷起袖子，弄脏我们的手并练习它，只要它需要掌握这门手艺。

因此，即使一个普通的程序员被委托进行一个项目，他也会在不知不觉中编写代码，其中嵌入了技术债务，直到后来他才意识到。 如果你想知道整个行业如何在大多数程序员不适合这份工作的情况下发挥积极作用，那是因为他们高效的经理和经验丰富的前辈通过艰难的方式学到了东西。 他们帮助那些新手和头脑在编写最佳代码的危险道路上导航，使项目的交付可行，并使其免于沉重的债务。 最终，通过适当的修饰和培训，让这些新手变得擅长他们的工作，或者他们最终与 IT 行业告别。

所以，总而言之，我觉得这次合作中的所有 3 个主要方面都应为编译代码债务分担责任。 再说一次，不要把这篇文章当作对行业所有问题的批评。 它就像世界上任何其他行业一样，有着相当多的恐怖和英雄。 即使在这样做了 10 年后，我仍然不会用我的生命做任何其他事情。 我喜欢这份工作，我喜欢成为一家致力于来自全球客户的令人兴奋的项目的小公司。

其目的是让所有 3 个利益相关者承担更多责任，并让他们了解这种潜在的软损失，这种损失是由于合作不当而对他们造成的。 如果软件开发团队希望准确计算和衡量他们的技术债务，他们可以遵循基于敏捷方法甚至瀑布方法的严格流程模型。 当您遵循这种严格的方法时，您将能够分别标记这些修订和修复冲刺，并且在一个阶段结束时，您将能够准确计算出您需要多少，并轻松进入原因。

我将以塞缪尔·贝克特 (Samuel Beckett) 的这句话作为结束语：