Предлагаю проверить, насколько хорошо вы понимаете, что происходит внутри сборки. Небольшой квиз из 10 вопросов про зависимости, плагины, задачи, конфигурации и другие возможности Gradle. Здесь не нужно разбирать километры кода — вопросы скорее проверят, насколько хорошо вы понимаете, как работает Gradle и зачем нужны его основные механизмы.
Квиз вы найдете по ссылке
Приветствую, дорогие читатели! 👋
Давненько не было постов. Думали, я забросил?
Ан нет — всё идёт полным ходом. Просто были другие жизненные дела. 😁
Итак, продолжим.
После того как наша игра получила первую визуализацию, захотелось сделать её похожей на настоящую настолку.
Поэтому мы временно отложили бэкенд и занялись фронтом.
И тут начались недопонимания. Объяснить словами код — это одно.
А вот объяснить словами то, что я вижу, а ИИ — нет… это уже сложнее.
В какой-то момент поле превратилось в хаос: блоки накладывались друг на друга, смотрели не в ту сторону. Я говорил Логосу — он решал одну проблему и тут же создавал другую. А я, поддавшись эмоциям, тоже потерял холодную голову. 😁
Но потом — вдох. Выдох. Остановился. Подумал.
Открыл код, вспомнил свой прошлый опыт по фронту — и поправил как надо.Теперь это действительно больше похоже на настольную игру.
Правда, окончательно фронт мы не доделывали — я понял, что работы там не меньше, чем с бэкендом (а то и больше).
Главное — теперь можно было тестировать визуально.
И в первой же партии обнаружился баг: определённая карта при розыгрыше добавлялась в два места, а не в одно.
В JSON я бы этого не заметил.
А на экране — сразу.
Дальше мы продолжили внутреннюю работу — но уже не просто прописывая карты, а то, как они должны взаимодействовать с другими объектами.
Тут тоже получился интересный момент.
Изначально у меня крутилось видение, как это должно быть, но я не мог сформулировать — мысль ещё не созрела.
Поэтому сначала мы сделали парсинг JSON по эффекту карты.
И вот сижу в конце вечера, гляжу на код — и меня озаряет: это неправильно.
Вспомнилось про ООП… и мысль созрела.
Я сообщил Логосу. Мы отказались от парсинга эффектов из JSON.
Вместо этого логика эффектов была вынесена в отдельные сервисы-обработчики, которые в зависимости от типа и ID карты выполняют нужные действия, взаимодействуя с другими картами, предметами и состоянием игры.
Карты остались объектами-данными, но теперь их поведение определяют обработчики.
И наконец я смог спокойно лечь спать. 😁
Каждый раз хочу лечь часов в 22–22:30.
Но не могу оторваться — и только в 12 лечу в кровать.
Вредно, но что поделать, когда процесс так затягивает.
Ой… отвлёкся. 😁
Работающий бэкенд (пока ещё шлифуется)
Первичный фронт — играть уже можно
Закрепление навыков во взаимодействии с ИИ
Мысли о дальнейших шагах 😊
Вот как-то так…
Как вы считаете: моя фантазия, что ведя такой блог, меня кто-то увидит, заметит во мне потенциал (если он вообще есть) и скажет: «Пойдём работать к нам» — это вообще реально?
Или как говорится: «Нет, сынок, это фантастика» 🥲
P.S. Спасибо, что читаете. Ваши комментарии — топливо для этого костра.
А если у вас есть истории, как блог или проект помогли вам в карьере — делитесь. Очень интересно.
Дорогие читатели, категорически вас приветствую! Я прошел путь от стажера до разработчика Java с опытом в 5+ лет. За это время было принято не мало хороших решений, но плохие тоже не отставали, о последних и возможном способе их решения я хочу рассказать, и возможно кому то это поможет не наступить на те же грабли что и я, или же менее болезненно “отодрать” их от своих ног, если вы уже попали на них.
В самом начале я думал: «Вряд ли есть что-то настолько же важное как сам код», а как оказалось вокруг есть еще очень много важных аспектов, о которых было бы здорово услышать заранее. Материал будет разбит на две части, в этой: онбординг, работа с задачами, код-ревью, тесты и чистые код и архитектура.
1. Онбординг: не бояться спрашивать и просить помощи
Многие люди боятся спрашивать, потому что кажется: «Я и так должен сам разобраться». В итоге вы можете сидеть часами множить неудачные попытки с чем-то разобраться, и винить себя в некомпетентности, хотя очень вероятно, что проблема не в вас. На самом деле никто не ждет от вновь прибывшего сотрудника, тем более у которого еще нет многолетнего опыта за спиной, что он с ходу разберется во всем.
Задача онбординга – с наибольшим комфортом и за наименьшее время помочь вам влиться в процессы компании и команды. Поэтому смело задавайте вопросы и просите помощи при необходимости у ответственных лиц. При этом не забывая о балансе, есть вещи которые предполагается что вы знаете, например установить среду разработки, склонить проект, установить и настроить СУБД по конфигу и тому подобное. А есть вещи специфические для конкретной компании или команды, который вы не можете знать изначально, например где лежат конфигурации для различных стендов, какие политики именования веток в системе контроля версий, где взять доступы к внутренним API и так далее. И помните, вашем быстром и комфортном онбординге заинтересован бизнес, вы имеете полное право на него.
Например когда я пришел начинающим разработчиком в одну из компаний, где я работал, мне в первый день дали древнюю документацию, и сказали пройти по ней тестирование по знанию продукта, а после развернуть его, с тестированием я сходу справился, а вот с разверткой проекта возникла трудность, проект никак не стартовал. Я несколько часов штудировал доку и пытался найти чего же мне не хватает для поднятия проекта. Ведь мне дали большую доку, где, казалось бы, все необходимое уже точно есть, ведь люди наверняка поддерживают актуальность доки, но, к сожалению, я ошибался. Оказалось, что конфиги для поднятия проекта не актуальные, и я никак не смог бы сделать это самостоятельно. И прежде, чем корить себя после долгих неудачных попыток, лучше пойти и задать вопрос ответственному коллеге, ведь нет ничего зазорного в том, чтобы спрашивать о том, чего не могли значить чисто физически.
2. Не стесняться спрашивать того, кто дал задачу, но подходить к этому с умом
В начале карьеры (после тоже немало) особенно часто могут возникать ситуации, когда вы не поняли, что требуется в задаче. Не нужно думать, что вы не обладаете достаточным количеством знаний чтобы с ходу понять задачу. Проблема постановки задач преследует огромное количество специалистов, как начинающих, так и очень опытных. Но важно помнить о балансе, не нужно бегать с абсолютно любыми вопросами. Необходимо сначала постараться разобраться в вопросе, применить свои знания и опыт, а так же умение поиска информации, и только после этого идти к коллеге с собранной пачкой грамотно сформулированных вопросов.
Например, в одной из компании у меня была ситуация, когда на очередном распределении задач, я получил свою, в ней как мне, казалось, было все очень подробно расписано, с широко развернутым текстовым описанием, примерами, изображениями с уточняющей информацией и выглядело это как нечто внушающее доверие. Но у меня никак не получалось интегрировать функциональность в то место куда требовалось, я прилично времени сидел вчитывался в ТЗ, изучал целевой участок проекта, документацию по нему (в этом проекте она была хорошей в отличие от примера из первого пункта), но никак не мог ее интегрировать. Я думал: «Не пойму, такая красивая задача, все так хорошо описано, столько дополнительной информации, хорошая документация, а я не могу с ней справится». Оказалось, все довольно прозаично. Оказалось, что аналитик просто указал не тот участок приложения, а схожий, извинился и внес изменения в ТЗ.
Поэтому нужно смело уточнять все что вам не понятно, это естественная часть процесса решения задач. Лучше всего собрать список вопросов и подойти к ответственному сотруднику и обсудить максимум вопросов за раз. Это гораздо лучше каждые 5 минут бегать к коллеге с 1 новым вопросом.
Бывает, что сидишь с какой-то задачей, уже вопросы все задал, но все равно не получается ее решить. Скорее всего просто не хватает опыта решения задач в условиях реальной работы, и это нормально. Не нужно сидеть и заниматься самобичеванием, адекватные опытные коллеги не будут осуждать начинающего специалиста, они скорее с удовольствием помогут, ведь на самом деле отрадно и полезно помогать своим младшим коллегам.
3. Код-ревью. Защищаться и получать выгоду
Сомнительное ревью — вам могут сказать что-то вроде «Так пишут студенты», «Решение так себе» и не объясняют почему. Это не про вас. Это про неумение ревьюера в коммуникации.
Как-то раз мне сказали: «Мне не нравится, надо переписывать». Я спросил: «А что не так?» - «Так писать нельзя». И только после третьего вопроса «Почему именно не устроило решение?» я наконец получил внятный ответ. Хороший способ провести "эффективное" ревью. С тех пор я не стесняюсь переспрашивать. Уточните: «Расскажи, что именно не так». Если не помогает - фраза «Не понимаю, что вы говорите» часто отрезвляет. Она не обвиняет явно, но подчёркивает, что человек говорит невразумительно, и лучше бы ему изъясняться по-человечески.
Но оно бывает и таким: разговор начинается с того, что хорошо, но вот тут можно сделать более качественно - есть несколько подходов, вот первый, вот второй, вот примеры, где посмотреть. Если возникнут вопросы — сразу спрашивай, я помогу. Это бесплатный урок. Даже если ревьюер не сделал никаких замечаний, у таких коллег лучше лишний раз спросить: «А как бы вы сделали? Насколько вам нравится моё решение? Может, что-то можно улучшить?». Так можно быстрее улучшить свою экспертизу.
4. Сразу уделять большое внимание чистоте кода и архитектуры(уровень классов, сервисов и тп)
Лучше всего как можно раньше начать уделять большое вниманием этим аспектам, даже если вы видите, что в вашей команде кто-то на это забивал. Так как чем раньше начнете, тем меньше будет размер технического долга (скорость реализации в обмен на возможность поддержки и развития решения). Фраза «Потом отрефакторим», часто в действительности означает «Никогда»). А в результате мучительные и долгие правки которые делать либо вам, либо вашим коллегам, выслушивая много “лестных” слов в свой адрес, а вероятно и оба варианта сразу.
Например, в одной из компаний, где я работал, была практика выносить в отдельный общий модуль вещи, которые могут использоваться сразу в нескольких участках проекта и имеют идентичную структуру данных и функциональность и кажется, что для всех мест, где они используются - будут одинаковые изменения. Несколько месяцев, может лет, и в какой-то момент вполне предсказуемо изменения для разных участков проекта начали отличаться, не вносить их нельзя, так как заказчик уже стоит за дверью с мешком золота, и требует свои хотелки, причем побыстрее. А на этой вещи завязано множество критичных участков, и часть из них естественна не покрыта качественными тестами, следовательно, просто взять выкинуть старое и впихнуть туда новое не выйдет, нужно как минимум обеспечить хоть какие-то гарантии, что после изменений все зависимые участки не сломаются. И в итоге вам нужна куча времени, а как следствие и прилично денег компании на то, чтобы исполнить волю заказчика, который в ожидании своей хотелки то и думает, не пойти ли ему со своим мешком золота к более ответственным ребятам.
Таким образом, заботясь сразу о чистоте вашего кода и архитектуры, вы заплатите в разы меньше времени, а возможно и на порядок, чем если выберите подход “пока и так нормально”.
5. Не откладывать написание тестов
После того как вы реализовали какую-то функциональность, и прошло какое-то время, а тем более если это чужая функциональность, выбить время на покрытие ее тестами, будет сильно сложнее. Проще сразу заложить время на написание тестов в планируемое время на реализацию задачи.
Если у вас в команде плохо с культурой тестирования, можно сказать, что прежде, чем приступить к новой задаче, вы покроете тестами функционал предыдущей задачи.
Как-то раз была ситуация, когда нашей команде нужно было обновлять версию одной библиотеки для работы, и как на зло, с обновлением у нее изменился API, а тестов на участках, где она использовалась, было крайне мало. И помимо того, что тебе нужно разобраться с новым API, так тебе еще предварительно нужно покрыть все задействованные участки качественными тестами, а вспомнить как должны эти участки работать гораздо сложнее через несколько лет, чем в момент их создания. Поэтому, не забывая про тесты, вы сильно упрощаете себе жизнь на дистанции. И не забывайте о том, что тесты, это тоже код, и он тоже должен быть качественно спроектирован и реализован, и главное здесь не количество, а качество. Наличие бесполезных тестов хуже, чем их отсутствие, в основном бесполезные тесты дают ложное чувство безопасности, замедляют рефакторинг, множат себе подобных (плохой пример для других) и тратят время CI/CD.
6. Синдром самозванца
Синдром самозванца — это состояние, при котором специалист, независимо от реального уровня знаний, считает себя недостаточно компетентным. Вот несколько заблуждений, которые были у меня, которые я наблюдал у коллег и о которых слышал от знакомых разработчиков:
Кажется, что я обманул всех: случайно прошёл собеседование, испытательный срок, а теперь месяцами (или даже годами) обманываю наставника, старших коллег и руководство.
Когда я решаю сложные задачи — мне просто везёт. А если коллеги не справились до меня, значит, они уже частично решили задачу, и мне оставалось лишь «добить» ее.
Если я не могу решить задачу сам, прошу помощи или трачу много времени — причина только в моей некомпетентности.
И, конечно, кажется, рано или поздно придёт «настоящий эксперт» и разоблачит наглого диверсанта, который шифруется под программиста.
Полностью избавиться от этого состояния вряд ли получится, но с ним вполне можно работать. Лично мне и тем, кого я знаю, помогали следующие способы:
Фиксировать достижения. Точное знание, что за время карьеры вы достигли конкретных результатов, помогает увидеть более реальную картину. Это может быть список в заметках, история в таск — трекере, граф коммитов — что угодно. Когда становится совсем грустно — полезно открыть этот список и напомнить себе: вообще‑то вот тут я разобрался с нетривиальной задачей, тут предложил решение, тут мне доверили сложный участок.
Общаться с руководителем. Руководитель, как правило, видит картину целиком. Он может сказать, что вы на самом деле двигаетесь в правильном направлении, или помочь скорректировать вектор развития. Периодически инициировать такой разговор — нормально и полезно. Хорошему руководителю важно, чтобы сотрудник был заинтересован в росте, поэтому диалог пойдёт на пользу обоим.
7. Не изучать всё подряд
В первый год хочется охватить как можно больше: новые языки, фреймворки, инструменты — всё кажется важным и нужным. Но на ранних этапах такое распыление скорее мешает. Я в начале интересовался другими высокоуровневыми и низкоуровневыми языками, и кучей фреймворков, которые не использовались в работе. Прошло время, и выяснилось, что на практике мне сильнее всего не хватало знаний о рефакторинге, тестировании, архитектуре и производительности.
На старте эффективнее сфокусироваться на том, что используется в вашем проекте, а свободное время тратить на фундаментальные вещи. Такой подход даёт больше пользы и для текущей работы, и для роста как специалиста в целом.
8. Не злоупотреблять переработками
В начале карьеры кажется, что чем больше работаешь, тем быстрее растёшь. 12–14 часов в день, работа ночью, в выходные, в отпуске — я тоже таким промышлял. И у большинства тех, кто так делал, исход примерно одинаковый: кратковременный всплеск продуктивности, а затем резкое и уверенное снижение эффективности и движение в сторону истощения.
Стоит вспомнить одно старое сказание: сидишь до ночи над задачей — ничего не выходит, а утром садишься и решаешь её за 10 минут. Усталость сильнейшим образом влияет и на скорость, и на качество решений.
Конечно, бывают исключения: важный релиз, демо, срочная хотелка заказчика, который уже выслал своего курьера с мешком золота, в жажде важной фичи. Но если переработки становятся нормой — пора перерабатывать свой график. У каждого есть лимит часов, в которые он может выдавать качественный результат за разумное время.
9. Не бояться просить повышения
Вы растёте как специалист, и вместе с этим растёт ваша стоимость на рынке. Некоторые компании сами подходят и говорят: «Мы тебя повышаем». Но бывают и такие, где повышение нужно просить самостоятельно.
Ещё на этапе собеседования стоит узнавать, как в компании устроен карьерный рост: по каким критериям оценивают, как часто пересматривают зарплату, что нужно сделать, чтобы вырасти, и до куда примерно это возможно. Понимание этих правил поможет избежать неприятных ситуаций в будущем.
10. Не бояться проявлять инициативу
Если вы видите, что какой‑то процесс в команде или компании систематически создаёт проблемы, не нужно молчать только потому, что у вас мало опыта.
Пример: у вас в команде есть условный «человек‑знаток», который один знает ответы на специфичные для вашей компании/команды вопросы. Пока он на месте — все работают. Как только уходит в отпуск — процессы встают. Со стороны это выглядит как явная уязвимость процесса, и предложение завести базу знаний или хотя бы описывать где‑то типовые проблемы кажется логичным.
Если сомневаетесь, имеете ли право поднимать такие вопросы, — обсудите их с коллегами. Возможно, они думают о том же, и вместе вам будет проще сформулировать проблему и предложить решение.
Резюмируя
Это не исчерпывающих список, это то, что на мой взгляд было самое важное из опыта. Я постарался вкратце рассказать о каждом аспекте и если вам захочется что-то обсудить, с радостью отвечу в комментариях, а, если нужно будет раскрыть получше какой - либо из аспектов, могу написать дополнительный материал по ним.
эта игра сделана мной в одиночку я всегда хотел иметь своё комьюнити если хотите поиграть то напишите в комментарии , я стараюсь обновлять игру и не гонюсь за деньгами , я уже думаю написать музыку для неё и звуки !!!
Итак, в прошлом посте мы рассмотрели процессы с позиции бизнеса. Теперь с позиции именно технической части в ИТ.
Ключевой вопрос: кто считает рентабельность изменений в ИТ?
Правильный ответ - никто.
Я даже усугублю вопрос. Некоторый "уровень" и "престиж" инженеры в ИТ "зарабатывают" на выступлениях в разных конференциях. А вы на тексты выступлений, с позиции человека, который платит зарплату смотрели?
Корень проблемы в том, что экономика ИТ непосредственно инженеров волнует ещё меньше, чем то, что происходит внутри "чёрного ящика" ИТ для собственников бизнеса.
Вот решил собственник ... посмотреть выступление своих сотрудников на ...конфе2025. Посмотрел. А потом в неформальной обстановке меня спрашивает правильно ли он понял то, о чём говорили его сотрудники. Ситуация такая
"Нам поставили задачу сделать ... Обычно это делается через ... стоимостью 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 году трогать ИТ-департаменты было нельзя из-за ковида и СВО. Теперь стало можно.
!!! ВАЖНО ПОНИМАТЬ !!! У собственников бизнеса есть свой "Хабр". Только он не в Интернете, а в кафе, встречах и банях. Где оффлайн эти самые собственники общаются и делают пометки в блокнотиках. И обсуждают сотрудников, решения. В целом всё тоже самое, что и в ИТ-сообществе. Только вопросы там задают другие и ответы там ждут в другой форме.
Так же как в ИТ обсуждают архитектуры, языки программирования, библиотеки, стеки и т.д. и т.п. собственники бизнеса обсуждают задачи, их продажи и затраты на их решения.
И там гордятся тем, что продажи повышаются, стоимость решения уменьшается, а спектры задач расширяются.
Второе !!! ВАЖНО ПОНИМАТЬ !!!! на работе зарплату платят не за то, что вы можете чем-то выпендриться на Хабре или конференции. Зарплату платят за решение задач. И зарплату платит Вам Пользователь через Собственника. И размер зарплаты напрямую зависит от того, насколько удовлетворены эти категории людей. Если Пользователь не удовлетворён, то он идёт к конкуренту и денег на зарплату нет. Если Собственник не удовлетворён, то он полученные от Пользователя деньги положит к себе в карман. Не устраивает? Ну пили сам свой бизнес.
Ковид и СВО не вырастили ИТ. Они ЗАСТАВИЛИ бизнес переплачивать. Как врачам непосредственно в ковидные времена. А как только хромого вылечили, он первым делом бросает свою трость...
Что делать?
Решать проблемы. Список того что не устраивает бизнес и пользователей:
Не прозрачность решений. Каждое изменение должно быть обоснованным с рассмотрением вариантов. То есть мы делаем А потому что оно стоит Х, вариант Б стоит 2Х, вариант В стоит Х/2, но есть 80 % вероятность проблемы Г, которая будет стоить 10Х. Раньше бизнес слышал "Нужно Д", про себя матерился, но давал деньги... Это время прошло.
Достоверность. Приходит Менеджер ИТ к начальнику и озвучивает схему выше. По факту оказалось, что Х это 5Х, а у конкурента сделали Б и оказалось, что там не 2Х, а 0,75Х. В сауне с конкурентом собственника высмеяли за 5Х вместо 0,75Х... Но он не будет собирать всех и орать. Это в госсекторе так можно. Просто в следующий раз ваши слова считаются истиной на 20 % и как только будет вариант, которому верят хотя бы на 25 %, Вас будут заменять.
Эффективность. Снова повторю, что бизнес - благотворительная организация. Чем выше выручка и чем меньше затраты, тем Вы более ценный сотрудник. Если Ваша ценность становится ниже некоторого значения из полезного инструмента Вы превращаетесь в камень на шее. Полезный инструмент ценят, от камня на шее избавляются.
Кто сможет работать по новому - останется, остальных рано или поздно из ИТ выдавят. Скорее рано, чем поздно.
Кстати, коллеги, не расстраиваемся. Электрики с "красивыми щитками" и отдельными проводами к каждой розетки и лампочке, водопроводчики с отдельной трубой к каждому крану и сантехники по отоплению с отдельной парой труб на каждый радиатор во вполне обозримом будущем так же дружно нахуй пойдут.
P.S. Думал сделать бонусом рассуждения и инсайды о том, что и как будет дальше. Увидел по рейтингу поста и комментариям, что никто не хочет слушать и слышать...
Бывайте ихтиандры, потом сюрпризом будет.
Сломан не найм в ИТ. Сломано само ИТ. Намеренно. И не только в России. И началось всё не вчера и даже не позавчера. Ещё в далёком 2016-м бизнес стал понимать, что с ИТ "что-то не так".
Тема разделена на 2 поста. Сперва с позиции бизнеса, второй пост - с позиции инженера в ИТ.
На этот счёт я сделал пост-пример, который ушел в минуса: Ненависти пост 01: Позор профессии ИТ
Через год опять заминусованный пост про то, что с позиции бизнеса ряд "стандартов" в ИТ являются очень плохими: История одного взлома
В тот же год ещё один пост, но уже вышедший в плюс насчёт размеров приложений Технический коллапс (тема актуальна и сегодня)
И качества ИТ-продуктов: Яндекс. Когда левая рука не знает, что делает правая
Тут надо сделать остановку и ввести крайне важный "дисклеймер" (предупреждение). Уже излагал в посте Почему ИТшники не линейные работники поэтому просто процитирую себя:
Поэтому ИТ, хоть и является крайне важной отраслью, но её сотрудники являются сервисно-сопровождающим классом. А тем, у кого подгорает от этого... Мир не обязан подстраиваться под чьи либо хотелки, он такой, какой есть.
Почему позиционирование ИТ как сервиса/поддержки имеет принципиальную важность?
Возьмём ТО автомобиля. Клиент платит за то, чтобы автомобиль продолжал ездить. И он готов за него платить МИНИМАЛЬНУЮ стоимость. То есть никто делать ТО каждые 100 - 500 - 1000 км не будет. Принципиально. Заказчик (бизнес) платит за результат. Запустим аллегорию булки хлеба и сделаем точкой отсчёта 2010 год в котором собственно всё уже оказалось настолько запущено, что сор выполз из избы. Итак 2010 год, булка хлеба стоит 10 рублей, весит 1 кг и на вкус 10 из 10. Сделаем ещё пару важных предупреждений и пойдём по хронологии:
В прошлых постах не освещено, но тоже крайне важно:
С позиции бизнеса ИТ, это как с позиции коллективного запада понятие "русский", то есть от начальника ИТ и ниже (для англичанина/француза русские это не только жители России, и даже не только украинцы, белорусы... Но и всякие литовцы/латыши/узбеки/киргизы и т.д. и т.п.).
Для точного понимания нужно всё-таки ещё раз повторить кто такие "бизнес", "собственник", "предприниматель","капитал" и "капиталист" и каково их позиционирование.
Бизнес - коллективная деятельность направленная на извлечение прибыли или получение иного результата.
Собственник - человек, который вложил личные средства в бизнес. Личные - ключевое для понимания.
Предприниматель - собственник бизнеса, который создал его для получения какого-либо не финансового результата. Например, человек хочет в городе круглогодичный ледовый каток. Его строительство и эксплуатация стоит денег. Чтобы их заработать человек делает бизнес, который приносит деньги на строительство этого самого ледового катка. Ну или простой пример - Галицкий и его парк, это наглядный и точный пример предпринимательства.
Капиталист - собственник бизнеса, который создал его для увеличения личного капитала.
Капитал - совокупность активов, как в виде денег так и в виде собственности.
Ключевая цель капитализма - преумножение капитала. То есть чистая сумма активов должна постоянно возрастать. Для чего рост активов должен превышать инфляцию. То есть:
Если инфляция составляет А в год, а сумма активов Б, то по итогам года (В) сумма активов должна отвечать следующему соотношению: В > А + (А * Б)
Ключевая формула бизнеса: прибыль = выручка - расходы
То есть ключевая цель капитализма и капиталистов - повышение выручки и снижение расходов.
Тут надо остановиться и прямо указать один момент. Вы с объявления аллегории видели ИТ-термины? Нет. И не увидите. С позиции собственников бизнеса ИТ (как и любое другое подразделение) это "чёрный ящик" куда вкладывается А рублей в начале года и от которого ждут В рублей в конце. Что происходит внутри этого ящика капиталистов и бизнес волнует точно так же как шерифа проблемы негров т.е. извините за прямоту - абсолютно похуй.
ИТ - сообщество. Как и в любом сообществе тон задаёт крайне небольшое меньшинство, которое умеет громче всех кричать. Как зоошиза. Разбор "стандартов" в ИТ я уже делал:
Так же, его делали и другие люди с аналогичным результатом.
Так же я разобрал почему для бизнеса 1С круче всего остального:
Но @astrobeglec, же дебил и ничего не понимает...
Так вот возвращаемся из вводной части к аллегории. Сор из избы вышел в 2010. Предположим что инфляция 0, чтобы не рожать лишние расчёты и сущности:
Динамика:
2010 год, булка хлеба стоит 10 рублей, весит 1 кг и на вкус 10 из 10.
2015 год, булка хлеба стоит 20 рублей, весит 1 кг и на вкус 10 из 10.
2018 год, булка хлеба стоит 40 рублей, весит 0,9 кг и на вкус 9 из 10.
2020 год, булка хлеба стоит 100 рублей, весит 0,8 кг и на вкус 9 из 10.
2021 год, булка хлеба стоит 120 рублей, весит 0,7 кг и на вкус 9 из 10.
2022 год, булка хлеба стоит 150 рублей, весит 0,6 кг и на вкус 8 из 10.
2023 год, булка хлеба стоит 250 рублей, весит 0,5 кг и на вкус 7 из 10.
2024 год, булка хлеба стоит 275 рублей, весит 0,4 кг и на вкус 6 из 10.
2025 год, булка хлеба стоит 300 рублей, весит 0,3 кг и на вкус 5 из 10.
Ломать ИТ хотели ещё в 2020-2021-м годах. Но сперва ковид, а потом СВО не дали запустить механизм. В 2026 произошли сразу 2 события, которые позволили запустить процесс:
Перестали появляться блокирующий факторы типа ковида/сво.
Появился крайне удобный инфоповод - искусственный интеллект, который позволил замаскировать (т.е. послужить удобным прикрытием) для процессов.
И процесс запустили. Какой процесс? Типичный для бизнеса, который до этого работал со 100 % эффективностью. Урезание бюджетов. Помните высказывание (по словам В. В. Полеванова) Ржавого в начале 00-х?
Что вы волнуетесь за этих людей? Ну, вымрет тридцать миллионов. Они не вписались в рынок. Не думайте об этом — новые вырастут.
Абсолютно тот же процесс сегодня запущен в ИТ. Бизнес видел, что булка хлеба может стоить 10 рублей за кг с качеством 10 из 10. Там понимают, что новые потребности требуют не 1 булку хлеба, а 10. И что рост в 10 раз приведёт к падению качества... Ну например до 8 из 10.
Поэтому где-то на бумагах (а не в компьютерах) или в блокнотах лежат согласованные крупными игроками планы доведения к 20ХХ году стоимости 10 кг хлеба с качеством 8 из 10 до 100 рублей.
Не вписавшиеся в план капитал не волнуют.
То, что мы видим сейчас - процесс понимания насколько сильно можно и нужно давить на ИТ. Это ещё даже не начало самого процесса.
Мы провели эксперимент в реальном времени. На Пикабу. Сегодня утром.
Пикабу громит нейрослоп ))
Пикабу разнес нейрослоп - это ожидаемо. Но гораздо интереснее тут совсем другое - это то что нейросеть предсказала поведение пользователей Пикабу и результат поста. Очень точно. Смотрите сами:
Прогноз нейросети перед публикацией.
Это очень интересный результат. А вы как думаете?
Поэтому прошу вас обязательно проголосовать(от чистого сердца, если полная хрень - ставьте 1). Для точного голосования нужно чтобы все увидели этот опрос.
Поэтому прошу поставить плюсик самому посту и 1 в опросе если вам не понравилось. - это будет честнее всего. Удачи вам и всех благ. Надеюсь результаты голосования будут интересными для каждого.
Айтишники наверное уже догадались кто это ;)
Изначально статья предназначалась для узкого круга(ИТ), но её высоко оценили и решили выкатить в прод. Если ты айтишник - дочитай до конца, все персонажи узнаваемы. Возможно это позволит тебе взглянуть на найм в ИТ с другой стороны. Если ты просто читатель и не имеешь к ИТ никакого отношения статья сделана в виде рассказа(при этом основана на реальных событиях). Надеюсь понравится. Не забудь поставить плюс если зашло, минус если нет и написать коммент если есть что возразить или дополнить.
Начнём с самого простого и самого неудобного факта.
Суд, на котором разбирали, кто сломал найм в стране, — действительно был спектаклем. Не в переносном смысле, не как красивая метафора для статьи. В прямом.
Это был формат. Имитация судебного заседания в рамках ИТ-фестиваля. У него был организатор — конференция, которая зарабатывает на мероприятиях для айтишников и HR. Была заявленная механика: пятьдесят представителей нанимающей стороны и пятьдесят кандидатов в одном зале. Были роли, распределённые заранее: подсудимый, адвокат, прокурор, судья, присяжные. Были билеты, трансляция и промокод.
И был финальный элемент конструкции, на который почти никто не обратил внимания:
Судья не выносит приговор. Решение остаётся за залом.
То есть заседание было устроено так, чтобы никогда ничем не закончиться.
Запомните эту деталь. К ней всё и сведётся.
Место Антона — скамья подсудимых. Центр сцены, свет в лицо.
Антон любит истории. Не «полезный контент», не «пять лайфхаков для резюме» — именно истории. Он может полчаса разбирать, почему в «Аркейне» конфликт не между хорошими и плохими, а между двумя этажами одного города: верхний производит смыслы и прогресс, нижний производит людей, которые верхнему нужны ровно до тех пор, пока не начнут задавать вопросы.
Он объяснит, почему «Ведьмак» не про монстров, а про то, что выбирать всегда приходится между двумя дрянными вариантами, и любой, кто говорит «а я не выбираю», просто ещё не дочитал. Он пересказывает «Зайчиху» так, что к третьему абзацу ты уже не понимаешь, где сказка, а где твой последний перформанс-ревью.
И вот эта любовь к нарративу — самое интересное, что произошло в русском ИТ за последние годы. Потому что Антон первым додумался до простой вещи:
Рынок труда работает не на фактах. Рынок труда работает на лоре.
Резюме — не документ, а синопсис. Собеседование — не проверка знаний, а прослушивание: тебя оценивают по тому, насколько убедительно ты играешь роль. Грейд — не уровень компетенции, а место в сюжетной иерархии. «Джун», «мидл», «сеньор» — это не ваша оценка, а ваши амплуа в офисном спектакле.
Офис типичной крупной ИТ-компании, говорят что Яндекс. Но это не точно ;)
Антон построил вокруг этого сообщество. Заун против Пилтовера, волки против системы, «двери заперты — значит, будем входить через заднюю дверь». Людям без опыта продали не навык. Им продали роль: ты не безработный неудачник, ты волк, ты играешь против нечестной системы по её же нечестным правилам.
И дальше случилось главное. Индустрия получила то, чего ей отчаянно не хватало.
Она получила злодея.
До Антона было неудобно: найм ломался, а виноватых не было. Компании просто оптимизируют. Джоб-сайты просто площадка. Эдтехи, продавшие сотням тысяч людей мечту «войти в айти за полгода», просто бизнес. Никто не виноват, всем плохо, писать не о чем.
А тут — человек, который прямо говорит: да, я учу обходить фильтры. Готовый антагонист. С лицом, каналом и цитатами.
И его посадили на скамью. Буквально.
Место Леси — авансцена. Там, где актёр ближе всего к залу.
Она пришла в профессию, когда вакансии клеили на столбах и сокращали слова, чтобы влезть в газетную строку. Она видела джоб-сайты молодыми и дружелюбными — когда те правда хотели, чтобы компания и человек нашли друг друга. И она же видела, как те же самые площадки год за годом делали всё, чтобы компания и человек не встретились: платные поднятия, платные просмотры, платная видимость. Трение стало продуктом.
Её жанр — называть вещи именами вслух. Тарологи, оценивающие резюме. Компания, которая довела кандидата до оффера, заморозила позицию, через месяц выложила ту же вакансию и снова позвала того же человека. Конференция, где спикеры хвастаются, что у них в компаниях нет джунов, — и делают вид, что не понимают, откуда через три года возьмутся мидлы. Консультант, советующий матери-одиночке на пяти работах читать по 55 книг в год.
И вот теперь — ключевой момент всей пьесы.
Двумя годами раньше Леся выпустила про Антона расследование. Она была его публичным обвинителем. А на суде она вышла его адвокатом.
Это не измена позиции. Это осмысленный ход: если судить его одного, то со скамьи подсудимых тихо встанут и выйдут через служебный вход все остальные. Компании, которые режут найм и называют это трансформацией. Эдтехи, продавшие мечту в кредит. Джоб-сайты, монетизирующие отчаяние. Нанимающие менеджеры, не способные собрать интервью так, чтобы его не прошёл человек с выученной легендой. Защищая Антона, она защищала всех, кто вообще оказался на этом рынке.
Всё так. Но давайте посмотрим на это глазами не участника, а кастинг-директора.
Кого лучше всего поставить адвокатом человека, которого вы объявили виновным в поломке найма? Правильно: того, кто громче всех его обвинял. Это сильнейший драматургический ход из возможных. Ни один сценарист не придумает лучше: обвинитель переходит на сторону защиты.
Зал получает поворот. Продажи получают повод. Конфликт получает вторую жизнь.
И совершенно неважно, что Леся при этом говорит правду. Правда прекрасно работает как реплика в пьесе — при условии, что пьесу собирал не ты.
Тут и возникает вопрос, который мало кто задал.
А кто, собственно, решил, что это будет суд?
У Нинзи нет роли в программке.
Он не подсудимый, не адвокат, не прокурор, не судья. Он не входит ни в пятьдесят нанимающих, ни в пятьдесят кандидатов. Его нет ни на сцене, ни в зале.
Он стоит сбоку. У кулисы, где обычно находится тот, кто следит, чтобы всё шло по плану.
У Нинзи есть канал. И у канала есть цифры, которые растут ровно тогда, когда Антон и Леся оказываются по разные стороны рампы. Это его законный бизнес, он в нём хорош, и он на нём зарабатывает: просмотры, реклама, билеты, продукты следом.
Если спросить его прямо — он скажет, что просто снимает. Что он наблюдатель, что конфликт возник сам, что его дело — камера.
Возможно, так и есть.
А возможно, он режиссёр.
Потому что режиссуру в таких историях видно не по человеку, а по следам. Смотрите сами.
Кто-то выбрал формат. Не панельная дискуссия, не круглый стол, не разбор цифр по рынку — а суд. С мантией, скамьёй и присяжными. Суд — это готовая машина по производству напряжения: там по определению есть виновный.
Кто-то распределил роли. Посадил на скамью самого узнаваемого антагониста отрасли. Поставил его защищать женщину, которая его разоблачала. Дал обвинение представителю рекрутерского цеха, чтобы конфликт шёл не между людьми, а между кастами.
Кто-то разделил зал пополам — ровно пятьдесят на пятьдесят, нанимающие против кандидатов, — и этим гарантировал, что в помещении не будет согласия ни по одному вопросу.
Кто-то сделал так, чтобы приговора не было. Судья модерирует, решение за залом, зал разделён надвое. Вердикт не может быть вынесен в принципе. Спор уйдёт из зала таким же незакрытым, каким в него вошёл, — и, значит, останется живым для следующего сезона.
И кто-то выбрал точку съёмки ещё до того, как включили свет.
Ни одно из этих решений не принял ни Антон, ни Леся. Они играли. Хорошо, искренне, с настоящими эмоциями и настоящими аргументами — но играли в чужой постановке.
Вот почему Нинзя стоит сбоку. Сбоку — единственное место, откуда видно и сцену, и зал одновременно. Актёр видит только зал. Зритель видит только сцену. И только человек в кулисе видит, как одно работает на другое.
Заметьте, в чём его сила: он ничего не сломал. Не учил обходить фильтры, не морозил офферы, не поднимал цену за отклик, не увольнял джунов. Он не виноват ни в одной строчке реального кризиса.
Он просто сделал из этого кризиса формат.
И у любого режиссёра есть одна профессиональная особенность, о которой стоит сказать прямо: ему не нужен ответ на вопрос. Ответ закрывает тему, а закрытая тема не собирает зал. Режиссёру нужен вопрос, который можно задавать вечно.
«Кто сломал найм?» — идеальный такой вопрос. Ответить на него окончательно невозможно. Снимать про него можно бесконечно.
Режиссёр он или нет — вопрос открытый. Но постановка была. Кто-то же её поставил.
Давайте честно, без пафоса.
«Сломан»: тысяча откликов на вакансию, нейровакансии, нейроотклики, нейроинтервью, тесты на 385 вопросов с вопросами про стул, астрология в оценке, пятиэтапные собеседования с бесплатным консалтингом внутри, замороженные офферы, вакансии-призраки для отчётности, «нам нужны только сеньоры» одновременно с «джуны нам не нужны», отсутствие обратной связи как отраслевая норма.
«Не сломан»: вакансии есть. Квалифицированные голодные люди есть. Просто закончился аттракцион 2018–2022, когда рекрутеры бегали за разработчиками по личкам, а оффер можно было получить, зевнув в камеру. Шесть лет люди разучивались искать работу — потому что работа искала их. Правила вернулись к тем, что были всегда: уметь себя показать, иметь связи, держать удар отказов, считать деньги и не отращивать личный МРОТ до размера зарплаты.
Обе версии верные. Обе неполные.
Потому что настоящий ответ звучит скучно — и именно поэтому его почти никто не произносит со сцены:
Найм не сломали. Найм монетизировали.
Сломанная система — это система, которая не работает. А эта работает превосходно. Просто её продукт — не трудоустройство. Её продукт — трение. Каждый лишний отклик, каждый лишний этап, каждая лишняя тревожная ночь кандидата кем-то оплачены и кому-то принесли выручку.
Чем больше боли — тем выше чек.
И заметьте, как красиво тот же принцип работает этажом выше. Сам спор о сломанном найме тоже монетизирован — билетами в зал, где сто человек платят за то, чтобы посмотреть, как двое спорят о причинах их общей боли. Без приговора. С обещанием продолжения.
Итак, расстановка.
Антон на скамье. Леся у рампы. Прокурор напротив. Судья, который не судит. Сто человек в зале, разделённые пополам. Нинзя сбоку, с камерой и, возможно, с планом.
Все они — внутри здания. Сцена, авансцена, кулиса, партер — это всё один театр. А театр кому-то принадлежит.
В театре есть место, которое зритель не видит никогда. Колосники — решётчатый настил высоко над сценой, откуда управляют декорациями. Оттуда опускают задник, оттуда дают свет, оттуда одним движением меняют эпоху с рассвета на закат. Актёры внизу. Режиссёр сбоку. Зал ещё ниже.
А тот, кто дёргает верёвки, — сверху, в темноте, и на поклон не выходит принципиально.
Что мы про него знаем?
Он заинтересован, чтобы конфликт не заканчивался. Пока обвинение спорит с защитой, никто не смотрит наверх.
Он заинтересован, чтобы вы искали работу долго. Быстрый найм — одна транзакция. Долгий найм — подписка.
Он заинтересован, чтобы вы боялись. Испуганный кандидат покупает курс. Испуганный сотрудник не торгуется о зарплате. Испуганный руководитель покупает инструмент, который «заменит джунов», а через год — консалтинг о том, почему у него не осталось людей, способных вырасти в мидлов.
Он заинтересован, чтобы виноватым считался кто-то один. Желательно с лицом, каналом и скверной репутацией. Идеальный злодей гарантирует, что вопросы никогда не дойдут до бизнес-модели.
И вот вопрос, ради которого всё это писалось.
Кто он?
Тот, кто продал билеты обеим сторонам конфликта и посадил их в один зал?
Джоб-сайт, который берёт деньги с обеих сторон за то, чтобы они друг друга нашли, — и зарабатывает ровно на том, что они не находятся?
Эдтех, продавший в кредит мечту сотням тысяч человек и отгрузивший их на рынок, где их никто не ждал?
Вендор, объясняющий совету директоров, что агенты закроют джунов, — и отдельно продающий обучение тем, кто останется?
Топ-менеджер, который называет сокращение оптимизацией, получает бонус за сэкономленный ФОТ и уходит в другую компанию за полгода до того, как станут видны последствия?
Или — вариант, который никому не нравится — зритель? Тот, кто выбирает драку вместо разбора цифр. Кто досмотрит суд до конца, но не дочитает пост про то, как считать финансовый запас. Кто хочет злодея, потому что злодей понятен, а «структурный сдвиг на рынке труда» непонятен и не приносит облегчения.
Ведь если бы зал перестал покупать билет, постановки бы не было. Режиссёр снял бы что-нибудь другое.
Однозначного имени у меня для вас нет. Возможно, его и не существует — возможно, кукловод не человек, а само устройство рынка, где посреднику выгоднее держать двери закрытыми, чем открыть их.
Но проверить легко. Есть один надёжный способ найти его в темноте:
Посмотрите, кто в этой истории заработал больше всех — и при этом не сказал со сцены ни слова.
Антон сыграл подсудимого. Леся сыграла адвоката. Нинзя стоял сбоку и снимал.
А приговор так и не вынесли. И, кажется, никогда не вынесут — потому что приговор закрывает дело, а закрытое дело больше не продаётся.
Свет в зале. Занавес не опускается — следующая серия уже анонсирована. Где она появится никто не знает...
По итогам комментариев решим как быть дальше. Есть возможность получить подарки от участников истории - 50 лучших комментов что-то получат. Кстати предлагайте что. Мы открыты к диалогу и ещё ничего не решили. Спасибо что дочитали до конца.
