Самое печальное в сегодняшней ситуации то, что IT постепенно становится отраслью, где вообще нет слова “стоп” в количестве обязанностей на 1 человека.
Читая вакансии иногда уже даже видишь не 2-3 человека, а целую компанию в 1 лице, все спешат, тех.долг растёт, старое legacy на фоне новых продуктов выглядит совершенством, потому что в нём хотя бы есть дока и комменты в коде, новые продукты пишутся со скоростью света, но в итоге пользоваться ими нельзя ещё год после их написания, и зачастую этот год прибыли не приносит, более того, расходы на “облако” выше, чем продажи сервиса. Деньги инвесторов уходят на содержание ещё не работающего сервиса, но который уже выпустили в сеть как рабочий.
Как пример: известная компания, чей ремастер старой игры получил самые низкие оценки за всю историю индустрии. Я был одним из тех, кто купил данный продукт, но даже сейчас этот продукт работает ужасно, и по идее ещё не должен был в таком виде выходить в продажи. Возвраты денег, падение рейтинга, огромное количество банов пользователей на форумах за жалобы на работу сервисов. Количество патчей не восхищает, а ужасает, но всё равно – продукт не юзабелен. Если этот подход приводит к таким результатам у компании, которая занимается разработкой с 91 года, то у компаний, которые только начинают свою деятельность, ситуация ещё хуже.
Но это мы посмотрели на результаты такого подхода со стороны пользователя сервиса, а теперь посмотрим на проблемы, которые возникли у сотрудников.
Я часто слышу утверждение, что DevOps команд не должно быть, что это методология и т.д., но вот беда, компании почему-то перестали искать ноков, dba, инфруктурщиков и build инженеров – сейчас это всё DevOps инженер в единственном лице. Конечно, в отдельно взятых компаниях такие вакансии ещё есть, но их всё меньше. Многие это назвали развитием, я лично в этом вижу деградацию, невозможно поддерживать по всем направлениям хороший уровень знаний, и при этом успевать работать не более 8 часов. Естественно – это фантазии. В реальности, многие ITшники вынуждены работать и по 12, и по 14 часов, из которых оплачивается 8. А зачастую и без выходных, потому что «мне поставили задачу, доков нет или кривые, да ещё и денег стоит сервис», а за 1 ошибку в облаке можно в принципе не получить зп за пару месяцев, особенно, если работаешь по ИП. Мы по факту теряем слово в бизнесе, вместе с разделением обязанностей, я всё чаще сталкиваюсь с тем, что менеджеры лезут в процессы разработки, вообще в них ничего не понимая, они путают бизнес-данные и работу приложения, в результате начинается хаос.
Когда начинается хаос, бизнес хочет найти виновного, и тут нужно универсального виновного, повесить вину на 10+ человек сложно, поэтому менеджеры объединяют позиции, ведь чем больше обязанностей у 1 специалиста, тем проще доказать его халатность. А в условиях Agile нахождение «виновного» и порка — это основа данный методологии ведения бизнеса в менеджменте. Agile давно вышел из IT, и основной его концепции стало – требование ежедневных результатов. Проблема в том, что у узкоспециализированного специалиста не всегда будет ежедневный результат, а значит отчитаться будет сложнее, и это ещё одна причина, почему бизнес хочет «специалистов по всему». Но основная причина конечно же, это ФОТ – он основная причина всех изменений, ради надбавки люди соглашались работать за себя и того парня. Но в итоге, как и в других сферах, это просто стало теперь обязанностью, за меньшую оплату большего кол-ва предоставленных услуг.
Сейчас можно часто увидеть даже статьи о том, что уже и разработчики должны уметь деплоить, должны заниматься инфраструктурой рядом с DevOps инженером, но к чему это приводит? Правильно – к падению качества сервисов, к падению качества разработчиков. Вот буквально 2 дня назад я объяснял разработчику, что писать и читать можно из разных хостов, а мне с пеной у рта доказывали, что никогда такого не видели, вот есть в settings orm host, port, db, user, password и всё…. Зато разработчик умеет запускать деплои, писать ямлы…. Но уже забывает про юнит тесты и комменты в коде.
По итогу мы видим следующее – постоянные переработки, поиски решений проблем вне рабочего времени, постоянное обучение в выходные, и не для роста доходов, а для поддержки себя на плаву. Разработчики вынуждены помогать DevOps инженеру с CI/CD, а если у разработчика нет времени, тот начинает зашиваться, и менеджеры начинают компостировать мозги, а, если это не помогает увеличить желание работать сверхурочно, то применять взыскания и штрафы, человек ищет новое место работы, оставляя после себя тех.долг размером с Эверест, в результате долг начинает расти и у разработчиков, т.к. они вынуждены писать код с меньшим его рефакторингом, чтобы успеть помочь либо старому или новому DevOps инженеру, а менеджеров всё вполне устраивает, ведь виновный есть и его видно сразу, а значит основное правило при Agile в менеджменте соблюдено, виновный найден, результаты по его порке видны.
Когда-то на ITGM я выступал с докладом «когда мы научимся говорить «нет»» — его результаты были очень показательными. Огромное число людей считает, что это слово табу, и пока мы не перестанем так считать, проблемы будут только расти.
Частично на данную статью меня подвигла
Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát.
Сталкивались ли вы в работе, когда работодатель пытался заменить вами несколько человек?
-
65,6%Да, сталкиваюсь регулярно183
-
5,4%Да, сталкивался 1 раз15
-
15,4%Не замечал43
-
13,6%Я трудоголик, сам работаю сверхурочно38
279 người dùng bình chọn. 34 người dùng bỏ phiếu trắng.
Nguồn: www.habr.com