量化評估程式設計師貢獻,「逸碼科技Merico」由小切口改造開發部門與開源社群
人才成本不斷攀升,其中技術崗職位的招聘、培訓成本尤其高。如何判斷一個程式設計師優秀與否、貢獻多少?
一個比較直接的判斷標準是由效果出發,看這位程式設計師參加了些什麼專案,如果專案本身極具商業價值,那麼參與者是有乾貨的大牛的概率也更高。但以商業價值為導向的判斷標準存在以下痛點:
-
使用場景受限,只適用於評估商業公司的開發人員,不適用學校課程中的小組作業、非盈利開源專案等專案中的表現評估。
-
評估的是團體貢獻,難以精確到個人。由於大部分專案是由多人共同完成,對專案整體進行評估難以追根溯源到個人。這種精細度不足的衡量標準容易助長free ride風起盛行。
為了展現個人的工作貢獻,程式設計師們也常常會在簡歷和個人網站中附上程式碼託管平臺連結,從程式碼本身出發建立更為根本的衡量標準。但目前在GitHub等平臺,程式設計師們的個人開發貢獻常常被過度簡化為兩個指標:提交次數NOC與程式碼行數LOC。這兩個指標的痛點也非常明顯——側重於程式碼數量而非其本身的價值,顯然是不夠合理 。
36氪近期接觸的「逸碼科技Merico」 由是一家提供程式設計師貢獻量化模型的公司。基於程式分析和機器學習技術,Merico對程式設計師的程式碼貢獻進行測量 ,得出專案級、元件級和提交級的貢獻度、貢獻分佈和貢獻排名等指標,綜合反映程式設計師在開發活動中的表現。
貢獻度的分析維度可分為結構化價值 (即程式碼在結構本身中體現的價值,如被其他函式呼叫)及非結構化價值 (即程式碼對程式整體的貢獻度,如修復重要bug、修改演算法提升效能等)兩部分。其中,後者並不直接反映在程式碼中,因此衡量過程更類似於人類判斷,對智慧化的要求更高。早先Merico通過程式設計師提交程式碼的日誌來建立模型,但提交日誌由程式設計師本人撰寫,主觀性較強、精確度不足。所以目前Merico的方法是更多地回到程式碼本身,在抽象語法樹層面理解程式碼的模式,並根據不同模式分配貢獻度權重。
產品形態上,客戶只需要將託管程式碼庫的連結提交給Merico的系統,其模型即可自動量化評估每位成員的貢獻度。這套系統目前支援私有化部署及雲端部署。
目前,Merico貢獻度衡量模型主要有兩個落地場景:
-
商業公司開發團隊:程式設計師貢獻度的量化指標一方面給部門負責人和HR提供人事安排上的決策建議,為科學管理提供透明的全域性資料支援;另一方面,貢獻值及團隊排名以每週一次的頻率及時反饋給程式設計師個人,幫助他們建立準確的自我評估,找到技能提升的方向,提高工作效率。
-
開源社群:開源社群不具備公司層級結構,所以以層級為基礎的薪酬分配方案並不適用,專案所產生的價值難以合理分配給所有參與共同開發與維護的社群成員。收益分配的不合理、付出與回報的不匹配耗費著程式設計師們的開發熱情,也不利於開源模式的持續發展(可參見前端框架vue.js的作者對這一問題的討論 )。基於貢獻度測量,Merico引入“智力股權”概念,形成覆蓋更多開源社群成員、更加公平的分配方案。當專案獲得贊助或捐贈時,成員們便能夠按照股份比例獲得收益。
目前來看,無論是結構更嚴明的公司內部還是更鬆散自由的開源社群,這套模型的落地還更多是工作團隊的內部管理。 而從更長遠的視角來看,這套模型的潛在應用還可向前延伸至招聘考核和人才智慧匹配 ,評估程式設計師的能力水平及專長領域;更進一步還可以作為程式設計教育機構的技術提供商,共同服務C端 ,使基於合作專案開發的程式設計培 訓的效果更透明直觀,及時給予C端反饋。隨著業務的延伸,B、C兩端同步拓客也有助於加強Merico的品牌影響力,獲取更多使用者信任,彙集更大規模資料量,提高模型信效度,形成閉環。 創始人任晶磊表示, 一個合理的貢獻量化模型將幫助程式設計師群體重回價值導向,創造出更有意義的工作 。
Merico成立於去年十月,在過去幾個月內與Uber、騰訊某開源組及多家初創公司達成試用意向,正在共同測試調整模型,並於上週上線了1.0版本,未來預期按照程式設計師數量*市場薪資的1%來進行定價。
公司創始團隊來自微軟亞洲研究院、加州大學伯克利分校和斯坦福大學,團隊遍佈中美歐多個國家,公司在創立之初獲得Polychain Capital 及 OSS Capital 的天使輪投資,金額為110萬美元,前者是一家專注區塊鏈領域的風投機構,而後者是第一家專投開源軟體公司的基金。