先来说技术债这问题,软件开发人员或是在软件品质上,每个人都知道残留技术债是不好的。但是,现实状况下,企业内部开发想要做到没有的技术债是不可能。往往还没到这阶段,自己大概也先走人。但我们也不能放任技术债不管,因此,与其做到没有技术债,而不如去有效管理这些技术债,以及事后去消灭这些技术债,还是比较有效益的。而技术债要累积到多少才算破口呢?我个人认为要取决于团队对于风险的承受度与消化程度
简单来说,如果这些被列管的技术债是可被控管,且发生所造成影响是团队可以快速修复与承担,那这类性技术债是可以暂时被堆叠多一些,如果技术债可能导致系统影响层面过大,万一造成风险是团队难以承担,那样这类型累积量就相对要低到风险之下。
再回到定义求有的程度,先举一个例子,我们常常在使用电商网站或是一些Web服务,每当系统或是服务更新,如果该介面被修正更好更美观,我们基本上都会觉得是焕然一新感觉,会认为这系统有不段迭代更新是一件好事。但是,如果内部系统这样做,大多数时候就会被使用者反弹,认为没事做界面更新导致他们还必须重新学习甚至看不顺眼,降低他们工作效能或是做错事情。因此,当系统第一版介面的完成产出,也将势必订定了这个系统未来介面的走向,除非是被用户嫌弃外,基本上是无太大机会做整体异动或是变革。在这情况下,介面开发在求有的程度上基本上就要能达到七成的完整度。再举一个案例,如果初期认为采用Desktop程式是较好的方案,且用户也开始习惯这样功能使用与流程,当需求与功能越来越多时候,发现转换到Web将会有更好开发效率且产生问题更少的时候,除非开发者与用户能达成协议,不然是很做难转换或是变革的。