⚠️ Проблема и рефакторинг

Во время переноса на WebSocket выявили проблему: одна фаза вызывала другую, та — третью. Потому что всё создавалось пошагово.

Так мы подошли к вопросу: пора провести рефакторинг кода.

Пару вечеров была дискуссия, как это сделать лучше, чтобы потом не возвращаться.
В итоге в игре появился дирижёр. Теперь при необходимости можно поменять один файл, а не 3–4, как раньше.

Растёт скилл, как говорится. 😁

🎮 Тест-игра: кайф от прогресса

Раньше всё происходило на одном экране.
Теперь создаётся игра на 2–4 игрока — соответственно, в 2–4 вкладках.
Каждый игрок, несмотря на ход другого, видит только свои карты и может продумать стратегию.

Перенос на WebSocket прошёл успешно.

🛤 Развилка: тайминги или база данных?

Дальше встал выбор:

• Тайминги (время ожидания и т.д.)

• База данных (чтобы можно было перезапускать сервер, переподключать игроков)

Но, наверное, пока немного передохнём и погрузимся во фронт.
Сделаем визуальную часть приятнее и ещё больше похожей на игру.

Кстати, после рефакторинга бэкенда навели порядок и во фронте: создали пакеты, раскидали файлы по подпапкам (а то было по 500 строк кода в одном файле).

🙏 Особый вопрос к сообществу

Хочу обратиться к вам, моя дорогая аудитория и случайные гости.

Есть два сайта:

• HobbyWorld — издатель данной игры

• BoarGameArena — настольные игры в онлайне

Есть ли тут представители или работники этих организаций?
Или, может, в вашем окружении есть кто-то?

Хотелось бы неформально пообщаться и узнать о возможности размещения моего проекта в будущем в открытом доступе.

P.S. Спасибо, что читаете. Ваши комментарии — топливо для этого костра. 🔥
А если у вас есть опыт общения с издателями настолок — поделитесь, буду благодарен.

Продвинулись вперёд. Появилась первая анимация — выделение объектов мигающей рамкой! 😁
И самое главное: по бэку дело тоже пошло. Наконец получилось сыграть полноценную партию — хоть и в режиме «горячего стула».
Но это уже прорыв.

🧠 Мысль, которая не отпускает

Я не раз ловил себя на мысли: игру, правила которой объясняются за 10 минут, а разбираешься за одну партию, оказывается, довольно крупный проект. И ей есть куда расти.

Мы изначально планировали онлайн, так что на текущем этапе составили план: переход с REST на WebSocket.
Впереди — партия не в стиле «горячего стула», а в 2–4 вкладках браузера, где каждая вкладка — это игрок.

💡 Про свой проект

Я не раз слышал во время обучения: «Стоит сделать свой проект».
И сейчас я с этим полностью согласен.

Это совсем другой уровень. Когда от расписанного задания ты переходишь к тому, что сам планируешь, строишь и создаёшь.
И от каждого пройденного этапа получаешь восторг — как от первого скомпилированного Hello World.

Вот как-то так…
Впереди ещё много работы, но уже получилось сыграть несколько партий.
Хоть и сам с собой. 😁

💬 Вопросы к вам, друзья

1. А вы играли когда-нибудь сами с собой? В настолки, шахматы, карты? Или это только моя странность? 😄

2. Как вы справляетесь, когда инструмент (ИИ, редактор, что угодно) вдруг перестаёт работать как надо?

3. Есть ли у вас проект, который вы делаете только для себя — и получаете от этого кайф?

P.S. Спасибо, что читаете. Ваши комментарии — топливо для этого костра. 🔥

Задача онбординга – с наибольшим комфортом и за наименьшее время помочь вам влиться в процессы компании и команды. Поэтому смело задавайте вопросы и просите помощи при необходимости у ответственных лиц. При этом не забывая о балансе, есть вещи которые предполагается что вы знаете, например установить среду разработки, склонить проект, установить и настроить СУБД по конфигу и тому подобное. А есть вещи специфические для конкретной компании или команды, который вы не можете знать изначально, например где лежат конфигурации для различных стендов, какие политики именования веток в системе контроля версий, где взять доступы к внутренним API и так далее. И помните, вашем быстром и комфортном онбординге заинтересован бизнес, вы имеете полное право на него.

Например когда я пришел начинающим разработчиком в одну из компаний, где я работал, мне в первый день дали древнюю документацию, и сказали пройти по ней тестирование по знанию продукта, а после развернуть его, с тестированием я сходу справился, а вот с разверткой проекта возникла трудность, проект никак не стартовал. Я несколько часов штудировал доку и пытался найти чего же мне не хватает для поднятия проекта. Ведь мне дали большую доку, где, казалось бы, все необходимое уже точно есть, ведь люди наверняка поддерживают актуальность доки, но, к сожалению, я ошибался. Оказалось, что конфиги для поднятия проекта не актуальные, и я никак не смог бы сделать это самостоятельно. И прежде, чем корить себя после долгих неудачных попыток, лучше пойти и задать вопрос ответственному коллеге, ведь нет ничего зазорного в том, чтобы спрашивать о том, чего не могли значить чисто физически.

2. Не стесняться спрашивать того, кто дал задачу, но подходить к этому с умом

В начале карьеры (после тоже немало) особенно часто могут возникать ситуации, когда вы не поняли, что требуется в задаче. Не нужно думать, что вы не обладаете достаточным количеством знаний чтобы с ходу понять задачу. Проблема постановки задач преследует огромное количество специалистов, как начинающих, так и очень опытных. Но важно помнить о балансе, не нужно бегать с абсолютно любыми вопросами. Необходимо сначала постараться разобраться в вопросе, применить свои знания и опыт, а так же умение поиска информации, и только после этого идти к коллеге с собранной пачкой грамотно сформулированных вопросов.

Например, в одной из компании у меня была ситуация, когда на очередном распределении задач, я получил свою, в ней как мне, казалось, было все очень подробно расписано, с широко развернутым текстовым описанием, примерами, изображениями с уточняющей информацией и выглядело это как нечто внушающее доверие. Но у меня никак не получалось интегрировать функциональность в то место куда требовалось, я прилично времени сидел вчитывался в ТЗ, изучал целевой участок проекта, документацию по нему (в этом проекте она была хорошей в отличие от примера из первого пункта), но никак не мог ее интегрировать. Я думал: «Не пойму, такая красивая задача, все так хорошо описано, столько дополнительной информации, хорошая документация, а я не могу с ней справится». Оказалось, все довольно прозаично. Оказалось, что аналитик просто указал не тот участок приложения, а схожий, извинился и внес изменения в ТЗ.

Поэтому нужно смело уточнять все что вам не понятно, это естественная часть процесса решения задач. Лучше всего собрать список вопросов и подойти к ответственному сотруднику и обсудить максимум вопросов за раз. Это гораздо лучше каждые 5 минут бегать к коллеге с 1 новым вопросом.

Бывает, что сидишь с какой-то задачей, уже вопросы все задал, но все равно не получается ее решить. Скорее всего просто не хватает опыта решения задач в условиях реальной работы, и это нормально. Не нужно сидеть и заниматься самобичеванием, адекватные опытные коллеги не будут осуждать начинающего специалиста, они скорее с удовольствием помогут, ведь на самом деле отрадно и полезно помогать своим младшим коллегам.

3. Код-ревью. Защищаться и получать выгоду

Сомнительное ревью — вам могут сказать что-то вроде «Так пишут студенты», «Решение так себе» и не объясняют почему. Это не про вас. Это про неумение ревьюера в коммуникации.

Как-то раз мне сказали: «Мне не нравится, надо переписывать». Я спросил: «А что не так?» - «Так писать нельзя». И только после третьего вопроса «Почему именно не устроило решение?» я наконец получил внятный ответ. Хороший способ провести "эффективное" ревью. С тех пор я не стесняюсь переспрашивать. Уточните: «Расскажи, что именно не так». Если не помогает - фраза «Не понимаю, что вы говорите» часто отрезвляет. Она не обвиняет явно, но подчёркивает, что человек говорит невразумительно, и лучше бы ему изъясняться по-человечески.

Но оно бывает и таким: разговор начинается с того, что хорошо, но вот тут можно сделать более качественно - есть несколько подходов, вот первый, вот второй, вот примеры, где посмотреть. Если возникнут вопросы — сразу спрашивай, я помогу. Это бесплатный урок. Даже если ревьюер не сделал никаких замечаний, у таких коллег лучше лишний раз спросить: «А как бы вы сделали? Насколько вам нравится моё решение? Может, что-то можно улучшить?». Так можно быстрее улучшить свою экспертизу.

4. Сразу уделять большое внимание чистоте кода и архитектуры(уровень классов, сервисов и тп)

Лучше всего как можно раньше начать уделять большое вниманием этим аспектам, даже если вы видите, что в вашей команде кто-то на это забивал. Так как чем раньше начнете, тем меньше будет размер технического долга (скорость реализации в обмен на возможность поддержки и развития решения). Фраза «Потом отрефакторим», часто в действительности означает «Никогда»). А в результате мучительные и долгие правки которые делать либо вам, либо вашим коллегам, выслушивая много “лестных” слов в свой адрес, а вероятно и оба варианта сразу.

Например, в одной из компаний, где я работал, была практика выносить в отдельный общий модуль вещи, которые могут использоваться сразу в нескольких участках проекта и имеют идентичную структуру данных и функциональность и кажется, что для всех мест, где они используются - будут одинаковые изменения. Несколько месяцев, может лет, и в какой-то момент вполне предсказуемо изменения для разных участков проекта начали отличаться, не вносить их нельзя, так как заказчик уже стоит за дверью с мешком золота, и требует свои хотелки, причем побыстрее. А на этой вещи завязано множество критичных участков, и часть из них естественна не покрыта качественными тестами, следовательно, просто взять выкинуть старое и впихнуть туда новое не выйдет, нужно как минимум обеспечить хоть какие-то гарантии, что после изменений все зависимые участки не сломаются. И в итоге вам нужна куча времени, а как следствие и прилично денег компании на то, чтобы исполнить волю заказчика, который в ожидании своей хотелки то и думает, не пойти ли ему со своим мешком золота к более ответственным ребятам.

Таким образом, заботясь сразу о чистоте вашего кода и архитектуры, вы заплатите в разы меньше времени, а возможно и на порядок, чем если выберите подход “пока и так нормально”.

5. Не откладывать написание тестов

После того как вы реализовали какую-то функциональность, и прошло какое-то время, а тем более если это чужая функциональность, выбить время на покрытие ее тестами, будет сильно сложнее. Проще сразу заложить время на написание тестов в планируемое время на реализацию задачи.

Если у вас в команде плохо с культурой тестирования, можно сказать, что прежде, чем приступить к новой задаче, вы покроете тестами функционал предыдущей задачи.

Как-то раз была ситуация, когда нашей команде нужно было обновлять версию одной библиотеки для работы, и как на зло, с обновлением у нее изменился API, а тестов на участках, где она использовалась, было крайне мало. И помимо того, что тебе нужно разобраться с новым API, так тебе еще предварительно нужно покрыть все задействованные участки качественными тестами, а вспомнить как должны эти участки работать гораздо сложнее через несколько лет, чем в момент их создания. Поэтому, не забывая про тесты, вы сильно упрощаете себе жизнь на дистанции. И не забывайте о том, что тесты, это тоже код, и он тоже должен быть качественно спроектирован и реализован, и главное здесь не количество, а качество. Наличие бесполезных тестов хуже, чем их отсутствие, в основном бесполезные тесты дают ложное чувство безопасности, замедляют рефакторинг, множат себе подобных (плохой пример для других) и тратят время CI/CD.

6. Синдром самозванца

Синдром самозванца — это состояние, при котором специалист, независимо от реального уровня знаний, считает себя недостаточно компетентным. Вот несколько заблуждений, которые были у меня, которые я наблюдал у коллег и о которых слышал от знакомых разработчиков:

• Кажется, что я обманул всех: случайно прошёл собеседование, испытательный срок, а теперь месяцами (или даже годами) обманываю наставника, старших коллег и руководство.

• Когда я решаю сложные задачи — мне просто везёт. А если коллеги не справились до меня, значит, они уже частично решили задачу, и мне оставалось лишь «добить» ее.

• Если я не могу решить задачу сам, прошу помощи или трачу много времени — причина только в моей некомпетентности.

• И, конечно, кажется, рано или поздно придёт «настоящий эксперт» и разоблачит наглого диверсанта, который шифруется под программиста.

Полностью избавиться от этого состояния вряд ли получится, но с ним вполне можно работать. Лично мне и тем, кого я знаю, помогали следующие способы:

• Фиксировать достижения. Точное знание, что за время карьеры вы достигли конкретных результатов, помогает увидеть более реальную картину. Это может быть список в заметках, история в таск — трекере, граф коммитов — что угодно. Когда становится совсем грустно — полезно открыть этот список и напомнить себе: вообще‑то вот тут я разобрался с нетривиальной задачей, тут предложил решение, тут мне доверили сложный участок.

• Общаться с руководителем. Руководитель, как правило, видит картину целиком. Он может сказать, что вы на самом деле двигаетесь в правильном направлении, или помочь скорректировать вектор развития. Периодически инициировать такой разговор — нормально и полезно. Хорошему руководителю важно, чтобы сотрудник был заинтересован в росте, поэтому диалог пойдёт на пользу обоим.

7. Не изучать всё подряд

В первый год хочется охватить как можно больше: новые языки, фреймворки, инструменты — всё кажется важным и нужным. Но на ранних этапах такое распыление скорее мешает. Я в начале интересовался другими высокоуровневыми и низкоуровневыми языками, и кучей фреймворков, которые не использовались в работе. Прошло время, и выяснилось, что на практике мне сильнее всего не хватало знаний о рефакторинге, тестировании, архитектуре и производительности.

На старте эффективнее сфокусироваться на том, что используется в вашем проекте, а свободное время тратить на фундаментальные вещи. Такой подход даёт больше пользы и для текущей работы, и для роста как специалиста в целом.

8. Не злоупотреблять переработками

В начале карьеры кажется, что чем больше работаешь, тем быстрее растёшь. 12–14 часов в день, работа ночью, в выходные, в отпуске — я тоже таким промышлял. И у большинства тех, кто так делал, исход примерно одинаковый: кратковременный всплеск продуктивности, а затем резкое и уверенное снижение эффективности и движение в сторону истощения.

Стоит вспомнить одно старое сказание: сидишь до ночи над задачей — ничего не выходит, а утром садишься и решаешь её за 10 минут. Усталость сильнейшим образом влияет и на скорость, и на качество решений.

Конечно, бывают исключения: важный релиз, демо, срочная хотелка заказчика, который уже выслал своего курьера с мешком золота, в жажде важной фичи. Но если переработки становятся нормой — пора перерабатывать свой график. У каждого есть лимит часов, в которые он может выдавать качественный результат за разумное время.

9. Не бояться просить повышения

Вы растёте как специалист, и вместе с этим растёт ваша стоимость на рынке. Некоторые компании сами подходят и говорят: «Мы тебя повышаем». Но бывают и такие, где повышение нужно просить самостоятельно.

Ещё на этапе собеседования стоит узнавать, как в компании устроен карьерный рост: по каким критериям оценивают, как часто пересматривают зарплату, что нужно сделать, чтобы вырасти, и до куда примерно это возможно. Понимание этих правил поможет избежать неприятных ситуаций в будущем.

10. Не бояться проявлять инициативу

Если вы видите, что какой‑то процесс в команде или компании систематически создаёт проблемы, не нужно молчать только потому, что у вас мало опыта.

Пример: у вас в команде есть условный «человек‑знаток», который один знает ответы на специфичные для вашей компании/команды вопросы. Пока он на месте — все работают. Как только уходит в отпуск — процессы встают. Со стороны это выглядит как явная уязвимость процесса, и предложение завести базу знаний или хотя бы описывать где‑то типовые проблемы кажется логичным.

Если сомневаетесь, имеете ли право поднимать такие вопросы, — обсудите их с коллегами. Возможно, они думают о том же, и вместе вам будет проще сформулировать проблему и предложить решение.

Резюмируя

Это не исчерпывающих список, это то, что на мой взгляд было самое важное из опыта. Я постарался вкратце рассказать о каждом аспекте и если вам захочется что-то обсудить, с радостью отвечу в комментариях, а, если нужно будет раскрыть получше какой - либо из аспектов, могу написать дополнительный материал по ним.

Буду рад видеть вас в MAX и Telegram — там выкладываю материал, который не попал в статьи, рассказываю, над чем работаю, и общаюсь с вами

"Нам поставили задачу сделать ... Обычно это делается через ... стоимостью 50 тысяч рублей, за 1 день, но у нас его не оказалось, поэтому мы ...." Ключевое в "мы" - 2 инженера с суммарным ФОТ в 1 млн. руб. МЕСЯЦ делали то, что "обычно" делается 1 человеком за 1 день с устройством за 50 тыс. руб.

Если делать "как обычно" задача решается с бюджетом в 73 тыс. руб.

Если делать "по докладу", то задача решилась с бюджетом в 1 млн. руб т.е. в 13,7 раз дороже. При этом 2 инженера выпали из бизнес-процессов на месяц и не принесли прибыли.

Заказчик сего действия (не внутренняя задача) отказался от части пунктов контракта и переложил их на другого подрядчика, который такую же задачу на 2-м аналогичном сервисе решил вписав в счёт 150 тыс. руб., при том, что первый выставил 2 млн. руб.

Я смотрю материалы конференций. Слежу за трендами в ИТ. Ситуация выше - ПРАВИЛО, а не исключение. Безусловно я не отслеживаю каждый тренд, но по тем проектам за которыми слежу:

- уровня библиотек / сервисов уровня ОС/виртуализации - 90 % изменений экономически хуже, чем без изменений;

- уровень прикладных решений - 70 % изменений экономически хуже, чем без изменений;

То есть ситуация пришла к тому, что НЕ ДЕЛАЯ НИЧЕГО бизнес ПОЛУЧАЕТ БОЛЬШЕ.

Проблема существует на 2-х уровнях:

- управление в ИТ;

- инженеры в ИТ;

Рассмотрим на примере Яндекс.Навигатора, как наиболее для меня показательном.

Самим приложением я пользуюсь 10+ лет.

В 2016 году оно меня полностью устраивало. Как есть. Приложение занимало 106 Мб.

В 2022 году приложение (алгоритм поиска пути) поменяли и оно стало годиться только для того, чтобы прокладывать маршрут туда, куда 1 раз в жизни едешь и нет времени/сил вручную просидеть над картой.

В 2024 году Навигатор стал сбивать нормальный маршрут на свой высер (о чём я писал пост Яндекс.Навигатор и идиотизм)

В 2026 году "голое" приложение занимает 430 Мб. И с позиции потребителя оно ХУЖЕ, чем в 2016-м. При этом для использования в формате "мозгов" для головного устройства автомобиля оно требует подписку.

Подведём итог - за 10 лет приложение стало в +/- 4,3 раза больше, требует более нового железа, в приложении появилась куча багов, приложением пользоваться стало хуже, чем 10 лет назад.

Вопрос: а за что отдел разработки Яндекс.Навигатора 10 лет получал зарплату? Больше, дороже, хуже? А зачем?

Если мы посмотрим на жизненный цикл продукта, то увидим такую картину, которую можно изобразить классическим "крестом" спроса/предложения:

Если мы отсортируем возможности ("фишки") приложения так, чтобы слева были самые востребованные, то получим такое соотношение возможностей приложения и ресурсов, которое оно требует.

Синяя линия - доля пользователей, которым нужна функция. Красная линия - потребляемые приложением ресурсы. Высота под синей линией - для кого стало лучше, высота под красной - для кого стало хуже.

На графике отчётливо видно, что с момента пересечения каждое изменение делает продукт ХУЖЕ... НО!

Рассмотрим это с позиции всех участников, снизу вверх.

Пользователю нужно чтобы приложение имело меньше багов и весило меньше. Довольно быстро 85 - 90 % потребностей пользователя приложение закрывает полностью.

Разработчику нужны задачи, чтобы получать зарплату. Пофиг что - лишь бы были. Можно и на другой проект, но это же почти полностью переучиваться..

Менеджеру ИТ нужны задачи, чтобы получать зарплату. Причём смена проекта для него гораздо болезненней и опасней т.к. шанс вылета с работы гораздо выше, чем у разработчика.

Собственнику хочется больше денег в виде выручки и меньше денег в виде зарплат.

После прохождения критической точки получается, что интересы Разработчика и ИТ-менеджера не просто вступают в конфликт с интересами Пользователя и Собственника. Они становятся взаимоисключающими.То, что хорошо одной паре - плохо другой и наоборот.

Суть конфликта в том, что за всё платит Пользователь через Собственника.

Пользователь "голосует ногами" к конкуренту, его деньги не попадают к Собственнику. Как следствие Собственник режет бюджеты ИТ. А кто кого "съест" из менеджера и разработчика - плевать. В целом даже если оба уйдут - отлично. Приложение хуже становиться не будет и отток клиентов уменьшится.

Ещё в середине нулевых рядом ИТ-инженеров, которых сообщество быстро заклеймило идиотами, были призывы к тому, что ИТ-технологии не должны быть "вещью в себе". То есть не нужно добавлять в библиотеки функции ради функций, в интерфейсы кнопки ради кнопок и т.д. и т.п. Потому что будет... Да прямо скажем пиздец.

20+ лет таких инженеров подвергали остаркизму. Есть огромная библиотека мемов, поговорок и т.д. и т.п.

А теперь просто настало то, о чём предупреждали. Поэтому напомню аксиому и снова вернусь к картинке с графиками выше, потому что она иллюстрирует и второй пункт инженерии.

Пользователя и Собственника совершенно не ебёт как именно решена задача.

Если приложение на 100 Мб удовлетворяет мои потребности, то для Пользователя "хорошо" это:

- Приложение стало занимать меньше места;

- Приложение стало работать быстрее на том же железе.

Всё остальное - плохо! Вообще всё!

Для Собственника важен баланс затрат и выручки. То есть:

Если выручка в начале года была А, затраты Б, количество клиентов К, то "хорошо" это (н - начало года, к - конец года):

- в расчёте на пользователя (Ак - Бк) > (Ан - Бн)

- Кк > Кн;

Всё остальное - плохо! Вообще всё!

Так вот сегодня почти всё ИТ, это плохо. И с позиции Пользователя и с позиции Собственника.

Забавно, но у ИТ есть прекрасная, но позорная корреляция - АвтоВАЗ. Та же динамика - стоимость растёт, а качество не так чтобы очень...

В 2020 - 2025 году трогать ИТ-департаменты было нельзя из-за ковида и СВО. Теперь стало можно.

!!! ВАЖНО ПОНИМАТЬ !!! У собственников бизнеса есть свой "Хабр". Только он не в Интернете, а в кафе, встречах и банях. Где оффлайн эти самые собственники общаются и делают пометки в блокнотиках. И обсуждают сотрудников, решения. В целом всё тоже самое, что и в ИТ-сообществе. Только вопросы там задают другие и ответы там ждут в другой форме.

Так же как в ИТ обсуждают архитектуры, языки программирования, библиотеки, стеки и т.д. и т.п. собственники бизнеса обсуждают задачи, их продажи и затраты на их решения.

И там гордятся тем, что продажи повышаются, стоимость решения уменьшается, а спектры задач расширяются.

Второе !!! ВАЖНО ПОНИМАТЬ !!!! на работе зарплату платят не за то, что вы можете чем-то выпендриться на Хабре или конференции. Зарплату платят за решение задач. И зарплату платит Вам Пользователь через Собственника. И размер зарплаты напрямую зависит от того, насколько удовлетворены эти категории людей. Если Пользователь не удовлетворён, то он идёт к конкуренту и денег на зарплату нет. Если Собственник не удовлетворён, то он полученные от Пользователя деньги положит к себе в карман. Не устраивает? Ну пили сам свой бизнес.

Ковид и СВО не вырастили ИТ. Они ЗАСТАВИЛИ бизнес переплачивать. Как врачам непосредственно в ковидные времена. А как только хромого вылечили, он первым делом бросает свою трость...

Что делать?

Решать проблемы. Список того что не устраивает бизнес и пользователей:

1. Не прозрачность решений. Каждое изменение должно быть обоснованным с рассмотрением вариантов. То есть мы делаем А потому что оно стоит Х, вариант Б стоит 2Х, вариант В стоит Х/2, но есть 80 % вероятность проблемы Г, которая будет стоить 10Х. Раньше бизнес слышал "Нужно Д", про себя матерился, но давал деньги... Это время прошло.

2. Достоверность. Приходит Менеджер ИТ к начальнику и озвучивает схему выше. По факту оказалось, что Х это 5Х, а у конкурента сделали Б и оказалось, что там не 2Х, а 0,75Х. В сауне с конкурентом собственника высмеяли за 5Х вместо 0,75Х... Но он не будет собирать всех и орать. Это в госсекторе так можно. Просто в следующий раз ваши слова считаются истиной на 20 % и как только будет вариант, которому верят хотя бы на 25 %, Вас будут заменять.

3. Эффективность. Снова повторю, что бизнес - благотворительная организация. Чем выше выручка и чем меньше затраты, тем Вы более ценный сотрудник. Если Ваша ценность становится ниже некоторого значения из полезного инструмента Вы превращаетесь в камень на шее. Полезный инструмент ценят, от камня на шее избавляются.

Кто сможет работать по новому - останется, остальных рано или поздно из ИТ выдавят. Скорее рано, чем поздно.

Кстати, коллеги, не расстраиваемся. Электрики с "красивыми щитками" и отдельными проводами к каждой розетки и лампочке, водопроводчики с отдельной трубой к каждому крану и сантехники по отоплению с отдельной парой труб на каждый радиатор во вполне обозримом будущем так же дружно нахуй пойдут.

P.S. Думал сделать бонусом рассуждения и инсайды о том, что и как будет дальше. Увидел по рейтингу поста и комментариям, что никто не хочет слушать и слышать...

Бывайте ихтиандры, потом сюрпризом будет.