題:
刪除了2天的工作且沒有備份
user15704
2018-05-03 19:59:12 UTC
view on stackexchange narkive permalink

我刪除了我正在做的工作,但沒有將其添加到SVN中,明天我將進行性能評估,並且我已經提到我感到壓力很大,因此進展緩慢。現在有這個問題,我應該告訴我的經理嗎?我可以做到,但是如果不能,我是否必須在日常工作中報告?如何向經理解釋發生了什麼事?

評論不作進一步討論;此對話已[轉移至聊天](https://chat.stackexchange.com/rooms/77025/discussion-on-question-by-cookiemonster-deleted-2-days-of-work-and-no-backup)。
十 答案:
Summer
2018-05-03 20:07:23 UTC
view on stackexchange narkive permalink

這是一種非常不幸的情況,但是由於您無法再進行更改,因此使其成為寶貴的經驗。

我是否必須每天進行報告?

是的!。如果您不敢告訴您的團隊,請從Scrum管理員或產品所有者開始。透明和誠實是Scrum的關鍵要素之一。您對團隊負責,團隊對您負責。與您的團隊討論問題,他們需要重新評估時間表和故事點,並可以幫助您清理混亂。

我必須告訴我的經理嗎?

從不對您的經理撒謊。如果她/他有要求,請給出誠實的答案。 但是,請確保您已準備好後續回答。您(和您的團隊)將如何解決此問題?將來如何避免類似的問題?

如果有幫助,您可以從“我今天學到了非常有價值的一課”開始。。。然後嘗試盡可能高效地重新創建工作,並開始將文件添加到版本控制中,而不是等到工作快結束時再做。
在親自解釋了問題並使其獲得積極的體驗(或盡可能使之成為最佳體驗)之後,我會在幾個小時後或週末根據自己的時間重新創建自己的作品,以重回正軌。您的16個小時很可能會部分地花在電子郵件,日常工作活動,其他同事,支持等上。由於您一旦想到,便已經做到了。您應該能夠快速復制它。
此外,如果需要由IT組織的中央備份(不僅是您的計算機,還需要其他組織),那麼這可能是帶頭並滿足這一需求的好時機。
-1
也許@rackandboneman,但是OP應該謹慎行事。他們可能被認為是在試圖怪罪,即使這是一個公平的立場,也很少會下跌。我想說的是,這段對話最好留給以後。
確實..永遠不會說謊..我在謊報錯誤等之前曾與一個項目的開發人員合作過。可怕的隊友。人們會誠實地欣賞。
@AndréParamés向上推銷責任,而不是轉移責任:)
Sabine
2018-05-03 20:07:10 UTC
view on stackexchange narkive permalink

我發現通常最好對自己的錯誤負責,無論是在日常站立會議上的團隊還是經理。現在,性能審查的時機有些糟糕,但是如果這是您第一次犯這樣的錯誤,我認為這不會是一個大問題。

我會盡力(並交流)以盡快彌補丟失的工作,因為這是您的錯,並養成了定期保存到SVN的習慣

Rob P.
2018-05-04 05:21:58 UTC
view on stackexchange narkive permalink

幾件事。...

首先,至少根據我的經驗,您的效果評估可能已在幾週前完成,並且有相當的機會在您甚至還沒有接受其他人審核之前看到它。特別是如果它與工資調整掛鉤。如果您擔心這會破壞您的評論,那麼您可能會很清楚(儘管可能會出現在下一個評論中)。

第二個刪除的文件不一定消失,數據很可能仍然在磁盤上。至少,我會運行一些恢復軟件。如果您更傾向於技術,請關閉計算機,從某些外部介質啟動,然後使用工具掃描磁盤以查找丟失的文件。我的意思是,這取決於您對工作站的訪問級別。如果您處在無法解決或不知道如何解決的情況下,那麼可能值得聯繫之前可能已經處理過此問題的IT人員。

最後,作為一名前經理,最糟糕的事情就是嘗試隱藏它。人們會犯錯誤,不進行溝通會使它成為更大的錯誤。您可以盡快與經理交談。解釋發生了什麼,解釋您如何理解自己的錯誤,以及如何確保不再發生該錯誤。

嘿老闆-看來我犯了一個錯誤,意外刪除了大約兩天的工作。我無法提交/備份/存儲對源代碼管理的任何更改;我知道我應該有,我真的很抱歉。將來,我會更加小心,確保不會發生這種情況。

我知道我們的時間表很緊,我想盡一切努力改善這種情況。刪除的文件有可能是可恢復的,您是否希望我嘗試使用“取消刪除”軟件來恢復它們,或者與IT部門的人交談?否則,我將盡我最大的努力來重做我的工作,自從我完成工作以來不應該花兩天的時間,但是它會增加(無論您想多久)我的時間表。

如果是文本文件,將很難找到它們,但是`grep`會在原始塊設備上完成這項工作。
為“已刪除的文件不一定消失” +1
Zibbobz
2018-05-04 01:43:36 UTC
view on stackexchange narkive permalink

是時候學習任何員工都可以使用的最強大的工具之一。

向您的同事尋求幫助

我了解恐懼-您犯了一個大錯誤,並且您擔心會產生的影響。而且您不知道是否有任何方法可以從此錯誤中恢復過來。

這就是為什麼您絕對需要盡快(盡可能徹底)向您的主管報告此問題並尋求幫助的原因。

不要只說“我犯了一個錯誤,現在工作已經不見了,救命!”因為那看起來糟透了。相反,請準確地說明您所做的事情,不要找藉口。

說明:

  • 您正在做什麼(無論您打算做什麼)
  • 在失去工作之前所做的事情(這是非常重要)
  • 您嘗試進行 恢復操作的步驟(您必須聲明這些內容,以便可以證明自己做出了真誠的努力自己解決這個問題)
  • 請求幫助(如果您知道某人在這種事情上是“好人”,則可以按姓名要求他們的幫助)

通過解釋發生了什麼事情以及如何發生,您還可以通過將信息提供給將幫助您解決問題的任何人來幫助解決問題。通過說明您自己修復此問題的步驟,您可以證明自己是真誠地嘗試對其進行糾正的嘗試。

最重要的是,通過承認自己犯了一個錯誤,表明您已經足夠成熟,可以克服過去對錯誤的尷尬並找出問題的答案。這不僅僅是良好的職業道德-這是成熟的本質。

那不是一個大錯誤,而是一個中等大小的錯誤。丟掉自己兩天的工作很煩人,但這件事對我們所有人來說可能都是一次。
-1
delliottg
2018-05-04 02:03:18 UTC
view on stackexchange narkive permalink

作為過去這樣做的人,我現在要做的是減輕這種情況再次發生的可能性。

  • 首先,告訴您的經理,並解釋一下您將在以後做以防止這種情況發生。他們有權知道發生了什麼,並且對此不會感到高興,但是,如果您將來有解決方案來防止這種情況發生,他們(應該)將其視為寶貴的經驗教訓。
    向您的經理提出問題,但是沒有解決方案,這在很大程度上浪費了他們的時間。他們的工作不是解決您的問題,而是消除障礙,讓您可以自己解決它們。

  • 正如其他人所指出的,如果可以,請經常進行更改。但是,我公司有一條規則,即您不能檢入不起作用的代碼,那麼當您擁有不想丟失的中間/中間代碼時該怎麼辦? 備份。我的計算機中有一個備用驅動器,可以運行自動備份。它基本上是每晚對我的工作驅動器進行快照。我還手動備份到網絡驅動器(該驅動器本身每晚都會自動備份)。我每天離開時都會運行一個小的備份腳本,它會對我的現有文件進行增量備份。然後,我隨身攜帶了一個USB隨身碟,我也每周大約備份一次。第二次(通常)要容易得多,而且更快。您知道自己想寫的東西,已經經歷了思考過程才能到達目的地,因此與第一次重新創建相比,記住起來要容易得多。

  • 也就是說,我完全不同意“ 這些事情總是發生。不用擔心。”。實際上,它只會發生在您身上一次,這是您的學習失誤,然後再也不會發生,因為您現在已經制定了緩解計劃。繼續犯類似的錯誤是業餘愛好者的標誌,作為專業人士,您有責任向公司學習錯誤並發揚光大,而不是重蹈覆轍。

“但是,我公司有一條規則,即您不能檢入不起作用的代碼,因此當您擁有不想丟失的中間/中間代碼時該怎麼辦”。這是一個非常恐怖的規則,但是我認為實際上是“不要將未工作的,未經測試的代碼提交到與他人共享的分支中”-這是一個“偉大的”規則。
解決方案不是讓每個開發人員都推出自己的備份解決方案,而是要教育人們如何創建自己的功能分支。過去20年中,每個流行的源代碼控制系統都能夠做到這一點,即使SVN或TFSVC之類的系統比其他系統更麻煩。
@Voo OP使用SVN(這是集中式版本控制,而不是像git這樣的分佈式版本控制。)初級開發人員很可能無法在中央存儲庫上創建私有分支,更不用說壓扁和重新構建非工作提交以使其正常工作提交。在任何情況下(尤其是在這種情況下),源代碼管理都不能替代備份。所以+1到delliottg
@QSigma為什麼您不授予開發人員創建新分支的權限?這聽起來像是可怕的做法,絕對沒有好處-創建分支沒有任何危害(您確實希望為分支命名協議以避免衝突,但對於git這樣的DCS也是這樣)。OP是否具有將更改直接直接合併到master分支的權限是一個不同的問題(最好有一個審核過程需要團隊成員的批准),但在這裡無關緊要。
為何將推送到由負責部門安全備份的中央服務器的源代碼控制不是備份?我從來沒有在一家必須使用USB記憶棒進行代碼備份的公司工作(事實上,我出於安全原因在一家公司工作過,否則會被解僱)。**您需要使項目正常運行的所有內容,要么應檢查到源代碼管理中,要么可以從其他中央資源獲得-私人備份毫無意義,如果其他人必須繼續處理您的項目,他們也將需要所有這些東西!
@Voo我不知道SVN擁有如此細粒度的權限,所以您已經教育了我,謝謝。但是我聽說許多組織只允許提交到現有SVN分支。這裡有一些關於備份與源代碼控制的討論:https://stackoverflow.com/questions/110313/how-to-make-sure-my-git-repo-code-is-safe
@Qsigma:該帖子的開頭與Voo關於“推送到中央服務器的源代碼控制”的觀點相同。然後轉向討論分散系統。
Level River St
2018-05-05 16:55:23 UTC
view on stackexchange narkive permalink

我會盡力而為-“我刪除了2天的工作,但我想我可以在1天之內恢復工作。”

我認為您應該可以恢復在一天之內,我們都會誤刪所有工作(尤其是在壓力下),並且由於涉及的思想較少,通常比第一次花費更少的時間來

進行一些您不知道的自動備份,使您的經理可以恢復您的工作(使用git不太可能,但是您永遠不會知道。)

您的績效評估基於(我假設)至少需要6個月的工作,因此我真的不會擔心。另外,績效評估(不幸地)僅與加薪有關!

John Wu
2018-05-04 03:06:20 UTC
view on stackexchange narkive permalink

這是另一個要解決的問題;顯示您正在解決問題

我應該告訴我的經理嗎?如何向經理[或任何人]解釋發生了什麼?

取決於經理。我的經理不想听到類似的細節。

如果您的經理不想听到這樣的事情,您應該告訴他。保持技術水平-您沒有“草草”,正在解決“代碼管理問題”,並通過增強流程來避免將來出現此問題。問題是意外刪除。它發生了。您不必做大事,他可能也不會。只要確保您有一個切實可行的計劃來避免將來再使用它即可。

我可以做到,但是如果我做不到,我是否必須在日常工作中報告?

在日常工作中,您必須報告您昨天所做的工作,正在做的工作以及是否有任何障礙。昨天您正在對該功能進行編碼。今天,您將繼續努力。您沒有障礙-您可以在沒有外部幫助的情況下前進。除非有人問,否則您實際上並沒有義務說為什麼花這麼長時間。

當我領導團隊時,我希望在這方面給開發人員一些隱私,因為確實會發生這種情況,並且只要您達到目標並且不需要幫助或指導即可由於存在長期問題,團隊的其他成員無需知道詳細信息。您的領導可能會有所不同,因此請遵循他的領導。

sarmahdi
2018-05-04 04:52:03 UTC
view on stackexchange narkive permalink

最近這件事發生在我身上,發生在截止日期之前。這是一個新項目,所以我應該將其添加到git中,但沒有添加。幸運的是,這是一個帶有分發文件夾的Maven項目,並且在那裡出現了Java戰爭,所以我反編譯並重新製作了該項目。我確實告訴了總理,但也告訴他我已經解決了。 (有時)可以在較短的時間內復制兩天的工作效率,因此不必擔心已經完成的工作。

(編輯)我之前未提及的內容,請保持整潔。如果您刪除了某些內容,並且有可能被延遲,那麼最好將其清理乾淨並通知您的經理。我建議先嘗試找出要復制您的工作需要多長時間,以便您有問題(需要丟失代碼/進行返工)以及可能的解決方案。

雖然有相關經驗,但我不確定這是否能回答實際問題。
@MadPhysicist:是的,我添加了一個編輯
HopefullyHelpful
2018-05-06 14:32:08 UTC
view on stackexchange narkive permalink

編程主要涉及計劃和理解代碼及其基本規範。

即使您花了2天的時間編寫代碼,也應該可以在更短的時間內完成代碼。

p>

認真對待,請確保向您解釋,您將需要更少的時間,並且願意在必要時加班進行補償。

Drag and Drop
2018-05-04 13:41:12 UTC
view on stackexchange narkive permalink

問題解決之後:現在似乎是時候更大規模地審查備份計劃了。

一個智者曾經告訴我:

“在良好的基礎設施中,您必須進行電梯測試。” >

在大多數國家,電梯的監管是嚴格的。電梯的安全性基本上建立在以下方面:
檢測器>電氣安全>手動安全性

電梯的測試非常簡單,我們將逐一測試我們的安全性。嘗試通過以下測試使其與地面接觸(也必須測試底部的彈簧)。

全速自由落體+滿載->觸發檢測器。
全速+滿載->不帶檢測器以觸發電安全。
全速下自由落體+滿載->不帶電安全以觸發手動安全性。
全速下自由落體+滿載->無安全性,它被啟動。
與超速相同->進入彈簧。

在完全擦除後,有多少人曾經測試過備份,只是為了確定備份過程可以進行?

在備份工作中,他們採取的步驟很少

使用SVN等支持項目,使用Dpm等支持工作計算機並在外部進行支持。

我看到社會能夠在洪水,火災和惡意事件中倖存下來。即使他心髒病發作,蜜蜂也能救人。能夠從不斷發展的tfs / svn的一名開發人員中恢復過來。

這與錯誤無關,即使您願意,也應該不能這樣做。總而言之,計算機狀態必須安全。

這根本不是問題的答案。當某人剛剛被天空炸毀時,告訴他們“不要被閃電擊中”是沒有用的。
對我來說,問題是:我燒傷了手指,我該怎麼辦。我的答案是:何時修復。嘗試使您的房屋更安全地使用消防水和閃電
那麼,您的帖子根本無法回答問題。“我該怎麼辦?沒有通過“一旦燒傷burn愈,不要放火”來回答。
此答案在面向技術的網站上會有所幫助。但是,該網站是關於人為因素的。問題不是“我該如何預防”,而是“我如何告訴我的經理在不影響下一次績效評估的情況下發生了什麼”。


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