Самое печальное в сегодняшней ситуации то, что 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 я выступал с докладом когда мы научимся говорить
нет его результаты были очень показательными. Огромное число людей
считает, что это слово табу, и пока мы не перестанем так считать,
проблемы будут только расти.
Частично на данную статью меня подвигла данная статья, но я
позже возможно распишу её менее обходительными терминами.
|
Русский
|
|
|
Русский
|
|
English
|
