GitHub 憑藉其獨特的全球影響力，對開發人員的體驗產生了重大影響。 那麼，GitHub 如何衡量開發人員的效率呢？我們採訪了 GitHub 高階工程總監 Akshaya Aradhya，了解她的團隊如何提高科技公司的開發效率。
翻譯自 GitHub 開發人員每天 300 億條訊息的生產力，作者 Jennifer Riggins 是一名記者、作家，也是活動和播客的主持人，這些活動和播客講述了技術文化的故事，幫助分享文化和技術碰撞的故事，並解釋了我們正在構建的技術的影響。 她去過那裡。 如果 85% 的軟體工程師使用 GitHub，那麼 GitHub 的開發者體驗就變成了提高開發者生產力的套娃。 作為世界上最大的儲存庫，Copilot，乙個六個月大的 AI 結對程式設計師，有 142 億 GitHub 使用者，這使其具有影響全球開發人員體驗的獨特能力。 這種規模也使事情複雜化。 GitHub 有 99 個9% 的服務級別協議，為近 4 億個儲存庫中的使用者提供服務。 這使得世界上最大的軟體開發平台每天支援令人難以置信的 400 億條訊息——是的，確實是數百億條。 隨著我們繼續釋放開發人員的生產力，The New Stack 採訪了 GitHub 高階工程總監 Akshaya Aradhya，了解她的團隊如何提高 GitHub 整個公司的生產力——這反過來又應該會提高絕大多數技術組織的生產力。 她的團隊是 GitHub 基礎設施和平台工程組織的一部分，為整個公司提供橫向支援，包括應用程式團隊。
*搜尋。 github actions
copilot
GitHub Next 研發團隊。
與 Azure 雲的未來合作。
該平台團隊由近 300 名 GitHub 員工組成，其中約三分之一由 Aradhya 領導。 平台團隊還與另乙個主要的橫向實體（安全團隊）密切合作，完成他們所做的一切。
她的組織（以前稱為資料服務）負責她所謂的傳統資料相關問題，包括資料管道、操作的資料方面和訊息佇列。
我們有 Hydra 和 Aqueduct，它們每天處理數十億條訊息——大約 300 億條訊息，“她解釋道，”如果將開發者生態系統放在首位，這個數字甚至更高。 她的團隊約有 120 人，還解決了 GitHub 的所有內部和外部資料儲存問題（物件儲存、冷儲存、Blob 儲存）以及資料模式、下一代可擴充套件性問題、生產力問題等。 Aradhya 告訴 The New Stack，她的團隊專注於：“我們如何真正傾聽開發人員的意見，然後與我們自己的應用程式交談，用我們自己的資料進行測試，習，然後提出乙個產品？”
然後，當然，他們會衡量一切以持續改進。
您如何提高開發人員的效率和生產力，同時確保無縫部署，最大限度地提高解釋的便利性，並自動化人們喜歡的內容，尤其是在不同時區執行分布式團隊時這一切都讓 Aradhya 的團隊著迷，因為他們高度全球化的開發團隊能夠克服最令人沮喪的瓶頸。 “為什麼我需要等到德國和阿姆斯特丹的人們醒來？我被卡住了。 ”
由於 GitHub 在疫情之前就已經是一家遠端優先的公司，因此其數千名工程師成為了出色的第一批客戶，並不斷獲得反饋**，例如入職人員。 “當你進入軟體行業時，你會被告知，'哦，xyz是團隊領導'或'這是高階工程師，如果你不明白，就問他們。 然後是找到那個人的等待時間，為了知識轉移而向你解釋，如果你想再次提出問題，就會因為忘記內容而帶來的尷尬。 這對任何人來說都是尷尬的，尤其是新手，但對許多人來說簡直是不寬容的，Aradhya說。
有很多神經多樣性社群會說，'這是我的執行功能技能的問題。 我希望我不會因此而受到評判。 ’”
有了這些反饋——可能來自 30% 的自我認同為神經多樣性的 GitHub 員工的個人經歷——該團隊構建了乙個功能，其中 Copilot 的聊天功能（想象一下 Clippy，但更強大）將在你選擇乙個細分時解釋它是如何工作的。
適用於任何 ID。 無論你在做什麼。 您的副駕駛會建議方法並告訴您它是如何工作的。 例如，她解釋說，確保你不會從不同的類中寫錯方法名稱。 這有助於提高開發人員的信心，同時提高編寫速度並減少引入錯誤的可能性。
這項針對內部開發人員反饋的創新是 Copilot 採用超出所有預期的部分原因，自去年 6 月首次公開發布以來，美國約有 92% 的 GitHub 使用者使用它。 這也是 GitHub 作為第一批客戶和測試人員對一切採取全面方法的結果。
在我們向 GA 推送任何東西之前——即使是任何 alpha 版本、beta 版本——我們都希望確保它已為開發人員做好準備。 她說。 這反映在 GitHub 的價值觀中，這些價值觀都圍繞著促進協作和歸屬感，這是由持續反饋驅動的。 “當我們合作時，我們總是會問一些與生產力相關的問題，比如：你認為人工智慧對你的開發者體驗有什麼影響？我們使用這些資訊將其與企業的想法聯絡起來。 我們如何幫助企業公司（無論是蘋果、沃爾瑪、特斯拉還是谷歌）了解和支援工程團隊？”
像我們討論過的許多其他組織一樣，開發人員生產力的很多反饋都是通過開發人員調查收集的。
當我們談論開發人員體驗時，人們傾向於將其與產品或體驗（如 UI）聯絡起來。 但遠不止於此。 阿拉迪亞解釋道。 “從數學上講，它是開發人員的生產力加上開發人員的影響以及開發人員的滿意度。 如果將所有這些加起來並乘以指數，則開發人員體驗就是所有這些因素的總和，甚至更多。 GitHub 的研究團隊隨後發布了內部部落格，在早期，他們的 DevEx 見解參與了產品與市場的契合度討論和執行會議。
GitHub 研究一致認為，早期的痛點之一是等待測試完成或構建結束——Aradhya 稱之為等待協作的死亡：“你如何與人交談或理解每個人在做什麼？您如何自動化審查？如何加快構建速度？你如何處理錯誤？”
這就是人工智慧發揮作用的地方。 事實上，雖然許多人吹噓個人開發人員的生產力、更快的事件響應速度和更少的錯誤，但 2023 年 GitHub Octoverse 報告最令人驚訝的結果之一，該報告每年對所有擁有 GitHub 帳戶的人進行調查，發現 81% 的受訪者預計 AI 將增加基於團隊的協作。
這與內部調查相呼應，GitHub 的開發人員要求對他們的協作進行更多衡量——因為你無法改進你無法衡量的東西。 但是，如何衡量人與人之間的互動呢？Aradhya 表示，這遠遠超出了 Slack、Jira、拉取請求和文件等基本要求。 在開發人員生產力的世界中，這種對協作改進因素的檢查考慮了同步和非同步通訊的廣度。 他們可以從這些工具和訊息佇列中得出重要的定量指標。 她的團隊還專注於可發現性的平台工程目標：
你怎麼知道如何發現一些東西？
你如何衡量兩個人或兩個團隊之間的資訊流？
您是否在處理正確的問題？
你參加正確的會議了嗎？
您能否保護達到開發人員流程狀態的時間？
在這家遠端優先的公司中，個人有很大的責任去了解他們的最佳工作方式，並能夠自我組織他們集中的時間。 GitHub 擁有更高比例的神經多樣性團隊成員也就不足為奇了，因為這是一種非常包容的工作方式。 GitHub 還為所有員工提供無意識的偏見、特權和盟友培訓。 GitHub 的協作指標有意包括多樣性、公平性、包容性和歸屬感。 像大多數科技公司一樣，Aradhya 提到，他們在指導其他技術領域的女性和代表性不足的人群方面存在問題。
我們在指導、贊助和導師與學員關係方面面臨挑戰。 她說。 不僅在建立正式的指導計畫方面，而且“我們還存在乙個問題，即人們認為他們是他人的導師，但他們沒有為被指導者增加足夠的價值，或者被指導者沒有意識到他們可以指導他們。 “這種負面經歷不成比例地影響了那些來自代表性不足群體的人。
為了回應這些反饋，他們建立了乙個更正式的指導流程和培訓。
龐大的Octoverse報告只是對許多內部和外部資料的年度調查**。 雖然團隊能夠獲得定性指標，例如眾所周知的 DORA 核心四指標，但在任何開發人員生產力工程旅程中，通常都會結合定量和定性調查，包括 Space 框架和 DevEx 指標。 Aradhya說，GitHub的研發部門每週都會快速測試概念驗證，並得到幾乎即時的反饋。 平台和基礎架構團隊每隔幾周到每季度都會進行一次不同的開發人員體驗調查。 她向我保證，這不會是乙個沒有人願意回答的三頁調查，而是更短的調查和更高的回覆率的結合。
並非一切都需要調查。 她繼續說道。 例如，產品團隊不斷從客戶對話中採取行動，並在活動期間快速提供評級系統反饋。
我甚至記得在一次工程領導會議上，我在午休時間排隊等候食品卡車，有人看到我的 github 夾克，他們說，'你是做什麼的？我說我們支援 XYZ 和 Copilot。 我一說，他們就開始向我詢問功能，“她回憶道，”到食品卡車生產線結束時，我已經收到了 18 個不同產品的不同想法，我們可以增強或改進這些想法，“她立即將它們反饋給他們各自的產品團隊。
GitHub 是一家以反饋為導向的公司。 Aradhya 說，衡量開發人員的生產力和開發人員體驗是執行會議中乙個持續的話題。 在 GitHub 上，這些生產力指標包括：
需要多長時間才能獲得使用者反饋？
非同步通訊是什麼樣子的？
您可以在不開會或中斷的情況下不間斷地工作多長時間？
您花了多少時間構建新問題的解決方案？
你花了多少時間編寫或修復錯誤？
您遇到安全或漏洞問題的頻率如何？
在新產品發布或更新期間，您花了多少時間進行自我提公升？花多少時間指導和改進他人？
您花了多少時間編寫自動化測試？
您多久切換一次上下文？
您的工作效率如何？
她解釋說，許多較小的內部指標都與較大的指標相關聯。 例如，當 Aradhya 還是一名工程師時，她意識到在短期內自己執行生產測試會更快，但從長遠來看，不編寫可重複的自動化測試會浪費時間。 自動執行重複性任務是開發人員生產力工程的乙個重要目標。
她和她的團隊負責人一起說，“我評估了某些事情所涉及的人類接觸點的數量。 衡量開發人員可以花在創新上解決獨特問題的時間也很重要，她說這對於留住人才至關重要。 “這是關於設計新穎的指標——新穎的通訊、新的 API，以應對所有最新問題。 基本上，您是否有 10 倍的心態，您是否了解客戶的問題以及您想使用什麼方法來解決問題？”
這些是 Aradhya 所說的“非常規開發人員生產力”的東西，她的團隊正在努力尋找解決方案。 GitHub 使用這些指標來培養 10 倍的開發人員思維方式，她將其定義為“具有遠見和技術能力的開發人員，可以預測他們在短期和長期內可能遇到的問題，並且從擴充套件使用者群的角度思考，超越產品定義的界限或工程主管定義的界限。 ”
對規模的考慮對 Copilot 的成功至關重要，因為他們預計它開始時可能會有 1500 萬使用者，但很快就發現它大約是 115 億將是乙個更接近的估計——到那時考慮可用性、可靠性和安全性為時已晚。
GitHub 發布的任何內容都必須是可擴充套件的。
乙個 10 倍的開發人員可以預見到這一點，然後提供備份，提供 b 部分，幫助制定技術策略，以便我們了解未知的未知。 然後找到一種根據消費者需求進行擴充套件的方法，而不會讓質量下降。 阿拉迪亞說。
總的來說，在擁有GitHub的Microsoft，她說任何人都有機會成為10倍的開發人員，無論級別如何，都會帶來非凡的思維，並強調公司文化和協作。 她舉了乙個這樣的例子：“你是如何擴大你周圍的團隊的？你如何影響他們？您是否以積極的方式改變了您的團隊或公司文化？”
當然，GitHub 關注的開發人員生產力指標的另乙個領域是工具，例如查詢以下問題的答案：
擁有完全配置的環境意味著什麼？
在該平台環境之上構建有多容易？
GitHub 還收集了大量自動化反饋，並一直在尋找收緊反饋迴圈的方法，從驗證和合規性檢查到幫助開發人員了解他們工作效率最低的地方，尤其是將客戶反饋傳達給開發人員以確保他們納入功能請求。
所有這些都是通過正在進行的匿名和認證調查、問題、拉取請求等來衡量的。
如果你用調查淹沒人們，他們就會停止回答，所以我們要在這裡發揮創意，“她說，”我們還會研究我們自己的分析和內部執行的渠道。 ”
所有這些結果都會傳達給組織的其他部門，並解釋：
您在 x 上花費的時間百分比。 我們用 y 改進了它。 然後再次徵求反饋意見。 她解釋說，任何人都可以在內部看到這些資訊，世界各地的所有工程師都可以。