[技术债务概念](http://www.infoq.com/cn/articles/technical-debt-levison)就不在这里详解了,需要的同学点链查看。
技术债务类似于金融债务,它也会产生利息,这里的利息其实就是指由于鲁莽的设计决策导致需要在未来的开发中付出更多努力的后果。我们可以选择继续支付利息,也可以通过重构之前鲁莽的设计来将本金一次付清。虽然一次性付清本金需要代价,但却可以降低未来的利息。
当然技术债务不限于开发项目管理,整个组织运营过程中,借债是不可避免的,关键在于评估自身是否偿还得起。
债务清单
- 技术过于集中于某个自然人 导致从运营到开发的节奏完全依赖于某个人,一旦这个单位不工作了,整个项目进展大幅度降低甚至停滞。个人也被束缚于这样的恶性循环中,成为工具人,不得解脱,个人成长与发展受限。
- 新员工入职后基本技能培训完全消失 直接导致IT工作量激增,被琐事占用大量工作时间。管理员沦为工具人,预定的工作目标难以顺利展开。
1. 重构入职指南,完善服务清单 梳理新员工欢迎邮件内容,确保第一封邮件的可读性与内容有效性
1. 重新梳理与审视新员工入职所需的内容 包括但不限于IT需求发起方法,外网WIFI访问方法,协作软件使用方法等常见问题
1. 习惯培养与引导
1. 提供更专业的IT服务支持
- 运维系统协同开发问题 目前运维系统的协同开发刚起步,也发现了比较有意思的问题。两运维大牛的两套系统,如何整合并融合成一套,存在技术、协作和项目协同开发上的问题。由于是初期,负债还不算高,系统可以并行,结果有效。但从未来规划看,整个运维平台会出现上述技术过于集中于某个自然人的问题。
1. 及时沟通梳理协同开发存在的问题
1. 增加开发、测试、部署环境等流程、文档规范与要求
1. 实践敏捷开发
1. 保证会议时间与会议内容有效性,及时获取问题反馈
别人家的债务
- WIFI上网问题无法解决,IT挂在行政部下,天花板低,导致各类能解决的技术问题因为行政部门负责人视野局限而无法完成。