工程师自我修养之为什么需要技术KPI？

在业务技术团队，有一个不好的趋势就是团队越来越业务，越来越没有技术味 道。每个人都在谈业务，技术大会上在谈业务，周会上在聊业务，周报里写的是业务 项目…… 唯独少被谈及的是技术本身。此处并不是说业务不重要，而是说理解业务和把控 业务需求是技术人员的 base，而不是全部。 将就的代价 这种技术味道的缺失对技术团队来说是非常可惜的，也不利于技术人员的成长和 发展。因为很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可 扩展性好的系统。相反，这种业务代码的堆砌，从短期看也许是“较快”实现了业务 需求，但是从长远来看，这种烂系统的增加会极大的阻碍业务的发展，形成一个个的 黑洞应用，而工程师被裹挟在业务需求和烂系统之间，疲于应对，心力交瘁。 这种将就将导致系统腐化，技术债越垒越高，像肿瘤一样消耗你所有的能量。 我不是药神，只能尝试开出一方——那就是在不影响业务的情况下（特别是相对 稳定的业务，请拒绝业务方的时间倒排），Tech Story 应该和 User Story 有同等的 重要性，要把重构优化提到和业务需求相等的优先级去处理。我们不仅要对业务需求 负责，我们更要对应用的质量，系统的可维护性负责。 因为我们技术人员是应用的父母（有些是亲生父母，有些是养父母），你不照顾它 们，不治理它们，它们就会生病，你忍心看到这样的局面吗？ 技术管理者者（TL）的失职 造成这种局面，我们的技术管理者，我们的 TL 要负有主要责任。如果一个 TL 从来不关注系统架构和设计，从来不写 code，对技术没有热情也不学习，甚至其本身技术就很烂，那么在这个 TL 领导下的技术团队，又怎么会有技术味道，团队成员 又怎么能进步和成长？ 现在很多的 TL 每天都混迹在各种会议上，很忙，做着各种沟通协调的事情，可 是我们真的需要这么多的会议、这么多的沟通吗？ 如果沟通的结果只是做业务和 PD 对团队的传话筒，没有业务创新，没有用技术 和数据系统化的解决业务问题，没有在技术方向和架构上给团队指引，没能切实的帮 助系统优化、团队提效，请问这样的沟通给业务带来了什么价值，给团队带来了什么 价值？还是沉下心来，多看看书，哪怕非技术的书也好。多写写代码，哪怕跟业务无 关的代码也好。 所以，我们要回归技术本身。我们不需要这么多“高高在上”、“指点江山”的技 术 Manager，而是需要能真正深入到系统里面，深入到代码细节，给团队带来实实 在在改变的技术 Leader。