11月22日，ONES 與 QECon 聯合主辦了以「效能平臺的行業趨勢與成功之路」為主題的線上直播，邀請的嘉賓分別為馮斌（Kid，ONES 聯合創始人兼 CTO）、石雪峰（京東零售技術效能通道常委）、魏昭（騰訊研發效能技術專家），DevOps 與研發效能資深技術專家張樂擔任主持人。
「效能平臺」作為研發效能「黃金三角」中的重要一角，其重要程度不言而喻。不過企業普遍不缺工具，小規模的企業可能會選用開源工具或者採購商業化效能平臺，規模相對較大的企業可能會採用自研的方式來設計和研發符合自己上下文的效率平臺。
無論是哪種方式，在數字化轉型浪潮席捲的今天，我們都會面臨重重挑戰。尤其很多企業已經走過了從 0 到 1 的工具小範圍試點的階段，那麼在 1 到 N 的規模化發展階段，如何透過平臺產生更好的效能？為了達到我們所追求的價值目標，平臺該往哪個方向發展？哪些方向值得進一步探索？
今天這場線上沙龍，我們就來看看四位老師的精彩討論和碰撞。
工具最重要的目標是讓業務成功
張樂：在降本增效的大背景下，研發效能平臺應該往哪個方向演進？我們做工具還要是想一想，往哪個方向走才能獲得更多好處。
馮斌（Kid）：數字化演進的實踐其實已經跨過第一步了，就是把很多資訊放在一個工具系統裡，並且產生一些結構化的東西。但是有了工具之後，我們就更希望從中產生一些資料，並對資料進行度量。不過隨之而來的問題是，我們到底應該要看哪些資料呢？
很多團隊容易犯的一個錯誤是，定義的指標與最終的業務價值離得很遠，最經典的笑話就是把研發效率和程式碼行數強關聯起來，這就很容易產生內卷，而且方向也不對。
從我們的經驗看，將與度量相關的最佳實踐落到平臺上是值得嘗試的方向。比如在推進工具落地的過程中肯定會遇到一個挑戰，就是在一個團隊的推行效果不錯，那怎麼讓第十個團隊也能取得同樣的效果？很重要的一點是把這些最佳實踐落地到工具裡，以便於透過平臺幫我們去做規模化的擴充套件，把好的實踐方法擴充套件到更多的團隊。
當然還會有另外的挑戰，比如如何度量效能，到底該用哪些指標。這方面我們也跟客戶反覆溝透過，首先指標一定不能是太過程的指標。衡量價值時要看最終的指標，改進時則需要更關注過程的指標。
石雪峰：我們做工具很長時間了，在我看來，從 0 到 1 再到 N 可以分為三個階段。第一個階段，工具特別重要，大家的注意力基本都聚焦在工具的建設上。
第二個階段，工具沒那麼重要。我們建了很多工具，但無論是 DevOps 還是研效，都沒有取得特別明顯的效果，大家的感知也沒有那麼真切，所以就會產生另外一個極端：是不是用錢造出來一款最好的工具，就能提高人效呢？顯然不是，很多有錢公司的人效並沒有做到業界的 Top。繼而大家就會推翻之前的結論，說工具可能不重要，我們要去做其他事情。
慢慢地就會來到第三個階段，也就是今天這個大環境，工具的重要性又凸顯出來了。這時就有一個特別有意思的話題：度量和工具哪個更重要？
度量固然很重要，但做工具的方式更重要。為什麼？因為度量的目的最終還是會落到工具上，做度量不是目的，而是為了改進工具。工具的改進，能實實在在地幫助我們一線研發提升效率和體驗滿意度。那麼在我看來，「以產品化的方式去做工具」就是未來比較明確的一個趨勢。
以產品化的方式做工具，資料就顯得尤為重要。從 0 到 1 時，大家去對齊功能，把工具做出來。從 1 到 N 時，如果再去堆砌功能，會讓工具變得臃腫，沒那麼好用。所以從 1 到 N，導向應該是資料。
資料可以從兩方面看，一是使用者的反饋、主觀感受、滿意度，二是使用者使用的資料，可以幫助我們真正去改善工具。
最後是工具要向業務靠近。做工具也好，我們作為研發人員也好，如果一直以一種成本中心的方式去做，其實很難自證效果，因為我們本身就是成本中心。無論再怎麼證明，也只能說明是大成本中心或者小成本中心，始終跳不出這個圈。
如果讓工具成為業務的夥伴，業務方等角色對於工具價值的認可度就會越來越高，也更容易落地推廣，A/B Test 就是一個很好的例子。工具最終的目標還是讓業務成功，所以跟業務走得更近也是在擴充套件工具的邊界。
魏昭：降本增效可以說是網際網路寒冬的大勢態下很多企業的共識。我個人認為降本不是目的，而是一個手段，降本的終極目標還是增效。比如透過裁員降低人力成本，短期看成本的確降低了，但從長期收益來看很可能是不值當的。所以降本，肯定不是單純地去降人力成本。
我們更應該聚焦使用者的痛點，在研發的各個流程中，解決人工化的一些痛點問題，從而實現工具化、智慧化，透過創新來破局，達到增值的效果。
像需求管理平臺、程式碼管理平臺、CI/CD，都屬於基礎平臺。除了這些平臺外，研發環節中還有哪些痛點問題需要解決？比如程式碼開發環節，大廠積累了很多程式碼，為了避免重複開發、造輪子，就需要有程式碼搜尋的工具，幫助檢索內部的程式碼，複用高質量的程式碼。
降本增效和創新這兩者並非互相沖突，如果用很傳統的降本增效的方式，我們可能永遠是在一個老的結構裡不斷迴圈，並不能帶來本質上的改變。但創新就不一樣了，創新很有可能帶來十倍甚至更高的效能提升，起到破局的作用。
相比工具的功能，流程數字化更重要
張樂：之前有篇文章很火，叫「DevOps 已死，平臺工程永生」，其中就把平臺工程作為 2023 年一個極為重要的技術趨勢。我們要怎麼理解平臺工程？平臺工程跟研發效能有什麼關係？是否有值得我們學習的地方？
馮斌（Kid）：還是要強調平臺的重要性。工具的功能很重要，不過更重要的是「流程數字化」。對於一箇中大型的團隊來說，比如說幾百人的團隊，作為技術管理者，面臨的很重要的挑戰就是怎麼保障大家在日常工作當中不犯大錯，否則會嚴重影響效率。
以前我們會強調培訓，激勵大家從底層上有不犯錯的驅動力，這沒問題，不過可能沒那麼牢靠，因為人是肯定會犯錯的。這個時候有一個很重要的手段，就是透過工具幫助我們把最佳實踐固化到工具裡。不過怎麼保證第一位同學跟第三百位同學都做到不犯大錯呢？
舉個例子，我們在為客戶服務的過程中，都會用工具平臺去做卡點，比如分支要滿足什麼樣的條件才允許被合併進去，而沒有任何別的途徑。
流程數字化有一個很重要的好處，就是可以保證大家執行完之後至少做到70分。想要做到90分，這對於團隊來說是一個成本極高的事情，但是有了這70分的基礎，之後再透過工具、激勵團隊等手段，就很有可能讓團隊往90分的狀態逼近。所以透過工具固定流程，可以幫助我們把底線定義出來，把大家的水平拉到一個水平線上。
石雪峰：平臺工程現在這麼火，或許更需要追問的是，這背後所反映的訴求是什麼？行業為什麼會對它感興趣？難道說是因為 DevOps 搞不下去了，渴望一個新的概念嗎？
對於我們做平臺或做工具的同學來說，平臺工程並不是什麼新鮮的概念，或者說它並不能給我們非常多的啟發，也不能顛覆我們以往的固有認知。從這個角度來看，平臺工程與我們的認知本質上是一脈相承的，不是多麼新的領域或概念。
不過其中的確有值得我們借鑑的地方。第一是自服務，一直以來我們做工具都追求無人化，比如在超市可以做到自助結賬。對於工具來說，無人化是好不好用的一個重要衡量標準。所以平臺工程給我的第一個啟發，就是我們做工具時應該思考「怎樣才能做得越少，而不是做得越多」。
這需要我們站在使用者的視角去做工具。比如做工具的時候切忌把自己變成上帝，使用者一提需求，我們就覺得不靠譜，甚至覺得使用者沒有理解我們高深莫測的設計思路。
第二是基礎設施即程式碼。就跟全世界的工程師都在 Github 寫作一樣，大家用的都是程式碼語言，能減少大家的溝通成本，更快地建立共識。
第三是黃金流程。比如在零售、購物的場景中有一條黃金鍊路，就是從商品詳情搜尋到下單結算的路徑，這其實就是我們的核心繫統。在平臺工程裡，可能一開始是條土路，還一堆坑。那我們可以透過工具把坑填上，把土路變成一個路徑，然後再變成高速公路，讓大家跑得更快。
不過不可能整個國家所有的路全是高速公路，高速公路只適用於那種點對點、有明確起始目標的場景，這樣一來，需要鋪裝路徑才能構成一個完整的道路體系。對於工具來說也是如此，假設未來整個研發工作都是按照標準化齊步走的方式，那麼我們可以提供一條鋪裝路徑，降低門檻，滿足更大範圍的人群需求。
所以對於我們做工具的人來說，最引以為豪的不是做的平臺怎麼樣，而是透過平臺去整合出來的這條路徑，可以幫助更多人快速交付。
效能工具如何在企業規模化落地？
張樂：效能平臺在企業落地並不是一件容易的事，尤其對於一些規模較大的企業，該怎麼讓大家接受工具？換句話說，效能工具該怎麼在企業裡規模化落地呢？
馮斌（Kid）：這是落地效能工具過程中很經典的一個問題，也是我們經常碰到的問題。首先，工具一定是解決了某些關鍵和痛點問題。那麼在推廣的過程中，我們就需要把使用過程中的關鍵問題找出來，然後去打一個「小勝仗」，這在推廣過程中是一個很關鍵的節點。
第二，戰役規模不要太大。在團隊裡我們總能找到一些人，會更有意願來主動體驗和嘗試我們的工具。如果我們能從中看到他們真實存在的問題，那麼這裡就是我們繼續改進的機會。而有了這些人的試驗，之後的大規模推廣落地相對來說就容易一些。因為大部分公司都有追求卓越的企業文化基因，當工具的的確確在某個團隊起到作用後，我想大家會開始主動了解和體驗的。
第三，工具的推廣說到底是一把手工程。從我們服務客戶的經驗來看，有些團隊推進速度特別快，雖然團隊的滿意度不能說非常高，但整體效果卻是相當不錯的。我們發現推進一個體系工具的落地，最終都是一個一把手的工程，需要團隊的 Leader 想得很清楚。「求之於勢，不責於人」，靠每個人自己去拼，可能很難規模化，所以要造一個勢能，自頂向下地推廣。
石雪峰：我們一做工具，就希望能在非常短的時間內得到規模化推廣，我覺得這麼說有點理想化，可能需要我們「降預期」。因為推廣工具本來就比較強人所難，當使用者習慣用某個工具解決問題，新的工具如果不能帶來顛覆性的提改變，就很難說服他去用新的工具。此外，即便這款工具是一個顛覆性產品，但肯定還有細節需要最佳化。
既然如此，那是不是可以藉助使用者已有的習慣去做一些改變？比如跟使用者已有的工具建立關聯。
首先可以將使用者的痛點透過場景化的方式呈現出來。從功能的視角出發來看，我們對於修復了多少 Bug、新增了多少功能，會很有成就感。但從使用者的視角看，他們對功能沒有太多概念。那麼不如透過場景化的方式去介紹工具，讓使用者知道工具可以幫助他解決什麼問題。
其次，工具是給使用者用的，不是當擺設的。所以交付工具就不僅僅是在交付工具，配套的文件、培訓、答疑，這些非技術性質的周邊內容也承擔著非常重的責任。它們相當於工具的門戶，可以為使用者提供好的指引和嚮導能力。
最後是快速反饋。大家做過工具都知道，大部分功能可能使用的頻率並不高，所以要跟使用者建立一種簡單直接的反饋機制，讓使用者能直觀地感受到工具的變化，而不是我們按照自己的節奏迭代了很多功能。
魏昭：想要落地，我覺得前提是對於工具平臺要有一個非常清晰的定位，就是說這個工具平臺是一個生命線的業務，還是一個輔助性的業務？生命線工具，就是說沒有這個工具就幹不了活，比如程式碼管理平臺。輔助性工具，就是說人力可以代替，只是效率可能沒那麼高。比如程式碼補全工具，可以幫助提效，但是沒它也行。
有了定位，就容易幫助我們找到痛點中的痛點問題，然後解決，最後帶來的收益增值也會更大。