當業務複雜到一定階段的時候，效率問題會首當其沖，基本解法是化整為零、分賽道，對應的産物可以是子公司、事業部、業務單元、項目組。
好處是目标聚焦、問題也會聚焦；工作内容閉環，團隊人數可控，協作、試錯成本都會很低；但是不可避免的會有很多問題：
1）重合區域
2）三不管區域
初期重合、三不管區域占比小于2%，團隊總有願意「吃虧」的同學，倒也不成問題。
随着團隊規模擴大，業務複雜度加劇，重合、三不管區域占比大于一定數值，比如10%的時候，加之專業領域沖突，文化沖突，陣營沖突，這種區域所造成的效率影響可能是「成倍增長的」
DDD可以解決科學分組的問題，中台要扮演「垃圾桶」協調解決重合與三不管問題，但是「漏網之屎」必不可少。
管理者嘛，無非一天「拉偏架」協調大家解決這些問題，再決策由誰「吃虧」（權責利模型）去解決。
這裡就出了「第一個問題」，誰去吃虧？
誰背這個鍋？
某天，測試環境有個BUG，前端可以寫代碼解決，于是後端認為是前端的問題；後端也可以寫代碼解決，于是前端認為是後端的問題，這是一個有趣的「評價模型」：
誰能解決或者說誰最終的解決了這個問題，誰就變成了這個鍋的擁有者
兩個同學一步不讓，10分鐘代碼的事，扯了一個小時，甚至後端同學已經把前端的代碼寫出來，貼在了群裡，讓前端同學發上去即可，可謂侮辱性極強。
前端同學氣不過就是不上傳代碼，讓後端同學自己去上傳，于是10分鐘的事情兩個人拉扯了一天...
一些同學可能會認為他們「小肚雞腸」，于是馬上更新場景！
線上有一「嚴重事故」，A團隊的同學能解決，B團隊的同學也能解決，但是現在「觸發點」在A團隊，線上頁面「影響面」卻在B團隊。
于是10分鐘的事情，兩個團隊6個人扯了半天，都怕這次事故算到自己頭上...
在這個時候你會不會「小肚雞腸」呢？
這種事沒有絕對對錯，也沒有道理可講的，往往都是看誰「拳頭硬」（勢能高、影響力足），如果你看到有個「傻子」在那裡大放厥詞，可能有三個原因：
1）他在維護自己「較真」的人設，順便增加點自己的團隊「活躍度」屬性；
2）他在以講道理的方式「叫冤」，就算輸了也要找補下，因為以後的這類「髒活」是不是都要自己接？
3）這是個「真傻子」......
屁股決定腦袋，對站在某個立場的leader或者同學來說，當然是正确的。但是站在全局來說又很有問題，因為「10分鐘的事情變成了一天」啊！
這還隻是技術團隊層面的事情，擴大到産研團隊、事業部之間，這類分而治之所導緻的效率問題，「不可謂不大」
以上問題已經很令人頭疼了，但你以為就結束了嗎？
維護成本
公司大了後，無效資源消耗增多已經很讓人頭疼了，但是真實情況這裡還會多出很多「維護成本」
這種維護成本一般由幾部分組成：
1）之前十分重要的業務，疊代減緩，但依舊有很重的地位，需要持續維護；
2）之前不愠不火的業務，直接停止疊代，其中參與人員無事可做，卻又因為一些因素（如架構調整、leader離職）沒有得到妥善安排；
3）之前死掉的業務......
類似于這種業務以及之前的部分參與者，都會變成所謂的「維護成本」，這包括一些之前的「有功之臣」，處理起來比較麻煩了。
這種比例一大整體成本馬上就變高了，接下來就會定期出現成本優化，HC當機事項。
成本優化是很多公司一直在做的事情，甚至這些公司并不缺錢！。
這裡的重要标志就是「限制HC」、限制成本，對于不缺錢的公司似乎很奇怪。
這是因為公司大盤有一筆賬，他識别到整體的業務資源投入是完全夠的，比如各團隊多給10%資源用以解決沖突問題，但實際情況卻是各個團隊依舊在鬧缺人缺資源，那麼公司就會認為我們所付出的「維護成本」與「解決沖突成本」過高，公司會認為當下自身「結構出了問題」。
而事實上多餘的人事物所造成的資源浪費和「效率降低」甚至最終引起「死海效應」是公司絕對不能接受的，是以成本優化會是一個永久的話題，這裡優化的不是成本，而是「緩解系統性問題」的一種手段。
話雖然好聽，那麼備援成本「如何識别」呢？
團隊一旦大了，如何判斷哪個團隊該投入多少人，各個團隊leader是否會因為「本位主義」而有「善意謊言」，于是這個時候就會出現所謂的「公司級效率團隊」。
但真要細究，這裡有幾個問題：
1）這種識别備援團隊的「效率團隊」本身就是備援；
2）效率團隊多數情況隻能算老闆的傳聲筒，未必能深入業務、深入團隊，是以多數時候能做的有限；
3）效率團隊是建立在良好資料收集的前提下的，如果各個業務方初期項目資料收集工作都沒做，也沒辦法統計；
是以，公司級的成本優化、效率提升，需要良好的頂層設計，否則成本識别可能成為一筆死賬，效率團隊在左右橫跳中陷入消亡。
如何解決這種效率問題，是我們今天要探讨的...
熵增
上述的問題到底是什麼呢？一個實體熱詞能可解釋——「熵增」：
熵增：在一個孤立系統裡，如果沒有外力做功，其總混亂度（即熵）會不斷增大
管理的動作就是為了對抗熵增。
我認為管理是激發團隊小夥伴執行力的行為，借鑒更專業的描述：
如果你想創造一個能夠維持一定秩序、不會分解的系統，那麼這個系統必然是一個開放系統，就需要為他注入能力，并讓其在系統中流動以維持這種秩序。
管理動作就是為團隊注入能量，能量停止系統就會開始退化，這種持續為組織注入能量的行為、有效的熵減動作，正是上司力的核心。
有兩個核心點可以防止熵增：
1）不斷的能量輸入；
之前工作中常常聽到一句話「流量紅利時代已經結束」，後續的存量流量争奪可能會有很多公司被埋葬！
這句話背後表達的是在流量自然增長的時代，很多很普通的産品也能有不錯的增速，而當增量變得困難的時候，内部問題便會暴露，逐漸走向衰亡。
增長可以解決很多問題，創新是最好的增長手段，但未必會引起熵減，甚至會加速熵增！
2）開放系統，熵減；
大俠武功再高，也要放下包袱，背上背着共患難的媳婦，懷裡抱着紅顔知己，面對真正的強敵時，也不免進退失據。
對于公司來說，腐敗的員工、落後的制度是必須清理的。
這裡再舉個例子，古代打仗如果沒有紀律和機制保障,隊長死了有人兜底，兜底的死了還有人兜底，直到兜底到最後一人，很容易出現逃兵。
具體到我們實際工作中，一個公司存在了很多年後，一年的人力成本是10億。
而公司高層有印象的費用估計就1/10。
并就這1億的印象都很模糊，隻有大架構，沒有細節，輸入輸出也不标準，慢慢就形成了上面亂拍KPI，下面向上管理的情況。
公司管理複雜度提高，邊際效益遞減，無效的人事物增加，組織臃腫......
嗯？之前的華為貌似就遇到了這個問題
二十年前的華為
1998年9月20日， IBM顧問向任正非闡述了對華為管理問題的十大診斷：
一、缺乏準确、前瞻的客戶需求關注，反複做無用功，浪費資源，造成高成本；
二、沒有跨部門的結構化流程，各部門都有自己的流程，但部門流程之間是靠人工銜接，運作過程被割裂；
三、組織上存在本位主義，部門牆高聳，各自為政，造成内耗；
四、專業技能不足，作業不規範；
五、依賴個人英雄，而且這些英雄難以複制；
六、項目計劃無效且實施混亂，無變更控制，版本泛濫
……
其實華為的問題總結下來就兩個事：
1）規模擴張引起的管理掌控力下降、「跨部門協作」難度指數級上升；
2）專業瓶頸導緻的難度；
兩個因素制約了團隊創新。
一些解法
金山的解法是先做朋友、再做事業，隻有關系很好的朋友，和關系一般的朋友；
阿裡的解法是大中台、小前台；
華為的解法就牛逼了：
一套完善的項目管理辦法、績效管理機制，事無巨細全部定義......
這套東西怕要值不少錢，對于小一點的公司可能不太适用，那麼中小型公司應該怎麼辦呢？
利益配置設定機制
問題是什麼？
再次回到最初，問題到底是什麼？
Case 1，職能線比例
大概在兩年多以前，B站的leader在設計團隊招聘的時候，會宏觀強調職能比例，比如前後終端有一定比例要求，否則容易出現某個端成為瓶頸的現象：
我們遵照這個比例去做事，也确實沒有出現過某個端出現瓶頸的問題，除非突然某個端大批量離職。
這裡的點是将資源，分給了不同的職能線，偶爾也會微調不同職能線資源占比，隻要不出問題，那麼就會形成一個區間，比如：
我們發現前後端的比例在3:7和5:5之間都不會出現什麼問題，那麼在某個特别需要後端建設的時候，便會盡量壓縮到3:7。
需要知道底線在哪裡，可操作空間在哪裡，确定這個比例後，便形成了宏觀的「機制兜底」，也是「最外層」的兜底。
然後才是具體到前端團隊的招聘中進階:中級:初級的比例問題，這個會形成「第二層兜底」，有了這幾層兜底，便不容易出現端口上的瓶頸。
這裡需要注意的一個點是，比例一定要不斷微調驗證，一旦發現團隊因比例減少出現問題的時候，就要開始回調。
Case 2，家庭收入配比
在某一段時間裡，我的家庭關系處理的很糟糕，現在回想起來，除了最初主動作死之外，最大的沖突點來自于跟老婆結婚後，由二人世界變成了兩個家庭，而在家庭利益配置設定這個事情上總是達不成一緻。
女人總是幫娘家的嘛，男人雖說會更顧全大局一點，但對自己原生的家庭依舊會有所偏移，于是就容易出現各為各家，雞飛蛋打的結果。
後來生了個娃，大家更多的把精力投入到了自己的小家庭，一些沖突也就自然而然化解了...
這裡的點是什麼呢？
有一筆資源，是花在我家，還是我老婆家，整個應該有一個比例，舉個例子：
男方父母:女方父母:小家庭 = 2:3:5，大家都不開心；
于是調整為3:3:4，雙方父母倒是開心，但是我們夫妻不大開心；
最後生一個娃後比例變成了1:1:8，于是我們自己的家庭和諧了；
雙方父母卻有所怨言，當變成1.5:1.5:7的時候，似乎進入了一個穩态。
有了這個模型後，我們再觀察下目前教育行業的改革，國家醫療的投入，教育的投入，似乎慢慢能看懂一些東西了...
底層邏輯
上述Case中隻是調整了一些數字，問題卻消失了！
問題為什麼消失，有沒有「更宏觀」的視角？
再次回到裁員的話題，單單一個裁員就會有幾個視角：
1）一線員工：公司是不是沒錢了；
2）leader視野：又瞎搞，我的XX重構做不了了；
3）大leader視野：團隊可能确實已經産生備援了，要進行成本優化，接下來需要聚焦，但是那些由于人力短缺做不了的項目怎麼辦呢？
4）老闆視野：同樣一筆錢，是要用于維護老舊業務還是要用于創新，這是一個問題，但相關的投入比例必須開始調整；
是以這裡最宏觀的視角是：
這裡有一筆費用（資源），那麼首先應該盤清楚他會被用到幾個地方；
如果這個資源（錢）沒被用到自己想要的地方，那麼就要調整他的比例；
比例調整的時候要慢慢替換，用新的結構替換老的結構，太快容易拉着蛋；
最終拿到最優的配置設定比例。
具體到實際案例：
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都會通過總辦的Review（整改、優化）形成部門的重點項目；
使用OKR是因為每個項目都會有明确的驗收标準與時間，這會讓很多事項變得「相對可控」
這裡會形成兩套機制保障：
- 公司戰略輸出形成的項目，一定會緊扣公司方向，不太容易出錯；
- 部門OKR經過審批後的項目會有基本的兜底保障；
公司、部門級重點項目各自卷入一批人，能解一部分資源的「有效性」
為了激勵更多人參與到項目中，會有配套的獎懲措施。這裡會遵循一個基本邏輯：
事前預支，事中監控，事後評估，事成結算。
最後，我們開始盤點事項：
每個人會把自己的時間片分到不同的事項中，而彙總起來就形成了部門的資源投入彙總，這個時候再引入前面的利益配置設定機制：
如果日常類事項占比過高，肯定是有問題的，這裡不同部門如行政、财務會更偏向于日常營運事項的比例會有所不同的。
比例的改變，應該由「機制引導」，比如我們就想在公司級項目多投入，便會将考核與公司級項目做挂鈎，公司級項目就那麼多，各個部門會争相參與，進而緩解部門牆帶來的問題。
注意，沒有獎懲挂鈎的機制，就是無根之水
這裡有一點要注意，這裡的事項分類，是面向公司的大類，拉近到具體的部門，比如研發部門，由于他們的特殊訴求，需要把一些成本歸集到業務部門，會進一步細分，但大類就以上四類，如果有超出的，就要疊代基本機制。
一些問題
這套機制問題很多，需要持續疊代：
1）這套機制想要量化每個人的投入，并且規則複雜，初期會為每個部門帶來了大量工作量，推行不易；
2）人天生是不想被測量的，加之名額引導性可能導緻大量「失真資料」，這樣拿到的資料「顆粒度會很粗」；
3）項目具有很強的周期性問題，這也給測算帶來了很大的困難；
4）并不是參與了項目就是有效的輸出，比如我在項目中摸魚，項目負責人對我十分不滿，項目負責人的評價會很重要，但這同時又加大了項目負責人的「管理成本」，可謂「雙刃劍」；
綜上，這裡的問題總結下來就是，拿到的資料會「不準确」并且「推行難度不小」，但就算粗粒度的資料也「并非一無是處」，比如：
1）我可以知道一個項目的投入是什麼，對應人力甚至可以換算成錢；
2）我可以知道一個人一個周期内的投入是什麼；
3）我可以知道一個部門的資源成本是什麼；
到一定階段，我可以知公司級項目用了公司多少資源，部門級用了多少，莫名其妙的事情用了多少，我在調整的時候可以有所依舊了......
是以問題又來了，怎麼做，你TM告訴我怎麼做？
一分鐘日報
一到怎麼做，輪到誰都不好使了...
在網上找了很多資料，類似這類問題實操類的文章偏少，或者根本找不到，是以第一個問題是怎麼做！
從知行合一的角度我們肯定要處理到底，于是這邊設計了一個系統《CEO駕駛艙》去解決這些問題，也拿到了初步結果，這裡順便「把一些代碼放給大家」算了：
關注公衆号（葉小钗）：
關注公衆号後回複：一分鐘日報，擷取源碼。
示範位址：https://yexiaochai.github.io/60s_report/
回到上述問題，這裡要解決的是：
1）現在的資源用到了什麼地方？
2）我所關注的事項用了多少資源，是否足夠？
問題很清晰，我需要知道每個人都做了什麼，而這個知道每個人都做了什麼本身就是一個很難的事情！！！
怎麼知道每個人做了什麼？
這裡的方案很簡單，人作為最小單元模型，讓每個人「寫日報即可」。但這裡馬上會遇到第二個問題：
寫你妹的日報！
寫日報是反人性的，如果花費每個人的成本過高，這個事情會被各大leader聯合抵制，還沒開始就得結束，是以這個日報必須要被限制到1分鐘以内，最好是30S，于是形成了《一分鐘日報》的設計思路：
這裡先是對我們的工作内容做了窮舉，其次讓大家做選擇題，最終實作的效果是做選擇題，大家可以自己體驗：
https://yexiaochai.github.io/60s_report
這裡基本功能設計完了，馬上就迎來了第三個問題，基本功能開發完了如何推呢？
如何實施？
各位如果以後要推廣一個系統或者落地一個機制，一定要先做一個事：
打造案例！在你最有話語權的地方打造成功案例。
我在産研話語權很大，系統完成第二天就直接在産研團隊使用，要求所有人必須填，由此線上打磨體驗，邊修BUG邊優化體驗，并且拿到了第一波資料，于是可以處理第四個問題了：
如何進一步推廣？
有了小案例後就不要閉門造車了，該去找「投資人」了。
于是直接拿着目前案例去找CEO，也從他那裡拿到了正回報，CEO：這個東西真是個天才設計！！！這是繼續做下去的基礎。
接下來也不必着急全公司推，先看看情況，并且繼續打磨産品，畢竟從開發到上線到試用到CEO彙報一共才3周呢！
現在要做的是控制節奏，鼓勵項目組同學加班加點完成新子產品開發，并且不斷的優化體驗，想下周要拿什麼東西給CEO以便擷取更多的支援。
而好的東西是能說話的，過程中CEO已經把這個工具介紹給了其他部門：小钗那邊有個管理的好東西，你們都應該去了解下。
于是控制權已經不完全在你手裡了，要注意節奏，「控制節奏」這裡要做的是去除阻礙，千萬不要在「大面積推廣過程中被勸退」，是以這裡的問題是：
如何去除阻礙？
1）馬上籌備教育訓練材料；
2）馬上籌備宣傳圖冊以及宣傳海報，比如：
3）來個更有沖擊力的大屏，直接在公司播放！
于是，這個至下而上的産物演進為至上而下，拿到了紅頭檔案：
後面就是順理成章的事情，隻需要不停的優化營運......那麼到此就結束了嗎？
CEO駕駛艙的四個版本
很遺憾，一分鐘日報僅僅是CEO駕駛艙的1/4，他隻是開始！CEO駕駛艙的設計是：
《CEO駕駛艙》是一套效能解決方案，是公司數字化轉型、精細化營運的開始。
他對公司的幫助是：有一個工具能提供「依據」以「驗證」哪個地方「效能有問題」，并且提供一定「手段」去「降低」這些「損耗」産生的機率。
他的四個版本是：
「1.0 一分鐘日報」
将公司資源用到什麼地方能看清楚，并且有一些宏觀調控的能力；
「2.0 項目工作台」
主要目的是将所有項目收歸起來，每個項目不能随意立項，可以保證資源不被浪費；每個項目必須有驗收标準（甚至多個驗收标準），這樣會在一定階段防止爛尾（畢竟，有追責成本）；
「3.0 打破部門牆」
以項目虛拟貨币而成的“市場經濟”，以“宏觀經濟”加“市場經濟”促進跨部門協作（虛拟貨币+獎懲引導）；
「4.0 資料有意義」
人才天梯榜、部門天梯榜，項目ROI以及業務ROI測算模型與展示（精算+風控）；
一些效果比較敏感，随便截點圖：
那麼，系統開發結束就完了嗎？
這才是一個開始呢......
系統與機制
在某種程度上說，有機制就可以了，機制可以保證很多問題得到根本解決，這裡想要表達的點是：
所有的數字化轉型都需要比對的機制與流程輔助，甚至系統隻是機制的輔助！
但系統可以加速這一切的發生，也可以加強體系的穩定性，是不可或缺的重要組成部分。
是以，系統完成後，還需要産出：
1）備援預警政策以預警哪裡出現了備援；
2）項目月會政策以滾動跟蹤項目形成閉環；
除此之外的宣傳案例、獎懲政策、彙報模闆、會議設定等等全部必須比對！！！
每一個子產品的推行，都需要重複一分鐘日報的所有行為，甚至更難，其中一個環節出問題甚至會導緻所有前期努力白費......
這裡以項目月度報告舉例，他可能是這樣的：
機制要求：每個月月底，各部門需要寫一份項目月報；
月報内容：上報本部門最重要的三個項目（或者三件事），并且簡單描述項目（事件）進展；
項目結項：如果部門本月有結項的項目，會安排彙報并做評級，而後記錄在案，随後也會有專門的項目結項表彰大會予以激勵；
對于部門而言，以上并不重要，重要的是給到模闆（請不要讓我動腦，多數人都不喜歡思考），他可以是這樣的：
從底層邏輯聊日報設計與公司治理
然後在不斷的責罵中「日報寫了現在又來月報？」，最終會得到推行......
我想說，這一切很難，因為人都是有防禦機制的，部門的防禦機制更強。
管理的動作稍有放松，管理的意志稍加薄弱，這些防禦機制就會反撲。
他們甚至會不停的試探你的底線，你隻要在其中一個小政策松口，就有可能千裡之體潰于蟻穴。
這種事情做得好收益很大，做的不好就會變成公司的噪音！裡面的拉扯很值得玩味......
總之，這一路走的很不容易...
結語
有同學私下問了一些問題，也在此更新：
資料真實性
個人填寫的日報怎麼保證或者确定是真實的呢，畢竟沒人會寫我今天摸魚50%？
會有4層兜底校準政策：
1 leader每周或者每天會校準每個人，leader不爽誰就可以校準誰，這個是個管理工具；
2 項目負責人會校準參與我項目的人；
3 項目是要計算ROI的，參與人越多ROI越多；
4 總辦會問責ROI極低的項目或者事項；
經理如何用
日報沒看出對一線經理的管理造成了怎樣的影響，沒有說一線經理怎麼調整員工投入産出
第二部分是涉及了的，但是我這裡沒寫那部分，也就是CEO駕駛艙的第二部分。我們會把所有重點事項項目化，項目化後必須有考核和驗收，後續會根據考核結果給予獎勵也會有信用積分的增減
一年大概有一大筆的項目「獎金池」做宏觀調控。
考核的錯誤引導
考核這些東西，很容易出現「考核什麼，就得到什麼」的結果，解決日報、月報準确性，怎麼保證資源配置設定，尤其是月報，對于沒有資源的團隊經理造成傷害比較大，會裁撤團隊還是怎麼辦？
現在公司「主要的沖突」是備援過大，具體點說公司戰略執行不下去，是以更想要達到聚焦的作用，是以也是引導往項目上走。
具體的做法是公司會給幾個公司級重點項目，做上層“發改委”經濟調控，也鼓勵每個部門自己提報項目做市場經；
關于每個部門的資源或者事項的投入會有一個額度，比如研發還是需要做工程類建設，但是這個比例隻能在10%以下，不同的團隊會有帶寬，我們希望的是大家搶占帶寬，并且給到結果。
對于拿不到資源的團隊我們會認為他就是備援，除非他證明自己有用。
跨周期項目怎麼辦
月度的項目怎麼保證符合預期，比如是否因為月報好做彙報夠三個項目，存在大拆小、快拆慢的情況