如何做好技術調研？

了解需求--首先你肯定要足夠了解需求，然后才能確定一個技術調研方向

一定要確定好要求，準確分析出需要準備的技術點，再進入下一步。

需要技術調研的場景包括但不限于以下三個方面：

• 新技術，資料較少，社區(qū)不完備
• 足夠成熟，但不確定細節(jié)實現(xiàn)
• 想做 xxx 功能，但不確定能不能實現(xiàn)

調研方向

現(xiàn)存方案

你需要先盡可能地羅列出市面上已存的較為流行的方案，然后再對這些方案進行各方面對比，選出一個最適合你當前需求需要的方案。

對比環(huán)節(jié)

了解了需求，列舉了所有可用方案后，下面就進入最重要的選優(yōu)環(huán)節(jié)了，方案對比的方向不要求能夠覆蓋所有方面，但最起碼應該覆蓋一些關鍵節(jié)點

對比不應當僅是客觀地描述各個解決方案的優(yōu)劣，更主要的是結合你當前的實際需求，從不同的方向上給各個解決方案進行打分，以解釋明白為什么從 A 功能上看，要選 α 方案，而從 B 功能上看，β 方案更好

原理

實現(xiàn)原理基本上決定了具體方案的方方面面，了解了原理，才能更好地進行分析。

知道了原理之后，對于其優(yōu)缺點就能有進一步的認知，同時可以結合自己對于其底層原理相關知識的經(jīng)驗，得出更多的結論。

活躍度

主要從 github star 數(shù)、代碼更新頻率、issue響應速度、文檔完整度、在線示例、官方團隊和社區(qū)的規(guī)模等方面進行判斷

一個低于 1k star、超過半年沒有更新、issue很少或者響應速度很慢，低于 3 個 contributor、文檔只有幾段話的項目一般而言是無法用于線上環(huán)境的。

生產(chǎn)環(huán)境可用性

主要考慮的是，市面上是否已經(jīng)存在使用這個解決方案的案例了，如果有其他規(guī)模較大的產(chǎn)品線上使用了這個方案，那么在一定程度上可以證明，這個方案是可以放在線上的。

如果有內部團隊曾經(jīng)有過這方面的使用案例，那么就更需要去溝通一番了，可能他們的使用場景跟你的不一樣（完全一樣的話可能就沒必要重復調研了），但肯定有可以借鑒的地方，了解他們的使用場景、使用過程中遇到的坑、是否有踩坑文檔、是否推薦使用等。

功能

技術方案是為實際業(yè)務需求所服務的，選出的技術方案必須能夠滿足需求所要求的所有功能。

兼容性

性能

可以從XX、XX方面進行考量，除了這兩個通用的之外，對于特定的技術方案可能還有特定的衡量指標，另外，你可以親自對關鍵性能指標進行測試，列出詳細的數(shù)據(jù)，會更有說服力。

可維護性

主要從工作量、學習/維護成本、對于業(yè)務的侵入度、最佳實踐等方面考量

一般情況下，開箱即用的肯定比需要一大堆配置項的要好，沒有額外學習成本的肯定比需要專業(yè)知識的要好，業(yè)務侵入度越低越好，如果能有官方/社區(qū)的最佳實踐可參考那就最好不過了。

缺陷及隱患

關注缺點的優(yōu)先級高于關注優(yōu)點的優(yōu)先級，優(yōu)點再多，也可能因為一個缺點而不能被應用。不過也不是所有缺陷都不能容忍的。就算是可能與你需求相關的問題，如果其在可容忍范圍內，那么也是可以接受的。

其他

針對具體的技術方案，可能還有其他一些比較重要的環(huán)節(jié)，需要具體需求具體對待。

產(chǎn)出文檔

基本上上述信息足以支撐起得出一個調研結論了，但這個結論不能只存在于你自己的腦海中，你應當將這個過程記錄下來，可以就按照上面的步驟作為模板，形成一份調研文檔進行輸出 這份調研文檔應當包括以下四個方面：

1、需求背景

你的調研文檔可能會被其他不熟悉你所做需求的人查看，對于一個做業(yè)務的技術人員來說，脫離具體業(yè)務談技術就是耍流氓，你好不容易調研了一番然后又產(chǎn)出一篇文檔，那么當然想要更多的人能夠看得懂得到更多的認同

2、一句話結論

為了能快速給出一個定調，作為詳細內容的“太長不看版”

不是所有人都想先完整地看完所有調研內容然后才得到一個結論的，你的詳細調研內容都屬于過程，而結論可能才是很多看你調研文檔的人最先關心的東西，所以你應該提供一句簡短的斷言結論

3、現(xiàn)存方案對比記錄

詳細的對比過程是為了調研結論的細節(jié)和說服力，讓別人更加認同你的結論。

這個對比記錄的內容主要應當圍繞你當前面臨的實際業(yè)務需求展開，除此之外，還可以描述一些需求可能涉及不到的點，當然還是要注意主次關系，大部分內容應當都是圍繞你所面臨的實際需求，額外的東西應當放在次要位置。

4、參考文檔鏈接

作用和現(xiàn)存方案對比記錄差不多，都是你調研結果的支撐論據(jù)，也方便其他參考你報告的人自行去獲取更多的內容

參考

• 當我們在做技術調研的時候，到底需要做什么？怎么做？
• 技術調研的模式
• 如何做好技術調研
• 技術調研流程分享

如何寫好一篇技術調研報告

1.我們要什么（需求是什么）：選型文檔聚焦的還是業(yè)務需求，脫離需求來談選型，個人感覺其實就是扯淡，做了一個高大上的東西出來，不一定比普通的東西實用。畢竟我們做的是技術調研不是新技術預研。

2.我們目前有什么（現(xiàn)狀是什么）：其實這個我覺得就是深挖當前系統(tǒng)的問題和根因，把相關的技術債務理清楚，這些在選型過程中都是需要考慮的因素。

3.我們要達到什么樣的目的：凡事總要有個目標，特別是技術選型。通過選型，系統(tǒng)想要達到什么樣的一個目的，想要滿足什么樣的需要，達到什么樣的TPS等等。

4.方案分析：這一步個人感覺就是把待選項套在上面三個項里面進行多維度比較，以及分析每個方案帶來的優(yōu)缺點。

如何進行技術方案調研與設計？https://juejin.cn/post/6977625376738508808

技術調研流程分享https://shmily-qjj.top/4b21953d/

技術調研流程 整個調研流程分四個階段

第一階段：需求分析

分析目前/未來可能出現(xiàn)的瓶頸點

明確調研目標和方向（為了實現(xiàn)新需求？為了優(yōu)化瓶頸點？）

引入新工具后的結果衡量（效率提升、成本降低等，如何衡量）

結構化思考新工具引入的目標和衡量標準：場景（適用場景、知識要求）、效率（性能、效果預測）、成本（容量、硬件資源、維護成本）、穩(wěn)定性（故障分析工具、監(jiān)控完善度）等

第二階段：準備階段

理解需求

結合現(xiàn)狀評估可行性和收益

第三階段：調研階段

簡單調研

短時間內粗略了解所調研技術的應用場景和部署環(huán)境，進一步評估和權衡可行性和收益 經(jīng)過權衡后發(fā)現(xiàn)值得調研，發(fā)送郵件至直接上級并抄送部門Leader (標題：申請調研xxx 內容：簡述xxx值得詳細調研的理由) 協(xié)商決定是否批準，若批準，則開始進入詳細調研階段

詳細調研

包括但不限于： 先設計調研方法與調研過程 預估調研時間，并在北森設定Deadline，根據(jù)調研報告的要求按時完成調研報告 了解相關技術在其他公司的應用及收益 原理及核心技術調研 總結適合我們的場景及解決方案 調研過程遇到的問題與解決方案 未解決的問題/收集需求可隨時討論，有必要的話可以開討論會 設計落地方案

第四階段：反饋與落地

調研反饋

必須產(chǎn)出一份調研報告 選擇反饋形式：分享會、文檔、郵件、群通知（如果是分享會，則要有完善的PPT，會前共享出來）

技術落地

根據(jù)自己設計的落地方案得出詳細的部署文檔和使用文檔 配合運維部署

后續(xù)階段：落地后如何跟進

出現(xiàn)問題及時跟進解決，并把問題與解決方案更新到使用文檔中，如果影響較大，要在更新完使用文檔后發(fā)群通知。 相關的新人文檔/Wiki更新

文檔要求

所有調研文檔統(tǒng)一保存在部門文檔中的技術調研文檔目錄

1.部署文檔要求

這部分為了方便讓運維人員傻瓜式部署，并可以把簡單的運維工作交給運維。

盡量打包好主從節(jié)點的分發(fā)包（提前編譯好）

盡量采用傻瓜式命令

盡量寫出部署過程可能的報錯及解決方案

常用維護方案總結

2.使用文檔要求
這部分目的是方便大家使用新技術新組件。

格式包括但不限于： 場景1：示例代碼/操作 場景2：示例代碼/操作 場景3：示例代碼/操作 ...

常見錯誤及解決

遇到問題請聯(lián)系：調研人

3.調研報告要求

這部分的目的是調研時可能有遺漏的點，可以從這個列表里做參考。

開頭寫清 標題 + 調研人 + 調研時間

可以參考但不限于這些點：

xx是什么

xx的優(yōu)缺點

xx的應用場景

xx的功能/特性

xx的原理與架構簡述

相似技術橫向對比

初步評估帶來的收益

遇到的問題Q&A

xx的兼容性（支持什么不支持什么）

xx技術的核心點

xx的性能與擴展性（測試結果）

xx的部署難度

如何部署與簡單實踐

應用該技術帶來的工作量和學習成本

總結

注意事項

關注缺點的優(yōu)先級高于關注優(yōu)點的優(yōu)先級（優(yōu)點再多，也可能因為一個缺點而不能被應用）

明確場景，及時溝通需求，明確需求細節(jié) 多搜集信息，不急于出結果（搜集足夠的信息才能做出比較準確的判斷）

要從可行性，穩(wěn)定性，可維護性，工作量和學習成本等幾個重要方面考慮

合理安排時間，自己規(guī)定了Deadline，就要及時交付反饋

技術調研的模式https://zhuanlan.zhihu.com/p/61947357

技術調研的產(chǎn)出 ?

一句話概括

優(yōu)缺點分析

適用場景

比較，比較，比較

MVP最小可用產(chǎn)品

例子：low-code programming

收集相關的無代碼開發(fā)平臺，對于相關概念的介紹 。

了解無代碼編程所需要的技術相關的信息。

整理無代碼編程相關的優(yōu)缺點。

嘗試使用一些無代碼開發(fā)平臺。

結合自己的經(jīng)驗，設計一個無代碼編程的原型。

撰寫一篇相關的文章。

技術調研 主要從哪幾方面調研，技術調研，是指針對某項技術或研究領域，對技術背景、技術發(fā)展路線、技術現(xiàn)狀、研究熱點、主流研究機構等進行調查分析，為企業(yè)、研究機構的技術轉型、技術升級、申報項目、定題選題提供個性化定制調研分析報告。

第一點，調研報告的目的

第二點，調研報告的內容

第三點，調研報告的結論

例子：IM方案技術調研報告

目錄

1.編寫目的

2.調研方向

3.協(xié)議比較

4.融合通訊架構

? ? ? ? 4.1多媒體融合通訊平臺

? ? ? ? 4.2互聯(lián)網(wǎng)點擊呼叫架構

5.方案/產(chǎn)品介紹

? ? ? ? 5.1商業(yè)產(chǎn)品

????????????????IBM Lotus Domino Sametime

????????????????上海恒聚ICM

????????????????微軟Live Communications Server(LCS)

????????????????騰訊RTX

? ? ? ? 5.2開源方案

????????????????OpenFire

????????????????ejabberd

????????????????OpenSER

6.方案/產(chǎn)品比較

? ? ? ? 6.1技術比較

? ? ? ? 6.2架構比較

? ? ? ? 6.3功能比較

? ? ? ? 6.4擴展性比較

7.總結

例子：通付盾區(qū)塊鏈應用及專利技術調研報告

• 背景
• 全球區(qū)塊鏈技術與專利發(fā)展概況
• 通付盾區(qū)塊鏈保護技術與專利價值分析
• 通付盾區(qū)塊鏈專利保護格局詳解
• 通付盾區(qū)塊鏈專利技術的落地應用
• 總結

Flutter 技術調研報告

目 錄

一、Flutter是什么 1. 官方介紹 2. Flutter 與原生的性能對比

二、目前狀況

??1.大廠使用情況

??2.舉例說明

三、自身分析 1.公司目前項目 2.維護方案

四、優(yōu)勢 1.開發(fā)成本比較 2.跨平臺方案比較

五、坑

六、接入流程

七、結論

百度文庫 研發(fā)項目管理工具與模板研發(fā)項目管理工具與模板new1 - 百度文庫

研發(fā)項目技術調研報告

Apache Camel K 技術調研報告

Apache Camel K 技術調研報告_wu_weijie的博客-程序員ITS401_apache camel k - 程序員ITS401

《技術領導力》筆記（4）—— 技術調研和預研

《技術領導力》筆記（4）—— 技術調研和預研 - 別樣風景天 - 博客園

如何做好技術調研如何做好技術調研 - 簡書

1.調研內容：前言、背景、介紹、總結

2.調研內容：技術背景、產(chǎn)品簡介、功能特點、部署方案、成本和性能

3.調研內容：需求背景、產(chǎn)品簡介、本次調研目標、產(chǎn)品優(yōu)勢、產(chǎn)品目前存在的問題、產(chǎn)品調研實踐、產(chǎn)品調研結論、參考文檔

總結

以上是生活随笔為你收集整理的技术调研报告的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。