今天剛好跟一個前同事聊一些以前加班的事情，他跟我吐槽公司加班的問題，但我管理的技術部門一直沒怎麼加班。就想起來之前為了達成這件事做的一些努力，本來想細說，但他好像不太感興趣，結果我自己憋了一肚子話，不吐不快，不如分享給其他人吧。所以特此寫了這一篇。
原則上儘可能不加班，是為了把加班的時間用在刀刃上，用在非常緊急的事務裡，我們不是為了「完全的不加班」，而是不希望把加班常態化，如果加班是常態的話，遭遇緊急事件的時候，就沒有可用之兵了。
針對程式設計師這種職業來說，狀態低下時的工作效率慢並不是主要問題，而是出BUG的概率提升了很多，而BUG 的修復時間又是不可度量的，又會因為需要修復加班時產生的BUG而加班，這就陷入了加班的死迴圈裡了，對專案來說是得不償失，並且無端端的增加了很多風險。
所以不把加班常態化，才是重點。而為了達成這件事，需要在管理上調整很多細節，不太能一蹴而就，如果沒有合理的方法，只是一味拒絕加班，那反而會有不好的效果。
首先最好的辦法是技術管理許可權最高的那人來推動這些方法，如果只是普通員工的話，也可以向上建議，但許可權問題是很重要的，作為技術管理，一定要事先跟老闆取得認同，讓公司的主要話語人理解不加班原則，主要的說明方向是上面一條「不加班原則」，圍繞這條原則跟老闆解釋不加班的合理性，只有先做到這件事，你才能推行下去，否則你的管理辦法沒有得到上級理解的前提下，是很難推動的，有時候會被誤解為整體工作效率不高。
工期管理是達成不加班的重要事項，一定要讓所有參與者，包括你的客戶，明白一個無可爭議的道理，誰做事，誰對工期的判斷最準確。當然這裡有一個大前提，就是要有信任關係，如果不信任，別人就會懷疑你是不是虛報工期，這是很致命的問題，所以一方面你要掌握工期的主動權，另外一方面還要如實彙報，不要虛高，也不要虛低。否則一旦形成不信任，那麼你就會立即失去報工期的主動權，不要因小失大，禁忌耍小聰明。
如果你沒有掌握工期的主動權，那麼客戶就會自己報工期，但是他們並不是做事的人，他雖然有個期望時間，但實際上完成時間他是不知道的（除非他自己做，如果他自己做的話，又何必找你們），所以最合理的工期一定從做事的人說出來的，沒有人比你自己更理解你的工作效率，當然一開始你自己也不能確定工期，這沒關係的，他們只會比你更不確定。而且團隊內的每個人都需要經常性的做工期判斷，這樣的鍛鍊能夠讓大家越來越準確的估算自己的工作效率，而準確的工期判斷又會促進專案按計劃完成，不準確的工期判斷常常是加班趕工的主要因素。
而且你的客戶會試探你的工作效率，你如果把加班常態化了，你很難在同一個客戶專案上去掉這個習慣，因為客戶已經掌握你加班過程裡的產出率了，他只會按照原先的工作模式繼續試探你的極限在哪裡。這樣對團隊的壓力就會越來越大，而產出的東西質量也會越來越差，最後雖然你滿足了客戶所有的幻想，你的客戶卻拿不到好的產品。這個合作關係也就到頭了。
有時候你報的工期超出客戶的期望時間，這時不是調整你的工期去符合客戶的期望時間，這是一個坑，如果你的工期可以隨便調整，客戶只會覺得你報工期的準確度不高，又容易滋生不信任，解決辦法就是調整專案工作量，或者加大人力，因為你報的工期是 N（日/人） 而客戶的期望時間是N（天），這兩者本身就不是同一個東西，比如你報的是10 日/人 ，客戶希望5天內完成。那麼切記，你的解決方案就是叫多1個人做，變成2人就行了。而不是調整你的工期變成5日/人，或者人力緊張的情況下，跟客戶協調，調整一些需求。
調整需求的策略有三：下策是砍需求，把一些價效比低的需求協商砍掉。中策是需求降級，把一些複雜的需求降級，變成一些簡化版的需求。 上策是更好的替代方案，有時候客戶提需求的時候，會假定某種解決方案，他不知道達成他的核心需求的方案有更簡單更優秀的方案，這時候我們應該充分溝通，明白他的核心需求，刨除他的假想方案，給一個更好卻更簡單的替代方案，當然上策也不是時時能用的，看你能不能找到這個更好的替代方案了。
這個時候可能有人要問：如果有些事真的超級急，今天早上提，當天晚上就要。這種怎麼辦？那麼接下來我們講緊急程度
如果你去問客戶，或者PM，這件事急不急的？比較老道的PM會知道緊急程度，但是經常遇到不明就裡的PM怎麼辦，他會說所有事都很急，因為你不是他的專屬的程式設計師，他希望他自己的需求排在前面先做，客戶也希望自己的需求先做，但是你沒辦法處理每一件緊急的事，而且有些事情是真的很急，有些事並沒有他們口中說的緊急。團隊裡的每個人都應該明白這樣一種緊急程度的分級管理，要非常具體的，能套用大多數情況，而且沒有爭議空間的緊急。
我按照我們之前的工作內容分了三個級別：中 高 極高
極高：就是跟一些時間節點高度相關的專案，比如聖誕節，情人節，遊戲上線時間，宣發時間等
這個級別的緊急程度，代表一旦超出這個節點，這個專案就沒意義了，或者大打折扣，做個情人節的網頁，你不在情人節上線，前面做的事情就白搭了。或者宣發的資源都安排在這個時間點，錢都花出去了，如果不在這個點上線，就打水漂了。所以這種節點是極高的，其他所有專案都需要為這件事讓道。
高階別：比上面那種低一個級別，就是承諾性的節點，客戶有要求比如十月底必須上線，公司已經承諾出去了，或者PM已經協商好了，是某個具體的時間，但沒有跟這個時間點相關的事項，其實超出的話也沒多大問題，會損害一些商譽。或者這個節點有承上啟下的作用，後面有其他團隊需要在這個節點繼續推進專案，如果你交貨晚了，他們也會延後。
中級別：就是不能歸類前面兩種的其他事項。
這個級別管理是根據我之前的業務範圍定的，是非常符合我前公司的日常工作，但不一定符合其他公司的，有一定參考價值，實踐的時候要因地制宜，做一些調整。
分緊急程度的主要意義在於：有些事情雖然說得很急，但實際上今晚回家睡一覺明天做也可以。有些是真的需要加班了。
上面的方法論講完，我們再說一點日常的細節，作為一個管理崗的職位，沒事的時候你最好到點下班，要自己貫徹自己的原則，既然你希望團隊不加班，你自己就別加班，否則你老是不走，其他人想走也顯得不合適，還得陪你加班一樣。
另外一個如果晚上遇到早下班的，也別順口就問「怎麼這麼早下班？」 潛臺詞就是說別人不應該這麼早下班，應該加班到很晚。如果遇到晚加班的。
你可以問「怎麼這麼晚？遇到什麼事了嗎？」 這句的潛臺詞就是，你怎麼不早點下班，是有什麼緊急得非做不可的事情耽誤了嗎？如果不是的話，不建議加班。
不要鼓勵加班的員工，而是鼓勵那些提高做事效率的員工，允許他們懶，鼓勵他們為了懶而採取高效的辦法。可以懶但不能拖延，懶有時候是一種做事的動力，而拖延只是把該做的事無限期的滯後，沒有什麼實際意義。
當然很多人不是技術管理，作為員工的時候怎麼做向上管理呢？首先理念要一致，把加班的不合理情況儘可能向上彙報，實際工作中，多用資料跟範例來證明這個理念。
多做一些提高效率的辦法，可以先在團隊內傳播正確的加班理念，然後在一些融洽的時機裡一起向上反映，或者多利用工作彙報的時候夾雜一些工期管理建議，在例行談話的時候，分享工作中的加班問題，收集其他人對加班的實際看法，然後輸出給領導，在問及解決方案的時候把這套告訴他。
以上就是關於如何處理加班問題的建議，如果大家感興趣的話，我可以再出第二期講更多細節。