說明
最近在Quora 上看到了一個有趣的問題，What is the best way to communicate to a software development team that they need to work more hours to meet a launch date? (該如何與軟體開發團隊溝通，請他們加班以讓專案如期上線呢？)
問題原文如下︰
My team has a launch date two months out that we need to hit. Over the past year I’ve been comfortable with them working 40 hours per week, but momentum is slipping with vacations, early weekends, etc. I need to communicate that they need to step up their effort and work more hours per week until we launch.
我的團隊有一個專案要在兩個月後上線，在過去一年，我與我的團隊每週工作40 小時，但專案進度因為假期等因素而有所滑落。我需要與團隊溝通，請他們每週工作更長的工時，直到專案正式上線為止。My question is specifically about the best way to communicate this request.
具體來說，我的問題是，我該怎麼向我的團隊溝通這樣的需求呢？
就問題來看，發問者在團隊中應該擔任的是類似PM 的角色，而發問的內容在實務上也很常見，所以引起了不少人的回覆。其中在眾多答案中，評分最高的，也是最引起我共鳴的答案，是由前Quora 工程師Edmond Lau 所提供的(答案連結)。
Edmond Lau 在回覆中，說明為什麼他認為超時工作不可行，並且分享了他個人在過去專案執行中，所遇到的慘痛經驗。整個答案內文比原始的問題內文要長得多，但又非常實務且有趣。我在讀了之後覺得非常喜歡，所以想說就乾脆把它翻譯出來好了，希望也帶給遭遇類似問題的朋友一些思考。
要說明的是，我不是專業的譯者，所以對於內文的翻譯，或許有錯誤或是不到位的地方(這很有可能發生)，都非常歡迎大家指正。如果有相關的經驗可以一起分享的話，那就更好了，這也是一開始我翻譯這篇答案內文，希望帶給大家的幫助。
譯文
在要求你的開發團隊加班之前，請先確定你們目前的上線計劃是真正可行的。如果如期上線目前看來只是痴心妄想(wishful thinking)，那麼你最佳的策略，要嘛是根據目前的專案狀態，重新訂定到上線日時，你們可以交付的成品內容；又或者是，根據專案目前的進度狀態，重新設定更可行的上線日。
處理滑落的開發時程，在軟體開發上是很困難，但卻不幸地是非常常見的事情。我參與過兩個大型、開發時程橫跨多個月份的專案，在這兩個專案中，雄心勃勃的專案經理總是要求團隊加班，以向專案交期衝刺。
在這兩個專案中，因為我們被告知，專案一旦無法如期完成，將會造成嚴重的商業損失。因此我們團隊中許多有天份且願意付出的成員，拼盡全力試著達成這樣”樂觀” 的交期。我們的每週工時從一開始的60 小時，到後來成長到每週接近70 小時。
而在長達數個月的加班後，專案仍然結束不了。最後的結果證明，在這樣的專案馬拉松中，我們只跑到了一半，而不是接近終點。無謂的加班衝刺毫無意義。 (It turned out that rather than sprinting at the homestretch of a marathon, we had started sprinting somewhere near the middle.)
在這些專案中，燒掉了團隊成員們的熱情，他們當中的一些人相繼離開。而這使得團隊中的其他人，要再花時間來接手離職成員的工作。短期來看，做出加班的決策來追求更多進度似乎是合理的，但長期下來都會傷害開發團隊。
這兩個專案的經驗，教會了我們一個沉痛的教訓︰當你希望一個專案在可以指定日期內完成，並不表示這個專案真的可以在這個日期內被完成。不要混淆「一廂情願」和「對事物樂觀」這兩件事！ (just because you really want a project to be completed by a certain date doesn’t make it any more realistic that it will. Don’t confuse wishful thinking with realistic optimism.)
為什麼超時工作不可行？
你的思路可能是這樣子的︰目前進度已經落後表定的進度25%，所以為了趕上原訂的專案交期，你需要使團隊多花費25% 的工時以趕上進度。這表示在在未來兩個月中，團隊每個成員需要每週工作50 小時。 (譯註︰原發問者說明他們目前是每週工作40 小時)
在這裡我提供一些理由，來說明為什麼這樣的思考邏輯在實務上並不可行，與為什麼加班並不一定可以趕上上線日期的原因︰
1. 每小時的生產力，會隨著工時的增加而下降
如果你的團隊已經習慣一週工作40 小時的工作節奏，額外的工時帶來的邊際生產力，很有可能比一般工時來得低，甚至很有可能是負的。疲勞與睡眠的減少，最終會傷害認知功能與降低工作的品質。
近150 年下來，關於長時間工作如何降低生產力的研究，可以總結在Sara Robinson 的Bring back the 40-hour work week 與Evan Robinson 的”Why crunch mode doesn’t work” 兩篇研究文章中。 1890 年代的員工，在每天的工時為8 小時情形下，每位勞工的生產力較高[1]。 Sidney Chapman 在1909 展示，超時工作下，生產力會快速下降，勞工開始犯他們在充足的休息下，不會犯的錯誤。而後續的成本在，他們的產出在後續幾天也會接著下滑[2]。 Henry Ford 在1922 年開始採用每週40 小時工時制，因為持續多年的實驗告訴他這樣的制度設計，可以提升勞工的總產出。 [3][4]
Tom Walker 在”The Prosperity Covenant” 研究中寫下以下描述︰
「工作產出並不會隨著工時的提升或下降，而有等比例的變動，這似乎是每個世代都要重新學習的教訓。」 [1]
邊際生產力下降代表即使加班可以提升團隊的每週總產出，但總產出提升的幅度不會是你所預期的25% (譯註︰代表即使總產出有所提升，落後的專案進度仍然趕不上)。但1980 年代的一篇研究”Scheduled Overtime Effect on Construction Projects”，甚至質疑加班會提升每週總產出的這個論點︰
「每週工時長於60 小時，持續兩個月左右，生產力下降的累積效應將導致完工日期延遲，而延遲後的完工日期，甚至可能與在每週正常工時40 小時狀態下的完工日期相同。」[5]
這個研究也許不是以軟體開發工業為研究主題，但這並不能成為，我們不學習這100 多年來研究成果的理由。
2. 有很大的可能，團隊目前落後的進度比你們認知到的還要多
精確的專案估計是工程中最困難的一項工作[6]，目前專案進度上的滑落，代表你們之前幾個月的產出是低於預期的，而與其樂觀地認為只有先前的產出預估低於預期，更有可能的是對於整個專案產出上的預估都是錯誤的。這也包括你們對於未來的兩個月產出的預期。
使時程估計不準的效應更加重的情形是，我們傾向在專案開始時就可以將專案時程估計得準確，而此時我們預估時程的依據，都是聚焦在我們已經知道怎麼進行的開發工作上，而不是整體的專案工作專案。團隊常會低估整合測試所需花費的時間，而這些被低估的工作專案，通常會拖累整體的工時數週甚至更多。
Frederick Brooks 將這個效應寫在The Mythical Man-Month (人月神話) 一書中︰
「沒有留下足夠的時間進行系統測試，在特定情況下會造成災難性的後果。因為在測試工作上的延遲，會造成專案時程的滑落，而所有人只有在接近專案的交付日前才會意識到這一點」 [7]
3. 額外的加班工時可能會燒掉你的團隊成員
團隊成員的加班工時，來自於犧牲他們額外的時間- 也許是他們與朋友或配偶相處的時間、運動的時間、休息的時間、睡覺的時間或做其他工作以外的事的時間。當我們希望他們犧牲這些時間，而改用高壓的工時來代替時，所燃燒掉的團隊熱情將難以量化。
在Peopleware (Peopleware： 腦力密集產業的人才管理之道) 一書中，Tom DeMarco 與Timothy Lister 將其中一個這樣的現象，稱之為「偷工時間」(undertime)，而勞工在超時工作時「總是會幫自己挪出相同長度的偷工時間，以使自己的生活節奏得到補償」[8]
在我們的經驗中，加班的正面能量一向被過份地誇大，而它的負面效應則從未被考慮。而這些負面效應可以說是非常實際的︰容易犯錯、燃盡熱情、加速員工的離職、和補償性的「偷工時間」 (undertime)。 [9]
4. 加班可能會傷害到團隊的熱情
並不是所有團隊成員都有餘力可以應付額外的工時，可能有成員家中有小孩要照顧、可能成員花費在通勤的時間非常長，壓縮了可以額外用來工作的時間、或是有成員已經規劃好了未來兩週的假期。
而一開始團隊中處在正面的狀態，所有人都聚集在同一個地方，每週工作40 個小時。但現在所有人被要求投入更多他們不能或是不願意投入的的工時，其結果可能會導致原本快樂的團隊成員之間的痛苦或怨恨。
5. 倉促趕工會導致額外的管理成本
超時的工作，會需要額外的站立會議，來確保每個成員正在做正確的事情，而不幸地的是，這些額外的會議與溝通成本並沒有被納入當初的工時預估中。
6. 趕工可能會造成額外的技術債
有項難以避免的問題是，當你要求團隊成員超時工作以達成交期時，他們通常會在開發上，採取抄近路的方式以達成目標。
或許他們會負責任地寫下筆記，告訴自已在專案結束後，要回頭來處理這個問題，但他們在A 專案結束後，通常又會接著投入B 專案，而無法如他們的預期回頭處理問題。因此在趕工的專案結束後，團隊通常會留下一大堆等著未來要償還的技術債。
上述這些成本不是理論，而是實際發生在我參與的專案中。而且很不幸的，這些情形在軟體專案中是非常常見的。
但這些事不會發生在我身上
撇開上述這些長期的成本不看，我也理解改變航道與向上線日期說「不」的困難度。也許組織中的其他人都在期待這個專案的上線好一陣子了；也許這個專案相當重要，以致於如果專案延期會造成商業上的損失；也許你害怕如果專案延期的話，你的團隊不知道會發生什麼事(譯註︰XDD)；或者，也許你認為你和你的團隊的情況將會有所不同。
不論背後是怎樣的理由，如果你仍然執意想要求團隊加班，我建議你與你的團隊多著重溝通以下的專案︰
1. 與團隊討論並釐清造成目前專案時程滑落的主要因素
專案時程的滑落是因為成員的鬆懈，還是因為開發工作比預期來得更復雜與更花時間？如果你不瞭解專案落後的根本因素，那你就不能說服大家這些因素，在未來兩個月不會再發生。
2. 向團隊說明真正可行的新時程規劃，並向他們解釋為什麼這次加班，可以真的讓專案順利上線
只是告訴團隊成員因為進度落後需要加班是不夠的，如果你們討論不出一個更仔細且可行的上線計劃，那麼這將是一個警訊。因為很有可能接下來所需的工作，會比你們現在所認為的還要來得多，而加班並不是一種好的解決方式。
3. 確保專案成員都對新的時程「買單」(buy-in)
如果專案的關鍵成員(key person) 並不認同新的時程是可行的，那你可能要思考，你是不是將「某件事要在某天完成」和「某件事『真的』可以在某天完成」這兩件事搞混了？ (then you need to consider that you might be conflating what you want to get done by a certain date with what is realistic to get done by that date.)
如果你不讓所有人買單，那將只有部份專案成員會真正加班來追趕進度，就算不論這種情況會傷害團隊的公平性，你也別想讓專案在你所預期的日期上線。
4. 與團隊說明整體大方向，說明為什麼如期上線對於組織來說是重要的
如果你不能將所有團隊成員凝聚在一起，那這將是另一個警訊。因為所有團隊成員，將不是和你站在相同的出發點，進行加班趕工。
結論
最後，如果在這兩個月的加班期間，你們發現你們的進度又一次在新的專案時程中落後了，那你們應該準備放棄這次的加班衝刺。接受你們目前仍然處在在馬拉松慢跑的中段，而終點比你們所預期的還要遠(Accept that you might have sprinted in the middle of a marathon and that the finish line is farther away than you thought.)。在這種情形下，要求團隊更加努力解決不了這個問題。你應該要做的是擺脫你的損失，並且花心思擬出下一個可進行的應急計劃。
無法如期上線可能很糟，但更糟的是燃燒光了團隊的熱情，而仍然無法如期上線，而對於新的上線日期仍然無法有效掌握。處理滑落的上線日期並不是件容易的事情。
[1]: Tom Walker, The Prosperity Covenant: how reducing work time really works to create jobs.
[2]: Sydney Chapman (economist), Wikipedia.
[3]: Samuel Crowther, Henry Ford: Why I Favor Five Days’ Work With Six Days’ Pay, World’s WOrk, October 1926.
[4]: Ford factory workers get 40-hour week — History.com This Day in History — 5/1/1926, History.
[5]: Scheduled Overtime Effect on Construction Projects, Business Roundtable, 1980.
[6]: What are some ways to improve your project estimation skills?
[7]: Frederick Brooks, The Mythical Man-Month: Essays on Software Engineering, p20.
[8]: Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams, p15.
[9]: Peopleware, p179.