[Agile, DevOps, Управление персоналом, Читальный зал] DevOps или как мы теряем заработную плату и будущее IT-отрасли
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Самое печальное в сегодняшней ситуации то, что 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 я выступал с докладом «когда мы научимся говорить «нет»» — его результаты были очень показательными. Огромное число людей считает, что это слово табу, и пока мы не перестанем так считать, проблемы будут только расти.
Частично на данную статью меня подвигладанная статья, но я позже возможно распишу её менее обходительными терминами.
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-компании, Удалённая работа, Управление персоналом, Управление продажами, Фриланс] Увольнять или оставить: есть ли альтернатива бенчу, если грянул кризис
- [Конференции, Управление персоналом, Управление проектами, Управление разработкой] Почему онлайн-конференция по управлению знаниями — это не скучно
- [Управление персоналом] Хабр Карьера запускает Арсенал — инструмент для рекрутинга
- [DevOps, Kubernetes, Серверное администрирование, Системное администрирование] Логирование в Kubernetes: EFK против PLG (перевод)
- [Настройка Linux, Системное администрирование, Облачные вычисления, Серверное администрирование, DevOps] Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон, часть 2
- [DevOps, Настройка Linux] Используем nftables в Red Hat Enterprise Linux 8 (перевод)
- [Удалённая работа, Управление персоналом] 10 историй про IT-трансформацию в режиме самоизоляции
- [Веб-дизайн, Графический дизайн, Работа с векторной графикой, Управление персоналом] Как найти иллюстратора, если вы ничего не понимаете в иллюстрации
- [DevOps, Kubernetes, Системное администрирование] Валидация Kubernetes YAML на соответствие лучшим практикам и политикам (перевод)
- [DevOps, Open source, Карьера в IT-индустрии, Учебный процесс в IT] Какой совет оказал наибольшее влияние на вашу карьеру в DevOps (перевод)
Теги для поиска: #_agile, #_devops, #_upravlenie_personalom (Управление персоналом), #_chitalnyj_zal (Читальный зал), #_upravlenie_ljudmi (управление людьми), #_upravlenie_razrabotkoj (управление разработкой), #_upravlenie_proektami (управление проектами), #_upravlenie_vremenem (управление временем), #_trudogolizm (трудоголизм), #_trudovye_prava (трудовые права), #_agile, #_devops, #_upravlenie_personalom (
Управление персоналом
), #_chitalnyj_zal (
Читальный зал
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 03:16
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Самое печальное в сегодняшней ситуации то, что 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 я выступал с докладом «когда мы научимся говорить «нет»» — его результаты были очень показательными. Огромное число людей считает, что это слово табу, и пока мы не перестанем так считать, проблемы будут только расти. Частично на данную статью меня подвигладанная статья, но я позже возможно распишу её менее обходительными терминами. =========== Источник: habr.com =========== Похожие новости:
Управление персоналом ), #_chitalnyj_zal ( Читальный зал ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 03:16
Часовой пояс: UTC + 5