在之前的話題上繼續衍生：技術管理進階——利益分配機制
從管理的角度來看，人是個變數，是不可管理的，因為不可管理所以很難評估。
所以，管人不如管事，評估人不如評估事。
管人，事結束了，人會給自己找事，後面事情多了，資源耗散也多了，公司關注的事反而沒結果；管事，用事把人聚集到一起，便可有效減少目標偏移。
一、熵增
團隊大了後會產生很多“維護成本”，維護成本一般由幾部分組成：
1）之前十分重要的業務，迭代減緩，但依舊有很重的地位，需要持續維護；
2）之前不慍不火的業務，停止迭代（業務死了），其中參與人員無事可做，卻又因為一些因素（如架構調整、leader離職）沒有得到妥善安排；
3）......
這裡涉及到一個著名理論：
熵增：在一個孤立系統裡，如果沒有外力做功，其總混亂度（即熵）會不斷增大
我們常常再說一句話：
發展可以解決多數矛盾或者增長可以解決多數問題，這裡的點是外力足夠讓系統保持有序，但發展（增長）放緩，外力不足時，內部矛盾便會變多。
這裡再舉個例子，古代打仗如果沒有紀律和機制保障（隊長死了有人兜底，兜底的死了還有人兜底，直到兜底到最後一人），很容易出現逃兵。
具體到我們實際工作中，一個公司存在了很多年後，一年的人力成本是10億！而公司高層有印象的費用估計就1/10。並就這1億的印象都很模糊，只有大框架，沒有細節，輸入輸出也不標準，慢慢就形成了上面亂拍KPI，下面向上管理的情況。而其他9億的花銷更是摸不著門檻。
公司管理複雜度提高，邊際效益遞減，無效的人事物增加，組織臃腫......
公司會對9億成本花銷肉痛，迫切的想要改變這一切，這是造成裁員的根本原因：
成本優化是很多公司（甚至這些公司並不缺錢！）一直在做的事情。
這裡的重要標誌就是限制HC、限制成本，對於不缺錢的公司似乎很奇怪。
這是因為公司大盤有一筆賬，他識別到整體的業務資源投入是完全夠的（比如各團隊多給10%資源用以解決衝突問題），但實際情況卻是各個團隊依舊在鬧缺人缺資源，那麼公司就會認為我們所付出的【維護成本】與【解決衝突成本】過高，公司會認為當下自身【結構出了問題】。
而事實上多餘的人事物所造成的【資源浪費】和【效率降低】甚至最終引起【死海效應】是公司絕對不能接受的，所以成本優化會是一個永久的話題，這裡優化的不是成本，而是緩解系統性問題的一種手段。
綜上所述，公司會有很多冗餘的人事物，但是人是有主動性的，如果公司沒有分配重要的事項，他們會自發的找一些事做，而這些事對於公司來說多半是沒有意義的！
公司的裁員要解決以上問題，但是這些人如何找出來，這些事如何辨別，這很難，一旦裁員錯誤，會引起更嚴重的後果。
二、利益分配機制
前文所述，老闆提出了一個策略：
這裡有一筆費用（資源），那麼首先應該盤清楚他會被用到幾個地方；如果這個資源（錢）沒被用到自己想要的地方，那麼就要調整他的比例；比例調整的時候要慢慢替換，用新的結構替換老的結構，太快容易拉著蛋；最終拿到最優的分配比例。
具體到實際案例：
1）老闆開始識別冗餘，發現產研線一個月ROI較低；
2）老闆約談產、研負責人，要求做成本優化以及結構調整；
3）產研leader私下商量，少裁點，畢竟那麼多老舊業務要維護；
4）老闆不買單，要求首先將總成本減少某個比例，其次將現有資源投入做重新佈局；
這裡舉個例子，之前是有70%的人在維持老舊業務，30%用於新業務探索，老闆認為老舊業務投入太大沒有未來，於是希望把比例先調成5:5，然後在新體系開闢後逐漸改成4:6乃至3:7。
這裡產研leader的問題是會被歷史包袱束縛，並且這種歷史包袱反而是其安身立命的根本，是之前各種考核指標重點考核項，是KPI量化的體現。所以單靠產研leader自己努力，很難跳出框架處理這個問題，老闆的策略也很簡單，直接調整投入比例，幫產研leader卸下了包袱。
這個案例再細化，老舊業務維護資源40%中，到底有哪些業務，這些業務依舊有一個比例，要再細分；創新事項、新體系建立事項也是可以窮舉的，那麼這60%的資源又該如何投入？
以這種利益分配思維思考下去後，會引發以下結果：
1）一些老舊業務不得不放棄；
2）創新會更有重點，不會想要大而全；
3）在不停的調整比例過程中會達成一個動態平衡，確實有一些老舊業務無論如何都必須存在，那麼這個就會變成基建或者公共項；
4）在系統穩定後開始第二輪迭代；
規整一下老闆的思路：
1）識別冗餘；
2）格局梳理，識別利益分配者；
3）利益比例調整，結構替代法；
4）找到資源分配出去的方法，即如何將資源給到你想給的人事物；
5）確定穩態比例，並開始再迭代；
以上是之前的大思路，在公司級落地過程中卻發現了很多問題：
1）缺少理論基礎，畢竟是沒有驗證過的猜想；
2）上有政策，下有對策，實際執行緩慢；
3）很多事情沒有評價標準，冗餘難以識別；
4）......
三、OKR——為機制匹配落地工具
機制執行不下去往往是環境有問題，或者沒有匹配的“機制”，畢竟大框架由管人、管部門，演變成由專案管人，是個很大的跨度。這個時候OKR是一個很好的工具，從本質來說，OKR與否其實不關鍵，資源可控，目標實現才是重點，只不過OKR正好契合。
首先，總辦會做至上而下的戰略宣導，提出自己的OKR，甚至做命題作文形成公司的重點專案；
其次，各部門會形成自己的OKR，這些OKR都會通過總辦的Review（整改、優化）形成部門的重點專案；
這裡會形成兩套機制保障：公司戰略輸出形成的專案，一定會緊扣公司方向，不太容易出錯；部門OKR經過審批後的專案會有基本的兜底保障；
公司、部門級重點專案各自捲入一批人，能解一部分資源的“有效性”。
為了激勵更多人蔘與到專案中，可以會對每個專案進行基本定價，參與後可以拿到相關的獎勵，這裡會遵循一個基本邏輯：
事前預支，事中監控，事後評估，事成結算。
除此之外，我們的工作其實可以窮舉：
1）日常事項；
專案的日常運營事項，或者線上事故處理，或者專案某個節點準備，或者獎勵配置上傳，或者競品調研；
2）日常管理；
週會、日會、扯皮會....還可以細分為：
做戰略、做計劃->人才招聘、梯隊建設->戰略匹配的資源協調->做輔導->做機制匹配戰略落地。
3）日常耗損；
比如公司級專案立項前的討論成本；
比如部門級專案設計失敗導致的返工都屬於日常耗損。
所以，一個人的時間會被分到這些“事項”中：
1）公司級專案；
2）部門級重點專案；
3）日常運營事項；
4）日常管理；
5）日常耗損；
每個人會把自己的時間片分到不同的事項中，而彙總起來就形成了部門的資源投入彙總，這個時候再引入前面的利益分配機制：
如果日常類事項佔比過高，肯定是有問題的，這裡不同部門（行政、財務會更偏向於日常運營事項）的比例會有所不同的。
比例的改變，應該由機制引導，比如我們就想在公司級專案多投入，便會將考評與公司級專案做掛鉤，公司級專案就那麼多，各個部門會爭相參與，從而緩解部門牆帶來的問題。
這裡有一點要注意，這裡的事項分類，是面向公司的大類，拉近到具體的部門，比如研發部門，由於他們的特殊訴求，需要把一些成本歸集到業務部門，會進一步細分，但大類就以上五類，如果有超出的，就要迭代基本機制。
四、問題與展望
這套機制問題依舊很多，需要持續迭代：
1）這套機制想要量化每個人的投入，並且規則複雜，初期會為每個部門帶來了大量工作量，推行不易；
2）人天生是不想被測量的，加之指標引導性可能導致大量失真資料，這樣拿到的資料顆粒度會很粗；
3）專案具有很強的週期性問題，這也給測算帶來了很大的困難；
4）並不是參與了專案就是有效的輸出，比如我在專案中摸魚，專案負責人對我十分不滿，專案負責人的評價會很重要，但這同時又加大了專案負責人的管理成本，可謂雙刃劍；
綜上，這裡的問題總結下來就是，拿到的資料會不準確並且推行難度不小，但就算粗粒度的資料也並非一無是處，比如：
1）我可以知道一個專案的投入是什麼，對應人力甚至可以換算成錢；
2）我可以知道一個人一個週期內的投入是什麼；
3）我可以知道一個部門的資源成本是什麼；
到一定階段，我可以知公司級專案用了公司多少資源，部門級用了多少，莫名其妙的事情用了多少，我在裁員的時候可以有所依舊了......
後續文章會提供案例佐證。