[Управление разработкой, DevOps] Процесс — это не продукт: антиманифест методологии разработки ПО (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
TLDR:
Антиманифест методологии разработки ПО
— Процесс — это не продукт
— Руководство, а не менеджмент
— Диалог, а не диктат
Вот и всё, остальное вы можете додумать сами, но если хотите, продолжайте чтение.
Процесс — это не продукт
За свою (очень) долгую карьеру в технологической сфере я ощутил на себе большинство методологий разработки ПО, и этот опыт показал мне, что они больше похожи на обязанность, а не на помощь. Скажу больше: мне кажется, что избыток методологии гораздо опаснее её недостатка. Однако культ Одной Истинной Методологии продолжает процветать, и стоит поразмыслить над тем, почему так происходит.
«Если встретишь Будду на дороге — убей его!»
Думаю, что одна из причин заключается в том, что многие/большинство/все из нас втайне подозревают, что мы делаем всё не так, и есть кто-то, делающий всё правильно; если мы последуем его совету, то тоже будем делать правильно, и все ошибочные оценки, баги, плохой код и т.д, и т.п, исчезнут.
Не нужно так думать, они никуда не денутся.
Ещё одна причина — это экономика методологии разработки ПО. Она похожа на чудесную рекламу об инвестициях. Люди, продающие обучающие курсы, книги и другие атрибуты, действительно хорошо зарабатывают. Но они зарабатывают на курсах, книгах и так далее. Если бы они были хороши в своевременной разработке ПО без багов, то зарабатывали бы намного больше. Но они, как и консультанты по инвестициям, зарабатывают на нашей технологической неуверенности.
Если можешь делать, то делай. Если не можешь, то управляй.
Однако ещё одна причина — это бесконечное разрастание менеджмента среднего звена, поражающее и крупные, и мелкие компании. Если компания растёт, то нам кажется, что ей нужно больше менеджмента. И ещё. И ещё. Почему? Каков карьерный путь менеджера? Он нанимает менеджмент более низкого звена. Хуже того — компании поддаются этому, они склонны укреплять свою иммунную систему. Любые попытки изменения статуса-кво менеджмента будут угрозой самим основам культуры менеджмента. Не говоря уже обо всех этих должностях в менеджменте. Нужны инновации? Отлично. Давайте наймём руководителя отдела инноваций. И, разумеется, менеджменту обязательно нужно чем-то заниматься, и это процесс, отслеживание спринтов, доски trello, что угодно, чтобы заполнить восемь рабочих часов.
Руководство, а не менеджмент
И это приводит нас к следующему пункту манифеста: к лидерству. Знаете, такому настоящему руководству. Ты приходишь и показываешь путь вперёд. Лично каждому, чётко, по одному программисту за раз, и не только то, что они должны знать, но и спринты с use cases. Нужно иметь достаточно технических возможностей, чтобы обучать, готовить и мотивировать. И учиться самому. Сообщать всем, вплоть до уборщиков, куда и зачем мы движемся. Не один раз, а постоянно. Организации, которые будут это делать, окажутся самоуправляемыми. Почему? Потому что люди (даже программисты) умны. Если даёшь им информацию и полномочия, они думают, правильно расставляют приоритеты, не ругаются из-за смены целей и не особо нуждаются в менеджменте. Если сделать всё правильно, то окажется, что вы следуете за коллективом, а не ведёте вперёд, потому что культура команды становится больше, чем любой из её участников.
Диалог, а не диктат
Наконец, мы добрались до последнего пункта, который следует из предыдущего. Коммуникации никогда не должны быть односторонними. Информация должна распространяться и вниз, и вверх. Единственный смертный грех — не неудача, а нежелание коммуникации. Если обращаться с людьми правильно, они умны, и с большой вероятностью у них есть более качественные идеи, чем у руководства. Каждый должен быть выслушан с уважением.
Если всё это заставило вас ощутить неудобство, то это хорошо. Для того и написана эта статья.
P.S.: Никакой Jira.
На правах рекламы
Многие клиенты уже оценили преимущества серверов от Вдсины.
Мы предлагаем выделенные и виртуальные серверы. Максимальная конфигурация позволит реализовать практически любую идею — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Закажите и вы!
Подписывайтесь на наш чат в Telegram.
оригинал
===========
Источник:
habr.com
===========
===========
Автор оригинала: Michael Karliner
===========Похожие новости:
- [Научно-популярное, Финансы в IT, Транспорт] Как ажиотажный спрос на туалетную бумагу привел к дефициту электроники
- [Управление разработкой, Управление проектами, Управление продуктом] Разработчики не могут исправить ошибки управленцев (перевод)
- [Управление разработкой, Управление персоналом, Конференции] Книги, которые повлияли на меня как на разработчика и управленца
- [Python, Программирование] 22 полезных примера кода на Python (перевод)
- [Разработка веб-сайтов, Работа с видео, DevOps, Видеоконференцсвязь] Google Cloud Platform for WebRTC CDN with Balancing and Autoscaling
- [Разработка веб-сайтов, Работа с видео, DevOps, Видеоконференцсвязь] WebRTC CDN на Google Cloud Platform с балансировкой и автоматическим масштабированием
- [Системное администрирование, Серверное администрирование, DevOps, Kubernetes] Контролируем удаление с финализаторами (перевод)
- [Программирование, DevOps, Kubernetes] Kubernetes Headless Service: А если Pod исчез?
- [Системное администрирование, IT-инфраструктура, DevOps] Как работает single sign-on (технология единого входа)? (перевод)
- [Разработка веб-сайтов, CSS, HTML] DIV должен уйти: улучшаем HTML (перевод)
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_devops, #_antimanifest (антиманифест), #_metodologii_razrabotki (методологии разработки), #_blog_kompanii_vdsina.ru (
Блог компании VDSina.ru
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 11:08
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
TLDR: Антиманифест методологии разработки ПО — Процесс — это не продукт — Руководство, а не менеджмент — Диалог, а не диктат Вот и всё, остальное вы можете додумать сами, но если хотите, продолжайте чтение. Процесс — это не продукт За свою (очень) долгую карьеру в технологической сфере я ощутил на себе большинство методологий разработки ПО, и этот опыт показал мне, что они больше похожи на обязанность, а не на помощь. Скажу больше: мне кажется, что избыток методологии гораздо опаснее её недостатка. Однако культ Одной Истинной Методологии продолжает процветать, и стоит поразмыслить над тем, почему так происходит. «Если встретишь Будду на дороге — убей его!» Думаю, что одна из причин заключается в том, что многие/большинство/все из нас втайне подозревают, что мы делаем всё не так, и есть кто-то, делающий всё правильно; если мы последуем его совету, то тоже будем делать правильно, и все ошибочные оценки, баги, плохой код и т.д, и т.п, исчезнут. Не нужно так думать, они никуда не денутся. Ещё одна причина — это экономика методологии разработки ПО. Она похожа на чудесную рекламу об инвестициях. Люди, продающие обучающие курсы, книги и другие атрибуты, действительно хорошо зарабатывают. Но они зарабатывают на курсах, книгах и так далее. Если бы они были хороши в своевременной разработке ПО без багов, то зарабатывали бы намного больше. Но они, как и консультанты по инвестициям, зарабатывают на нашей технологической неуверенности. Если можешь делать, то делай. Если не можешь, то управляй. Однако ещё одна причина — это бесконечное разрастание менеджмента среднего звена, поражающее и крупные, и мелкие компании. Если компания растёт, то нам кажется, что ей нужно больше менеджмента. И ещё. И ещё. Почему? Каков карьерный путь менеджера? Он нанимает менеджмент более низкого звена. Хуже того — компании поддаются этому, они склонны укреплять свою иммунную систему. Любые попытки изменения статуса-кво менеджмента будут угрозой самим основам культуры менеджмента. Не говоря уже обо всех этих должностях в менеджменте. Нужны инновации? Отлично. Давайте наймём руководителя отдела инноваций. И, разумеется, менеджменту обязательно нужно чем-то заниматься, и это процесс, отслеживание спринтов, доски trello, что угодно, чтобы заполнить восемь рабочих часов. Руководство, а не менеджмент И это приводит нас к следующему пункту манифеста: к лидерству. Знаете, такому настоящему руководству. Ты приходишь и показываешь путь вперёд. Лично каждому, чётко, по одному программисту за раз, и не только то, что они должны знать, но и спринты с use cases. Нужно иметь достаточно технических возможностей, чтобы обучать, готовить и мотивировать. И учиться самому. Сообщать всем, вплоть до уборщиков, куда и зачем мы движемся. Не один раз, а постоянно. Организации, которые будут это делать, окажутся самоуправляемыми. Почему? Потому что люди (даже программисты) умны. Если даёшь им информацию и полномочия, они думают, правильно расставляют приоритеты, не ругаются из-за смены целей и не особо нуждаются в менеджменте. Если сделать всё правильно, то окажется, что вы следуете за коллективом, а не ведёте вперёд, потому что культура команды становится больше, чем любой из её участников. Диалог, а не диктат Наконец, мы добрались до последнего пункта, который следует из предыдущего. Коммуникации никогда не должны быть односторонними. Информация должна распространяться и вниз, и вверх. Единственный смертный грех — не неудача, а нежелание коммуникации. Если обращаться с людьми правильно, они умны, и с большой вероятностью у них есть более качественные идеи, чем у руководства. Каждый должен быть выслушан с уважением. Если всё это заставило вас ощутить неудобство, то это хорошо. Для того и написана эта статья. P.S.: Никакой Jira. На правах рекламы Многие клиенты уже оценили преимущества серверов от Вдсины. Мы предлагаем выделенные и виртуальные серверы. Максимальная конфигурация позволит реализовать практически любую идею — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Закажите и вы! Подписывайтесь на наш чат в Telegram. оригинал =========== Источник: habr.com =========== =========== Автор оригинала: Michael Karliner ===========Похожие новости:
Блог компании VDSina.ru ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 11:08
Часовой пояс: UTC + 5