題:
如何處理與現代軟件開發失去聯繫的老闆?
user128738
2014-05-01 16:56:07 UTC
view on stackexchange narkive permalink

我(作為初級開發人員)在一家中型公司工作,該公司是我們行業的唯一市場領導者。我們的軟件主要由已被移植/複製到90年代編程語言的 old 代碼組成,並且使用當前語言進行了一些重寫。90年代編程語言已經有兩年沒有支持了。整個過程都是一個拼湊而成,需要大量工作來維護,更不用說向其中添加新功能了。

現在的問題是,我們的老闆(建立公司的開發商和市場地位)領導者)在1990年代某個地方停止與現代軟件開發保持同步。他希望我們不切實際地快速添加新功能,而不必考慮代碼質量,可維護性或面向未來。

我們的最新任務是聽起來很簡單,但是需要對數據訪問子系統進行大量重做。即使沒有事先的全面計劃和事後的測試,也將需要數月的時間。在他看來,這最多只需要幾天,而我們和我們的經理們都無法扭轉他的局面。在子系統中,他現在希望我們顯示可見的(即客戶可見的)進度。這很難做到,因為我們大多數東西都位於底層庫中。他認為我們懈怠,希望我們確定每日目標,每天向他展示新功能,並為我們所做的事情寫日記。這給我們的開發人員造成了極大的壓力,動盪和部分恐懼,因為我們必須證明我們採取的每一個小步驟都是合理的,並感到我們不再被他所信任。

雖然顯而易見的答案是尋找另一份工作(以防萬一,我已經在做這件事),但由於實際的工作環境非常好,並且我希望盡可能專業地處理這種情況我想暫時保留這份工作。

我們/我有什麼選擇?他對閱讀我們的代碼或聽我們開發者農民的推理都不感興趣。

本著SO的精神,您到目前為止嘗試了什麼?您是否製作了任何易於理解的文檔或演示文稿,清楚地表明了當前系統存在缺陷的原因以及其不可擴展性?您能告訴他當前系統如何因預期的功能而失敗嗎?
您的老闆不是開發人員嗎?--- *“在他看來,這只需要幾天的時間即可。” * ---告訴他抓住鍵盤並在幾天之內將其寫入。
它沒有解決如何處理老闆的問題,但是對於初學者而言,您應該*確保*您正在應用[重構是關於功能](https://www.codesimplicity.com/post/refactoring-是功能簡介/)。
我不知道您所處的確切領域,實際上我也不確切地知道90年代,因為我的第一份工作是2000年開始的。但是,我對交付新功能的時間是*比現在少了90年代*。據我所知完全相反。那麼,為什麼老闆(以90年代的思維方式)在*少於*的時候估計時間呢?聽起來,雖然您的老闆可能確實對現代方法存在疑問,但“相關”問題是老闆大量低估了隨著時間的推移代碼庫變得多麼複雜和難以處理。
十六 答案:
Preet Sangha
2014-05-01 17:29:28 UTC
view on stackexchange narkive permalink

金錢。

您需要向他提供適當的成本核算,以了解為什麼他的方法會比您的花費更高。為什麼要花幾個月的時間進行基礎架構工作?他從事這項工作有什麼底線好處。我說的是冷酷的數字。為什麼現代做法更好?他為什麼要在乎?對客戶有利的地方,最終是對他有利的地方。

您說他失去了實踐經驗,儘管他有實踐經驗,但他很可能已經獲得了很多關於如何成功開展業務的知識。作為工程團隊,您有責任為他提供數據,以便他做出決定。如果他的行為會損害他的業務,那就是他需要聽的。

最終,如果他的度量標準是客戶可以看到的功能,那麼您會遇到一個問題,即非客戶在他看來,可證明的工作似乎並不專注於他的核心目標。您已經用他的語言和他說話了,那語言就是數字。

假設現代實踐會有所幫助,這一切都很好,但是如果沒有備份數據,您很可能會遇到他不會將您視為有價值的員工的情況。

編輯:

從您的問題中我看到他正在要求大量的每日更新,每日可演示的物品等。對我來說,這是您在現代汽車中可以找到的很多東西像方法一樣混亂。實際上,我什至會說您可能對他和他的方法有誤解。也許您應該採用這種方法,使戰鬥的雙方共同接近目標。

+1“儘管有這些做法,他仍可能獲得很多有關如何成功開展業務的知識”,而且您對日常更新的觀點也很好。很好的答案。
我們實際上將Scrum引入了我們的團隊,但是我們的經理告訴我們不要太開放,因為我們的老闆認為這是“浪費時間”,而我們“實際上可以完成一些編碼”。
@user128738所以我看不到問題。您作為工程團隊能夠在不影響其目標的情況下進行現代化改造。為什麼您不能在繼續展示他的價值的同時繼續採用這種方法?
我將此答案設為-1,因為我認為這不是最有效的答案。是的,用金錢來構架是向老闆展示事物的好方法。但是,對於改變這種特別的局面,這不會像離開那樣有效。
@geekrunner-離開以什麼方式回答問題?對於OP的理智而言,這可能是最好的選擇,但對於所問的問題是如何與老闆打交道,這並不是正確的答案。
如果問題是“我的汽車著火了,現在變成了一塊融化的瓦礫,我該如何使其恢復工作?” -您可以提供有關如何重新組裝並使其正常工作的詳細答案,也可以說“購買新車”。
“儘管有這些做法,他仍可能獲得許多有關如何成功開展業務的知識”。實際上,我認為這無關緊要。剛開始時,您可以擺脫糟糕的做法/束手無策,但是隨著公司的成功發展,軟件總是會變得越來越複雜,這是常用的最佳做法來解決的。認為您可以永遠作為一家初創企業運營是危險的,並且會導致重大問題。我實際上在某種程度上正在處理這個問題。
@Andy-我並不是說他的方式是最好的前進方式。我是說他覺得工程團隊沒有解決他的擔憂。他認為自己一直以客戶為中心,但是可能他需要了解如何以目前的方式改進持續性,但要使用一種能夠解決這些問題的語言-前進的底線以及面向客戶的可驗證代碼。
我了解尊重的角度,但是每天的更新對我來說聽起來並不像SCRUM,而是微觀管理。我曾與成千上萬的人合作,他們一無所有地建立了小型公司並尊重他們的知識,但是-我需要100%明確-微觀管理從來不是一個好兆頭。
user19202
2014-05-01 21:45:07 UTC
view on stackexchange narkive permalink

您陷入了一種普遍的情況,比軟件開發之外的人所想的要普遍得多。

如果您在一家貨運公司工作並推廣使用30年以上的舊卡車,被認為是瘋狂的(也許嗎?),但是在軟件公司中事情並非如此,主要是因為沒人能“看到”代碼-他們看到了網站或應用程序界面。

許多著名的公司都有在放開過時的系統時遇到了麻煩,Microsoft是第一個想到其Windows Phone 6.0的人。在許多情況下,我可以想到該公司最終成為其自己的“搖錢樹”或“已建立的生態系統”的受害者,最終被某些競爭對手的創新系統所取代。

在我的經驗中,過時的環境表明自我促進:老闆選擇同意他的中尉,他們修飾並促進類似的想法,而中層管理人員和進步思想家則被推到一邊,淪為猴子。這樣做需要花費企業數百萬美元,但是因為所有電力工作都是由害怕改變害怕失去電力工作方式的人來完成的。直到公司最終失敗的惡性循環不可避免地失敗了(雅虎,黑莓)。我曾在一家大型 HVAC公司工作,我可以肯定的是,在過去兩年中,他們從事的一個項目已經花費了超過500萬美元(據我估計),少10倍,快3倍。

如果您所處的環境過於陳舊,則應考慮您要去哪里工作。您是學習Fortran / Cobol / VAX的初級開發人員嗎?您是否確信如果您掌握了一些過時的技能,就可以找到另一份工作?

我的建議是:不要試圖改變公司的發展方向,它幾十年來一直保持不變,最終可能會被擱置一旁。繼續前進,找到另一項可以訓練您現代技能的工作。從現在開始的30年後,不要再當老闆了:)

這實際上很好地描述了環境。它不像Fortran / Cobol那樣糟糕,但仍然太受限制,無法滿足現代要求,例如觸摸功能,集成的OS外觀以及甚至現代的OS兼容性。
“如果您在一家貨運公司工作,並且正在推廣使用30年以上的卡車,您會被視為瘋了(也許嗎?)”-您從未從U-Haul租車,對嗎?
+1。去年正是我所做的,我的新環境促進了現代思維,最新工具和最佳實踐。這使我成為一名更好的工程師和一名快樂得多的員工。
我從來沒有得到這麼多程序員總是要進行代碼重構。嚴重的是,我討厭編寫絕對沒有添加任何代碼的代碼,只是為了擁有更簡潔的編碼風格或其他目的。當然,在某些情況下,您必須完全替換代碼,但是在大多數情況下,我會說替換部分代碼或使用新技術添加新功能並具有一些接口就足夠了。
實際上-如果您喜歡這些語言(或者至少可以將它們理解),那麼擁有Cobol或Fortran知識將是一個很大的優勢。這類程序員的需求很高,而且報酬很高,尤其是在大型機或大型商業環境中。
thursdaysgeek已經鏈接了[本文](http://www.joelonsoftware.com/articles/fog0000000069.html)。閱讀。 [此外](http://onstartups.com/tabid/3339/bid/97052/How-To-Survive-a-Ground-Up-Rewrite-Without-Losing-Your-Sanity.aspx)。不要將創新與無法認識到已經完成的工作中的價值相混淆。或者,您當然沒錯(除了Cobol,您實際上真的錯了,我的意思是總的來說),但它並不像舊的無聊和過時阻礙了新事物那樣簡單。
為了重構而進行@dirkk:重構是一個可怕的想法。僅僅為了使代碼更漂亮而乾擾一個工作系統是不值得的。但是重構肯定有它的位置。我見過一個舊的bacnet com系統,該系統圍繞1200Kbps調製解調器設計,使其極為神秘,並且只有很久以前用C編寫的一些DLL才能理解,當您嘗試在C#MVC前端中使用它們時會引起各種問題。有一個重構的時間和地點,不要忽略它,否則您將來的項目會受到影響
@NathanCooper:當特定技術的開發人員的資源池枯竭時,就會出現此問題。如果您不跟上現代技術的步伐,那麼您可能會發現自己輸給了敏捷的競爭對手。本文列出了重寫嘗試出錯的情況。但是,人們只能想像,如果Microsoft意識到一旦他們將目光投向iPhone,就必須重寫WinMo,那麼移動領域將會是什麼樣子,就像Android http://tech.fortune.cnn.com一樣。 / 2013/12/20 / apple-google-vogelstein-dogfight /
附帶一提:COBOL非常適合1)移動數據塊和2)加數字。令人驚訝的是,許多任務歸結為這一點。僅僅因為代碼陳舊,並不自動意味著它已經過時。
@ThorbjørnRavnAndersen,如果您剛剛創建了一家將從事Interweb的下一件大事的公司,您會使用Cobol嗎?不僅從技術角度而且從業務角度:尋找熟練且廉價的勞動力。是的,它已經過時了。
@user19202這是一個關於如何選擇正確的計算機語言如何使作者成功並賺取很多錢的好故事:http://www.paulgraham.com/avg.html-在他的情況下是Lisp(順便說一句也很老)。另外,初創公司不需要尋找熟練且廉價的勞動力-他們需要自由電子(http://randsinrepose.com/archives/free-electron/)才能真正發光。
@ThorbjørnRavnAndersen在戰場上射擊目標,您仍然可以使用a,因為它具有隱身性,因此可以說它是優越的。然而,在現代戰鬥中,無論它是否使用(非常少見),它仍然過時
@user19202我在一家以COBOL編寫核心產品的公司工作了9年,該語言在移動數據和添加數字方面的速度以及底層操作系統的靈活性使我們能夠通過簡單地謀生高度定制產品以滿足每個客戶的喜好並降低複雜性。當我是一名Java程序員,在編寫程序以補充COBOL程序時,我充分理解了兩者的優缺點。
請注意,如果您不介意保留古老的代碼,那麼精通COBOL的人們將變得稀有而有價值……
@keshlam將其與您可以購買的各種商品上的“手工”標籤進行比較。很有可能是手工製作的藝術家,例如餐桌,在上面賺了很多錢。然而,整體而言,大多數餐桌上的錢不是由工匠賺錢,而是由使自己的生產鏈至少保持合理更新的工業機構賺錢。然後還有像計算機芯片這樣的複雜商品,它們甚至不能使用過時的工具來製造。軟件也是如此-過時的技術可能會賺到一些利基的錢,而且有些東西您無法用它構建(合理地)
我並不是在倡導舊技術-遠非如此-但更好的類比是那些對古董家具進行博物館品質維修的人。現代家具可以很好地工作,並且便宜得多。但是,如果您有一個舊作品,但它仍然可以滿足您的需要,那麼您可能要繼續使用它,因為您對它感到滿意,並且找到與套件其餘部分協調一致的替代品會比原來更麻煩您現在可以證明理由。
我的錢用於Visual Basic。
讓我們也不要忘記一個問題,如果您對使用錘子非常有經驗,突然之間一切都會看起來像釘子...
@keshlam我們古老的人,我們中那些談論磁帶驅動器,打孔卡和軟盤的人保留了很多智慧
@user19202 _如果您剛剛創建了一家將從事Interwebs的下一件大事的公司,您會使用Cobol嗎?_希望不會,為什麼那根本不重要?您從哪裡得知他們將繼續做The Next Great?該領域的大多數人都知道絕對沒有最佳或最差的語言,它總是與在特定情況下要實現的特定目標相關,當然,在很多情況下,最適合的語言是較老的語言一。你真的發現那奇怪嗎?
@SantiBailors首先,您說“希望不”,然後說“為什麼重要”-這樣您就清楚地理解了為什麼重要。不是因為語言的好壞,而是因為市場環境。使用現代語言通常在技術上有優勢-工具,庫等-因此可能會很有用。能夠僱用人們加入該項目-更加有用。
@user19202-希望不是,因為在您所描述的情況下這將是一個錯誤,並且為什麼會如此_因為該情況與所討論的情況不同,因此在該情況下進行的任何操作都與當前主題無關。
Dimitrios Mistriotis
2014-05-01 18:25:59 UTC
view on stackexchange narkive permalink

我曾在這樣一家公司工作。問題在於,很難破壞和/或殺死搖錢樹。我還觀察到的是,大多數人在90年代(即00或10年代)的環境中工作都沒有問題(一個有趣的問題:“為什麼這對我如此重要,而不對那裡的其他員工如此重要? / em>”)。

我相信該組織中的大多數人都會說:“有現金流量,系統以某種方式出售,沒有人願意對其進行重構,以便使它更現代。”原因是您的老闆多年來已經開始僱用會同意他的人(相對於目前的做法,“僱用自己”的心態)。到現在為止,他們應該太多了,以至於佔多數。多年來關注的人可能已經搬到其他地方,或者他們選擇保持沉默。

我不同意@Preet Sanga,如果所有者關心任何指標,他會在2010或2005年,情況一開始不容忽視。

當我開始抱怨第一段中描述的情況時,一連串的刺傷事件開始了,最終使我離開了公司,對我和公司來說都是結果。根據我的個人經驗,我的建議是... 離開。 :-(。

“有愛心的人會搬到別處。”是的,似乎該公司有自欺欺人的“ [死海影響](http://brucefwebster.com/2008/04/11/the-wetware-crisis-死海效應/)”
+1表示“發生了刺傷事件”。有時,搖船最終將您帶入水中。然後您會找到更好的船。
更好的西裝評論:一個在美國某地方經營諮詢公司的偉人開了很好的談話(失去了聯繫)。他遇到了一些“陷阱”問題,例如:“現代軟件開發實踐對我來說很重要”,類似的問題是為了過濾掉與他的業務不相關的人員(他主要維護舊軟件)。人力資源(或人力資源人員)有責任事先進行溝通並告知候選人。
AfterWorkGuinness
2014-05-01 22:22:23 UTC
view on stackexchange narkive permalink

關於這位老闆對變更應該花多長時間有不切實際的想法,我建議為每個需要變更的組件創建一個工單/子任務/“但是您要記錄工作的單位” 。

面對所有需要更改以實現最終目標的所有組件的清單時,老闆很有可能會看到需要花費幾天以上的時間。

這是個好的觀點。列出完成工作所需的清單可能是雙方的健全性檢查。我有時發現我原本認為是重大更改的事情可以相對輕鬆地完成,有時似乎是次要更改的情況需要對當前流程進行徹底檢查。
如果列表中的第一項不是“用正確的2010年代語言而不是您決定使用的劣等90年代語言來重寫我們接觸的所有內容,因為我們不能指望這種廢話就可以工作”。老闆不會接受這確實是必要的,並且會開始喃喃自語地談論當今的年輕人,而不知道他們的出生。
Paul
2014-05-02 01:56:12 UTC
view on stackexchange narkive permalink

離開。

嚴重的是,作為一個在這種確切情況下花費過多年時間的人,這是我希望我可以回去給自己的建議。在BEST,您將推動未來幾年的發展,也許會引起人們的不滿,但幾乎可以肯定的是,您的努力不會得到應有的認可。該公司永遠不會追趕,因為經營一家現代化商店的人不會一直在等著您,與此同時,您也會落伍。在您作為初級開發人員的職業生涯的現階段,至關重要的是要被合適的同事所包圍,以便您成長和發展技能並養成良好的習慣。您所處的情況不會提供這些機會。在三到四個星期內,您可以在自己喜歡的工作場所中做自己的工作而感到自豪。

市場為與拒絕前進的“技術”公司打交道提供了一種絕佳的機制。

>

沒有一個完美的工作場所,但是您覺得有必要提出問題的事實向我表明,您已經知道有些事情是錯誤的。盡快出去。

thursdaysgeek
2014-05-01 22:17:37 UTC
view on stackexchange narkive permalink

您正在為一個以程序員身份開始並且具有很多知識的人工作,其中包括有關Netscape重寫失敗的知識以及如何破壞公司。他可能已經讀過本文。因此,由於重寫的危險,他可能會忽略技術債務的危險。

因此,由於他的確確實在使用Scrum和敏捷版本,因此可以使用它。找出需要完成的主要步驟,然後根據估計的時間詳細了解這些步驟。包括說明為什麼需要執行這些步驟的理由,並記住獲利能力與可維護性同等重要,並且代碼質量不會付賬。

詢問業務需求和壓力,然後聽他講。如果您聽他的話,並試圖了解他來自哪裡(他確實知道您不知道他來自哪裡),那麼您將獲得更多的尊重,他更有可能聽您講話。

他不使用敏捷模型,而只是“建議”該模型,因為我們沒有按他的時間表做好準備。他實際上有好主意。我們正在做的事情是一件相當不錯的事情,因為它可以解決將來可能發生的某些完整性問題,但是,實現起來並不像聽起來那樣容易,而他反過來又拒絕承認。
我一直喜歡經理人,他們認為敏捷意味著“同樣的工作,但是要更快”,在現實的截止日期前與經理人交戰在這個行業中是一個很普遍的問題,而我們大多數人都無法逃脫。以您的情況看來,您的老闆已經以自己的方式樹立了根,他改變的唯一方法就是明顯影響其底線。 (當一些競爭者從您身邊掠過並開始削弱他的客戶群時,開發時間不會太長,這不會造成金錢損失)
@RualStorge是正確的觀點,但他的恐懼可能是相反的觀點,也是正確的觀點。因此,您需要更好地溝通以了解他的來歷,並使用他所理解的工具來表達您的觀點。
+1:許多經理不了解第二系統綜合症。 http://en.m.wikipedia.org/wiki/Second-system_effect
gnasher729
2014-05-02 05:16:56 UTC
view on stackexchange narkive permalink

事實是,您正在使用一個舊的代碼庫,在過去的20年中,它可能變得越來越糟,進行更改的難度越來越大,比應有的難度更大-並且您也不會更改它。另一個事實是,無論您的老闆嘗試什麼,添加他想要的新功能都會花費時間,而您的老闆無能為力將改變這一狀況。

現在,如果您的老闆想要每日目標和每日結果,請給他每日目標和每日結果。早上半個小時的第一件事就是確定您當天要做什麼。那是您可以編寫代碼的半小時,但這正是老闆想要的。回家前半小時,請停止編寫代碼,並確定並記下當天的工作。現在很重要(尤其是作為初級開發人員):跟踪每天完成計劃的哪一部分。完成一周的工作後,您將了解一天中實際可以實現的目標,並更改當天的計劃,以便它們與實際發生的情況相匹配。您當天的計劃不應是“您想發生什麼”或“您的老闆想發生什麼”,而應該是“將會發生什麼”。您可能正在經歷的恐懼主要是由於未達到您認為應該達到的目標而產生的-一旦您學會了根據自己所達到的目標來調整計劃,就可以消除這種恐懼。

同時,讓我猜想您在工作期間接受了多少培訓...如果達到我的預期,那麼您的工作日就不會超過您的薪水,因此您足夠新鮮並有時間在家自行學習。特別針對學習可以幫助您完成其他工作的事物。

Carwyn Nelson
2014-05-01 17:10:14 UTC
view on stackexchange narkive permalink

如果有其他人可以與您交談以解釋這種情況,那麼我建議您這樣做。從更積極的角度來看它。這樣的事情可能就足夠了:

“我擔心X人可能無法與當前的軟件實踐保持同步,我相信這將來可能會對項目產生負面影響。可以給X人更多一些有關現代軟件開發實踐的培訓嗎?“在一家壓力重重的公司工作真的不值得您花時間。您還必須問自己,公司現在是否像這樣工作,他們在5到10年後的生存可能性有多大?基本上,您的工作安全嗎,還是競爭對手會丟掉他們?

不幸的是,他是公司中“最高”的人。我可能應該和董事會談談,但是我不知道在我低調的職位上這是否是個好主意。
我在答案中添加了一些額外內容,希望對您有所幫助。就像我在回答中說的那樣,為這家公司工作似乎並不值得。您最好不要去別的地方。
董事會可能與所有者在同一條船上。所有者建立了企業並賺錢,那麼為什麼他們不高興繼續做同樣的事情呢?
geekrunner
2014-05-02 03:14:18 UTC
view on stackexchange narkive permalink

改革業務運作方式不是您的工作,這是老闆的工作。

您的工作是適應並執行企業定義的角色。

不要陷入認為這項工作是世界上唯一的工作的陷阱,因此您需要對其進行改革以使其變得更好。

要認識到,即使是擁有20年經驗的開發人員,也仍然具有連續的才能-並非所有人都是“搖滾明星程序員”。

我並不是說不可能改革這個工作場所(什麼都沒有),但是常識表明,這裡最合理的做法是通過更現代的發展實踐找到一份更適合您的工作。這樣,您當前的角色將不再那麼雄心勃勃,或者可以將其磨碎而變得更加沒事,人員,否則業務將完全失敗。

`改革業務運作方式不是您的工作,這是老闆的工作。您的工作是適應並執行業務所定義的角色。這是一種扼殺創新和開箱即用的想法的思想,這將導致OP所描述的陳舊情況。如果您不喜歡自己的位置,請嘗試更改它,否則,請離開。
Michael Martinez
2014-05-02 00:35:49 UTC
view on stackexchange narkive permalink

這不是您的業務,這是所有者的業務。如您所說,您基本上只是一名農民工。也許您的想法是好的,並且所有的想法都很好,但是從所有者的角度來看-他只是在為自己工作,而後-他畢竟是建立公司並賺錢的人。多年來,這可能使他和他的合夥人賺了很多錢,那麼為什麼他們要改變它呢?

實際上,您可能要做的就是按照他的要求去做。聽起來您不喜歡“快速而骯髒的黑客攻擊”,但是有時候這是您需要做的。

您可以嘗試與他見面,也許您和您的同事可以與他坐下並友好地解釋您的立場。如果您以正確的方式進行操作,他可能會願意保持靈活性。我建議您嘗試這樣做。

這聽起來像是其中一種情況,您必須放下自尊心,隨波逐流。 (或者,如果您絕對受不了,還可以再做一份工作)

Peter M. - stands for Monica
2014-05-02 05:19:36 UTC
view on stackexchange narkive permalink

如果您不能更改公司-請更改您的公司。

如果您不能更改流程和技術,請離開。您在浪費時間而沒有獲得適銷對路的技能。公司盈利能力下降,解僱像您這樣的初級開發人員並且您的所有技能都在那些過時的技術中之後,您將做什麼? ”。

但是我沒有說只是“辭職”。我說:“如果您的公司糟糕透頂,並且您無能為力,並且您沒有掌握適銷對路的技能,那麼在適合您的情況下辭職是更好的選擇, ,而不是因為他人的無能而被解僱”。我真正相信,這種情況比等待斧頭更好。

幾年前,我處於類似的情況(成為過時的技術的晦澀專家),即使公司內部的人才很棒。

我能夠在我從中學到了現代技術,並且我是公司中最後一位按自己的條件離開的人-大多數人被解雇了,因為他們在公司重組,開發外包和轉換時訓練了他們自己的替代品時代的技術(使整個偉大的團隊過時)。 YMMV

不知何故,我在發布後的1秒鐘內投票了。有趣。
人們在這裡不喜歡簡單的“退出”答案,IMO有點不現實,因為通常“退出”是針對這種情況的最佳建議。
@geekrunner-確實,有時候退出*是*正確的答案,但考慮到這樣做的永久性財務和職業影響,許多社區成員認為,非常有力的解釋,甚至有專業研究或引用的支持,也是為了避免告訴人們放棄並放棄。彼得,請查看[此Workplace SE meta帖子](http://meta.workplace.stackexchange.com/questions/1692/is-quit-your-job-an-acceptable-answer),以獲取有關該討論的更多詳細信息。希望這可以幫助。
@jmort253是,Meta-post清楚地概述了在某些情況下說“放棄工作”是可以接受的答案。
@geekrunner-是的,但是這個答案的確對我有“我也是”的感覺。
@geekrunner我認為“退出工作” *可以*是一個可以接受的答案,但如果只有三句話說“退出工作”,則很可能會引起反對。
但是我沒有說只是“辭職”。我說過:“如果您的公司糟糕透頂,並且您無能為力,並且您沒有獲得適銷對路的技能,**比適合別人的無能而被解僱更好。”
durron597
2014-05-03 00:07:50 UTC
view on stackexchange narkive permalink

在我看來,您不想離開。雖然我了解這一點,但您也說您在看,所以至少要考慮一下是一件好事。但是,這裡的大多數答案都建議離開,所以我不再贅述。

與老闆交談時遇到的問題是,您沒有為他提供替代方案。我確定您認為您是,但實際上,您不是。說“讓我們每天開會5分鐘”與他已經想做的沒什麼不同。

如果您真的想留下,請利用您的業餘時間(可能在幫助下)的同事)真正制定一項業務計劃,以決定如果需要時如何調動部門。而且我保證,無論他之前是否讀過,他都會擔心(而且理應如此!)關於 Netscape的故事(我知道我不是第一個回答此問題的人。

因此,您需要做兩件事:

  • 準確記錄軟件重寫的所有不同部分以進行更改,以及您希望它們花費多長時間。需要分解成足夠小的部分,以至於他不會認為您只是在編造數字,但又不能太小以至於變成tl; dr。這需要花費大量的精力才能達到正確的平衡。
  • 然後,為如何逐步將系統移至未來製定一個計劃,這需要逐步完成,因為他們不能僅僅關閉所有設備一年。
    • 第一步必須是將現有軟件分解為可以相互通信的模塊;這不是一件容易的事!但是,無論如何這都是一件好事,只是使開發更容易並且將關注點分開。
    • 一旦那不是e,那麼您就可以開始將每個組件遷移到新版本中了。
    • 這一部分必須有足夠的細節供他查看時間範圍,這一點至關重要!您不能將煙和鏡子帶給他,因為他從事該行業已經足夠長的時間才能識別它們。
    • 同樣重要的是,他要有足夠的細節讓他覺得可以總結您為將想法賣給高層管理人員所做的工作(他不希望您寫出真正高級的執行摘要,因此不要這樣做)。 / li>

當您終於準備好與老闆會面時,請記住以下幾點:

  • 做到這一點私下。確保您的老闆不認為您正在積極嘗試使他看起來很糟。一個想法是邀請他在工作之餘與您一起喝酒,以使整個事情看起來不那麼嚴重,賭注也降低了。
  • 盡力使他感到自己被包容了。考慮一下他的想法,並確保對他所做或所啟發的一切功勞歸功於他,這是你撰寫論文的一部分。像這樣與他見面會感覺就像踩到他的喉嚨,所以您最好準備好在另一側按摩他的自我。另外,要表明意識到繼續執行您的計劃的決定將不會由他一個人決定,如果他同意您的話,請允許他成為向高級管理層提出該決定的人。 不要在這裡尋找信譽。
  • 您必須盡量減少自我。確保清楚您正在執行此操作,因為您認為這是對時間,團隊時間以及最終(如@PreetSangha的答案中所建議的)公司金錢的最佳利用。
  • 您應該還可以說明您有多不快樂,但不能以一種“禍不單行”的方式來解釋,而是以這些問題對士氣和生產力產生這些特定影響。嘗試在這裡保持冷靜。
  • 最後,您必須為此準備丟掉工作。許多老闆不想被如此徹底地露面,並會尋找第一個藉口將您踢出門。如果這是您的老闆,那麼以上都不重要,而實際上最重要的事情就是請假。
您已經制定了非常合理的行動方案,但是正如您所說的那樣,為獲得不確定的回報需要付出很多努力。
jwenting
2014-05-05 14:18:23 UTC
view on stackexchange narkive permalink

考慮一下:您是團隊中的小三歲,也是最小的孩子,但是您對如何使事情“變得更現代”有一些大想法。他們都失敗了。他沒有任何動機去聽你說話,因為他從幾十年的經驗中知道,每一個鼻涕的初級程序員都具有豐富的書本知識和關於如何“改善事物”的偉大思想,這些思想使他對自己感到the惱。年根本就沒有用,或者如果他們用不了,那麼實施這些工作就不值得了。

所以,即使您的想法很棒,也可以用,但您還是會遇到困難,這是一個固定的過程儘管已經有很多人像您一樣不斷嘗試改變它,但這種方法已經工作了數十年甚至數十年。
更糟糕的是,毫無疑問,他們已經獲得了高薪,非常昂貴的諮詢公司進行審計並就如何改進提出了建議一切都失敗了。
失敗的原因並不重要,但失敗了,多年來,這導致了對任何試圖改變事物的人和任何事物的敵對態度。

最好的辦法就是順其自然,順其自然,贏得人們的信任和尊重您的前輩確實比您了解得多,也許,也許也許,找到一些方法來最終完成事情的方式進行微小的增量變化。只是以一種不會中斷整個項目團隊的方式使您自己的個人工作流程更有效率,而是給人一種印象,“嘿,這個新來的孩子是個快速高效的工人”。也許人們會看你如何做事情,然後自己開始嘗試。那是您最好的期望,不要帶著一個滿腦子的想法和一種“您做錯了一切,現在我將在這里和現在告訴您如何做”的態度闖入老闆的辦公室on”,因為那隻會讓你成為敵人。

再說一次:您的想法是否有價值沒有關係。您的身份意味著他們不會被視為有功。對此,您無能為力,只有時間並贏得同事的尊重,才能改變它,因為知道他在說什麼的人可以做到這一點。

vulpineblazeyt
2015-09-26 00:46:36 UTC
view on stackexchange narkive permalink

在當前答案中我沒有看到這個想法,但是請讓我知道是否錯過了一些事情。

顯示您的工作:

如果您的老闆是一名開發人員,很久以前,他們應該知道差異日誌的外觀。展示完成“按自己的方式”需要花費的大量編程知識,應該足以讓一位前開發人員說:“天哪,這只是我的簡單要求而已。”

經常提交:

如果您可以向老闆展示每天的工作情況,那可能就足夠了。可能的反駁是,如果永遠只花一兩條正確的線,為此,我只能想到一種解決方案。

更頻繁地提交:

向您展示如何在這一部分上花費大量時間,而輸出日誌和錯誤堆積起來可能是您的解決方案。一方面,這是一堆細緻的文檔,但是節省您的工作(因為其他所有人都提到要離開,所以我假裝這是不可行的選擇)值得值得短期的努力。

注意:

這是基於您的老闆可以理解基本的編程工作,差異日誌,stdout和stderr等假設的。如果您的老闆由於無法管理而受到大腦的損害,這是不可能的(您應該即使您認為也不會嘗試,也可以嘗試),那麼剩下的唯一選擇就是完善您的簡歷。

Umberto
2014-05-02 10:48:48 UTC
view on stackexchange narkive permalink

我可能還會提出另一種想法:價值鏈(請參閱 http://en.wikipedia.org/wiki/Value_chain和波特的原著)。

我處於類似情況,出於一個簡單的原因,我要離開公司。您正在做的是“支持活動”(使用價值鏈理論的語言)。使用更現代的語言進行編碼不會銷售更多的軟件,也不會獲得更多的客戶。您可能會爭辯說,從長遠來看,這將為公司節省資金,我同意,但是為什麼要投資沒有“附加值”的東西呢?

現在,您必須閱讀我在價值鏈構想中撰寫的內容。我是科學家和程序員,所以我知道您的感覺。但這是硬道理。美麗而現代的代碼比舊而醜陋的代碼賣得更多。

現在在有人批評我之前:我還認為,我們應該根據最佳實踐等正確編寫代碼(否則,我不會離開我工作的公司),但是這不是公司的方式值編碼...只需我的兩分錢。

Fattie
2014-05-03 11:28:41 UTC
view on stackexchange narkive permalink

這種現像很常見,您或多或少都在描述....

軟件行業的本質 !!!!

本質上,如果您無法處理或使用它,那麼您將無法在行業中工作! (很遺憾,是真的。)

另一種看待它的方式:在軟件方面(基本上)非常賺錢的人,非常成功的人,的確能夠最好地處理您如此準確地描述的問題的人

絕對的底線是:只需清楚,盡可能客氣地解釋-並重複:

“很好,但是要花X歐元。使用這種更現代的系統,它要花費€Y 。”

對於例如,目前移動領域的一項巨大創新就是“ bAA”(例如Parse等)以及諸如Google Play等巨大創新。我們進行大型項目,並完全消除了.com的整個服務器端,僅使用Parse或其他任何工具即可。從字面上看,這導致3、4、5個服務器人員失業(並轉而從事更有趣的職業!)

您必須記住,“去中介化”是每個月持續不斷的故事軟件業務。回首20年,我們所有人都會發了一筆大筆財富,是王子的贖金,做著“向網上商店添加信用卡處理!!!”之類的事情。

過去能夠收取六位數的費用。..顯然,任何人的媽媽都可以立即免費使用Google,paypal和任何東西,完全免費地進行在線支付。整個業務的“細分”完全消失了。

另一個對您個人而言非常重要的要點...

您必須非常小心地問自己-為了您家人的經濟狀況等等-

您想在下一年花費在廢舊技術上嗎?

當您嘗試尋找下一份工作時,一年後會怎樣?嗎?”

看起來不太好。

只需考慮離開公司。只是很客氣地解釋,你看,我愛你們,但如果我在10歲的技術工作,在未來12-18個月,我剛剛失去了從我的職業生涯 - 2年,而程序員有可能最多15年電源

然後離開,然後在今天下午找到一份新工作。

工作量很大,任何人都可以找到任何工作他們希望隨時隨地都可以,因此,再次-請在此階段非常謹慎地研究“死技術”。希望它能以某種方式幫助您!



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