先来说技术债这问题，软件开发人员或是在软件品质上，每个人都知道残留技术债是不好的。但是，现实状况下，企业内部开发想要做到没有的技术债是不可能。往往还没到这阶段，自己大概也先走人。但我们也不能放任技术债不管，因此，与其做到没有技术债，而不如去有效管理这些技术债，以及事后去消灭这些技术债，还是比较有效益的。而技术债要累积到多少才算破口呢?我个人认为要取决于团队对于风险的承受度与消化程度


简单来说，如果这些被列管的技术债是可被控管，且发生所造成影响是团队可以快速修复与承担，那这类性技术债是可以暂时被堆叠多一些，如果技术债可能导致系统影响层面过大，万一造成风险是团队难以承担，那样这类型累积量就相对要低到风险之下。

再回到定义求有的程度，先举一个例子，我们常常在使用电商网站或是一些Web服务，每当系统或是服务更新，如果该介面被修正更好更美观，我们基本上都会觉得是焕然一新感觉，会认为这系统有不段迭代更新是一件好事。但是，如果内部系统这样做，大多数时候就会被使用者反弹，认为没事做界面更新导致他们还必须重新学习甚至看不顺眼，降低他们工作效能或是做错事情。因此，当系统第一版介面的完成产出，也将势必订定了这个系统未来介面的走向，除非是被用户嫌弃外，基本上是无太大机会做整体异动或是变革。在这情况下，介面开发在求有的程度上基本上就要能达到七成的完整度。再举一个案例，如果初期认为采用Desktop程式是较好的方案，且用户也开始习惯这样功能使用与流程，当需求与功能越来越多时候，发现转换到Web将会有更好开发效率且产生问题更少的时候，除非开发者与用户能达成协议，不然是很做难转换或是变革的。