LinkedIn如何轉向開發(fā)人員工具的實時反饋？

在過去的一年中，我們一直在使用實時反饋來改進我們的工具，并為LinkedIn的開發(fā)人員提供更高效的體驗。它幫助我們將反饋參與度提高了一倍，更重要的是，可以更好地調整我們的建議和改進。

對于希望改善開發(fā)人員體驗的任何工程組織，以下問題將提供一個很好的起點：

·我們如何才能使我們的開發(fā)人員更加高效和快樂？

·作為面向內部開發(fā)人員的工具的所有者，我應該進行哪些投資以最好地幫助我的用戶？

·如果有一種方法可以在開發(fā)人員遇到問題或經驗豐富時立即獲得他們的立即反饋，該怎么辦？

通過分享我們在實時反饋實施過程中的經驗教訓，我們希望它可以幫助其他組織改進自己的流程，從而在其開發(fā)人員和工具所有者之間創(chuàng)建自然的反饋循環(huán)。

傳統(tǒng)調查的挑戰(zhàn)

在過去的幾年中，我們依靠季度的開發(fā)人員調查來聯(lián)系工程師，并就他們使用的工具征求全面的反饋。但是，我們發(fā)現(xiàn)使用這種方法遇到了許多挑戰(zhàn)：

·開發(fā)人員有時會對他們很久沒有使用的工具提出意見。在某些情況下，我們發(fā)現(xiàn)在發(fā)布調查前的6個月中，超過90％的使用特定工具的人沒有使用過該工具。

·工具所有者對所提供的反饋了解甚少。開發(fā)人員提供什么評分？他們指的是什么具體工具或行動？這使得反饋的大部分無效。

·很難衡量定期調查之間的情況。在兩次調查之間發(fā)布功能和錯誤修復時，我們無法確定用戶評級適用于“之前”狀態(tài)還是“之后”狀態(tài)。此外，在兩次調查之間，我們無法對開發(fā)人員的想法產生任何干擾。

從高層次來看，結果幫助我們了解了整個工具生態(tài)系統(tǒng)的總體看法，并使我們在工具NSAT方面取得了重大進展。但是，我們對痛點的具體內容缺乏扎實的了解，因此希望就內部用戶對他們所使用的工具的感受如何提供更準確的信息。

解決方案：實時反饋

為了克服這些挑戰(zhàn)，我們開發(fā)了一種稱為實時反饋的機制。實時反饋是一個系統(tǒng)，該系統(tǒng)首先收集有關開發(fā)人員在我們的工具生態(tài)系統(tǒng)中采取的操作的信息，然后基于此上下文信息，確定是否，何時以及如何向開發(fā)人員征求反饋。

例如，我們可能會注意到開發(fā)人員剛剛完成了部署，并且在過去的兩周內沒有要求任何工具活動提供反饋。在這種情況下，我們可以發(fā)送電子郵件以征詢有關特定部署的工具體驗的反饋。將反饋請求無縫集成到日常工作流程中，意味著開發(fā)人員無需每季度坐下來一次就依靠他們的內存，而是可以每次自動添加一點時間提示您提供反饋。

捕獲上下文

當我們向工具的開發(fā)人員提供反饋時，我們可以包含有關開發(fā)人員在提供反饋時從事的特定活動的上下文。

如上所述，定期調查的挑戰(zhàn)之一是從反饋中提取可采取行動的信息。提到“有時”的評論尤其難以理解。通過確切地知道在特定時間發(fā)生了什么并立即詢問（實時），我們傳遞的反饋將更加精確，并提供有關特定會話和使用的更多詳細信息。

為了捕獲此上下文信息，我們創(chuàng)建了一個系統(tǒng)，該系統(tǒng)通過多種渠道記錄開發(fā)人員的操作：內部Web UI（通過使用Matomo），命令行界面（CLI）和內部API（通過利用我們的內部日志記錄和審核機制，將信息發(fā)布到Apache Kafka）。

上下文捕獲是我們策略的關鍵要素，它不僅用于反饋。我們計劃將其用作新系統(tǒng)的基礎，以幫助開發(fā)人員獲得工具方面的幫助。從理論上講，如果我們能夠全面了解開發(fā)人員在尋求幫助時正在做的事情，那么提供該支持將更加容易。

參與率

對于任何調查過程，其有效性的主要因素取決于用戶群體的響應意愿。實際上，當我們過渡到實時反饋方法時，我們一直關注的一個主要問題是持續(xù)的參與率。

事實證明，就人口覆蓋率而言，使用實時招標方法比我們的傳統(tǒng)調查更為有效。我們設法使參與調查的人口增加了一倍（從定期調查的大約15％增加到采用實時方法的30％以上）。

由于參與度的提高，我們現(xiàn)在能夠對開發(fā)人員群體進行更好的市場細分。在LinkedIn，有很多開發(fā)人員，例如UX開發(fā)人員，后端開發(fā)人員，站點可靠性工程師和機器學習專家。這些不同的開發(fā)人員類型（開發(fā)人員的分組/群組）具有不同的需求，使用模式和生產力問題。更精確的定位和細分將導致更好和更個性化的工具，以滿足每種開發(fā)人員類型的特定需求。

我們也意識到不要過多地要求開發(fā)人員征服反饋，否則參與度可能會急劇下降。因此，我們實現(xiàn)了智能節(jié)流機制，以確保僅在開發(fā)人員完成其意圖時（即，它們處于流程的盡頭）才要求反饋。征集本身的重點是他們的經驗，而不是技術工具的特定工具或層。例如，我們可能會問他們整個部署過程如何，而不是僅僅使用一種工具的經歷。

我們還確保尊重關于反饋請求的偏好。開發(fā)人員可以選擇他們希望被詢問的頻率，以及希望被詢問的渠道（例如電子郵件，Web，Slack等）。我們認為，允許這種靈活性，以便將反饋的傳遞合并到每個開發(fā)人員的工作流中，也起到了增加參與度的作用。

開發(fā)人員可以選擇他們希望被詢問的頻率，以及他們想被詢問的渠道。這些渠道包括：

·電子郵件：這完全依靠電子郵件客戶端來捕獲反饋（單擊，基于mailto鏈接）。

·可插拔的UI小部件：我們開發(fā)了產品內可插拔的UI小部件，它可以服務于各種請求機制，包括被動和主動的請求機制（例如，內聯(lián)，toast通知和彈出窗口）。

·Slack：通過與即時消息集成，我們還開發(fā)了一種通過Slack收集反饋的方法。

·Web門戶：我們開發(fā)了一個Web門戶，允許開發(fā)人員以獨立體驗的形式提供反饋，并與其他用戶報告的內容進行交互（即投票，評論）。

對反饋采取行動

聆聽反饋是一個很好的起點，但是實施反饋后所發(fā)生的事情是促使我們創(chuàng)建實時反饋的動力。從各種收聽渠道收集反饋后，我們便將其合成為可共享的報告（文檔和其他產品，例如儀表板）。我們確保相關團隊根據(jù)反饋采取行動，并且當他們選擇不這樣做時，我們確保推理與提供反饋的開發(fā)人員共享。確保完成此循環(huán)對于維持健康的反饋文化非常重要，這樣反饋提供者就可以知道他們正在聽取并繼續(xù)提供有價值的輸入。

我們的“聽，行動和分享”框架

建立這兩種關系類型-向內（面向工具開發(fā)人員）和向外（向整個公司的工程師）-允許我們建立共生關系。我們將深入了解如何使開發(fā)人員提高工作效率和幸福感，并與工具開發(fā)人員進行交流以提出改進建議，以更好地幫助他們的服務對象。

從反饋中獲得的見解

我們想分享兩個我們從主觀反饋中獲得的主要見解的例子。

·我們的內部CI系統(tǒng)為預期的管道運行時間提供了估計。事實證明，這些估計有時不是很準確，但導致開發(fā)人員對所討論的工具的可靠性問題產生懷疑。

·當流量變化導致分析失敗時，我們的金絲雀部署監(jiān)視系統(tǒng)（EKG）添加了一個保護層，以確保開發(fā)人員意識到該分析是不可靠的，因為控件可能已更改了其行為。不幸的是，開發(fā)人員最終認為EKG本身不可靠，因此忽略了分析。通過獲取有關此現(xiàn)象的反饋，我們改進了系統(tǒng)，現(xiàn)在正在以更好的方式處理這種情況。

綜上所述，通過傳統(tǒng)調查了解我們以前方法的盲點有助于我們重新思考如何收集反饋。通過創(chuàng)建實時反饋，這是從開發(fā)人員那里收集反饋的全渠道上下文方式，我們已經能夠增加接收到的反饋的數(shù)量和質量，從而使我們在如何更好地支持開發(fā)人員方面獲得了更具可行性的見解。

致謝

我們要感謝Vineet Juneja，他根據(jù)以往的經驗幫助我們在這一領域提供了指導；管理團隊的Ben Lai，Awais Tariq，Narsi Nagampalli，Jeff Galdes和Jared Green；工程團隊的Naman Jain，Troy Holsapple，Sahil Patwardhan，Sunting Sun，Aaron Dai，Barry Warsaw和Max Kanat-Alexander（向Max致以特別感謝！我們的用戶體驗合作伙伴Arun Yegappan，陳寬英和凱爾·史密斯；最后是我們的數(shù)據(jù)科學合作伙伴Wu Wu。LinkedIn上的許多團隊與我們合作推出了“實時反饋”，我們感謝他們的支持。

原標題：How LinkedIn turned to real-time feedback for developer tooling