[Agile, DevOps, Управление проектами, Читальный зал] DevOps или как мы теряем заработную плату и будущее IT-отрасли, часть вторая
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Прошлая статья уже вызвала много возмущений, думаю эта статья многим ещё больше не понравится, в ней я распишу то, как заказчики видят DevOps инженера.
Чем больше идёт времени, тем больше я слушаю о том, что «это обязанность «девупса», запросы в БД хотят чтобы тюнинговал девупс, догадывался, как и с какими зависимостями собирается у кодера софт – девупс, evpn+bgp+ipsec+geo dns+сетевая авторизация по сертификатам – девупс, исправлять ошибки архитектуры и придумывать бескровные варианты – девупс, превращать обычный pg_dump в синхронную репликацию – девупс, быть психоаналитиком для СТО/CEO и команды – девупс.
Ещё интересная тенденция – это k8s+load balancer на любой чих. Не так давно мне даже предложили поставить load balancer на бд, авось load average понизится и диски меньше нагружены будут…. K8s это вообще отдельная тема, про мифы связанные с ним можно написать 2-3 статьи.
Всё чаще от бизнеса можно услышать – что разработчики и инженеры зажрались, что сбербанк устроил мыльный пузырь, и вот-вот должно случиться чудо, и мы начнём работать как обычный люд за 60-80к у сеньора. В регионах уже, конечно, такое есть, да там всё и было печально, но тут мечтают уже и за все города кроме Москвы.
Ещё веселее от этого же бизнеса слушать, какие все лентяи, рассказы про то, как бесполезны работники, и что нужно искать способы не планировать работу, архитектуру, думать о будущем, а шлёпать некачественный код со скоростью света, ведь потом девупс его «горизонтально масштабирует», да у нас 1 запрос в БД стоит 15% от мощности железа, а 5 запросов — коллапс, ну и что с того? Горизонтальное масштабирование без выделения ресурсов нас спасёт!!! – правда не уточняется каким образом. Особенно, если БД довольно кривая по архитектуре, например дефолтный PostgreSQL либо Elasticsearch.
Использовать технологии по назначению? Нет, это скучно. Планировать архитектуру, схемы данных и их обработку – зачем это дорого и медленно. Но что делать? Решение есть — найми девупса и обвини его во всех смертных грехах твоего проекта, не забывая добавлять – ровно до твоего прихода всё работало. А логи врут, всё работало!!!
Я всё чаще вижу, как достаточно интересные и перспективные проекты умирают, ещё даже на этапе зарождения, просто из-за политических игр. Я общаюсь с РМ, которому уже полгода мешают реализовывать продукт, который может приносить компании миллиарды рублей в год, но ему ставят палки в колёса постоянно. Все ищут способы как сделать разработку без расходов на неё, а DevOps методология всё чаще воспринимается как способ вывалить нерабочий продукт в прод, а косяки замазать контейнерами, балансирами и заглушками, даже если это приводит к низким рейтингам и большому числу негатива, главное — экономия на разработке.
Как показал опрос в предыдущей статье, у большинства посетителей habr работодатели пытаются заткнуть несколько дыр 1 человеком. Естественно, не компенсируя данные обязанности. Но, проблема в том, что страдает в итоге и сам бизнес. За счёт низкой оплаты труда и высокой производительности труда относительно к финансовому и техническому обеспечению, бизнес выживает, если бы с таким управлением, как в СНГ, пытались делать бизнес в Японии или США, он бы давно обанкротился.
Многие методологии пришедшие к нам с развитых стран были исковерканы напрочь. Например Agile, Scrum, DevOps – все 3 методологии требуют для работы существенного изменения бизнес-процессов, но менеджмент в СНГ не готов к этому, он надеется совместить старые привычки и современные методологии, мы вверху по-старому, а вы по-современному и эффективному внизу. Все 3 методологии бессмысленно внедрять снизу, наличие карточек, ежедневных отчётностей, планов на 2 недели и релизов на каждую строчку кода – не означает что вы внедрили эти методологии, это означает, что вы ввели дополнительные процессы по отчётности, которые просто помогают найти виновных и оправдание для вышестоящего менеджмента. Проекту и людям, которые начинают работать в таких условиях, только сложнее реализовывать задуманное, потому что кол-во отчётности растёт существенно больше, чем если бы их не было.
Сейчас довольно много статей и выступлений странных менеджеров от IT которые уже предлагают платить за результаты, почти как раньше за строчки кода, убирая из работы время на обдумывания реализации, считая, что оно минут 30-40 а дальше чисто написание кода. При этом на управленческие решения дайте нам 2-3 недели подумать и рассчитать стоимости и риски…. В результате мы всё чаще сталкиваемся с тем, что качество продуктов неизбежно падает, конечно это проблема не только IT отрасли, но в нашей отрасли она стоит особенно остро, потому что неудачи потом списывают на программистов, которые типа «разбазарили 180 млн рублей», я видел уже 4 проекта, которые в результате такого процесса не выполняют свои задачи, но израсходовали по 1 млрд рублей и более, но виновны в итоге стали ленивые айтишники и начинается её большее кол-во отчётности и регулирующих процедур, для исправления ситуации. Для обеспечения надзорных функций нанимаются дополнительные менеджеры, а ФОТ для IT специалистов сокращается. Кол-во решений, которые мы принимаем сами уменьшается, а ответственность и отчётность растёт, что приводит к ещё большим проблемам.
Вам необходимо чётко проводить линии обязанностей, и их минимизировать, в противном случае – вы просто становитесь жертвой в любой политической игре.
Следующую статью я напишу подробнее о том, почему DevOps и Agile внедрённые снизу никогда не принесут пользы.
===========
Источник:
habr.com
===========
Похожие новости:
- [DevOps, Облачные сервисы] Принимаем 10 000 ивентов в Яндекс.Облаке. Часть 2
- [Habr, Контент-маркетинг, Конференции, Читальный зал] Вот и поговорили: в кулуарах «ТехноТекста» уютно и пахнет хардкором
- [Профессиональная литература, Управление продуктом, Читальный зал] Digital Practitioner Body of Knowledge — обзор инструкции по цифровой трансформации для практиков
- [Интервью, Проектирование и рефакторинг, Системное программирование, Управление проектами] И снова о Legacy. Вечная боль техдира
- [JavaScript, Тестирование веб-сервисов] Регрессионная спираль смерти (перевод)
- [Управление проектами, Учебный процесс в IT, Карьера в IT-индустрии] Как сдать PMP, не выходя из дома. Личный опыт
- [Java, Разработка под Linux, Управление проектами] Как я автоматизировал разворачивание приложений на Linux на коленке с помощью Bash скриптов и Java
- [DevOps, Go, Open source, Системное администрирование, Тестирование веб-сервисов] Squzy — бесплатная open-source self-host система мониторинга с инцидентами и уведомлениями
- [] Год в Scrum: наблюдения скрам-мастера
- [Карьера в IT-индустрии, Профессиональная литература, Читальный зал] Путь в ИТ. Книга о том, как жить в ИТ профессионально и счастливо
Теги для поиска: #_agile, #_devops, #_upravlenie_proektami (Управление проектами), #_chitalnyj_zal (Читальный зал), #_upravlenie_proektami (управление проектами), #_devops, #_objazannosti (обязанности), #_prava_i_svobody (права и свободы), #_agile, #_devops, #_upravlenie_proektami (
Управление проектами
), #_chitalnyj_zal (
Читальный зал
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 22:16
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Прошлая статья уже вызвала много возмущений, думаю эта статья многим ещё больше не понравится, в ней я распишу то, как заказчики видят DevOps инженера. Чем больше идёт времени, тем больше я слушаю о том, что «это обязанность «девупса», запросы в БД хотят чтобы тюнинговал девупс, догадывался, как и с какими зависимостями собирается у кодера софт – девупс, evpn+bgp+ipsec+geo dns+сетевая авторизация по сертификатам – девупс, исправлять ошибки архитектуры и придумывать бескровные варианты – девупс, превращать обычный pg_dump в синхронную репликацию – девупс, быть психоаналитиком для СТО/CEO и команды – девупс. Ещё интересная тенденция – это k8s+load balancer на любой чих. Не так давно мне даже предложили поставить load balancer на бд, авось load average понизится и диски меньше нагружены будут…. K8s это вообще отдельная тема, про мифы связанные с ним можно написать 2-3 статьи. Всё чаще от бизнеса можно услышать – что разработчики и инженеры зажрались, что сбербанк устроил мыльный пузырь, и вот-вот должно случиться чудо, и мы начнём работать как обычный люд за 60-80к у сеньора. В регионах уже, конечно, такое есть, да там всё и было печально, но тут мечтают уже и за все города кроме Москвы. Ещё веселее от этого же бизнеса слушать, какие все лентяи, рассказы про то, как бесполезны работники, и что нужно искать способы не планировать работу, архитектуру, думать о будущем, а шлёпать некачественный код со скоростью света, ведь потом девупс его «горизонтально масштабирует», да у нас 1 запрос в БД стоит 15% от мощности железа, а 5 запросов — коллапс, ну и что с того? Горизонтальное масштабирование без выделения ресурсов нас спасёт!!! – правда не уточняется каким образом. Особенно, если БД довольно кривая по архитектуре, например дефолтный PostgreSQL либо Elasticsearch. Использовать технологии по назначению? Нет, это скучно. Планировать архитектуру, схемы данных и их обработку – зачем это дорого и медленно. Но что делать? Решение есть — найми девупса и обвини его во всех смертных грехах твоего проекта, не забывая добавлять – ровно до твоего прихода всё работало. А логи врут, всё работало!!! Я всё чаще вижу, как достаточно интересные и перспективные проекты умирают, ещё даже на этапе зарождения, просто из-за политических игр. Я общаюсь с РМ, которому уже полгода мешают реализовывать продукт, который может приносить компании миллиарды рублей в год, но ему ставят палки в колёса постоянно. Все ищут способы как сделать разработку без расходов на неё, а DevOps методология всё чаще воспринимается как способ вывалить нерабочий продукт в прод, а косяки замазать контейнерами, балансирами и заглушками, даже если это приводит к низким рейтингам и большому числу негатива, главное — экономия на разработке. Как показал опрос в предыдущей статье, у большинства посетителей habr работодатели пытаются заткнуть несколько дыр 1 человеком. Естественно, не компенсируя данные обязанности. Но, проблема в том, что страдает в итоге и сам бизнес. За счёт низкой оплаты труда и высокой производительности труда относительно к финансовому и техническому обеспечению, бизнес выживает, если бы с таким управлением, как в СНГ, пытались делать бизнес в Японии или США, он бы давно обанкротился. Многие методологии пришедшие к нам с развитых стран были исковерканы напрочь. Например Agile, Scrum, DevOps – все 3 методологии требуют для работы существенного изменения бизнес-процессов, но менеджмент в СНГ не готов к этому, он надеется совместить старые привычки и современные методологии, мы вверху по-старому, а вы по-современному и эффективному внизу. Все 3 методологии бессмысленно внедрять снизу, наличие карточек, ежедневных отчётностей, планов на 2 недели и релизов на каждую строчку кода – не означает что вы внедрили эти методологии, это означает, что вы ввели дополнительные процессы по отчётности, которые просто помогают найти виновных и оправдание для вышестоящего менеджмента. Проекту и людям, которые начинают работать в таких условиях, только сложнее реализовывать задуманное, потому что кол-во отчётности растёт существенно больше, чем если бы их не было. Сейчас довольно много статей и выступлений странных менеджеров от IT которые уже предлагают платить за результаты, почти как раньше за строчки кода, убирая из работы время на обдумывания реализации, считая, что оно минут 30-40 а дальше чисто написание кода. При этом на управленческие решения дайте нам 2-3 недели подумать и рассчитать стоимости и риски…. В результате мы всё чаще сталкиваемся с тем, что качество продуктов неизбежно падает, конечно это проблема не только IT отрасли, но в нашей отрасли она стоит особенно остро, потому что неудачи потом списывают на программистов, которые типа «разбазарили 180 млн рублей», я видел уже 4 проекта, которые в результате такого процесса не выполняют свои задачи, но израсходовали по 1 млрд рублей и более, но виновны в итоге стали ленивые айтишники и начинается её большее кол-во отчётности и регулирующих процедур, для исправления ситуации. Для обеспечения надзорных функций нанимаются дополнительные менеджеры, а ФОТ для IT специалистов сокращается. Кол-во решений, которые мы принимаем сами уменьшается, а ответственность и отчётность растёт, что приводит к ещё большим проблемам. Вам необходимо чётко проводить линии обязанностей, и их минимизировать, в противном случае – вы просто становитесь жертвой в любой политической игре. Следующую статью я напишу подробнее о том, почему DevOps и Agile внедрённые снизу никогда не принесут пользы. =========== Источник: habr.com =========== Похожие новости:
Управление проектами ), #_chitalnyj_zal ( Читальный зал ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 22:16
Часовой пояс: UTC + 5