这里的技术主张，是指把自己喜欢的技术、框架甚至是一些idea推广到团队的过程。这些东西可以是别人的，也可以是自己的。本文抛开技术本身，结合自己的团队技术推广经验，谈谈如何更好地让对方或团队理解并认可自己的推荐，从而采纳自己的意见。
这是我参与更文挑战的第2天，活动详情查看： 更文挑战
充分的技术调研
首先你应该做充分的准备工作，对一个框架或技术尽可能多的了解或理解，并且对于一些潜在的问题要考虑到别人的前面，这样可以增加别人对你的信任。
谈到了解或理解一个框架或技术，你至少要知道：
- 这个框架的诞生背景是什么，或者它主要解决什么问题？
- 它的主要原理是什么？
- 整个框架的结构是什么？（比如vue：三大块：
script、style、template） - 基于该框架的项目组织架构是什么样的？
以上几点比较基础，可通过阅读官方文档来了解（对于文档，你应该抽时间全部看完，可以有选择地看，但一定是看完的）。
看完后，你还应该动手写一些Demo，上手感受一下框架的开发感受，Demo应该不过于简单亦不过于复杂，要很好地还原一些常见的业务功能点。
最后，如果有条件，你还应该阅读一些关键模块的源码，理解核心模块的实现原理，这样你在讲述时会更加底气十足。
用数据衡量潜在的效益
光有技术调研本身还不够，还需要结合项目业务特点，指出该框架或技术会给团队带来哪些潜在的收益和风险点，毕竟开发必须同时考虑收益和风险，知己知彼才能百战不殆。
比如强调它带来的好处：
- 降低开发成本30%（如果给出数据，需要解释这个数据是怎么来的？）
- 提升了开发体验（提高了编译打包速度，热更新啊），开发心情好了，代码质量提高，bug减少
- 良好的生态（丰富组件库啊、第三方的类库啊等等），基本满足大多数应用场景
- ...
但也要考虑一些风险点：
- 项目里引入该框架的成本有多大，有没有额外的风险？
- 项目里已有功能该框架能否很好地支持？
- 在未来该框架能否很好的适应业务的发展？
- ...
两个方面都要尽可能地仔细考虑，做到心里有数，因为一旦别人提出了你忽略的重大问题，你就会变得非常被动。因此，对于那些核心的重大问题你一定要认真考虑并核对清楚。
同时牢记自己的目的是推荐，有必要突出技术本身的优点，同时认真解答其他同事的疑惑或顾虑。
你提出的潜在效益越多、数据越真实、准备越充分，你的观点就越有说服力！
站在别人的角度思考问题
准备完资料，有一个很重要的点你需要特别注意，就是沟通。
无论你认为自己的准备多充分、观点有多正确，所推荐的技术会多大程度上造福团队，你都不要认为一切应该水到渠成。
不要有任何的心理预设：这个事情，领导应该支持，不支持你就是傻逼之类的。
相反，我们应该站在对方的角度思考问题，问自己：他更在乎的是什么？（这里主要是指领导）
开放性话题：面对新技术，领导更在乎什么？
- 稳定性（框架比较底层，万一不稳定，有严重issue，这可都是领导背锅的）
- 在未来一段时间内能否很好的支撑业务（如果将来公司业务重心发生了偏移或者其他的变动，这种技术革新还有多大的价值呢？）
- 迁移或应用成本（只有在抛去成本依然有显著的收益时领导才感兴趣，因为那样才算创造了价值）
- 采用新技术后能给团队带来多大的收益（开发效率是否提升？开发质量是否提高？ 没有比节省时间更有价值的了）
以上是我的观点，你认为呢？（可以在文末留言哦）
当然，还有你的同事，他们可能也会参加你的推荐会，也是一样的道理。
所以，我们通过站在别人的角度上思考问题，拉近双方的距离，郑重地考虑一些别人关注地现实问题，会让整个沟通变得更顺畅，从而让别人更好的理解你提出的倡议。
最后，别人可能也会提出一些问题，一定要认真客气地回答。如果别人对你的讲述有误解，切忌表现出轻蔑或不耐烦的口气，无论是你没有讲清楚还是他自己没理解透彻，事实是你的倡议没有很好的传递到他的脑袋里，我们很有必要换种方式再解释并说明一次。
牢记自己的目的：推荐自己的主张。
讲讲我的一次失败的经历
当时公司决定使用游戏引擎egret开发产品的某个模块，团队调研了一个开源的框架，最终决定基于这个框架做一些组件封装。然而，几个迭代下来，开发苦不堪言。
在最后一次迭代结束后，我总结了一些问题，并尝试加班加点做了一个更加轻量的框架（说到框架，我更愿意称他为App应用toolkit），封装了一些基础代码并解决了之前封装的一些问题或bug，提供了路由、组件等模块。代码不到一千行（目测有800到900行的样子），相比之前的框架轻量了N倍。
在该框架稳定后，我尝试用这个东西开发了一部分业务，结论是：效率和质量方面都有很明显的提升。对此，我很有信心将其介绍给其中一个同事，在得到了肯定的回答后，我组织了会议打算将它推荐给团队：
- 提供了路由模块。以前应用只能一步步地往下走，现在有了路由，可以通过路由定位到业务模块（提效，职责更加的清晰）
- 分类App的视图层：canvas和html。在源头上定义了两种视图容器，有效防止了不同层之间的干扰
- 封装了组件模块，组件可以全局共享。以前组件只能在特定的单元内共享。导致需要人工复制多个拷贝到不同的单元，当多人协作时带来了很大的维护负担和同步成本
- 代码更精简，更少的代码实现了同样的业务
然后最终结果是，领导并没有同意采用我写的东西，虽然他表示很欣赏我的设计和想法。
当时我特别不解，并且心里非常不服气。其实大可不必：领导有他的考虑，毕竟这是一个新的东西，稳定性和可靠性都是未知的，一旦出现严重问题，那后果是很可怕。
其实从现在来看，我写的这个框架更加符合公司的业务场景，相比现在用的更优秀。
如果再给我一次机会，我会多费点心思跟领导多一些沟通，通过一些行动去证明：多写一些测试用例啊，写一些对比代码啊，多一点耐心、多一点坚持，也许结果会不一样，谁知道呢?
后来也做过一些技术的布道之类的，有成功的，也有失败的。一旦心态摆平了，把该做的工作都做了，结果什么就显得没那么重要了
最后
最后，感谢阅读，如果本文对你有所帮助，欢迎点赞或转发给其他人哦，如果有任何的疑惑，也欢迎留言讨论哦，谢谢！
