原創不易，求分享、求一鍵三連
當業務複雜到一定階段的時候，效率問題會首當其衝，基本解法是化整為零、分賽道，對應的產物可以是子公司、事業部、業務單元、專案組。
好處是目標聚焦、問題也會聚焦；工作內容閉環，團隊人數可控，協作、試錯成本都會很低；但是不可避免的會有很多問題：
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%以下，不同的團隊會有頻寬，我們希望的是大家搶佔頻寬，並且給到結果。
對於拿不到資源的團隊我們會認為他就是冗餘，除非他證明自己有用。
跨週期專案怎麼辦
月度的專案怎麼保證符合預期，比如是否因為月報好做彙報夠三個專案，存在大拆小、快拆慢的情況
這裡所謂的月度專案不是每個月就必須結項一個專案，而是公司想要看到每個部門在「持續」的做一件事情或者投入一件事情，「不要太唯上」；
專案長的會持續2年，但我們希望至少一個季度會有一個節點考核，以防止「沉沒成本」的產生。
工程團隊的問題
工程團隊會不會成為眾矢之的
大概率會吧...
好了，今天的分享就到這，希望對各位有用。「原創不易，多多分享」