要不要引入新技术?先思考这几个问题

h4cd
 h4cd
发布于 2019年03月02日
收藏 71

我们应该使用这种新技术,你看它多快、多好,又多么优雅,可以加快开发进度啊。

你看,我上周末实现了一个原型而且它还可以跑生产,这新技术就是这么牛 X。

……

说好的要让员工在公司里学习和成长呢?

……

呵呵,干里凉,辣鸡公司,我唔捞喇。

这样的对话熟不熟悉?作为开发,你有没有经历过想要在工作中引入新技术却阻力重重,而且很多时间就花在了这样的争论之中,最后还搞得心力交瘁。

前 Etsy CTO Kellan 发表了一篇文章,他认为技术团队中沟通成本太高,有时候总是需要花时间与精力去讨论一些难以达成统一观点的问题,比如上边这种典型的“是否要引入一项新技术”。

如何去避免呢?

Kellan 介绍了自己已经使用了十多年的“问题列表”,在想要引入一项新技术之前把该列表的问题都思考一下,而不是去无休止地讨论,甚至于辞职。

问题列表比较简短,思考过这些问题之后,也许就不用去争论了:

  • 我们到底是要解决什么问题? (永远不应该因为自己的目的而引入新技术)
  • 我们可以怎样用当前的技术栈解决这个问题?(如果答案是做不到,那么可能对这个问题没有进行深入思考;如果可以,那么思考下一个问题)
  • 我们当前的技术栈为什么不能以金钱、人员与时间等方面经济有效的方式去解决这个问题?
  • 我们是否明确了新技术会带来的新成本?(监控、员工培训、学习精力等)
  • 如果这项新技术可以替代目前的一些方案,那么我们能不能保证将来把相关的开发都迁移到这项新技术上?还是说我们针对这一个问题其实会有多种解决方案的尝试?(这个新技术路线会不会稳定下去?)
  • 有没有我们信任的人在使用该新技术?我们和他们谈过这个东西吗?他们是什么想法?新技术有什么是他们不喜欢的?(如果他们不讨厌它,那么他们还没有深入使用过)
  • 怎样低风险去尝试?
  • 有没有组织各个部门的高级别员工逐一回答上述各项,有没有文档记录?

你的想法呢?

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.aercaste.com]
本文标题:要不要引入新技术?先思考这几个问题
加载中

精彩评论

MrXionGe
MrXionGe
目标技术栈的生态丰富度应该是最最重要的,其次是社区活跃度
遇见更美好的自己
做什么事之前,多多思考,是没有坏处的,思考的越深,后期踩的坑就越少
超级大丁丁
超级大丁丁
我觉得这样挺好,不过通常我让持不同意见的小伙伴列一下优缺点,然后我下定论说服不采纳的一方
笨笨D幸福
笨笨D幸福
第二个问题是个坑,大部分情况都是一切都OK,但是新旧业务交叉,复杂度太高,领导要求“无损”重构和迁移(<=这点是不可能的)

最新评论(11

Jimmm
Jimmm

引用来自“笨笨D幸福”的评论

第二个问题是个坑,大部分情况都是一切都OK,但是新旧业务交叉,复杂度太高,领导要求“无损”重构和迁移(<=这点是不可能的)
哈哈,这个java7更新java8就没那么多事。。。虽然这变革已经算很大了。
haitaosoft
haitaosoft
跟风赶时髦=面向简历开发
tengyz
tengyz
新技术坑多,最近公司压测发现spring cache有bug,在高并发情况下暴露出来,不是新的技术就适用
ychost
ychost
新技术一般会节约开发时间
超级大丁丁
超级大丁丁
我觉得这样挺好,不过通常我让持不同意见的小伙伴列一下优缺点,然后我下定论说服不采纳的一方
笨笨D幸福
笨笨D幸福

引用来自“笨笨D幸福”的评论

第二个问题是个坑,大部分情况都是一切都OK,但是新旧业务交叉,复杂度太高,领导要求“无损”重构和迁移(<=这点是不可能的)
还有,更新技术导致的人力时间成本,大部分领导都不愿意出
笨笨D幸福
笨笨D幸福
第二个问题是个坑,大部分情况都是一切都OK,但是新旧业务交叉,复杂度太高,领导要求“无损”重构和迁移(<=这点是不可能的)
遇见更美好的自己
做什么事之前,多多思考,是没有坏处的,思考的越深,后期踩的坑就越少
光石头
光石头

引用来自“MrXionGe”的评论

目标技术栈的生态丰富度应该是最最重要的,其次是社区活跃度
赞成!还有一点就是持续性!
返回顶部
顶部