谈谈如何推进自己的技术主张

这里的技术主张,是指把自己喜欢的技术、框架甚至是一些idea推广到团队的过程。这些东西可以是别人的,也可以是自己的。本文抛开技术本身,结合自己的团队技术推广经验,谈谈如何更好地让对方或团队理解并认可自己的推荐,从而采纳自己的意见。

这是我参与更文挑战的第2天,活动详情查看: 更文挑战

充分的技术调研

首先你应该做充分的准备工作,对一个框架或技术尽可能多的了解或理解,并且一些问题要想到别人前面,这样可以增加别人对你的信任。

谈到了解或理解一个框架或技术,你至少要知道:

  • 这个框架的诞生背景是什么,或者它主要解决什么问题?
  • 它的主要原理是什么?
  • 整个框架的结构是什么?(比如vue:三大块:scriptstyletemplate
  • 基于该框架的项目组织架构是什么样的?

以上几点比较基础,可通过阅读官方文档来了解(对于文档,你应该抽时间全部看完,可以有选择地看,但一定是看完的)。

看完后,你还应该动手写一些Demo,上手感受一下框架的开发感受,Demo应该不过于简单亦不过于复杂,要很好地还原一些常见的业务功能点。

最后,如果有条件,你还应该阅读一些关键模块的源码,理解核心模块的实现原理,这样你在讲述时会底气会更足。

用数据衡量潜在的效益

光有技术调研本身还不够,还需要结合项目业务特点,指出该框架或技术能给团队带来哪些潜在的收益以及风险点,毕竟编程的世界里是没有银弹的。

比如强调它带来的好处:

  • 降低开发成本30%(如果给出数据,需要解释这个数据是怎么来的?)
  • 提升了开发体验(提高了编译打包速度,热更新啊),开发心情好了,代码质量提高,bug减少
  • 良好的生态(丰富组件库啊、第三方的类库啊等等),基本满足大多数应用场景

但也要考虑一些风险点:

  • 项目里引入该框架的成本有多大,有没有额外的风险?
  • 项目里已有功能该框架能否很好地支持?
  • 在未来该框架能否很好的适应业务的发展?

两个方面都要尽可能地仔细考虑,做到心里有数。一旦别人问到了一个你忽略的重大问题,你就会变得很被动,所以核心问题一定要认真核对。

当然你的目的是推荐,所以应该突出技术本身的优点,认真解答其他同事的疑惑或顾虑(风险或缺点)。

你提出的潜在效益越多越真实越准备,你的论点就越具有说服力!

站在别人的角度思考问题

准备完资料,有一个很重要的点你需要特别注意,就是沟通

无论你的准备多充分,推荐的技术会多大程度地造福团队,你都不要认为一切应该水到渠成。不要有任何的心理预设:这个事情,领导应该支持,不支持的人就是傻逼,之类的。

相反,我们应该站在对方的角度思考问题,问自己:他更在乎的是什么?(这里主要是指领导)

开放性话题:面对新技术,领导更在乎什么?

  • 稳定性(框架比较底层,万一不稳定,有严重issue,这可都是领导背锅的)
  • 在未来一段时间内能否很好的支撑业务(如果将来公司业务重心发生了偏移或者其他的变动,这种技术革新还有多大的价值呢?)
  • 迁移或应用成本(只有在抛去成本依然有显著的收益时领导才感兴趣,因为那样才算创造了价值)
  • 采用新技术后能给团队带来多大的收益(开发效率是否提升?开发质量是否提高? 没有比节省时间更有价值的了)

以上是我的观点,你认为呢?(可以在文末留言哦)

当然,还有你的同事,他们可能也会参加你的推荐会,也是一样的道理。

所以,我们通过站在别人的角度上思考问题,拉近双方的距离,郑重地考虑一些别人关注地现实问题,会让沟通变得更顺畅。

最后,别人可能也会提出一些问题,一定要认真客气地回答。如果别人对你的讲述有误解,切忌表现出轻蔑或不耐烦的口气,无论是你还是他的问题,现实是你的观点没有很好地传递给他,我们可以尝试换种方式再说一次。

牢记自己的目的:推荐自己的主张

讲讲我的一次失败的经历

当然公司使用游戏引擎egret制作产品的某个模块,团队采用了一个开源的框架,基于这个框架做了一些封装,几个迭代下来,大家苦不堪言。

后来熟悉这个框架并做了几次迭代后,我总结了一些问题,尝试加班加点做了一个更加轻量的框架(说框架,我更愿意称他为App应用toolkit),封装了一些基础代码,提供了路由、组件等模块。代码只有几百行,相比之前的框架轻量了N倍。

在解决了一些bug后,我尝试用这个东西开发一部分业务功能,无论效率和质量方面都有很明显的提升,于是我很有信心,介绍给其中一个同事,得到了肯定的回答后,我组织了会议打算将它推荐给团队:

  • 提供了路由模块。以前应用只能一步步地往下走,现在有了路由,可以通过路由定位到业务模块(提效,职责更加的清晰)
  • 封装了App层,源头指定两种容器:canvas和html。以前都是随便写,很容易出现干扰的情况,现在在源头实现了视图分层
  • 封装了组件模块,组件可以全局共享。以前组件只能在特定的单元内共享。导致需要人工复制多个拷贝到不同的单元,当多人协作时带来了很大的维护负担和同步成本
  • 代码更精简,更少的代码实现了相同的业务

无论是当时还是现在,我都认为我写的这个框架更加符合公司的业务场景,相比现有的框架更加优秀。然后最终结果是,领导并没有同意采用我写的东西,虽然他表示很欣赏我的设计和想法。

当时我特别不解,并且心里非常不服气。其实大可不必:领导有他的考虑,毕竟这是一个新的东西,稳定性和可靠性都是未知的,一旦出现严重问题,那后果是很可怕。

如果再给我一次机会,我会多费点心思跟领导多一些沟通,通过一些行动去证明:多写一些测试用例啊,写一些对比代码啊,多一点耐心、多一点坚持,也许结果会不一样,谁知道呢?

后来也做过一些技术的布道之类的,有成功的,也有失败的。一旦心态摆平了,把该做的工作都做了,结果什么就显得没那么重要了

最后

最后,感谢阅读,如果本文对你有所帮助,欢迎点赞或转发给其他人哦,如果有任何的疑惑,也欢迎留言讨论哦,谢谢!

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享