題:
我該如何回答有關如何處理我無法滿足的艱鉅期限的面試問題?
tnkh
2019-08-16 16:42:23 UTC
view on stackexchange narkive permalink

我去了一些基於項目的公司接受軟件開發商職位的採訪。他們往往會問的一個最常見的問題,也是最難回答的:

鑑於您手頭有一個項目,給出的截止日期是X天,而您要知道,無論您每天多麼努力工作,都無法熬夜,您將永遠無法在最後期限之前完成任務。客戶提到這是一個艱難的期限。

我應該給出什麼答案?他們希望聽到什麼?

[艱難的曲線球面試問題]的可能重複項(https://workplace.stackexchange.com/questions/2965/tough-curveball-interview-questions)
這是否是秘密探尋您是否同意定期進行全黑和無償加班?
X天?除非X是一個大數字,否則早就應該知道該問題。
十二 答案:
Neo
2019-08-16 16:52:04 UTC
view on stackexchange narkive permalink

我應該給出什麼答案?

此答案適用於軟件開發人員角色(無直接報告) :

這裡的簡單答案是真相。在這種特定情況下,如果您知道截止日期將得不到滿足,那麼最好盡快提供真相,而不是遲於。

基本上,他們想知道您不會掩蓋您不會按時完成任務並且不害怕尋求幫助的事實。

>
@Andrew,我不清楚您的評論。我理解這一點,但為什麼您會以中小型企業的身份來承擔您絕不會傳達您最了解的情況的知識呢?
@Andrew對於那種情況,這不是一個很好的解決方案。這是一個非常現實的問題,因為這種情況一直發生。人們說截止日期很艱鉅,但要滿足這一要求是不現實的。您所能做的就是推後推,說實話。您不能每次都退出。
有些公司可能希望您撒謊並束縛客戶,直到他們受夠為止,但我想大多數信譽良好的公司都會期望真相。理想情況下,應在客戶之前與管理層進行討論。
這就是為什麼我在面試中問這個問題,我想知道候選人會及時說出問題,以便我們做些事情,無論是擴大範圍,尋求其他團隊的幫助,甚至只是與客戶交談並準備讓他們失望。
@Andrew不,實際上不是。
這個答案是當場。真的就是這麼簡單。實際上有點擔心這個問題有多少爭議-在這樣的情況下,你們不僅表達真相嗎?為什麼不?
@Andrew:不行,面試問題假定管理層正在做一個合理的工作(即使只是在他們自己的眼中),但並不總是很了解情況。他們尋找可以在出現問題時正確地通知他們的員工,以便他們可以完成自己的工作,而不必擔心事情會被隱藏起來以節省面子。換句話說,該問題旨在過濾您要在假設中投影到公司的工程公司的相同問題行為。問題是由公司的各個層面引起的-出現問題時不說話的員工是其中的一部分。
@Andrew:當然,可以從問題擴展為候選人提出類似問題作為回報。但是,直接回答該問題而不嘗試回答訪調員所說的一個問題可能不會找到您。回答得好,然後詢問項目管理保障措施將是最好的
Kate Gregory
2019-08-16 16:56:01 UTC
view on stackexchange narkive permalink

通過重複在這樣的網站上給您的答案,您將永遠不會得到這樣的工作。您需要學習如何使用您實際參與的經驗和示例來用語言回答這個問題。也就是說,您可以找到一個更好的答案,下次再給他們。他們的關鍵是要了解他們為什麼要問。他們認為自己知道在這種情況下該做什麼和不該做什麼,並且他們想看看您是否也這樣做。

一個好的答案將包含兩件事。首先,您應該能夠輕鬆列出您的選擇:告訴客戶截止日期將不兌現,放棄工作的某些部分,諸如此類。並且此列表中不應包含無法正常工作的內容,例如將人添加到項目中。其次,您應該能夠解釋如何在這些選項中進行選擇以及如何在這種情況下進行交流。如果您只說“我願意X”,而沒有解釋為什麼用X代替Y,這不是一個好答案。

如果您要申請項目管理職位,他們會期望一些不同的選擇,並且比起您是否要在沒有PM支持的情況下申請開發人員的情況下,我會思考過程,但是基本的“我可以選擇X或Y,我不會考慮A或B,而我會根據Z”仍會存在。

如果您對此沒有一個好的答案,並且被多次詢問,請給自己一個好的答案。您肯定已經面對了嗎?即使您看到別人處理而不是自己處理?什麼起作用了,什麼沒起作用,您以前在那種情況下做了什麼?更好地講這個故事。

回答問題後,這也是一次機會,討論不要陷入這種情況有多重要,以及如何採取預防措施。這可能是定期的狀態會議,頻繁發布,抵制範圍爬升,監視進度或您在工作中學到的許多其他技術。面試官想知道你知道該怎麼做。

提示,下午的“鐵三角”是范圍,時間表,資源……靈活選擇其中之一或提早開始。他們基本上是在詢問您是否了解項目管理的基礎知識,儘管您顯然不知道,但是您可以學習...
在這種情況下,“早起”是什麼意思?
“此列表中不應包含無法正常工作的東西,例如將人添加到項目中”-稱為“布魯克斯法則,但有例外”(https:// en。wikipedia.org/wiki/Brooks%27s_law)。否則,以荒謬的程度來看,任何截止日期的項目的最佳人數是1人。另外,您是否建議您應該完全忽略不起作用的內容?如果是這樣,面試官怎麼會知道您將那些可能性視而不見(而不是可能只是沒有想到)?
我可能會說諸如“增加更多的人很少有用,所以這不是一種選擇”之類的話,然後繼續討論可能的事情。但主要要點不是說“我會從另一個團隊中邀請5個人來加入我們”,因為那是行不通的。一旦項目遲到,增加更多的人只會在以後。那不是有最後期限。
@mxyzplk-嗯...作為項目經理,我非常成功,儘管我確實知道範圍,進度和資源至關重要,但我不知道“鐵三角”是什麼。在我看來,凱特的回答是完美無缺的。這是一個經典的“失敗場景”問題,其目的不是測試開發人員的項目管理技能,而是測試他們的思維過程。
@KateGregory-增加更多的人可能會在以後製作該項目。布魯克定律的關鍵不是要增加更多的人總是使項目遲到,而是像阿姆達爾定律(我相信弗雷德和吉恩在IBM一起工作)一樣,增加更多的人(或核心...)可以增加事情例如“通訊開銷”。如果我需要增加人員來製定時間表,則應確保這些交互作用已最小化或不存在。如果那不可能,那么生活會很費力,需要時間來確定何時可以交付項目。
“早起”指的是,一旦受到限制,該項目將無法按時交付。
@GregoryCurrie“ Punt”來自美式足球(不是足球!),在這場比賽中,一支即將丟球的球隊故意放棄它,但將球踢到盡可能遠的低場。我們也說負主要責任的人有球。因此,平底鍋就是將問題轉嫁給其他人。提早下賭注是為了避免解決問題,請儘早通知主管。
Simon B
2019-08-17 02:09:52 UTC
view on stackexchange narkive permalink

作為軟件開發人員,與客戶討論這類問題不是我的工作,而作為軟件開發人員,我個人無能為力。問題。

因此,唯一明智的選擇是盡快與項目經理聯繫,以使他們意識到存在問題,並與他們討論如何做才能使項目恢復正常

答案可能是為工作分配更多的人,與客戶協商一個更晚的截止日期或其他幾種選擇。但是這個決定不是我的。

這個答案正好說明了人們為什麼提出這個問題。如果您在沒有項目經理和期望軟件開發人員處理的地方進行面試該怎麼辦?這個答案將使您的應用程序不再需要考慮。(您對此可能會感到放心。)
@KateGregory,我相信您的批評是雙向的。如果您在一個*有人*負責管理與客戶關係的地方進行面試怎麼辦?直接將此消息傳遞給客戶而不與團隊或其他負責方協調的情況將是非常糟糕的形式。如果我的一位開發人員直接將這種事情告訴客戶,我會很高興。
你是對的。答案顯示了受訪者對工作場所的期望。對於任何答案,有些工作場所將非常適合該工作場所,而有些則不會。如果公司希望項目經理能夠解決這個問題,而開發人員則不會這樣做,那麼這個答案將使您被雇用。
@KateGregory然後,採訪成功地完成了雙向任務。
這就是我最初評論的重點。對不起,如果不清楚。
@JohnWu:僅僅因為我展示了管理項目工作的能力並不意味著我完全拒絕由專職經理來管理項目工作。
Joe Strazzere
2019-08-16 17:10:32 UTC
view on stackexchange narkive permalink

或者他們希望聽到什麼?

他們希望看到您如何思考和處理此類問題。

他們不想看到您嘗試告訴他們您想听到的內容。他們不想听罐裝答案。

這很困難,但是請不要猜測他們想听的內容。取而代之的是,聆聽問題,仔細思考,然後誠實回答。嘗試讓自己處於擺出的姿勢,並告訴他們您將如何應對。同樣的事情。

我對此表示懷疑。我懷疑答案中有一個或也許只有少數,比所有其他答案都“正確”得多。
@SouthpawHare-不,因為目標確實不是“答案”。“不可能的問題”總是關於檢查候選人的思維過程。如果是在這種情況下,我會問面試官2或3個問題,以了解公司項目和客戶的性質,然後針對這種情況調整我的答案。不會背誦2或3個固定答案中的一個,例如“我將協商一個新的功能集,這將在分配的時間內實現,並為各方帶來最大的利益。”聽起來很像“我想要一隻小狗”。
Peter M. - stands for Monica
2019-08-17 01:36:12 UTC
view on stackexchange narkive permalink

有趣的是,這是一個問題,我的回答(我認為)給了我以前的工作之一。這不是一件好事,因為那裡的情況很普遍。但這對這項工作很重要(應該給我一個提示,不要接受它。)

我提到了我們參與的一個項目所做的事情:

不可能的情況:在一家小公司中,我們需要這份合同才能使我們在接下來的幾個月中繼續生存。這是我們想要實施的(會計)系統的擴展,但是完成它的截止日期是不可能的。因此,無論如何我們都以最好的猜測開始實施它,並發布了一個大文件,其中包含許多問題,詢問他們如何確切地實現新功能。然後我們告訴他們,我們將在X個月後收到最終答案。

猜猜是什麼:他們花了個月彼此之間才真正確定了他們想要的東西,而我們正在實施最佳猜測。我們獲得了合同,並從客戶那裡獲得了一些里程碑式的付款。在大多數情況下,我們猜對了,在少數情況下,我們不得不重新設計,很少有功能推遲到第二階段,但是公司倖存下來又奮鬥了一天。

我不確定您是否可以偽造這樣的答案(因為這是一個真實的戰爭故事,如果您沒有經歷,任何後續問題都可能將您透露為假貨。

在生死存亡的情況下,您被迫懷有希望你會很幸運,因為如果沒有,公司總會死的。沒有人寫過數百家失敗的創業公司的文章,只提到了成功的公司。請參閱生存傾向偏差-您以為自己會生存。

偉大的策略很好地突出了導致錯過最後期限的最常見原因之一:客戶不知道自己想要什麼,他們只是知道自己想要什麼,而開發人員的經理則不要求客戶提供重要細節(按順序(使銷售更有可能),因此對開發人員而言,需求幾乎帶來了比他們要解決的更多的疑問,因此開發人員將做出太多的猜測和假設。如果在設定了最後期限之後,客戶需要幾個月的時間在彼此之間達成他們真正想要的東西的共識,那麼讓開發人員猜測這反而會變得更好。
@SantiBailors-我並不是說嘗試猜測是“更好的”。我說的是,在客戶思考答案的同時進行猜測和發展,比“失去公司賴以生存的合同更好”。
與我的意思相比,我認為我的觀點顛倒了,這絕對不是想猜測會更好。我想說的是“很難再變得更好了”。
Thomas Matthews
2019-08-17 01:53:26 UTC
view on stackexchange narkive permalink

根據團隊軟件流程(由卡內基梅隆大學提供),一旦團隊知道無法按時完成任務,就需要與利益相關者進行溝通。這使所有感興趣的各方都可以重新計劃,刪除功能或採取某些措施來解決問題(不符合截止日期)。

根據小弗雷德里克·布魯克斯(Fredrick Brooks Jr.)的《神秘人月》,將更多的人添加到一個項目中不會縮短進度。

在項目管理方面,存在一個三角形,其中包含範圍,時間和預算。如果一側改變(長度),另一側也必須改變。

因此,回答訪調員的問題:

  1. 根據當前情況計算新的截止日期。確定成功達到期限的可能性。
  2. 計算完成剩餘需求所需的持續時間。
  3. 通過添加項目資源來計算新的截止日期。最多1人,最多5人。
  4. 召集與利益相關者的會議以討論情況和重新計劃。使用上面#1,#2和#3中的信息。
  5. ol>

    #1,#2和#3中的信息應來自團隊成員(進行工作)。它們最接近項目,並且可以提供最高確定性的信息。

    恕我直言,僅在完成時間較少時才計劃加班。無法保證加班會提高產品質量;有時加班可能會帶來更多問題並延長時間表。

    在我工作過的一家商店中,為了減少進度,從項目中刪除了需求。

Gregory Currie
2019-08-16 16:57:36 UTC
view on stackexchange narkive permalink

如果我的職位是項目經理

,這就是我的答案:如果我認為我們不能按時完成任務,那麼我首先要確定

然後我應該去我的管理層,我們可以一起進行評估,以確定是否有必要花費額外的資源才能達到目標要完成該項目。

如果管理層要求增加資源,我會去諮詢客戶並說明情況,並建議縮小工作範圍,直到可行為止在時間範圍內。我將與客戶一起對工作進行優先排序,以確保將對客戶的影響最小化。一組可交付成果,它們限制了對我公司聲譽的損害,此外,還施加了任何經濟處罰。我會很清楚地告訴客戶在那個時間範圍內將交付什麼,以便減輕客戶的影響。

我想在某些情況下,當客戶意識到他們會更願意接受重新談判時他們不會得到他們想要的一切,他們想更好地控制自己得到的東西。他們可能也願意推遲“艱苦”的截止日期。

很顯然,令人遺憾的是,任何項目都將在最後階段出現重大驚喜。理想情況下,我們將跟踪進度,這將使我們能夠逐步修改工作範圍,以確保滿足最重要的要求。

抱歉,我之前沒有澄清我正在面試軟件開發人員的職位。
@tnkh然後,這種情況對您來說要容易得多。您需要與主管討論並誠實。
我同意這個問題最適合項目經理而不是軟件開發人員。您只是不能讓每個項目開發人員都與客戶進行獨立交談。即使您是一個單人商店,您也將扮演多個角色,例如,作為項目經理,作為開發人員。
Mast
2019-08-17 16:14:14 UTC
view on stackexchange narkive permalink

我以前有類似的問題,所以並不少見。在我看來,唯一正確的答案是遵循以下原則:

可能會出現em> ,而不是不可能。

知道您將要失敗,無論如何都要這樣做是錯誤的答案。如果無法完成,則無法完成。但是,您會經常遇到看上去的情況,就像他們要您去做不可能的事情。

這裡的絕對關鍵是要找到可能的 從那里工作。這不是關於硬軟件工程的問題。這是一個關於管理期望,處理意外情況以及將項目保持在一起的問題。

這還意味著他們所尋求的不僅僅是那些只編寫代碼的人。他們正在尋找具有管理能力的人,或者至少正在尋找是否具備這些能力。因為無論您給他們什麼答案,如何您給他們的答案都會告訴他們很多您對項目的看法。

可能的後續行動可能是(他們提出的問題,或者如果他們期望得到長久的回答,則是您的回答))如何處理後果並減少再次發生的可能性。

gnasher729
2019-08-18 00:26:56 UTC
view on stackexchange narkive permalink

所以有最後期限,不可能滿足。無論您回答什麼,無論您做什麼,都不會發生的一件事就是您在截止日期前完成。您和您的經理可以執行以下操作:

  1. 盡快告訴您的經理,讓他們有機會將損失降到最低。錯過10,000美元財務損失的最後期限比錯過100,000美元財務損害的最後期限要好得多。

  2. 不要驚慌,冷靜下來並使其他所有人冷靜下來。說真的在那種情況下,我看到成年人像無頭的雞一樣四處飛舞。我年輕的時候就做過同樣的事情,並從中學到了東西。現在我知道,您可以將問題從無法解決的“我如何滿足無法滿足的最後期限”更改為“如何最大程度地減少損失”,而不是四處走動。

  3. 不起作用的方法是嘗試著急,或者試圖增加更多的人。有用的是讓人們做次要的事情。例如,如果您應該編寫代碼並進行嘗試,則可以編寫代碼,而其他人則可以嘗試。經理可以使用的另一種方法是提高工作時間的能力。離我的工作場所100米有一家不錯的酒店。如果老闆付錢給我留在那家酒店,並命令健康食品在午餐時間到達,而更多健康食品在下午5點到達,我可以做更多的工作。有一次,有人必須在我家裡來運送家具。我的老闆太太做到了。她不開心,但是我的老闆需要我工作。這種事情也很激勵人。

  4. 有兩種顯而易見的方法可以提早完成:降低質量和簡化功能。這需要討論。

  5. 有一個顯而易見的方法來滿足人們經常忘記的截止日期(因為請參見第2點):移動截止日期。截止日期極少。參見Peter M.的巧妙方法。恭喜您能實現目標。通常更容易進行談判。這可能比您高一到兩個級別。但是,如果您向客戶明確表示他不可能在承諾的時間拿到承諾的東西,那麼他們可以選擇延長截止日期或什麼也沒有得到。

  6. 我希望這不會成為現實,但是第一隻跳下沉船的老鼠有最好的生存機會。

  7. ol>
Joshua
2019-08-18 05:06:48 UTC
view on stackexchange narkive permalink

我覺得其他一些人構建的“硬期限”太弱了。

我從來沒有擔任過PM,但是在不止一次的情況下,我不得不把真相告訴了首席執行官在其他所有人(包括應該認識的總理)都保持沉默的時候。我們有某些法律要求,並且當法律要求發生變化時,我們必須更改我們的法規以使其匹配,並且最後期限由政府設定。事實是“那天已經過去了。”

我去那裡已經很長時間了。我知道從內部工程發佈到生產需要多長時間。我剛剛查看了測試日誌,就知道測試需要多長時間。對於返回失敗測試的項目數量,我有一個很好的估計,使用較低的數字表示周轉時間,使用非常好的數字表示重新測試時間。我把數字加起來,結果說我們有-1天的時間可以繼續開發。我不記得對這一切的解釋是如何進行的(立即發生),但是我只記得我的開場白。

由於源代碼控制的局限性,管理層之前並不關心。並沒有決定放棄完整的功能來減少測試時間,因此無法改進這些東西。

我無法告訴他們他們實際上可以期望多少天,因此他們沒有接受我的回答。但是,在下週的監管要求功能的內部演示中,管理層要求對其進行全面更改。走吧。

我們最終交付了一個半月。

grambo
2019-08-18 08:10:24 UTC
view on stackexchange narkive permalink

在岩石和堅硬的地方之間?站在另一端,在截止日期的1/2天內為客戶提供部分功能演示。您將使他們措手不及,並將其拉入對話。每週帶他們來討論那一周增加了哪些功能,您將很快了解到他們的需求並不是他們所需要的100%,並且在截止日期臨近時,您可能已經有了可以使用的“功能”,即使其80%的功能正常,您也將在瀑布競賽中遙遙領先。

user108032
2019-08-18 00:24:12 UTC
view on stackexchange narkive permalink

一言不發,最好的選擇是考慮在該項目上進行更多工作,這是浪費時間,而是跳到下一個項目。這不是軟件開發人員要做出的決定。

這在現實生活中不會發生。我曾經遇到過這樣的情況,而解決方案基本上是給客戶他們想要看的東西。從不可讀的數據(格式不正確但不是故意的)變為偽造的數據(通過編寫例程生成或測試的數據),再到通過人工干預準備的東西,再到手工選擇的工作示例,再到真實的東西。

這可能涉及與實際簽約的公司合作,以說服下游接收者也玩等待遊戲:東西看起來應該看起來像是缺少的東西很少,所以放棄是沒有意義的。

我已經從不稱職的承包商那裡轉包了合同,這些承包商具有良好的業務關係,並且支付得很好,主要的優先事項是始終保持您的資產安全,安全地計算截止日期並提供工作和有據可查的材料,以便您每次都簽署因為治理項目肯定是要墜機了,而且您不想成為倒塌的起落架下的替罪羊。

這種垃圾大火在“艱苦”的任務執行兩年後就被取消了dline,在我交付和收集很長時間之後。這就是為什麼對硬性截止日期的確定失敗的正確反應很少放棄的原因:某些截止日期可能會觸發人們想要避免的處罰。但是永久終止正在運行的項目的截止日期很少,最終決定很可能在您不知道的時候落空。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
Loading...