如何作好技術調研

你們好，我是光源。

近日一直在思考一個問題，到底怎樣作纔算是完整且優秀得完成一次技術調研。

我曾經以實習生的身份作過糟糕或讓老大稱讚的技術調研；也以正式員工的身份獨自負責過技術調研工做（意味着不用向誰彙報，直接進項目）；也以導師身份分配技術調研工做給新人，看着幾個新人經歷着我以前的遭遇，他中有完成得漂漂亮亮的，也有完成得不夠好的；最後也旁觀過優秀的同事作過技術調研。

教技術的書籍不少，可是教作事的書籍不多——即便有也不會教那麼細。我曾因這類工做而彷徨、受挫，如今又看着新人彷徨、受挫，因而就有了想法嘗試總結一個範式出來。

所以下文會從我的的一些出發作一些總結和思考，與各位讀者分享。固然做爲追尋最佳實踐的我而言，更歡迎能互相討論以完善個人觀點。因能力有限，若是有不妥或者補充的地方，還請聯繫我（微信公衆號：guangyuan_coder），十分期待與你的交流。

1、瞭解需求

除去本身發起的技術調研，其餘技術調研都須要先了解需求。估計不少人看到這個就會心想，切，這個誰都知道啊。

是的，「瞭解需求」這是我的盡皆知且每一個人在技術調研前都會去作的一件事。但不誇張地說，在這個階段栽跟頭的人最多。

不少人，特別是新人，在這個階段出問題的廣泛緣由大概有如下幾點：

• 做爲新人畏畏縮縮，擔憂一開始問太多會顯得本身很無知，擔憂對方輕視本身
• 聽到幾個關鍵字就覺得了解需求，沒有在乎對方說的一些細節
• 對需求有疑惑的狀況下硬着頭皮作，缺少溝通意識
• 沒有分階段跟需求方溝通，可能在快完成了發現需求理解錯誤要推倒重作

諸如此類。

解決方案也很簡單，我們把問題一一解決。

首先是接到需求時，認真聽對方講，對對方所講內容有疑惑的是能夠在對方講完後提問的。千萬不要聽的時候是懂非懂，想着待會私底下本身查（固然提問也要有技巧，這個本身琢磨去）。

而後假如不瞭解的東西太多（例如一上來就給新人分配一個陌生業務模塊的任務，的確會一臉懵逼），又不想圍着需求方各類打擾，徹底能夠請教下熟悉相應模塊的同事嘛。

最後，假如是複雜的需求，能夠在作的過程當中，分步跟需求方確認，這個下文會展開。

這裏舉個例子：

一天，小明正熱火朝天地寫着代碼，忽然肩膀被人一拍，回頭一看老大正站在背後。

小明，這有個調研工做你去作一下？

沒問題，具體是作什麼呢？

是這樣，咱們須要作一個 A 功能以支撐 B 模塊，這塊功能 iOS 端已經完成，能夠與他們討論下。

好的，沒問題。

因而小明屁顛屁顛開始調研 A 功能是怎麼實現，耗費了幾天時間後，老大過來一看，誒，你這實現不是我想要的呀。

原來雖然小明選取的技術方案是業界知名的 A 功能實現方案，但卻無法用到 B 模塊上。並且需求隱含的意思是，既然 iOS 端已經實現了，需求的具體狀況能夠去詢問 iOS 端對應開發。

2、進行調研

在作好需求瞭解的前提下，調研自己會顯得輕鬆點。

須要注意的是，進行調研時要合理安排時間，調研過程每每伴隨着對新知的探索，很容易「沉迷於學習」。別忘了這是一項工做。（固然不僅是技術調研在平常工做中也同樣，要學會合理安排時間，注意時間成本）

我的有個小技巧，按照如下步驟來作每每效果不錯：

1. 儘可能多得收集各類方案和資料
2. 迅速粗略得過一遍，大致上總結出幾種可能合適的方案
3. 針對幾種方案，一邊分別調研每種方案，一邊作筆記
4. 最後拿着筆記作最後的橫向對比
5. 得出結論，同時由於作了筆記，反饋的素材也有了

以上是關於「如何作」的。須要說明的是這只是個人我的習慣，你有本身的作事風格更好，不必強行一致。

還有一點須要注意的是，千萬不要埋頭苦幹。

「溝通」應該是貫穿始終的一件事，在上文也提到了，對需求的理解誤差可能會致使整個調研工做推倒重來。

那麼該如何溝通，以及溝通些什麼呢？

第一個問題，如何溝通。個人方案是，階段性得去跟需求方或者跟有經驗的同事討論。好比一個技術調研有四個階段，那每完成一個小階段，就能夠嘗試去溝通一次（必須強調下，規則是死的人是活的。假如對方很忙的狀況下，你偏要強行打擾對方去溝通；或者一個很小的技術調研你也按階段屢次去溝通，就尷尬了）。

第二個問題，溝通的內容，我認爲主要有如下幾點：

• 對需求的細節的分別確認
• 將本身的工做進度彙報給對方（這點很重要，一方面是讓對方知道你在作什麼及完成到哪一個階段，另外一方面是假如你路走偏了，對方能及時知道並糾正）
• 將本身當前的工做成果告知對方

作到以上幾點，應該就差很少了。下面說說第三階段，結果驗收。

3、反饋

作完技術調研後，必定要有成果。

能夠是調研以後發現「某個方案是最佳的」，也能夠調研以後發現「尚無解決方案」，還能夠調研後對需求自己提出質疑，但必定不能作着作着無聲無息得作沒了（不是全部技術調研都有需求方催促或跟進）。

反饋的展示形式根據需求來，有幾種常見的展示形式：

• 假如是比較大的技術調研能夠作一些分享的能夠用 PPT 的形式展示出來。好比有同事調研 「兼容 Android 6.0 權限管理」，用一個 PPT 將技術方案的選擇、6.0 權限管理的原理、最終方案的選取等分享出來就特別好
• 假如是簡單的技術調研能夠以文檔的形式展示，推薦用 markdown 來寫，github/gitlab 能夠直接展現，很方便
• 再簡單點則是以郵件或口頭的形式反饋

我的比較推薦以文檔的形式，大部分調研工做都很適合。

反饋的內容有幾點是須要考慮寫進去的：

• 簡要說明下調研需求
• 介紹下跟需求相關的前置知識
• 目前有哪些方案，具體分析下各個方案的優缺點及適合的場景
• 技術調研的結果是怎樣，不可行的話是由於什麼，可行的話說說最終決定使用何種方案（本身沒法決定的話能夠弄個分享討論會），並說說該方案跟其餘方案比有何優點
• 假如是新庫的引進，須要簡要介紹下該庫的使用及內部原理
• 調研過程當中碰到了哪些問題，如何解決
• 另外，假如時間容許，能夠考慮把反饋當成分享來作，系統介紹下相關的知識——這個比較適合 PPT 的形式

大概是這些，總而言之，把一次技術調研當成一次絕佳的學習機會來作，那反饋的內容就不會顯得空洞。

反饋的時機的話，在保證質量的前提下，儘可能主動、提早向需求方或組內其餘同事提出。一方面是你的反饋對別人而言也是一個學習機會，另外一方面主動推送一件事也是一個優秀的表現。

寫在最後

以上是一點我的淺見，必需要說明的一點是，本人能力有限見識淺薄，上文的一些觀點不必定正確。各位看官切不可太過信賴，仍是要有本身的思考爲妙。

另外，寫到最後，發現跟「技術調研」中的「技術」倒關聯不大了，哈哈。我也就不糾結這個了。

最後，我寫博客的目的就是但願將我的的觀點、觀念擺出來讓讀者評價或吐槽，所以假如以爲有不妥或者可優化的地方，還請不吝賜教。