如何做好技术调研？
了解需求--首先你肯定要足够了解需求，然后才能确定一个技术调研方向
一定要确定好要求，准确分析出需要准备的技术点，再进入下一步。
需要技术调研的场景包括但不限于以下三个方面：
- 新技术，资料较少，社区不完备
- 足够成熟，但不确定细节实现
- 想做 xxx 功能，但不确定能不能实现
调研方向
现存方案
你需要先尽可能地罗列出市面上已存的较为流行的方案，然后再对这些方案进行各方面对比，选出一个最适合你当前需求需要的方案。
对比环节
了解了需求，列举了所有可用方案后，下面就进入最重要的选优环节了，方案对比的方向不要求能够覆盖所有方面，但最起码应该覆盖一些关键节点
对比不应当仅是客观地描述各个解决方案的优劣，更主要的是结合你当前的实际需求，从不同的方向上给各个解决方案进行打分，以解释明白为什么从 A 功能上看，要选 α 方案，而从 B 功能上看，β 方案更好
原理
实现原理基本上决定了具体方案的方方面面，了解了原理，才能更好地进行分析。
知道了原理之后，对于其优缺点就能有进一步的认知，同时可以结合自己对于其底层原理相关知识的经验，得出更多的结论。
活跃度
主要从 github star 数、代码更新频率、issue响应速度、文档完整度、在线示例、官方团队和社区的规模等方面进行判断
一个低于 1k star、超过半年没有更新、issue很少或者响应速度很慢，低于 3 个 contributor、文档只有几段话的项目一般而言是无法用于线上环境的。
生产环境可用性
主要考虑的是，市面上是否已经存在使用这个解决方案的案例了，如果有其他规模较大的产品线上使用了这个方案，那么在一定程度上可以证明，这个方案是可以放在线上的。
如果有内部团队曾经有过这方面的使用案例，那么就更需要去沟通一番了，可能他们的使用场景跟你的不一样（完全一样的话可能就没必要重复调研了），但肯定有可以借鉴的地方，了解他们的使用场景、使用过程中遇到的坑、是否有踩坑文档、是否推荐使用等。
功能
技术方案是为实际业务需求所服务的，选出的技术方案必须能够满足需求所要求的所有功能。
兼容性
性能
可以从XX、XX方面进行考量，除了这两个通用的之外，对于特定的技术方案可能还有特定的衡量指标，另外，你可以亲自对关键性能指标进行测试，列出详细的数据，会更有说服力。
可维护性
主要从工作量、学习/维护成本、对于业务的侵入度、最佳实践等方面考量
一般情况下，开箱即用的肯定比需要一大堆配置项的要好，没有额外学习成本的肯定比需要专业知识的要好，业务侵入度越低越好，如果能有官方/社区的最佳实践可参考那就最好不过了。
缺陷及隐患
关注缺点的优先级高于关注优点的优先级，优点再多，也可能因为一个缺点而不能被应用。不过也不是所有缺陷都不能容忍的。就算是可能与你需求相关的问题，如果其在可容忍范围内，那么也是可以接受的。
其他
针对具体的技术方案，可能还有其他一些比较重要的环节，需要具体需求具体对待。
产出文档
基本上上述信息足以支撑起得出一个调研结论了，但这个结论不能只存在于你自己的脑海中，你应当将这个过程记录下来，可以就按照上面的步骤作为模板，形成一份调研文档进行输出 这份调研文档应当包括以下四个方面：
1、需求背景
你的调研文档可能会被其他不熟悉你所做需求的人查看，对于一个做业务的技术人员来说，脱离具体业务谈技术就是耍流氓，你好不容易调研了一番然后又产出一篇文档，那么当然想要更多的人能够看得懂得到更多的认同
2、一句话结论
为了能快速给出一个定调，作为详细内容的“太长不看版”
不是所有人都想先完整地看完所有调研内容然后才得到一个结论的，你的详细调研内容都属于过程，而结论可能才是很多看你调研文档的人最先关心的东西，所以你应该提供一句简短的断言结论
3、现存方案对比记录
详细的对比过程是为了调研结论的细节和说服力，让别人更加认同你的结论。
这个对比记录的内容主要应当围绕你当前面临的实际业务需求展开，除此之外，还可以描述一些需求可能涉及不到的点，当然还是要注意主次关系，大部分内容应当都是围绕你所面临的实际需求，额外的东西应当放在次要位置。
4、参考文档链接
作用和现存方案对比记录差不多，都是你调研结果的支撑论据，也方便其他参考你报告的人自行去获取更多的内容
参考
- 当我们在做技术调研的时候，到底需要做什么？怎么做？
- 技术调研的模式
- 如何做好技术调研
- 技术调研流程分享
如何写好一篇技术调研报告
1.我们要什么（需求是什么）：选型文档聚焦的还是业务需求，脱离需求来谈选型，个人感觉其实就是扯淡，做了一个高大上的东西出来，不一定比普通的东西实用。毕竟我们做的是技术调研不是新技术预研。
2.我们目前有什么（现状是什么）：其实这个我觉得就是深挖当前系统的问题和根因，把相关的技术债务理清楚，这些在选型过程中都是需要考虑的因素。
3.我们要达到什么样的目的：凡事总要有个目标，特别是技术选型。通过选型，系统想要达到什么样的一个目的，想要满足什么样的需要，达到什么样的TPS等等。
4.方案分析：这一步个人感觉就是把待选项套在上面三个项里面进行多维度比较，以及分析每个方案带来的优缺点。
如何进行技术方案调研与设计？https://juejin.cn/post/6977625376738508808
技术调研流程分享https://shmily-qjj.top/4b21953d/
技术调研流程 整个调研流程分四个阶段
第一阶段：需求分析
分析目前/未来可能出现的瓶颈点
明确调研目标和方向（为了实现新需求？为了优化瓶颈点？）
引入新工具后的结果衡量（效率提升、成本降低等，如何衡量）
结构化思考新工具引入的目标和衡量标准：场景（适用场景、知识要求）、效率（性能、效果预测）、成本（容量、硬件资源、维护成本）、稳定性（故障分析工具、监控完善度）等
第二阶段：准备阶段
理解需求
结合现状评估可行性和收益
第三阶段：调研阶段
简单调研
短时间内粗略了解所调研技术的应用场景和部署环境，进一步评估和权衡可行性和收益 经过权衡后发现值得调研，发送邮件至直接上级并抄送部门Leader (标题：申请调研xxx 内容：简述xxx值得详细调研的理由) 协商决定是否批准，若批准，则开始进入详细调研阶段
详细调研
包括但不限于： 先设计调研方法与调研过程 预估调研时间，并在北森设定Deadline，根据调研报告的要求按时完成调研报告 了解相关技术在其他公司的应用及收益 原理及核心技术调研 总结适合我们的场景及解决方案 调研过程遇到的问题与解决方案 未解决的问题/收集需求可随时讨论，有必要的话可以开讨论会 设计落地方案
第四阶段：反馈与落地
调研反馈
必须产出一份调研报告 选择反馈形式：分享会、文档、邮件、群通知（如果是分享会，则要有完善的PPT，会前共享出来）
技术落地
根据自己设计的落地方案得出详细的部署文档和使用文档 配合运维部署
后续阶段：落地后如何跟进
出现问题及时跟进解决，并把问题与解决方案更新到使用文档中，如果影响较大，要在更新完使用文档后发群通知。 相关的新人文档/Wiki更新
文档要求
所有调研文档统一保存在部门文档中的技术调研文档目录
1.部署文档要求
这部分为了方便让运维人员傻瓜式部署，并可以把简单的运维工作交给运维。
尽量打包好主从节点的分发包（提前编译好）
尽量采用傻瓜式命令
尽量写出部署过程可能的报错及解决方案
常用维护方案总结
2.使用文档要求
这部分目的是方便大家使用新技术新组件。
格式包括但不限于： 场景1：示例代码/操作 场景2：示例代码/操作 场景3：示例代码/操作 ...
常见错误及解决
遇到问题请联系：调研人
3.调研报告要求
这部分的目的是调研时可能有遗漏的点，可以从这个列表里做参考。
开头写清 标题 + 调研人 + 调研时间
可以参考但不限于这些点：
xx是什么
xx的优缺点
xx的应用场景
xx的功能/特性
xx的原理与架构简述
相似技术横向对比
初步评估带来的收益
遇到的问题Q&A
xx的兼容性（支持什么不支持什么）
xx技术的核心点
xx的性能与扩展性（测试结果）
xx的部署难度
如何部署与简单实践
应用该技术带来的工作量和学习成本
总结
注意事项
关注缺点的优先级高于关注优点的优先级（优点再多，也可能因为一个缺点而不能被应用）
明确场景，及时沟通需求，明确需求细节 多搜集信息，不急于出结果（搜集足够的信息才能做出比较准确的判断）
要从可行性，稳定性，可维护性，工作量和学习成本等几个重要方面考虑
合理安排时间，自己规定了Deadline，就要及时交付反馈
技术调研的模式https://zhuanlan.zhihu.com/p/61947357
技术调研的产出
一句话概括
优缺点分析
适用场景
比较，比较，比较
MVP最小可用产品
例子：low-code programming
收集相关的无代码开发平台，对于相关概念的介绍 。
了解无代码编程所需要的技术相关的信息。
整理无代码编程相关的优缺点。
尝试使用一些无代码开发平台。
结合自己的经验，设计一个无代码编程的原型。
撰写一篇相关的文章。
技术调研 主要从哪几方面调研，技术调研，是指针对某项技术或研究领域，对技术背景、技术发展路线、技术现状、研究热点、主流研究机构等进行调查分析，为企业、研究机构的技术转型、技术升级、申报项目、定题选题提供个性化定制调研分析报告。
第一点，调研报告的目的
第二点，调研报告的内容
第三点，调研报告的结论
例子：IM方案技术调研报告
目录
1.编写目的
2.调研方向
3.协议比较
4.融合通讯架构
4.1多媒体融合通讯平台
4.2互联网点击呼叫架构
5.方案/产品介绍
5.1商业产品
IBM Lotus Domino Sametime
上海恒聚ICM
微软Live Communications Server(LCS)
腾讯RTX
5.2开源方案
OpenFire
ejabberd
OpenSER
6.方案/产品比较
6.1技术比较
6.2架构比较
6.3功能比较
6.4扩展性比较
7.总结
例子：通付盾区块链应用及专利技术调研报告
- 背景
- 全球区块链技术与专利发展概况
- 通付盾区块链保护技术与专利价值分析
- 通付盾区块链专利保护格局详解
- 通付盾区块链专利技术的落地应用
- 总结
Flutter 技术调研报告
目 录
一、Flutter是什么 1. 官方介绍 2. Flutter 与原生的性能对比
二、目前状况
1.大厂使用情况
2.举例说明
三、自身分析 1.公司目前项目 2.维护方案
四、优势 1.开发成本比较 2.跨平台方案比较
五、坑
六、接入流程
七、结论
百度文库 研发项目管理工具与模板研发项目管理工具与模板new1 - 百度文库
研发项目技术调研报告
Apache Camel K 技术调研报告
Apache Camel K 技术调研报告_wu_weijie的博客-程序员ITS401_apache camel k - 程序员ITS401
《技术领导力》笔记（4）—— 技术调研和预研
《技术领导力》笔记（4）—— 技术调研和预研 - 别样风景天 - 博客园
如何做好技术调研如何做好技术调研 - 简书
1.调研内容：前言、背景、介绍、总结
2.调研内容：技术背景、产品简介、功能特点、部署方案、成本和性能
3.调研内容：需求背景、产品简介、本次调研目标、产品优势、产品目前存在的问题、产品调研实践、产品调研结论、参考文档
