1 月 6 日，在 TOP100 全球軟體案例研究峰會上，ONES 聯合創始人兼 CTO 馮斌作了題為《大型團隊高效管理的機械化原理》的演講。
以下是馮斌當天分享的主要內容。
大型團隊的技術管理問題
我們先來看大型團隊在技術管理上面臨的問題。
首先，我們有沒有一個辦法可以低成本地做出足夠正確的決策？因為在研發場景下，特別是技術管理者，天天都需要做決策。這個決策可能是有關招聘，包括決定用哪個人，決定晉升哪位同事；也可能和功能或某個需求相關，包括是否需要選擇某個客戶，進入某個市場等。
其次，在上百人的研發團隊中，所有人的工作質量如何按照預期進行下去？在大中型團隊裡，技術管理者的下級有經理，經理下級有一線工程師，彼此存在一定的層級關係。作為最頂層的技術管理者，沒有辦法直接知道每人每天的工作情況如何。
其次，如果我們定義了一些標準，但培訓完以後，大家還沒完全理解或者執行起來的時候不習慣，這些標準怎樣才能快速落地？
最後，當我們有標準的時候，怎麼讓大家在工作的時候儘可能遵循標準，同時又不死板，有一定的靈活性？
在這裡，我要先丟擲結論：我們要基於結構化的標準和流程來做「機械化」的執行。這裡的「機械化」並非貶義，而是一箇中性詞。
結構化標準
如何進一步理解「機械化」，我們要從專家系統和結構化標準之間的區別入手。
何謂專家系統？以招聘為例，在決定是否要錄取某個研發候選人時，公司的工程師、技術負責人、HR，甚至管理層都會各抒己見，從不同的角度來表達自己的看法，看誰說服誰，最後得出一個結論——這種決策方法就叫做專家系統。
但我們發現，專家系統存在不少問題：行為經濟學的不少實踐證明，專家系統作出判斷和決策的成功率並沒有特別高，同時，專家系統經常會比較模糊，這種模糊性會讓整個團隊覺得不夠清晰，甚至可能對有些同事來說不夠公平。
相對而言，結構化標準對決策有更好的效果。
結構化量化方式，指的是我們在做決策之前，應該要先對相關事情做一些維度的分解，然後對它進行打分，通過各種手段對需要決策的物件進行量化，量化完後分高的我們可以優先選擇。
這種量化的標準更容易被執行，因為我們一旦能把這些東西量化，最後甚至可以用機器去算分。一個結果化的、清晰的標準，更能產生一個公平的效果，也能為團隊帶來安全感，而安全感能產生多團隊的驅動力。
如果我們有辦法用結構化的標準去判斷一個事物的方方面面，那麼它會更容易被我們的數字化工具落地，一旦能落地，我們就可以很方便地去做統計、分析和預判。
決策的結構化標準
既然「機械化」執行的關鍵是結構化標準，那麼，我們應該遵循哪些原則？
從技術管理的角度，結構化標準可以分成兩類，一類是關於決策的，另外一類是關於執行的。
那麼，關於決策的結構化標準是怎樣的？我們在做結構化標準的時候，會列出判斷一個事物的各個維度，例如畫成一張雷達圖，這些維度是應該要滿足的一些原則。
第一個是 MECE 法則。它強調每個維度應該是相互獨立的，不重複的，儘可能覆蓋我們想要判斷的問題。
MECE 法則，是麥肯錫諮詢顧問芭芭拉·明託在《金字塔原理》中提出的一個思考工具，意思是「相互獨立，完全窮盡」，也常被稱為「不重疊，不遺漏」。形象地看，就像是拼圖遊戲，用一張張碎片拼出完整的圖，如果拼得正確，最後一定是一張不多，一張不少。
MECE 法則是「結構化思維」的基本功。使用 MECE 法則時，要注意三點：謹記分解目的、避免層次混淆、借鑑成熟模型。
第二個是聚焦原則。我們到底如何落地一個好的標準？而這個標準為什麼能低成本地落地？這時要考慮到「聚焦」。
「聚焦」指的是，當我們判斷一個事物的時候，不要求要有非常多的維度。最關鍵的四到六個維度，一般就足以讓我們對一個事物做出一個比較準確的判斷，一旦我們求大或求全，就非常容易導致成本高、不好執行、不好培訓等問題。
在很多時候，我們定了一些結構化的標準，最後卻沒有用。回頭去看，是因為這個標準裡需要判斷的維度可能有二三十項，例如，在招聘過程中，我們可能要判斷候選人的技術能力、溝通能力、價值觀，等等，而技術能力裡面又細分出很多子類別，從計算機基礎，到他的專業的技術棧——這些繁雜的維度讓執行變得很困難。
第三個是量化原則。當我們有了維度以後還不夠，還要對每個維度進行量化，而量化就會涉及到每一個維度的打分，它的打分標準可以根據不同的情況有所區別，但是有一些方向是需要把握住的：區分度要高，要清晰，要容易衡量。
舉個反例，當我們描述某人能力的時候，有時候我們會評價為良好、優秀、卓越，等等，其實，這些詞都是「程度詞」，無論是確定標準的人，還是執行標準的人，在這裡都很難做判斷，因為這些詞非常模糊，每個人可能都有不一樣的理解。
同時，分值不應該太多，分值如果太多的話，也會導致區分度不夠高，並且大家需要思考非常多，我們一般都會採用五分制或者十分制的方式。
執行的結構化標準
說完了決策方面結構化標準的原則，我們再來看執行層面上的結構化標準是如何具體實現的。
經過 ONES 的實踐，我們發現：把相關的結構化標準在工具上數字化，那麼在實踐使用中的效率會非常高。
首先，如果我們要真正促使行為變化，就必需內化自己的整個習慣。例如，在一個軟體團隊專案管理的場景中，如果我們要標準化自己的工作方式和流程，養成習慣最好的辦法就是讓大家在一個工具裡工作，讓工具告訴大家，當需求分解完以後，下一步是什麼，將一系列的流程固化在整個系統裡面。
其次，如果大家可以在一個數字化工具裡工作，無論是做決策還是在執行流程，都可以利用工具去收集到相關的資料，並且形成一些新的結論和行動。
最後，這會是一個更公開更透明的場景，使得大家能更好地工作，因為它更有安全感。
我舉個經典的例子，讓大家可以更好地理解如何執行結構化標準。
「阿普加評分（Apgar Score）」，是麻醉學家阿普加 1953 年設計的一個判斷新生兒是否健康的模型。他一共考慮了五個指標，分別是：膚色、心率、表情反應、肌肉張力、呼吸。
第二步，打分。給每個指標設定一個整數分數區間。比如阿普加評分中每個指標可以打 0、1 或者 2 分。像膚色，全身粉紅色就是 2 分；四肢是青紫色就是 1 分；如果全身青紫就是 0 分。
第三步，計算總分。也不用加權平均了，簡單相加就行。阿普加評分的滿分是 10 分。那麼這個判斷系統規定，總分在 7 分以上就是健康；4 到 6 分就不太健康；0 到 3 分就是需要立即採取急救措施。
這是就是一種「簡單易行」的結構化標準。現在醫學界的很多診斷，比如一些癌症的篩查，都是使用類似的打分系統。這個方法把複雜的決定分解成了幾個維度上的簡單判斷。它容易操作，不怎麼受醫生經驗和水平的影響，而且因為大大減少了噪聲，準確性很高。
數字化工具內嵌標準
關於用數字化工具內嵌標準，我介紹一下 ONES 的具體做法。
在 ONES Project 裡，我們可以設定工作流引擎。就是當我們要去處理一個 bug 或需求的時候，到底走的是一個怎樣的流程。這裡我們看到有七個步驟，這七個步驟如果要人完全記下來，成本太高了。所以，我們可以通過一個資料化工具內嵌整個流程，並且在流程執行的時候用工具來提醒大家每一步需要做的事情。這樣，我們的培訓成本甚至是文件，都可以大大減少。
例如，在 ONES 新建任務時有很多自定義屬性，它是必填的，我們可以把一些任務結構化地管理起來。
關於 ONES Wiki 的功能，這裡有一個關於故障分析的模板，它比文件、比培訓更加直接。數字化工具能直接給我們提供一個預置好的標準，大家在這個標準之內去工作，快速地去完成一些必要的事情。
當標準真的可以跑起來以後，我們一定要定期覆盤，因為簡單的標準才好執行，本質上它是在簡單和有效之間做取捨，隨著時間的推移和外部環境的變化，它是會有侷限性的。
除此之外，我也分享一下 ONES 做技術招聘的模型，我們的模型會分成四個方面，第一個方面是專業能力，也就是技術能力。第二個方面是學習能力，第三個是思維表達能力，我們認為一個人的表達能力反映了他的思維能力是否結構化，是否夠清楚，是否能聚焦到目標，第四個是思維層次，主要判斷一位候選人的驅動力的來源是外部還是內部。
拿學習這個方面來講，我們會分成 0-5 六個分值，以判斷一個候選人有沒有主動的學習行為，他的主動學習行為是不是碎片化的，相對於我們剛剛說的主動、堅定、優秀、良好這些詞語來說，它更能通過一個特點、一個行為區分出不同的分值，在這個情況下，打分會更加簡單和精準。
保證決策足夠正確
最後總結一下，在大型團隊的技術管理當中，我們經常要做很多決策，同時我們要保證這些決策足夠正確。
其實我們不需要百分百正確，我們只需要足夠正確，並且讓大家在工作中可以按照一個標準來工作，保證一定的質量。
首先，機械化的標準以及流程是更有效的，執行成本是更低的。
結構化的標準和流程都應該是聚焦、清晰、簡單的。當我們有這樣的一些標準和流程以後，就可以很好地用數字化工具去做管理。
當每個人回到數字化的環境下去工作，自然就會 follow 我們之前定過的一些結構化標準，確保執行到位。同時，我們只需要在系統上點幾個按鈕，就能彙總出想要的資料，高效完成量化，這對於我們覆盤改進都非常有幫助。