自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

為滿足項(xiàng)目上線日期要求,如何讓團(tuán)隊(duì)工作更多時間?

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

說明

最近在 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? (該如何與軟件開發(fā)團(tuán)隊(duì)溝通,請他們加班以讓項(xiàng)目如期上線呢?)

問題原文如下︰

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.
我的團(tuán)隊(duì)有一個專案要在兩個月后上線,在過去一年,我與我的團(tuán)隊(duì)每周工作40 小時,但專案進(jìn)度因?yàn)榧倨诘纫蛩囟兴洹N倚枰c團(tuán)隊(duì)溝通,請他們每周工作更長的工時,直到專案正式上線為止。

My question is specifically about the best way to communicate this request.
具體來說,我的問題是,我該怎么向我的團(tuán)隊(duì)溝通這樣的需求呢?

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

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

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

譯文

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

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

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

而在長達(dá)數(shù)個月的加班后,專案仍然結(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ì)中的其他人,要再花時間來接手離職成員的工作。短期來看,做出加班的決策來追求更多進(jìn)度似乎是合理的,但長期下來都會傷害開發(fā)團(tuán)隊(duì)。

這兩個專案的經(jīng)驗(yàn),教會了我們一個沉痛的教訓(xùn)︰當(dāng)你希望一個專案在可以指定日期內(nèi)完成,并不表示這個專案真的可以在這個日期內(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.)

為什么超時工作不可行?

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

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

1. 每小時的生產(chǎn)力,會隨著工時的增加而下降

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

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

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

「工作產(chǎn)出并不會隨著工時的提升或下降,而有等比例的變動,這似乎是每個世代都要重新學(xué)習(xí)的教訓(xùn)?!?[1]

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

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

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

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

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

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

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

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

#p#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)論

***,如​​果在這兩個月的加班期間,你們發(fā)現(xiàn)你們的進(jìn)度又一次在新的專案時程中落后了,那你們應(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ì)更加努力解決不了這個問題。你應(yīng)該要做的是擺脫你的損失,并且花心思擬出下一個可進(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

責(zé)任編輯:林師授 來源: littlelin.info
相關(guān)推薦

2013-08-30 13:35:14

項(xiàng)目團(tuán)隊(duì)

2012-05-16 14:25:51

世界電信和信息社會日信息通信電信日

2021-06-29 09:03:40

5G運(yùn)營商消費(fèi)者市場

2022-08-08 13:17:59

數(shù)據(jù)安全

2015-03-03 09:05:23

2014-02-12 10:36:49

網(wǎng)絡(luò)演進(jìn)移動性

2018-01-18 12:36:14

Linuxbashhistory

2020-04-24 21:20:34

IIoT工業(yè)物聯(lián)網(wǎng)數(shù)字化轉(zhuǎn)型

2011-12-21 15:04:09

程序員

2013-08-26 10:32:17

管理創(chuàng)業(yè)公司管理

2015-09-22 20:40:54

2014-08-06 10:41:35

IPv6

2011-04-21 11:35:13

黑白激光打印機(jī)

2014-05-13 14:18:45

戴爾

2010-06-10 23:53:24

SSL VPN深信服科技

2021-04-09 10:50:22

人工智能AI智能交通

2020-07-08 13:57:50

密碼DFARS身份驗(yàn)證

2016-05-09 09:55:56

IBMBM FlashSys

2023-05-18 12:49:24

人工智能AI
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號