說明

最近在 Quora 上看到了一個(gè)有趣的問題，What is the best way to communicate to a software development team that they need to work more hours to meet a launch date? (該如何與軟件開發(fā)團(tuán)隊(duì)溝通，請他們加班以讓項(xiàng)目如期上線呢？)

問題原文如下︰

就問題來看，發(fā)問者在團(tuán)隊(duì)中應(yīng)該擔(dān)任的是類似PM 的角色，而發(fā)問的內(nèi)容在實(shí)務(wù)上也很常見，所以引起了不少人的回覆。其中在眾多答案中，評分***的，也是最引起我共鳴的答案，是由前Quora 工程師Edmond Lau 所提供的(答案連結(jié))。

Edmond Lau 在回覆中，說明為什么他認(rèn)為超時(shí)工作不可行，并且分享了他個(gè)人在過去專案執(zhí)行中，所遇到的慘痛經(jīng)驗(yàn)。整個(gè)答案內(nèi)文比原始的問題內(nèi)文要長得多，但又非常實(shí)務(wù)且有趣。我在讀了之后覺得非常喜歡，所以想說就干脆把它翻譯出來好了，希望也帶給遭遇類似問題​​的朋友一些思考。

要說明的是，我不是專業(yè)的譯者，所以對于內(nèi)文的翻譯，或許有錯(cuò)誤或是不到位的地方(這很有可能發(fā)生)，都非常歡迎大家指正。如果有相關(guān)的經(jīng)驗(yàn)可以一起分享的話，那就更好了，這也是一開始我翻譯這篇答案內(nèi)文，希望帶給大家的幫助。

譯文

在要求你的開發(fā)團(tuán)隊(duì)加班之前，請先確定你們目前的上線計(jì)劃是真正可行的。如果如期上線目前看來只是癡心妄想(wishful thinking)，那么你***的策略，要嘛是根據(jù)目前的專案狀態(tài)，重新訂定到上線日時(shí)，你們可以交付的成品內(nèi)容；又或者是，根據(jù)專案目前的進(jìn)度狀態(tài)，重新設(shè)定更可行的上線日。

處理滑落的開發(fā)時(shí)程，在軟體開發(fā)上是很困難，但卻不幸地是非常常見的事情。我參與過兩個(gè)大型、開發(fā)時(shí)程橫跨多個(gè)月份的專案，在這兩個(gè)專案中，雄心勃勃的專案經(jīng)理總是要求團(tuán)隊(duì)加班，以向?qū)０附黄跊_刺。

在這兩個(gè)專案中，因?yàn)槲覀儽桓嬷瑢０敢坏o法如期完成，將會(huì)造成嚴(yán)重的商業(yè)損失。因此我們團(tuán)隊(duì)中許多有天份且愿意付出的成員，拼盡全力試著達(dá)成這樣”樂觀” 的交期。我們的每周工時(shí)從一開始的60 小時(shí)，到后來成長到每周接近70 小時(shí)。

而在長達(dá)數(shù)個(gè)月的加班后，專案仍然結(jié)束不了。***的結(jié)果證明，在這樣的專案馬拉松中，我們只跑到了一半，而不是接近終點(diǎn)。無謂的加班沖刺毫無意義。 (It turned out that rather than sprinting at the homestretch of a marathon, we had started sprinting somewhere near the middle.)

在這些專案中，燒掉了團(tuán)隊(duì)成員們的熱情，他們當(dāng)中的一些人相繼離開。而這使得團(tuán)隊(duì)中的其他人，要再花時(shí)間來接手離職成員的工作。短期來看，做出加班的決策來追求更多進(jìn)度似乎是合理的，但長期下來都會(huì)傷害開發(fā)團(tuán)隊(duì)。

這兩個(gè)專案的經(jīng)驗(yàn)，教會(huì)了我們一個(gè)沉痛的教訓(xùn)︰當(dāng)你希望一個(gè)專案在可以指定日期內(nèi)完成，并不表示這個(gè)專案真的可以在這個(gè)日期內(nèi)被完成。不要混淆「一廂情愿」和「對事物樂觀」這兩件事！ (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.)

為什么超時(shí)工作不可行？

你的思路可能是這樣子的︰目前進(jìn)度已經(jīng)落后表定的進(jìn)度25%，所以為了趕上原訂的專案交期，你需要使團(tuán)隊(duì)多花費(fèi)25% 的工時(shí)以趕上進(jìn)度。這表示在在未來兩個(gè)月中，團(tuán)隊(duì)每個(gè)成員需要每周工作50 小時(shí)。 (譯注︰原發(fā)問者說明他們目前是每周工作40 小時(shí))

在這里我提供一些理由，來說明為什么這樣的思考邏輯在實(shí)務(wù)上并不可行，與為什么加班并不一定可以趕上上線日期的原因︰

1. 每小時(shí)的生產(chǎn)力，會(huì)隨著工時(shí)的增加而下降

如果你的團(tuán)隊(duì)已經(jīng)習(xí)慣一周工作40 小時(shí)的工作節(jié)奏，額外的工時(shí)帶來的邊際生產(chǎn)力，很有可能比一般工時(shí)來得低，甚至很有可能是負(fù)的。疲勞與睡眠的減少，最終會(huì)傷害認(rèn)知功能與降低工作的品質(zhì)。

近150 年下來，關(guān)于長時(shí)間工作如何降低生產(chǎn)力的研究，可以總結(jié)在Sara Robinson 的Bring back the 40-hour work week 與Evan Robinson 的”Why crunch mode doesn’t work” 兩篇研究文章中。 1890 年代的員工，在每天的工時(shí)為8 小時(shí)情形下，每位勞工的生產(chǎn)力較高[1]。 Sidney Chapman 在1909 展示，超時(shí)工作下，生產(chǎn)力會(huì)快速下降，勞工開始犯他們在充足的休息下，不會(huì)犯的錯(cuò)誤。而后續(xù)的成本在，他們的產(chǎn)出在后續(xù)幾天也會(huì)接著下滑[2]。 Henry Ford 在1922 年開始采用每周40 小時(shí)工時(shí)制，因?yàn)槌掷m(xù)多年的實(shí)驗(yàn)告訴他這樣的制度設(shè)計(jì)，可以提升勞工的總產(chǎn)出。 [3][4]

Tom Walker 在”The Prosperity Covenant” 研究中寫下以下描述︰

「工作產(chǎn)出并不會(huì)隨著工時(shí)的提升或下降，而有等比例的變動(dòng)，這似乎是每個(gè)世代都要重新學(xué)習(xí)的教訓(xùn)。」 [1]

邊際生產(chǎn)力下降代表即使加班可以提升團(tuán)隊(duì)的每周總產(chǎn)出，但總產(chǎn)出提升的幅度不會(huì)是你所預(yù)期的25% (譯注︰代表即使總產(chǎn)出有所提升，落后的專案進(jìn)度仍然趕不上)。但1980 年代的一篇研究”Scheduled Overtime Effect on Construction Projects”，甚至質(zhì)疑加班會(huì)提升每周總產(chǎn)出的這個(gè)論點(diǎn)︰

「每周工時(shí)長于60 小時(shí)，持續(xù)兩個(gè)月左右，生產(chǎn)力下降的累積效應(yīng)將導(dǎo)致完工日期延遲，而延遲后的完工日期，甚至可能與在每周正常工時(shí)40 小時(shí)狀態(tài)下的完工日期相同。」[5]

這個(gè)研究也許不是以軟體開發(fā)工業(yè)為研究主題，但這并不能成為，我們不學(xué)習(xí)這100 多年來研究成果的理由。

2. 有很大的可能，團(tuán)隊(duì)目前落后的進(jìn)度比你們認(rèn)知到的還要多

精確的專案估計(jì)是工程中最困難的一項(xiàng)工作[6]，目前專案進(jìn)度上的滑落，代表你們之前幾個(gè)月的產(chǎn)出是低于預(yù)期的，而與其樂觀地認(rèn)為只有先前的產(chǎn)出預(yù)估低于預(yù)期，更有可能的是對于整個(gè)專案產(chǎn)出上的預(yù)估都是錯(cuò)誤的。這也包括你們對于未來的兩個(gè)月產(chǎn)出的預(yù)期。

使時(shí)程估計(jì)不準(zhǔn)的效應(yīng)更加重的情形是，我們傾向在專案開始時(shí)就可以將專案時(shí)程估計(jì)得準(zhǔn)確，而此時(shí)我們預(yù)估時(shí)程的依據(jù)，都是聚焦在我們已經(jīng)知道怎么進(jìn)行的開發(fā)工作上，而不是整體的專案工作項(xiàng)目。團(tuán)隊(duì)常會(huì)低估整合測試所需花費(fèi)的時(shí)間，而這些被低估的工作項(xiàng)目，通常會(huì)拖累整體的工時(shí)數(shù)周甚至更多。

Frederick Brooks 將這個(gè)效應(yīng)寫在The Mythical Man-Month (人月神話) 一書中︰

「沒有留下足夠的時(shí)間進(jìn)行系統(tǒng)測試，在特定情況下會(huì)造成災(zāi)難性的后果。因?yàn)樵跍y試工作上的延遲，會(huì)造成專案時(shí)程的滑落，而所有人只有在接近專案的交付日前才會(huì)意識(shí)到這一點(diǎn)」 [7]

#p#

3. 額外的加班工時(shí)可能會(huì)燒掉你的團(tuán)隊(duì)成員

團(tuán)隊(duì)成員的加班工時(shí)，來自于犧牲他們額外的時(shí)間- 也許是他們與朋友或配偶相處的時(shí)間、運(yùn)動(dòng)的時(shí)間、休息的時(shí)間、睡覺的時(shí)間或做其他工作以外的事的時(shí)間。當(dāng)我們希望他們犧牲這些時(shí)間，而改用高壓的工時(shí)來代替時(shí)，所燃燒掉的團(tuán)隊(duì)熱情將難以量化。

在Peopleware (Peopleware： 腦力密集產(chǎn)業(yè)的人才管理之道) 一書中，Tom DeMarco 與Timothy Lister 將其中一個(gè)這樣的現(xiàn)象，稱之為「偷工時(shí)間」(undertime)，而勞工在超時(shí)工作時(shí)「總是會(huì)幫自己挪出相同長度的偷工時(shí)間，以使自己的生活節(jié)奏得到補(bǔ)償」[8]

在我們的經(jīng)驗(yàn)中，加班的正面能量一向被過份地夸大，而它的負(fù)面效應(yīng)則從未被考慮。而這些負(fù)面效應(yīng)可以說是非常實(shí)際的︰容易犯錯(cuò)、燃盡熱情、加速員工的離職、和補(bǔ)償性的「偷工時(shí)間」 (undertime)。 [9]

4. 加班可能會(huì)傷害到團(tuán)隊(duì)的熱情

并不是所有團(tuán)隊(duì)成員都有余力可以應(yīng)付額外的工時(shí)，可能有成員家中有小孩要照顧、可能成員花費(fèi)在通勤的時(shí)間非常長，壓縮了可以額外用來工作的時(shí)間、或是有成員已經(jīng)規(guī)劃好了未來兩周的假期。

而一開始團(tuán)隊(duì)中處在正面的狀態(tài)，所有人都聚集在同一個(gè)地方，每周工作40 個(gè)小時(shí)。但現(xiàn)在所有人被要求投入更多他們不能或是不愿意投入的的工時(shí)，其結(jié)果可能會(huì)導(dǎo)致原本快樂的團(tuán)隊(duì)成員之間的痛苦或怨恨。

5. 倉促趕工會(huì)導(dǎo)致額外的管理成本

超時(shí)的工作，會(huì)需要額外的站立會(huì)議，來確保每個(gè)成員正在做正確的事情，而不幸地的是，這些額外的會(huì)議與溝通成本并沒有被納入當(dāng)初的工時(shí)預(yù)估中。

6. 趕工可能會(huì)造成額外的技術(shù)債

有項(xiàng)難以避免的問題是，當(dāng)你要求團(tuán)隊(duì)成員超時(shí)工作以達(dá)成交期時(shí)，他們通常會(huì)在開發(fā)上，采取抄近路的方式以達(dá)成目標(biāo)。

或許他們會(huì)負(fù)責(zé)任地寫下筆記，告訴自已在專案結(jié)束后，要回頭來處理這個(gè)問題，但他們在A 專案結(jié)束后，通常又會(huì)接著投入B 專案，而無法如他們的預(yù)期回頭處理問題。因此在趕工的專案結(jié)束后，團(tuán)隊(duì)通常會(huì)留下一大堆等著未來要償還的技術(shù)債。

上述這些成本不是理論，而是實(shí)際發(fā)生在我參與的專案中。而且很不幸的，這些情形在軟體專案中是非常常見的。

但這些事不會(huì)發(fā)生在我身上

撇開上述這些長期的成本不看，我也理解改變航道與向上線日期說「不」的困難度。也許組織中的其他人都在期待這個(gè)專案的上線好一陣子了；也許這個(gè)專案相當(dāng)重要，以致于如果專案延期會(huì)造成商業(yè)上的損失；也許你害怕如果專案延期的話，你的團(tuán)隊(duì)不知道會(huì)發(fā)生什么事(譯注︰XDD)；或者，也許你認(rèn)為你和你的團(tuán)隊(duì)的情況將會(huì)有所不同。

不論背后是怎樣的理由，如果你仍然執(zhí)意想要求團(tuán)隊(duì)加班，我建議你與你的團(tuán)隊(duì)多著重溝通以下的項(xiàng)目︰

1. 與團(tuán)隊(duì)討論并厘清造成目前專案時(shí)程滑落的主要因素

專案時(shí)程的滑落是因?yàn)槌蓡T的松懈，還是因?yàn)殚_發(fā)工作比預(yù)期來得更復(fù)雜與更花時(shí)間？如果你不了解專案落后的根本因素，那你就不能說服大家這些因素，在未來兩個(gè)月不會(huì)再發(fā)生。

2. 向團(tuán)隊(duì)說明真正可行的新時(shí)程規(guī)劃，并向他們解釋為什么這次加班，可以真的讓專案順利上線

只是告訴團(tuán)隊(duì)成員因?yàn)檫M(jìn)度落后需要加班是不夠的，如果你們討論不出一個(gè)更仔細(xì)且可行的上線計(jì)劃，那么這將是一個(gè)警訊。因?yàn)楹苡锌赡芙酉聛硭璧墓ぷ鳎瑫?huì)比你們現(xiàn)在所認(rèn)為的還要來得多，而加班并不是一種好的解決方式。

3. 確保專案成員都對新的時(shí)程「買單」(buy-in)

如果專案的關(guān)鍵成員(key person) 并不認(rèn)同新的時(shí)程是可行的，那你可能要思考，你是不是將「某件事要在某天完成」和「某件事『真的』可以在某天完成」這兩件事搞混了？ (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.)

如果你不讓所有人買單，那將只有部份專案成員會(huì)真正加班來追趕進(jìn)度，就算不論這種情況會(huì)傷害團(tuán)隊(duì)的公平性，你也別想讓專案在你所預(yù)期的日期上線。

4. 與團(tuán)隊(duì)說明整體大方向，說明為什么如期上線對于組織來說是重要的

如果你不能將所有團(tuán)隊(duì)成員凝聚在一起，那這將是另一個(gè)警訊。因?yàn)樗袌F(tuán)隊(duì)成員，將不是和你站在相同的出發(fā)點(diǎn)，進(jìn)行加班趕工。

結(jié)論

***，如​​果在這兩個(gè)月的加班期間，你們發(fā)現(xiàn)你們的進(jìn)度又一次在新的專案時(shí)程中落后了，那你們應(yīng)該準(zhǔn)備放棄這次的加班沖刺。接受你們目前仍然處在在馬拉松慢跑的中段，而終點(diǎn)比你們所預(yù)期的還要遠(yuǎn)(Accept that you might have sprinted in the middle of a marathon and that the finish line is farther away than you thought.)。在這種情形下，要求團(tuán)隊(duì)更加努力解決不了這個(gè)問題。你應(yīng)該要做的是擺脫你的損失，并且花心思擬出下一個(gè)可進(jìn)行的應(yīng)急計(jì)劃。

無法如期上線可能很糟，但更糟的是燃燒光了團(tuán)隊(duì)的熱情，而仍然無法如期上線，而對于新的上線日期仍然無法有效掌握。處理滑落的上線日期并不是件容易的事情。

[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.

原文鏈接： Quora

譯文鏈接： little lin