最近這段時間，“內卷” 這個從學校傳播開來的詞匯被炒得沸沸揚揚，基本每個行業都在用這個詞匯進行自嘲、暗諷，當然也有很多人想着如何突破。今天我們探討一下在研發體系內的內卷現象以及如何去內卷化。
什么是內卷
在探討之前還是學究性的了解一下，什么是內卷。百度的解釋是：一類文化模式達到某種最終形態以后，既沒有辦法穩定下來，也沒有辦法轉變為新的形態，而只能不斷地在內部變得更加復雜的現象。引申到我們日常的工作中，內卷就表現為公司內部競爭越來越激烈甚至殘酷，但公司整體業務卻沒有什么突破。在參與競爭者角度來看，這與“囚徒困境”概念頗有類似。在企業整體視角來看，更像“熵增”的概念。
軟件研發團隊內卷現象
你可能認為，內卷就是網上各種職場新聞、行業八卦，在我們的身邊其實並沒有那么嚴重的內卷現象。以軟件研發行業為例，你是不是也遇到過以下類似的場景
1、業務開發主力，職業發展卻沒有出路作為業務開發人員，我勤懇而努力，但每次考評都反饋說技術深度不夠。我也想好好沉淀一下技術，但每次業務需求來了因為我最熟悉，又不得不讓我加班加點開發業務需求。久而久之，工作得不到認可也逐漸失去了上進心。
2、會議冗長，形不成結論會議的目的無非就是就某一問題形成共識，如果無法達成共識說明雙方一定存在根本的沖突。多數情況下這種沖突就是多方利益的沖突。經常出現利益沖突，說明團隊的本位意識和山頭意識已經開始出現。
3、績效考評，流於形式浪費人力成本作為團隊成員，每次績效考評都要花較多時間准備，但每次好的績效就那么幾個名額，准備吧也比不過那些“能說會道”的人，不准備吧又讓人覺得自己不上進。總之，一個考評周期下來對自己的真正提升幫助很有限。作為團隊管理者，每次考評時都是最頭疼的時候。要花大量時間不說，更重要的是團隊成員都差不多，公司又強制要求績效分布比例，這績效到底該怎么打？績效考評不但對團隊沒有促進作用反而會引起很多矛盾。
4、新技術、新流程、新組件的引進和推廣使用越來越難團隊內部很多人對通用組件、CI/CD等都有共識，但是真正在分配任務和制定計划時，每個團隊都無法給出計划並提供了“合理”的理由。有的說業務需求緊張，如果要占用開發資源就需要業務團隊同意；有的說自己團隊最近已經連續996，再增加額外工作團隊就會不穩定。無論是研發團隊人員的難受還是團隊管理者的無奈，如果這些現象或多或少的出現，說明你的團隊已經內卷了。
研發體系去內卷化
內卷是職場人的束縛，也是管理者的焦慮。在研發團隊管理過程中，如何去內卷化從而達到團隊整體不斷提升和突破的效果？以下從解決思路和實踐操作上給出一些參考：
1、過程數據化，結果導向化
在上面提到過，會議長而不決現象的發生就是因為決策沒有數據支撐。在沒有明確決策依據的表面問題下隱藏着的是權力尋租、個人和小團隊利益主導、屁股決定腦袋等深層次管理機制問題。數據的收集無疑會增加團隊成本的消耗，因此建議使用研發過程管理工具完成日常數據采集工作。使用研發管理系統不但能可視化定義流程標准和規范，更能讓數據采集變得輕而易舉。當然，數據的積累只是完成了基礎工作。使用數據作為結果進行管理和考核才能真正達到整體提升的效果。市面上也已經出現數據收集、數據智能分析甚至智能決策的產品，應該會給大家帶來幫助。
2、打破團隊的豎井效應
為了達到更高的執行效率，團隊到了一定的規模會根據需要進行小團隊的拆分。常規的團隊划分方法有按職能和按業務划分等兩種方法。無論哪種划分方式，內外部利益不對等的關系長期累積下來都會產生團隊之間的豎井效應。在中等規模、團隊快速發展的階段，建議采用職能和項目交叉的矩陣式管理模式。一般情況下，按照職能進行團隊的實際划分，如服務端開發團隊、前端開發團隊、測試團隊等，按照業務項目進行虛擬團隊的組織。
3、豐富人才的崗位/層級模型
基於團隊分工和人才發展的需要，一般團隊都會制定崗位和層級等人才管理模型。但隨着業務的增長和團隊規模的發展，同崗位或同層級的人數過多勢必會導致內卷現象的發生，特別是在考核和晉升管理過程中表現尤為明顯。如果將崗位或層級直接調整、細分，人才模型的不穩定性不利於人才穩定，同時也會增加管理成本。在團隊內部可以根據團隊自身需要設定多種角色。如：團隊的項目一般復雜度較高，可以設置項目經理的角色；團隊目標是提升部署效率，可以設置配置發布經理的角色；團隊在某個階段要提升技術架構，可以設置架構經理角色等。角色的設置一方面是團隊目標的需要，另一方面也是對人才能力的培養，提升團隊的活力。當然，角色也需要設置對標的能力要求和考核標准，這樣在考核時才能按結果導向，做到公平公正。有了崗位層級的多樣性，人才的發展方向就有多種選擇，也在一定程度上降低或者杜絕內卷現象的發生。
以上，結合當下時尚的內卷話題，我們簡單的剖析了軟件研發體系的團隊管理問題。希望這些探討對大家有所幫助，也歡迎有興趣的同學留言，一起繼續深入探討。