laofo 推薦：宗綿大佬通過自己多年的工程實踐、管理實踐在組織管理、工具建設、目標對齊、績效考核、用戶故事粒度、MVP、過度設計、代碼質量等方面進行了分享。造輪子有成本為啥還不斷重復造？產品創意怎么評估驗證？質量是免費的么？字字珠璣，沒有上手實操干過的人，寫不出這么深入的文章，推薦給大家。

關于官僚主義

就我個人而言，我一直批判官僚主義。它政治、迂腐、效率差等等，我想大家也對這個概念并不陌生。直到我看到了下面這段話：

官僚主義的目標是，通過將規則應用于行政行為來確保公平。規則面前，人人平等 -- 沒有人會得到特殊優待，也沒有人會被歧視。不僅如此，規則還能很好地體現組織所積累的知識；制定規則的官僚是來自各個領域的專家，這些規則將高效的結構和流程強加于組織，同時保證公平性，消除任意性。也許，最好將官僚主義型文化理解為：比完成使命更重要的是遵循規則。

嗯，希望看完這段話大家能對官僚主義有另外一個視角的看法。顯然這段話里面也包含了一些前提條件，否則便是災難性的。它預設了兩個條件：1.制定規則的人是專家。但是我們都明白在現實中往往并非一定如此，我們的老板不一定比我們更加知道一線的細節，我們的老板不一定寫代碼就比我們厲害。往往職位越高不僅對于知識的深度有更高的要求，對于知識的廣度也要求頗深。

創業當過老板的知道，不同的職能部門都需要你來做最后的決策，而如果自己在某個職能不夠專業的時候，往往做出的決策怎么都會不夠周全，甚至是完全錯誤的一個決策。2.規則本身是公平的。我們大概都應該知道法規是最低的道德底線。規則是最低的保障，它不能面面具到的涵蓋所有場景和條件。再者，我們想利用規則來為自己行方便這顯然也不是一件非常困難的事情，特別是掌握了一定的權力時，行起方便來還是很方便的。

我說這么多，只是想表達兩點：

1. 盡管這么多年來官僚主義已經變成一個完完全全的貶義詞，但其實官僚主義也有它的作用，并沒有那么不堪，且自上而下的管理模式在目前還是被無數次證明是效率最高的一種。
2. 讓官僚主義發揮它的價值是一件很難的事情，雖然每種方法論都有它的局限性，但落地的效果其實與組織的能力更加相關。

關于工具

我們常常在提倡不要重復地造工具，顯然覺得這樣并不是非常經濟的行為。但是為什么會有人需要（是的，我說的是需要）重復地造工具呢？

我一直在說工具的背后是隱含了一種方法論，工具開發者希望通過自己的工具來解決某一個或者多個問題。TA 首先想到了解決某個解決問題的方法，然后開發出相應的工具。針對同一個問題，不同的人對于解決它的思路是不同的，從 A 地到 B 地，人們生產了不同的工具（或服務）：汽車、火車、單車、地鐵等。對于工具的使用，不同的人也有不同的需求，比如可以選擇自己開車、騎單車、打車、坐地鐵等等，于是面對同一個問題，不同的的解決思路衍生出不同的工具。

作為一個工具，它面對要解決的問題有一定的針對性，它無法完全覆蓋不同團隊的管理模式，不同團隊的現實狀態。它不妨是一個好的工具，但是對于某些團隊來說引入成本過高，所在團隊為了解決特定的問題需要自己制作一個相對更低成本的工具來解決遇到的問題。即便一個工具大部分的功能可以被復用，但是當使用方需要對一些功能做出調整或者添加新功能時，會面臨在需求優先級的沖突，對于使用方來說是高優先級需要解決的需求，在工具研發團隊來說可能只是一個特別小的需求，而無法馬上去實現功能上的支撐，這個時候使用方需要面對兩個選擇：1.自己學習工具源碼然后自己實現；2.自己做一個新工具來滿足自己的需要。嗯，還有一個情況是：使用方的需求與工具研發團隊的思路是相違背的，而被工具研發團隊拒絕實現。

【注：復用也是需要成本的 1）發現成本 2）使用成本 3）改動成本 4）等待支持成本】

目標與績效

關于 OKR

OKR 提出來并被大家知曉已經有不少年頭了，但是真正能把這套方法論很好落地的案例少之又少。在我接觸的大多數人中，都把 OKR 當作一種績效管理方法來看待。重要的事情說三遍：OKR 不是績效方法，是目標對齊方法。OKR 不是績效方法，是目標對齊方法。OKR 不是績效方法，是目標對齊方法。而且 Google 也沒有廢棄 OKR，他們變更的績效管理方法。

簡單地講，OKR 就是 CEO 定了一個目標“今年公司的利潤率要增長 20%”。這個時候不同的部門再各自按照各自的崗位來確定自己的目標和工作內容。比如對于 人力部門來說：他們可以招聘能力更好的員工，也可以淘汰掉更多不合格的員工。對于市場部門來說：他們可以提高 ROI、減少營銷成本，也可以加大市場推廣力度來增加銷售額。對于研發部門來說：他們可以研發更多產品市場，也可以優化研發流程降低成本。出發點在于每個部門都比 CEO 更加接近一線，他們更加知道所在崗位的問題、所在領域的發展情況，因此應該比起 CEO 來決定他們應該做什么，他們自己決定自己如何完成既定目標更加可靠、接地氣。

而現實的狀況是，OKR這套方法對員工的能力有了更高的要求，需要有更好的主觀能動性，要更加善于思考，更加全面的能力要求。在目前大部分的螺絲釘管理模式下，他們已經被馴化成一個聽話的員工，領導喊我做什么我就做什么，做完就收工。他們不被允許有過多自己的自主操作空間，他們的工作計劃、工作內容已經被上層管理者詳細思考和拆解，他們不需要過多思考，只需要按照計劃和安排的工作內容按部就班完成好自己的工作就可以了。推行 OKR 方法將會徹底的改變他們的思維方式和工作方式，基層員工們舉步艱難，他們無法做出正確的行動來完成目標，這種改變帶來的無形阻力讓 OKR 的落地變得異常的艱難，推行失敗自然也不足為奇了。

關于績效考核

很多年前，有幸參與為一個百人研發團隊制定績效考核制度，并最后以失敗告終。作為人類我們是復雜多樣的，且對于同一個人來說，TA 也無時不在變化（嗯，我不用成長這個詞，因為有時候是走下坡的）之中。

當時在制定制度的時候，我就知道需要考慮到不同崗位，不同人之間的細微區別。另外也希望能改變績效考核一直是領導主觀評估這樣一個現狀，應該是可以做到客觀量化的。我先是按照不同崗位列出不同的技能點，然后不同的技能點分出不同的能力掌握程度，且具體的定義不同掌握程度的衡量標準（其實并不能完全量化，有些也是主觀的衡量，比如對 JAVA 的掌握程度，不可能去考核每個知識點，而且有些知識點實際工作根本用不上）。這份崗位技能標準也是一份崗位晉升的指引，一套成長體系，只要掌握了其中某些技能到達某個程度就能升職為某個崗位。每個崗位會有不同的 Excel 表格，先下發給全員研發各自填寫評估當前自己的技能程度，做摸底調查，作為年末績效評估的基線。

這套制度很細致，于是它就很復雜，評估成本很高，如果不細致它就無法覆蓋現實中的各種個性化的差異。它深深地陷入了各種自身的矛盾中。另外，它只是衡量了技能，沒有衡量產出，要衡量產出就需要再引入一套復雜指標。它會朝著一個越來越可笑的方向發展。

足夠的主觀是一種偏激，足夠的客觀也是一種偏激。人的主觀感受也是一種指標，是否善于合作，是否善于溝通等等都應該被列入考核的范圍內。但是這種主觀的感受并不能被量化度量。兩個有相反性格差異的人無法順利地合作，但并不表示這兩人是不善于合作和溝通的。

好了，這個事情做不下去。既然做不到，讓各位負責人自己決定就好了，說不好聽叫甩鍋，說得好聽就是充分信任向下授權了。績效這個事情總會有人不滿意的。

順便說一下，沒事不要折騰績效。對于基層員工來說，他們的第一反應是，老板又要一套規則來剝削我們了。調整績效規則會帶來不小的風波，而搞不好就是激起民憤，這個時候，公司想不倒也挺難的，不傷點元氣都對不起它這個名字。所以沒事別折騰，本來大家還好好干活，一折騰大家都沒心思好好干活了，然后還有一波要離職的。各位老板好好想想自己折騰績效到底為了啥。

關于故事

故事（需求，以下統稱故事）是流程最開始的一環，它的質量直接影響后繼環節的質量。大多數情況下，我們都更應該回到故事環節來思考，是否我們在做故事評估、故事拆分、故事演進等環節中是否可以進行優化調整，從而解決后繼流程中遇到的問題。

MVP

 

MVP 最小可用性產品，大家對這個概念應該都不陌生。但是誰又能說自己合理的定義了一個 MVP 呢？每個人對這個概念都要有一些自己的理解和看法。在不同的場景下需要驗證的需求各不相同。即便在相同的場景下，也有不同的需求需要驗證。還記得上面提到的從 A 點到 B 點嗎？單車、火車、油車、電車的 MVP 定義是各不相同的，且無法斷言哪種方法就是有效驗證。

有些團隊資源更加豐富一些，他們會用用戶調研來驗證自己的需求假設，但是被調研的人群種類、數量是否能夠足夠充分地驗證假設呢？比如：向男士詢問什么衛生巾更好用；向80歲老奶奶詢問哪個口紅顏色更好用；向低收入的年輕女生詢問對名牌包包的需求；向不去肉菜市場的人詢問是否需要改善市場環境等等。向 1000 個人中的 100人進行了調查取樣來證明另外的 900 個人也有同樣的需求，看起來也是不太可靠的。發生幸存者偏差的可能性是很大的。

創意無法預先評估，只能被市場驗證

一個新的創意或者業務需求被提出的時候，我們如何才能衡量這是否是一個好的創意和需求，而不至于浪費后繼更多研發、市場推廣等等的成本呢？我們要如何掐住成本的喉嚨？反正我自己是不夠聰明能夠想出好的度量方法，更多的是自己自以為是的主觀感受，一種不知道從哪里來的自信。

作為最終的用戶大概他們也不知道需要的是什么，當詢問他們是否需要一臺帶觸摸屏的手機時，答案可能是否定的，但是你把 IPhone 給他們看的時候，他們眼睛會發光。而這樣帶來的驗證成本是極高的，起碼你要做多幾臺樣機出來給用戶看看。更接近現實的狀況是大多時候用戶的反饋是負面的，像iPhone這樣出圈的產品在這個世界上并不經常發生。

于是，業務敏捷是該出現的時候了，為了降本增效，需要讓創意更加快速的推向市場，業務部門也需要敏捷起來。關于業務敏捷我沒有更多可說的（主要是不懂），只是告訴大家有這么個概念。它好像還不太出名，因為我偶爾才能從別人那里聽到這個名字。

故事粒度

一輛汽車和一輛單車的制造成本是不同的，在定義故事的時候，我們需要充分考慮故事粒度，以便讓它更快的速度完成研發推向市場。我經常遇到覺得研發速度慢，一個功能要做很長的周期才可以推向市場的抱怨。作為直男研發人員，我們的直覺是去堆人、優化研發流程，很少去思考如何在需求的角度解決這個問題。當一個故事被確定下來之后，它的工作量基本就確定了，所以在一開始確定故事時，就應該考慮它的實現成本，避免需要使用過多的工作量才能推向市場。我們更應該拆分過大的故事，通過不同的迭代周期控制大故事的上市周期。這樣也可以更快地收到市場反饋來調整故事。

順便說下，我不是說堆人、優化研發流程不重要，只是想說明故事的粒度相對更加容易能夠直接控制推向市場的時間。

過度設計

過度設計這個事情很微妙，非常的見仁見智。過度設計顯然是一種成本的浪費。但想要不過度設計，需要有一個合理預見事情未來發展的能力。我們設先假設我們某個功能的服務的會有較大的用戶群體和訪問量，于是我們在設計中通過加入緩存等等的技術手段來提高系統性能。我們也會預設下個版本需要增加的新功能，而預埋一些在當時看起來合理的設計。但是現實是可能這個功能上線只有少的可憐的訪問量、可能下個迭代我們調整了產品方向而導致之前預埋的設計并沒有發揮作用，于是之前做的準備工作就變成了過度設計，但是能完全說之前的預估在事情發生的當下是不合理的嘛？我想也不能這么說吧。這也許就是所謂的成功之后，說什么都是對的吧。

代碼質量

我相信大家都認可質量本身的重要性，但在實際的研發活動中，我們常常迫于業務功能的完成截止時間而對質量有所取舍。編寫單元測試、性能測試、重構等等質量活動在截止日期面前都顯得不那么重要了，我相信這個便是大多數團隊中的現實狀況。我們常聽到的是下個迭代再補上，而下個迭代其實時間也是很緊迫的，根本沒有時間來完成這些非業務需求。而同樣的大家也都在吐槽自己項目中的各種質量問題，并且對此束手無策。

首先我們自己就是項目成員，項目代碼就是我們自己寫出來的，那么第一個要問的就應該是問問自己，為啥自己寫出來的代碼質量過一段時間回過頭來看的時候，質量并沒有那么高？其實自己就是那個制造質量問題的罪魁禍首。我想我們首先需要承認的就是自己的技術能力有待提升，并且在這個認識之后努力付諸實踐的提升自己的代碼能力。

我承認比較好的質量是有成本的。就我自己的開發經驗來說，寫面條代碼是最一氣呵成的方式，而且它可以正常的運行，但是當我需要考慮設計模式的時候，需要按照邏輯拆分方法的時候，需要符合Linter 規則的時候，確實需要停下來想想如何處理更好，寫代碼的速度的確會有降低。但是經過一定時間的練習之后，這個速度是會有不少提升的，并且寫出來的代碼質量要更好的。當然，這需要老板們能扛得住截止時間的壓力，允許生產力在某段時間的下降來讓團隊去做更多的練習，而這個某段時間的范圍根據不同團隊的具體情況而有不同，這與學習能力有關，可能很短也可能很長，還有可能失敗。

說質量不能免俗的總要提提單元測試，寫單元測試比上面寫相對高質量的業務代碼其實難度更大一些。我們在說單元測試最大的價值在于在修改被測試代碼之后，可以通過運行單元測試來檢測修改后的邏輯是否正確，是否影響了原有的代碼邏輯。但是在現實的案例中，我們經常會因為需要去 Mock 被測試方法依賴的邏輯， 而導致單元測試過度的描述了被測試代碼的邏輯，于是導致單元測試用例無法被直接復用，我們修改為被測試代碼之后，做得更多的是修改測試用例來讓讓這個測試可以通過。其實這樣已經違背了測試用例存在的意義，反而成倍地增加了維護代碼的成本。我想說的不是測試用例做不到讓系統更可靠，而是想說其實寫出合格的單元測試是一種不小的挑戰，它需要更多的思考和練習才能達到的。

資本的角度

我想大家心里都明白，真正產生利潤的是業務部門，研發部門是成本中心，并不直接產生利潤。現實狀態下誰賺錢誰是老大，誰賺得越多話語權就越大，于是研發部門往往活得也憋屈，想推行一些新東西新方法，做出一點改變的時候，得不到業務部門的支持也只能作罷。站在業務側來說，讓新功能上線，滿足客戶需求幫公司賺取更多收入才是最重要的事情，要用 10 塊錢的投入賺取 100 塊錢的回報。而系統的穩定性跟性能只要在一個合理的范圍就可以，并不需要精益求精，因為終端客戶并不需要，他們需要的是一個可以正常運行的產品就已經足夠了，而不是一個高性能的產品，他們也不會為更好的穩定性跟更好的性能多付一分錢。

在客戶角度來說，仿佛穩定性和高性能并不需要付出任何一點成本而是本身就是理所當然的最低產品標準。對于研發團隊來說，無法證明提高了 1 秒的響應速度到底給公司帶來多少利潤，甚至可能因為引入了其他中間件而導致花費了更多成本。

在大部分情況下，一個產品的生命周期并沒有足夠長到需要為質量買單的時候，很多時候一個產品的瓶頸不在它的質量，而在于它的市場規模遠遠沒有想象中的那么大，因為錯誤的預估市場、用戶需求而胎死腹中的產品遠遠比因為質量不過關而失敗的產品多得太多了。所以我認可在產品的初期階段，是允許產品的質量大不了預期標準的，這個時候把產品快熟推向市場獲得反饋來得更加重要得多得多。當然，在驗證了有效需求和用戶規模之后，對于質量的要求應該嚴格地提上日程，并要還上之前欠下的質量債務。

另外，在業務能夠賺到足夠利潤的時候，其實相對低效的研發效能和高昂的成本并不是一個首要的問題，更甚者的是這可能是一個業務上天然的壁壘，意味著競爭對手大概率也要付出等額或更多的成本。在利潤可觀的情況下，往往浪費會變成一種默許，用于彰顯自己的實力。只有當市場不景氣，追求更高的利潤率時，研發效能才會被擺上臺面，成為公司活下來的救命稻草。但到了這個時候也就為時已晚了。

最后

有人提醒我，這仿佛是在用一種紙上談兵的方式討論如何不紙上談兵，之后，我深深地陷入了這個駁論中。我努力地讓這篇內容更多描述現實之中的細節，但也因為自己本身認知的局限、世界的復雜而無法完全一一認識和描述。就像開頭說的，時至今日我們對于官僚主義也并沒有一個很完整的認知，同樣的道理，這篇內容的觀點不一定對 （更可笑的可能是以上的這些只是我自己不知道而已，且我以為很多人都不知道。），且當它被寫出來的時候已經過時，作為作者的我無法也不能實時的向大家更正我的觀點和認知。但也希望這個內容能夠帶來一些啟發和思考。

最后的最后，希望我們能夠跨越現實與理想的鴻溝，一起構建那個我們理想中的世界。好運。

感謝點贊、轉載，關注我，了解最新研發效能發展動向，歡迎進入「DevOps研發效能群」一起探討