原創文章首發於【ITPUB企業級】公眾號，轉載請微信聯絡：ITPUBeditor

難道當管理就只會用加班這個手段嗎？

除了讓團隊加班管理者還會什麼？

工作中偶爾的這些「感嘆」「發問」，相信不禁或多或少曾引發我們的思考，接下來也想與大家共同交流探討下。

質量約束，離不開三板斧

我一直認為，我們所做的事情並不是團隊割裂的獨立性的工作，而是屬於有目標、有階段的團隊共同作業性工作，也就是我們常談及的軟體工程。在軟體工程裡，有一個非常著名的金三角理論：專案質量是由範圍、成本與時間這三個要素進行平衡與約束的。 

一般來說，專案質量是開發團隊的基礎保證，該要素大部份情況是「不妥協的」。因此當專案開發過程中遇到意外事件時，需要靈活調整範圍、成本、時間以此確保質量。

簡單舉個例子，假如哪天管理層希望卡某個時間點或者節假日上新版本的功能需求壓縮時間，那麼專案負責人則需要與產品經理協商減少非核心需求的範圍，再或者從別的部門借調人員來加快開發效率。

假設，在時間壓縮的前提下，不減少需求範圍，又不增派人手，那麼專案質量必然會受此影響進而致使交付質量降低。

應對之法：一減兩加

理解完金三角理論後，我們可以思考下，假如專案出現了意外，應該如果應對。我過往的經驗中有三種應對方案，一減法兩加法：「砍需求」「加人」「加班」，這三個方案正分別對應著範圍、成本、時間這三個要素。

應對方案的優先度，要是排個序，我認為是 砍需求>加人>加班。下面我具體說說原因。

當專案出現意外的時候，團隊更多考慮的是 是否可在約定的時間裡保質交付專案，因此砍需求本質上來說，是一個低成本，低風險並且可控的應對方案，既可以減少過多的成本投入，又不會打擊團隊士氣。把非核心的需求向後排期挪一挪，以逐步演進的方式完善優化產品，例如像使用者體驗類的優化需求。

理想上，誰都會希望把事情一次性做完美，但現實上，在有限的資源前提下我們是無法一口吃成個大胖子的。有的放矢也是一種選擇方式。

有些特殊的場景下，既不能砍需求，還有可能會額外增加需求。一般情況下，進入開發的階段是需要凍結需求變更的，如果真的有不可退讓的理由而需要增加需求，則需要重新評估工時並調整排期。假如既得加需求，又不允許調整時間，那麼我們還有個方法就是增派人手。

調派的人數不宜過多，因為人數增加必然會增加溝通成本。《人月神話》這本書有說，如果專案或組織的人員越複雜，那麼他的溝通成本將會越高。即溝通成本會隨著專案或者組織的人增加成指數增加。洶通成本計算公式 n(n-1)/2，5個人的團隊，溝通渠道是10；15個團隊，溝通渠道是105。也因為溝通成本的存在，效率也不會以平均數的方式提升，也就是說3人15個工作日調整成了6人後，並不會說以完美的7.5人工作日進行交付 。

大多數公司都是一個蘿蔔一個坑的，特別是中小型公司想調派人手還是有點困難的。假如上面兩個方案都都沒辦法應對，那麼就只能使用下下策-加班。

加班方案的優缺點

加班這種做法，我是非常建議使用到衝刺性的團隊任務上，短期的衝刺性任務可以使得團隊凝聚力增加，因為大家共患難了嘛。但是戰線拉長了，加班是非常打擊團隊士氣的，還會額外增加不少成本。特別是那種長期加班或者政治性加班的，會讓團隊產生惰性、負能量，這種的結果就會與初衷背道而馳。

有些同行看到這裡可能會認為加班，其實是一種應對專案意外的最直接最簡單的方式，你看，管理者根本不需要額外去協調需求範圍和人手，只需要一句指令「加班」，就可以應對所有意外情況。

對於這種只會用加班的管理者，我只想說一句，這群偽管理者，別用他人的額外付出以此掩蓋管理的無能，也不要用戰術上的假勤奮掩飾戰略上的真懶惰。如果只會用加班解決問題，那團隊還真的需要你管麼？

當然了，加班這種社會亂象，在咱們國家各行各業都非常普遍，我總結了主要這三點原因：

1、有待完善的勞動法監管制度；

2、人多了就會「卷」出「廉價」的勞動力；

3、缺乏擔當的「偽管理者」。

對於這三點原因，我簡單解釋下：

首先，我國確實存在著一些勞動法監管的不足之處，導致某些企業僱主能夠以各種方式繞過加班限制，迫使員工超負荷工作。其次，我國人口多以至於勞動力市場競爭激烈，某些僱主為了降低成本，更傾向於僱傭廉價的勞動力。這些勞動力通常面臨較低的工資待遇和勞動條件，因此他們更容易被要求加。以上兩點都屬於國情，並非由我們的綿薄之力就可以解決的。

對於偽管理者這個說法，我希望大家別輕易的對號入座。當然了，在我職業生涯裡，確實遇到了，也聽到了不少的管理者缺乏擔當精神和責任感，不能有效地組織、分配和管理工作，導致工作流程不暢，員工任務無法合理分配，而他們的本質可能就是個上級的「傳話筒」，這些管理者只關注自身利益，缺乏對員工權益的關注和保護，加重了員工的工作壓力和加班負擔。 

以上就是我這次分享的內容，大家可以把自己的想法反饋到下方評論，我們一起探討。