seo建站推广,wordpress 导航下拉,百度指数的网站,网站建设调查报告摘要#xff1a; 为什么需要技术KPI#xff1f; 在业务技术团队#xff0c;有一个不好的趋势就是团队越来越业务#xff0c;越来越没有技术味道。每个人都在谈业务#xff0c;技术大会上在谈业务#xff0c;周会上在聊业务#xff0c;周报里写的是业务项目...... 唯独少…摘要 为什么需要技术KPI 在业务技术团队有一个不好的趋势就是团队越来越业务越来越没有技术味道。每个人都在谈业务技术大会上在谈业务周会上在聊业务周报里写的是业务项目...... 唯独少被谈及的是技术本身。
为什么需要技术KPI
在业务技术团队有一个不好的趋势就是团队越来越业务越来越没有技术味道。每个人都在谈业务技术大会上在谈业务周会上在聊业务周报里写的是业务项目......
唯独少被谈及的是技术本身。此处并不是说业务不重要而是说理解业务和把控业务需求是技术人员的base而不是全部。
将就的代价
这种技术味道的缺失对技术团队来说是非常可惜的也不利于技术人员的成长和发展。因为很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统。相反这种业务代码的堆砌从短期看也许是“较快”实现了业务需求但是从长远来看这种烂系统的增加会极大的阻碍业务的发展形成一个个的黑洞应用而工程师被裹挟在业务需求和烂系统之间疲于应对心力交瘁。 这种将就将导致系统腐化技术债越垒越高像肿瘤一样消耗你所有的能量。
我不是药神只能尝试开出一方——那就是在不影响业务的情况下特别是相对稳定的业务请拒绝业务方的时间倒排Tech Story应该和User Story有同等的重要性要把重构优化提到和业务需求相等的优先级去处理。我们不仅要对业务需求负责我们更要对应用的质量系统的可维护性负责。 因为我们技术人员是应用的父母有些是亲生父母有些是养父母你不照顾它们不治理它们它们就会生病你忍心看到这样的局面吗 技术管理者者TL的失职
造成这种局面我们的技术管理者我们的TL要负有主要责任。如果一个TL从来不关注系统架构和设计从来不写code对技术没有热情也不学习甚至其本身技术就很烂那么在这个TL领导下的技术团队又怎么会有技术味道团队成员又怎么能进步和成长 现在很多的TL每天都混迹在各种会议上很忙做着各种沟通协调的事情可是我们真的需要这么多的会议、这么多的沟通吗 如果沟通的结果只是做业务和PD对团队的传话筒没有业务创新没有用技术和数据系统化的解决业务问题没有在技术方向和架构上给团队指引没能切实的帮助系统优化、团队提效请问这样的沟通给业务带来了什么价值给团队带来了什么价值还是沉下心来多看看书哪怕非技术的书也好。多写写代码哪怕跟业务无关的代码也好。
所以我们要回归技术本身。我们不需要这么多“高高在上”、“指点江山”的技术Manager而是需要能真正深入到系统里面深入到代码细节给团队带来实实在在改变的技术Leader。 技术KPI的量化
提升技术氛围打造工程师文化不能仅停留在口头上可搭配一定的强制手段比如和技术人员的利益绑定。这种绑定就需要我们能对技术贡献进行一个相对公平的分解和量化。
技术KPI
基于此我将技术人员的KPI分解为业务贡献、技术贡献和团队贡献三个大的部分其详细内容如下。
• 业务贡献包括需求把控业务项目和业务创新。• 技术贡献包括设计重构、技术影响力、Code Review、创新提效和代码质量。• 团队贡献包括招聘、新人培养和团队氛围。
那么技术贡献中的这几个维度要怎么理解呢解释的话我就不多说了用我们工作中的一些案例来描述一下吧。
应用质量
• 你负责或者共同负责的应用质量分可以从代码重复率圈复杂度分层合理性等维度考察。• 你做了哪些提升应用质量分的工作。
设计重构
• 我在客户通项目中对CRM销售域进行了领域建模和设计并且抽象合理。• 我发现Infrastructure中package分类不合理进行了重新设计并重构完成。• 我发现现在系统中错误码比较混乱我梳理制定了新的错误码规范并完成了代码重构。
技术影响力
• 在团队内分享10篇干货点赞数1000。• 团队分享策略模式得到同学好评 。• 我接受邀请在行业会议上分享了SOFA架构。
Code Review
• 我在review某某代码的时候发现可能存在线程不安全的隐患。• 我在review某某代码的时候发现存在设计不合理的现象此处使用责任链可以很优雅的解决问题并具备一定的扩展性。
创新提效
• 我发现本地测试启动PandoraBoot比较浪费时间所以写了一个TestContainer大大提升了自测效率。• 我发现有一些boilerplate代码不需要写所以对乐观锁、分页进行了annotation支持简化了代码。• 在某个项目或者技术点上面我产出了一篇专利基于领域模型的业务配置化。
代码质量
• 提测后的Bug数线上故障数系统可以提取不用自己填写• 我完善了某某模块的单元测试并多次在自动化回归中发现问题。
KPI答疑
对于上面的KPI大部分的技术同学是表示认可的当然质疑的声音也很多我这里挑一些典型的回答一下。
Q技术KPI的提出会不会导致技术同学只关注技术不做业务项目了
A关于绩效肯定是综合看业务贡献技术贡献和团队贡献。但是作为一个重要参考和风向标技术KPI是有积极意义的。
Q 你这个设计重构怎么量化 A 这个很难用系统标准化更多的还是要依赖TL的专业能力进行评分但即使是这样也比以前什么都没有完全黑盒要强。至少在传达一个信息我们鼓励好的设计鼓励不断地重构优化。
Q我们现在的业务需求已经在堆积一线同学根本没有时间去做重构优化。 A这个问题开篇其实已经说过了你是要不断地裹挟在业务需求和烂代码里面呢还是花时间improve然后更快地支持业务。这个权衡应该不难做关键是要看决心和能力。对于很多业务我没有看到推迟几天上线就会影响业务格局的业务场景所以作为技术团队我们就应该在User Story之外加上我们的Technical Story把完成业务需求和系统重构都当成我们的核心任务。
原文链接 本文为云栖社区原创内容未经允许不得转载。
