您應該與您的老闆交談，並要求他在每次打算退職時給您打電話。您的老闆很忙，但是如果他可以花時間聽他講話，那麼他可以花時間聽您講話。如果這些轉變持續不斷地受到挑戰，那麼他對您的能力的感知就會變色，並且您很可能會在績效評估時聽到一些關於您自己的不愉快反饋。

您目前的優先重點是總結一句話：訪問。每當老闆在辦公室要求換班時，您絕對需要在老闆的隔間或辦公室。如果您不在那兒，就沒有機會解釋為什麼做這些事情，或者為什麼做出自己的選擇。即使您提出自己的觀點，他們也可以還原您所做的更改，但它們並不能使您作為稱職的專業人士公信力。如果有辦法解決同事的瘋狂行為，您需要傾聽並挑戰，以便在公平聽取所涉及的觀點的基礎上做出決定

不要讓自己對自己的瘋狂感到沮喪老闆懇求他沒有時間，而您正在遠程工作。您必須要求訪問。讓您加入Skype並成立GotoMeeting或電話會議對其進行哈希處理並不會傷害您的老闆。我認為您在此站點上是因為您已經厭倦了數小時或數天的工作被淘汰，更不用說重做整個事情了。因此，您需要向老闆聲明您需要參與，因為這樣的工作流程效率很低。如果老闆對您不耐煩，您不希望在績效評估時或什至之前不知道他們想要哪種方法

關於聚會日討論的話題：您正在問老闆，下一次他們談論您的代碼並還原它-您是討論的一部分。這是您的代碼，並且您知道您的同事想要還原哪段代碼，因此您確切地知道討論的主題以及您要說的內容。保持討論集中在技術方面。無需談論同事個性的吸引力較弱的方面。您正在建立並維護自己的專業信譽，沒有它，您將無話可說

Vietnhi Phuvan的回答很好，但我認為首先要做的是：與同事交談。

所以你說你的同事已經在這個項目上工作了多年，但是後來你承諾他會做些什麼不同意。也許他以前沒看過，但這就是問題所在。他很有可能對產品和代碼基礎有更好的了解。

在實現您的修復/功能之前，您應該仔細檢查他的設計是否可以與體系結構很好地集成。那麼您可以要求進行快速代碼審查，以確保他看不到任何可反應不良的可疑信息……

從技術上講，您可能和他一樣好，但是他絕對了解更多產品，因此他的意見極有可能會被實施（這是公平的還是不公平的是另一個問題）。

如果這樣做，您的老闆就不會再有任何問題了。 。如果您的同事實際上還是豎起大拇指時仍然發生這種情況，請應用Vietnhi Phuvan的答案。

PS：如果您在遠程工作。您可以只問Skype等...或進行更正式的審查。

在這種情況下，這是在浪費時間。

首先，您是在浪費時間實施功能，這些功能不僅不必要，而且在同事看來還很糟糕，需要刪除。

其次，您的同事在代碼事務上浪費了老闆的時間。

交互表明您的開發過程存在一些問題。

1. 誰輸入了票證進入系統？誰審核和批准門票？誰分配他們？大多數票怎麼辦？誰來指導開發過程？誰的願景正在實施？誰是客戶？
2. 開發人員為什麼要去老闆“撤消”門票？開發人員為什麼不互相討論問題，然後向老闆展示統一的面孔？為什麼開發人員為什麼沒有權力做出這些決定？
ol>

浪費的工作，尤其是在情況不罕見的情況下，是一個嚴重的問題。

我去老闆並提出以下一個或多個要點和建議：

• “我已經實施了幾項隨後被刪除的任務。如何驗證我將要處理的任務是在花時間之前是有用且必要的嗎？有沒有更好的方法來分配任務，以便將我的同事似乎非常了解的那些任務分配給他而不是我？我們可以每週或每天一次站起來嗎會議討論我們打算處理的任務，以便那些具有特定信息的人可以完成給定的任務？“
• ”我們可以調整流程，以便在團隊成員之間進行回滾之前進行討論這個問題給您解決了嗎？這應該可以減輕您的工作量，並使我們所有人都在同一頁面上。“
• ”在完成一項任務之前，我們是否可以讓每個任務至少由兩個開發人員批准旨在確保任務有用，並且任何回滾都必須包括與批准該任務的人員的討論，以便我們可以以團隊的形式而不是單個地進行課程更正？'

老實說，似乎嚴重缺乏溝通。這可能是因為沒有領導力或遠見。

如果不採納上述建議，則可以接受它，也可以嘗試作為團隊急需的溝通方式。

每次發生這種情況-無論對您還是對其他任何人-嘗試以下一種或多種方法：

1. 與被罰單的人交談。向他們詢問為什麼要刪除它的背景。找出故障單和功能列表之間是否存在衝突，或者這是他們對產品的個人看法。
2. 與創建故障單的人交談。傳達您在上一步中學到的信息，並了解他們是否意識到這一點。詢問他們票證要管理的功能或問題。
3. 確保所有這些信息都已收集在設計文檔中。
ol>

從本質上講，您將成為信息中心，您就可以積極地移動信息和團隊的遠景，從而使每個人都在同一頁面上。通常，無需進行流程更改或批准即可完成此操作，但這很耗時。

最後，如果您想阻止人們刪除任務，請與任務進行長時間的討論。將您的椅子帶到他們的辦公室，並與他們真正互動，確保您完全了解正在發生的事情。不要僅僅接受快速的簡單答案並繼續前進，而是要真正表明您想了解項目的總體願景和理解。

這可以完成三件事-第一，您花費時間，最終他們將了解到，除非值得您花時間與您交談，否則最好滑動一下。第二，您將獲得他們對產品/項目的願景，並希望隨著時間的推移他們將獲得您的願景。第三，你們之間的關係有望改善，它們將不再直接向老闆，而是向您發展。

總是友好而謙虛，但要為您理解產品/項目的願景而奮鬥。如果很明顯他們正在定義項目，然後與他們交談並傳播這些信息，這將是統一團隊的最佳選擇。

最後，所有這些交談都應該使您了解您的票證是由您提供的他們很可能會拒絕的桌子。在處理這張票之前，先去問問他們這張票是否似乎是他們稍後會試圖殺死的一張。

問題：我的同事做的事情真煩人，我沒有和他談過。我該怎麼辦？

答案：和他談談。 （他指的是他，而不是您的其他工人，老闆，人力資源。）

這始終是專業工作場所的答案。顯然，您總是會仔細而專業地進行對話。我真的認為答案的大部分應該像這樣簡單。

但是，還有其他附帶問題需要解決。我討厭得出結論，但您的同事有可能會認為您的貢獻不是很好，這就是為什麼他們不真正尊重他們的原因。在進行了上面的直接對話之後，您可能還想問一個直接的問題，即您的貢獻是否有點糟，這就是為什麼這樣的情況。您應該這樣做，因為這是很多人非常不舒服的事情。您甚至可以通過改善溝通來“解決”這個問題，但無法發現這個更嚴重的問題。

如果他們確實認為您的某些更改很爛，那麼您需要緊緊抓住這一點。但是，解決該問題是一個完全不同的問題，我認為這裡討論的距離有點太遠了。

我同意Vietnhi如何開始掩蓋您的...聲譽。

您還應該要求一個更好的流程。我將保留提倡流程更改的實際細節，並專注於目標。

如果您的代碼通過了測試，那麼應該足以勝任前沿開發分支（根據開發分支的定義），甚至有一些很好的理由也不發布它。在我看來，恢復更改似乎是一種過度反應，除非您的公司在其褲子旁邊放任版本控制。這取決於您如何使用源代碼控制，但是通常來說，如果有問題，他不需要還原它，他應該不接受它。

如果代碼沒有通過測試，那麼您的流程需要停止它到達可能造成破壞的地方。大概這就是您的同事試圖通過還原它來實現的目標-但存在過程問題。如果他必須還原它以防止問題，那麼為時已晚，它已經存在於可能導致問題的地方。您可以在提交之前 而不是之後進行代碼審查（這很愚蠢，但是也許使用源代碼管理的方式很愚蠢，所以這是最好的）。您可以使用更多的分支，以便您的同事可以查看和抱怨代碼而無需還原。

您可以更改測試/票務系統，以便對可以解決當前票證但由於其他原因而不好的更改做出的正確響應是添加捕獲“其他原因”的測試，而不是還原更改並從頭開始重新製作原始票證。特別是，如果他在您按照先前已知的要求工作的同時從管理層發現了新的要求，那麼他應該經歷某種要求變更過程（也許只是提出新的要求， “要求已更改”）。該過程不僅要拋棄所有依賴於先前需求的工作：這不是應對新需求的好方法。

此外，如果您經常處在做大量工作的位置的工作而又不知道它是無用的，那麼在開始工作之前，您需要更多的溝通。因此，您應該尋求這一點。不在現場意味著您沒有機會在早上大聲說：“我將使用搖臂槍來解決此問題”，對於所有去那裡停留時間長於你要吟：“哦，你不能那樣做，將除顫器與吐痰管和綁架綁在一起，不會承受壓力。”

你可以要求你的同事不要打擾老闆首先，當您的代碼存在問題時，只需告訴您問題所在。然後，您可以相互討論更好的解決方案，然後交給老闆。說“需要恢復”很像說“ ForOhFor昨天的全天都浪費了”，這對任何人都沒有很好的反映。您的同事可能不同意，但如果他拒絕，那麼至少您有確鑿的證據表明他故意將您搞砸了，而不是僅僅遵循令人驚訝地對待他不同意的工作流程。

對公司的規模一無所知，但這是我的猜測：

即使您可能不是一個更好的開發人員，這個人也會感到受到威脅。儘管我確信在許多經濟上不錯的情況下，一個人擔任小型項目或小型公司的唯一編碼員會很好，但他是該項目的唯一工人這一事實應該是一個巨大的危險信號。

這意味著...

• 該公司在軟件開發中的地位不高。如果是這樣，您將步入一個更好的流程和一個更大的團隊。此外，有什麼優秀的開發人員在某個時候不會從這樣的孤獨局勢中發展出來，而通過與其他開發人員合作變得更好呢？

• 他們可能是因為想要將您帶入通過傳播非常具體的項目/代碼庫知識來提高項目的速度（神話般的人月，有人嗎？）並降低其“總線因素”。如果他是“團隊合作者”，那麼他會意識到這一點，而不是去找老闆並退還您的更改，而是會坐下來幫助您了解如何更好地推理系統，或者建議您保留設計討論之類的。

• 他已經習慣於以自己的方式做事，並且樂於改變。最好的情況是，他是一位出色的開發人員，但是卻是一個la腳的社交人，使工作變得尷尬。最糟糕的情況是，那些la腳的部分仍然都是正確的，而且他可能在設計決策和/或良好實踐方面並不總是正確的。

正如其他人指出的那樣。 ，這種情況可能會隨著時間的流逝侵蝕您的聲譽。您可能想要在其他地方。

開始產生微小的變化。而不是重寫整個子系統然後再提交，而是在執行過程中的每一小步。強迫“有經理人的傢伙”在每一步都去找經理，說你所做的改變是有害的。如果管理者有任何判斷力，則所有“但是[x]”和“因為[y]”都會變得令人厭煩，並且管理者將立即抹殺無用方對您代碼的危害性的抱怨。 p>我對公司類型的處理方式很不滿意。我是反對壞主意的反對者，而某些公司的走狗似乎是反對好主意的反對者，因為它們代表著變化……所以，我制定了一個較小的策略。唯一的解決方案（作為參考，我從來沒有能夠在公司的地獄中完全正常地執行），是向系統發送垃圾郵件，其中包含一些無法反駁的好主意。做美國的事情。預解決一個大問題並緩慢提交解決方案，以使情況1出現，但以這種方式反駁的可能性更大。在此期間，拿錢跑。工作慢，賺錢快。混蛋經理把它帶到了整個組織。