看到一篇讲技术债务中的人力成本的文章，显微阐幽，粗略译成中文，不求信雅达，但求不离原意太远。
原文地址为：http://www.daedtech.com/human-cost-tech-debt/
“技术债务”这个概念很值得去熟悉一下，如果你对这个概念还不熟悉的话；它不单是一个常见的业界术语，也是一个重要的概念。
Ward Cunningham创造了“技术债务”这个词，这个词本身就意味着在如果今天在你的软件中走了捷径，那么不单是最后要还这个债，而且还要支付债息。换句话说，今天你在交付之前用一个全局变量省了半天的工作量，意味着你以后要为此多干半天以上的活。
有用的比喻
在多年的编程之后，近几年我做了很多IT管理咨询的工作。我可以告诉你，用“技术债务”来比喻软件代码中的捷径，在业务部门和开发部门之间的沟通中非常有用，用这样的一个经济学术语，跟经理和MBA们解释技术上的一些决策时他们很容易理解。
因为这个术语好使，而且对业务会有影响，大家经常用它来表示一个项目的健康状况，特别是在面临最后期限或者是里程碑时间的时候。开发人员可能会说太紧的期限会导致技术债务，以至于以后加功能时需时更长，而分析师和项目经理在讨论延长期限时可能会考虑技术债务问题。IT高层管理人员在进行战略决策，作或更换或下架或重写的决定的时候可能会要求对技术力量进行评估。
基本上对大多数人来说技术债务是一个啥时候交付功能的问题。但是这里我想谈一下其中和人相关的问题。毫无疑问，从更大视角来说，在商业上，所有的人力问题都是商业问题。郁闷的人是郁闷的码农，郁闷的码农效率低，在我的印象中，很少有人从这个角度讨论技术债务。
不开心的工作
对经理而言，一个高技术债务的代码库意味着功能交付会慢如蜗牛，每逢谈及业务能力的时候都会让人感到沮丧和糟糕。对开发人员而言，则更加沮丧。没有人喜欢总是面对重重障碍，每天都没有什么产出，但这就是这种代码库带给开发者的结果。
每天他们到了办公室后，在状态较好的时候做些简单的事情，比如给表单增加一个复选框，他们知道接下来又要不厌其烦地解释为什么一个看起来很简单的事情要花那么久的时间。一个新来的同事或者一个顾问来的时候，他们知道又要面对疑惑的表情，以及新同事们隐约的蔑视。
就拿债务这个比喻来说吧，想象一下，一个背着几座山一样的债务的人，想解释被债主逼债的情景。这很尴尬，然后，让人意志消沉。
团队内讧
好不稀奇，内讧会导致团队里面争吵不断，这时，参考一下一对背负严重债务的夫妻的情景吧，团队内部会划出三八线来。
这些三八线可能是前面提到的新员工与他们所指责的老员工之间，可能是维护人员和开发人员之间，也可能是全新项目开发人员和历史遗留项目开发人员之间。不论是哪种三八线，它们都会变成事实，产生新问题，在老问题本身已经让人沮丧和意志消沉之余，还加上讥讽嘲弄。
技能衰退
当沮丧的情绪上升，愈加责备时，团队成员会觉得他们的专业性不知不觉消失了。毕竟，技术债务不仅阻碍了功能开发，而且阻碍了代码库的正常演进。在这类代码库里面，所有的事情都异常艰难。团队推迟升级到编程语言的最新版本，他们拒绝现代架构和设计实践，他们害怕将过时的第三方插件替换成现代的版本，通俗点说，他们人为地想尽可能少地接触东西，以免影响他们迟缓的进度。这太慢了，也太大风险了。
但是即便他们做出了这些决定，他们也知道他们的市场价值每天都在减弱。他们不会忘记，当外面广阔的开发世界拥抱着最新的javascript框架和领域驱动设计方案时，他们正在为给一个快跑不动的，基于CRUD的WinForm程序加功能而努力挣扎。
隐没成本：成交量和内耗
希望管理层认为不开心的员工很明显是一个商业问题，一个严肃的商业问题。在当前的IT市场环境下，开发人员可以有更多的选择，即使他们在一个背负严重技术债务的代码库上工作。如果每天都在折磨人的代码库上工作，周围的人满肚子牢骚，越来越觉得无所谓，这样会导致整个团队的人身在曹营心在汉，迟早他们都会离开。最早走的人是公司最输不起的，因为接下来会越来越难招到人，新进的人产生效益的时间也是越来越长。
当你考虑技术债务的时候，不要单单从功能延迟交付、bug增加这些业务问题来考虑，更要考虑人力成本，以及所产生的更加严重的，要花更长时间来解决的问题。