技术调研报告

如何做好技术调研？

了解需求--首先你肯定要足够了解需求，然后才能确定一个技术调研方向

一定要确定好要求，准确分析出需要准备的技术点，再进入下一步。

需要技术调研的场景包括但不限于以下三个方面：

• 新技术，资料较少，社区不完备
• 足够成熟，但不确定细节实现
• 想做 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.调研内容：需求背景、产品简介、本次调研目标、产品优势、产品目前存在的问题、产品调研实践、产品调研结论、参考文档