如今的情況最可悲的是，IT正逐漸成為一個人均責任數無「止」字的行業。
在閱讀職位空缺時，有時你看到的甚至不是2-3個人，而是一個人整個公司，每個人都很匆忙，技術債務越來越大，舊的遺產在新產品的背景下看起來很完美，因為至少它有代碼中的對接和註釋，新產品以光速寫出來，但最終寫出來之後就不能再用一年了，而且往往這一年也沒有帶來利潤；而且，“雲”的成本” 高於服務銷售額。 投資者的錢花在維護一項尚未運行的服務上，但該服務已經在網上發佈為可用服務。
舉個例子：一家知名公司的一款舊遊戲的重製版獲得了整個行業歷史上最低的評分。 我是購買該產品的人之一，但即使現在該產品的效果也很糟糕，理論上它不應該以這種形式出售。 退款、評分下降、論壇上大量用戶因投訴服務工作而被禁止。 補丁的數量並不驚人，但也很恐怖，但產品仍然無法使用。 如果這種做法對於一家自91年以來一直在發展的公司來說會導致這樣的結果，那麼對於剛起步的公司來說，情況就更糟了。
但我們從服務使用者的角度來看了這種方法的結果，現在讓我們來看看員工遇到的問題。
我經常聽到這樣的說法：DevOps 團隊不應該存在，這是一種方法論等等，但問題是，公司出於某種原因已經停止尋找nok、dba、基礎設施和構建工程師- 現在都是一個DevOps工程師。 當然，個別公司還是有這樣的空缺，但已經越來越少了。 許多人稱之為發展，我個人認為這是退化，不可能在所有領域保持良好的知識水平，同時設法工作不超過8小時。 當然，這些都是幻想。 現實中，很多IT工作者被迫工作12、14個小時，其中8個小時是有工資的，而且常常沒有休息日，因為「給我一個任務，沒有文件，也沒有歪歪扭扭的，而且服務要花錢」。而雲端上的一個錯誤，你基本上幾個月就拿不到工資，特別是如果你是個人創業家。 隨著職責的劃分，我們基本上失去了在業務中的發言權；我越來越多地面臨這樣一個事實：管理者在完全不了解開發流程的情況下乾預開發流程，他們混淆了業務數據和應用程式的操作，並且作為結果，混亂開始了。
當混亂開始的時候，企業想要找到罪魁禍首，這裡需要一個萬能的罪魁禍首，很難把責任歸咎於10個人以上，所以管理者會合併崗位，因為一個專家的職責越多，就越容易解決問題。證明他的疏忽。 在敏捷條件下，找出「有罪者」並進行鞭打是這種管理方法論的基礎。 敏捷很早以前就誕生於IT，它的主要概念成為了日常結果的要求。 問題是，高度專業化的專家並不總是每天都有成果，這意味著報告會更加困難，這也是企業需要「樣樣精通」的另一個原因。 但主要原因當然是薪水——這是所有變化的主要原因，為了獎金，人們同意為自己和那個人工作。 但最終，與其他領域一樣，它現在只是成為一種責任，即以更少的費用提供更多的服務。
如今，您甚至經常可以看到文章指出開發人員也應該能夠部署，應該與 DevOps 工程師一起在基礎架構上工作，但這會導致什麼呢？ 沒錯——服務品質下降，開發人員品質下降。 就在2天前，我向開發人員解釋說，你可以從不同的主機上寫入和讀取，他們口吐白沫，證明他們從未見過這樣的東西，但在設定中有orm主機、連接埠、資料庫、使用者、密碼，就這樣… 但開發人員知道如何運行部署、編寫 yam... 但他已經忘記了程式碼中的單元測試和註解。
於是，我們看到了：不斷加班，在工作時間之外尋找問題的解決方案，週末不斷訓練，不是為了增加收入，而是為了維持生計。 開發人員被迫幫助一個 DevOps 工程師進行 CI/CD，如果開發人員沒有時間，他就開始陷入困境，而管理人員則開始堆肥他們的大腦，如果這無助於增加加班的慾望，然後施加處罰和罰款，這個人正在尋找新工作，留下了珠穆朗瑪峰規模的技術債務，結果開發商的債務開始增長，因為他們被迫編寫較少重構的程式碼，以便有時間幫助新舊 DevOps 工程師，而經理們對一切都非常滿意，因為罪魁禍首就在那裡，並且可以立即看到，這意味著基本規則敏捷管理已經跟進，罪魁禍首已經找到，鞭打他的結果是可見的。
我曾經在 ITGM 上做過一次演講，「當我們學會說「不」時」——其結果非常有啟發性。 很多人認為這個詞是禁忌，除非我們停止這樣想，否則問題只會越來越嚴重。
這篇文章部分受到我的啟發，但稍後我可能會用不太禮貌的術語來描述它。
只有註冊用戶才能參與調查。 ， 請。
您在工作中是否遇到過雇主試圖替換您幾個人的情況？
-
企業排放佔全球 65,6%是的，我經常遇到它183
-
企業排放佔全球 5,4%是的，遇過1次15
-
企業排放佔全球 15,4%沒注意到43
-
企業排放佔全球 13,6%我是工作狂，我自己也加班38
279 位用戶投票。 34 名用戶棄權。
來源： www.habr.com