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