День 1575. #DevOps #ProjectManagement
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Окончание
Начало
Шаг 3. Исправление: начнём работать над проблемой
Мы знаем, что у нас есть проблема, мы знаем источник проблемы, теперь давайте составим план и исправим её. Мы все любим переходить к этому шагу, сразу приступать к исправлению. И иногда у нас есть такая роскошь для простых вопросов, когда проблема настолько очевидна, что подтверждение и понимание источника проблемы — быстрые шаги. Но если проблема зашла далеко или она серьезная, нужно поступать более обдуманно.
Тут координатор поможет расставить приоритеты в работе, выяснить, где находятся самые важные шаги по смягчению последствий, и убедиться, что у всех заинтересованных сторон есть чёткие ожидания относительно того, что надо делать и какой будет результат. Разработчик, работающий над проблемой, обязан привлечь этого человека, убедиться, что он предоставит ему ресурсы, необходимые для решения проблемы. Это может быть время, доступ или другие люди, у которых есть специфические знания. Это важная тема на данном этапе: дать инженерам то, что им нужно, чтобы исправить ситуацию. Возможно, это должно волновать всех инженеров-руководителей не только тогда, когда что-то пошло не так, и жизненно важные рабочие процессы встали.
Больше всего во время кризиса не хватает не информации или помощи других разработчиков, а возможности сфокусироваться. Это может показаться странным, но это чувство знакомо любому, кто был в одной лодке с лидерами, которые паникуют или никогда не понимали заблуждений мифического человеко-месяца. Они с нетерпением ждут новостей о ходе работы, и что может быть лучше, чем собирать всех на митинги четыре раза в день, чтобы узнать, как продвигаются дела. А это постоянные отвлечения, переключения контекста и обновления багтрекеров. Способность сосредоточиться и избавиться от отвлекающих факторов - самый важный фактор для решения проблемы.
Шаг 4. Проверка и обучение
Если все пойдёт хорошо, тесты подтвердятся, и вся ценная информация, полученная на шагах 1 и 2, даст вам уверенность в новых планах тестирования, вы можете развернуть исправление. Как только оно будет опубликовано, дайте время команде на всех уровнях, чтобы изучить его и подтвердить, что всё работает как надо. Если инженерам в начале этих инцидентов даются время и свобода, то они более уверенно и спокойно относятся к последующим релизам и исправлениям.
Однако, публикация исправления и уверенность команды в его правильности – лишь половина дела. Теперь нужно сделать так, чтобы болезненный и возможно дорогостоящий опыт этой проблемы способствовал развитию команды. Люди часто воспринимают крупные кризисы, как проблему, которая никогда больше не повторится, что совершенно неразумно. Часто лучшее обучение — это учиться справляться с проблемами, а не притворяться, будто мы можем их избежать.
В конце концов, чаще всего всё сводится к элементарной человеческой ошибке. Поэтому техническому руководителю нужно быть больше сосредоточенным не на предотвращении ошибок, а на оттачивании способности команды справляться с ними. Да, важна работа по предотвращению будущих подобных ошибок. Но часто есть больше возможностей для улучшения того, как команда реагирует на ошибку. Как дать инженерам больше возможностей для концентрации? Как можно ускорить расследование инцидента? Или даже кто лучше всего справляется с коммуникацией между разными специалистами или командами и какая информация им нужна?
Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Окончание
Начало
Шаг 3. Исправление: начнём работать над проблемой
Мы знаем, что у нас есть проблема, мы знаем источник проблемы, теперь давайте составим план и исправим её. Мы все любим переходить к этому шагу, сразу приступать к исправлению. И иногда у нас есть такая роскошь для простых вопросов, когда проблема настолько очевидна, что подтверждение и понимание источника проблемы — быстрые шаги. Но если проблема зашла далеко или она серьезная, нужно поступать более обдуманно.
Тут координатор поможет расставить приоритеты в работе, выяснить, где находятся самые важные шаги по смягчению последствий, и убедиться, что у всех заинтересованных сторон есть чёткие ожидания относительно того, что надо делать и какой будет результат. Разработчик, работающий над проблемой, обязан привлечь этого человека, убедиться, что он предоставит ему ресурсы, необходимые для решения проблемы. Это может быть время, доступ или другие люди, у которых есть специфические знания. Это важная тема на данном этапе: дать инженерам то, что им нужно, чтобы исправить ситуацию. Возможно, это должно волновать всех инженеров-руководителей не только тогда, когда что-то пошло не так, и жизненно важные рабочие процессы встали.
Больше всего во время кризиса не хватает не информации или помощи других разработчиков, а возможности сфокусироваться. Это может показаться странным, но это чувство знакомо любому, кто был в одной лодке с лидерами, которые паникуют или никогда не понимали заблуждений мифического человеко-месяца. Они с нетерпением ждут новостей о ходе работы, и что может быть лучше, чем собирать всех на митинги четыре раза в день, чтобы узнать, как продвигаются дела. А это постоянные отвлечения, переключения контекста и обновления багтрекеров. Способность сосредоточиться и избавиться от отвлекающих факторов - самый важный фактор для решения проблемы.
Шаг 4. Проверка и обучение
Если все пойдёт хорошо, тесты подтвердятся, и вся ценная информация, полученная на шагах 1 и 2, даст вам уверенность в новых планах тестирования, вы можете развернуть исправление. Как только оно будет опубликовано, дайте время команде на всех уровнях, чтобы изучить его и подтвердить, что всё работает как надо. Если инженерам в начале этих инцидентов даются время и свобода, то они более уверенно и спокойно относятся к последующим релизам и исправлениям.
Однако, публикация исправления и уверенность команды в его правильности – лишь половина дела. Теперь нужно сделать так, чтобы болезненный и возможно дорогостоящий опыт этой проблемы способствовал развитию команды. Люди часто воспринимают крупные кризисы, как проблему, которая никогда больше не повторится, что совершенно неразумно. Часто лучшее обучение — это учиться справляться с проблемами, а не притворяться, будто мы можем их избежать.
В конце концов, чаще всего всё сводится к элементарной человеческой ошибке. Поэтому техническому руководителю нужно быть больше сосредоточенным не на предотвращении ошибок, а на оттачивании способности команды справляться с ними. Да, важна работа по предотвращению будущих подобных ошибок. Но часто есть больше возможностей для улучшения того, как команда реагирует на ошибку. Как дать инженерам больше возможностей для концентрации? Как можно ускорить расследование инцидента? Или даже кто лучше всего справляется с коммуникацией между разными специалистами или командами и какая информация им нужна?
Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/
👍8
День 1622. #ProjectManagement
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Начало
Обычно бывает так: опытная команда блестящих инженеров запускает новый продукт, клиентам нравится, фичи релизятся как из автомата. А спустя какое-то время внезапно продуктивность падает, выпускать новые функции всё сложнее, клиенты недовольны, инженеры устают от работы больше, чем когда-либо прежде, и призывают переписать всё с нуля. Время паники. Что случилось?
Первые признаки ухудшения
Команды похожи на огороды. Вначале растения мелкие, сорняков мало. Затем, из-за того, что вы не пропалывали, не поливали и не подкармливали, половина растений погибла, а другая превратилась в джунгли. Три вещи заставляют команды переходить в режим бурлаков:
- Первоначальные архитектурные решения были неверны или основывались на несовершенных предпосылках.
- Команда вынуждена выпускать продукт любой ценой, откладывая работу над техническим долгом.
- У команды нет системного плана решения проблем долга по мере роста системы.
Технический долг — убийца команд. Думайте о функциях и долге как о кредитной карте. Залезать в долги по кредитке каждый месяц — это нормально. Однако высокая процентная ставка разорит вас, если вы не выплатите долг.
Уменьшение объёмов предоставляемых функций при увеличении серьёзности возникающих проблем указывает на то, что команда в опасности. Если команда замедлилась с выпуска пяти средних и крупных функций в квартал до 1 функции с 3-кратным увеличением количества серьёзных ошибок за тот же период без изменений в составе команды, она движется к провалу. Задача для любого хорошего лидера в том, чтобы постоянно поддерживать минимальный уровень технического долга, позволяя команде продолжать выпускать функции.
Хорошая практика №1: постоянные обзоры архитектуры
Обзоры архитектуры распространены в начале проекта. Сначала команда придерживается надёжных архитектурных принципов, система не слишком сложна в обслуживании и т. д. Как только выходит версия 1.0, команда обычно прекращает рассмотрение новых функций с точки зрения влияния на архитектуру в пользу быстрой доставки. Это компромисс. Нет времени пересматривать архитектурные изменения. Но правильно ли это? Понимаем ли мы растущую систему?
Что делать?
Необходим официальный анализ архитектуры каждой новой функции среднего и крупного размера. Назначьте команде фиксированное время для рассмотрения влияния на архитектуру всех новых функций. 3-5 страниц или слайдов обзора с 1-3 диаграммами архитектуры вполне достаточно. Включите требование о проведении архитектурного анализа во все планы проекта. Все участвуют в рассмотрении, и все оценивают.
Зачем?
- Все в команде понимают, что делают все члены команды.
- Команда может взвесить технические компромиссы до того, как код будет написан и помещён в репозиторий — тогда обычно уже слишком поздно.
- Сложность системы и потенциальные проблемы со стабильностью, производительностью и масштабируемостью выявляются заранее.
- Команда создаёт архив диаграмм, чтобы будущим товарищам по команде было проще адаптироваться.
- Младшие инженеры узнают, как легко создавать более сложные системы.
Непрерывные обзоры архитектуры — первая защита от деградации проекта. В конечном счёте 30-минутная встреча в будущем сэкономит месяцы. Поэтому обозревайте архитектуру заранее, регулярно и используйте обзоры как средство раннего предупреждения.
Продолжение следует…
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Начало
Обычно бывает так: опытная команда блестящих инженеров запускает новый продукт, клиентам нравится, фичи релизятся как из автомата. А спустя какое-то время внезапно продуктивность падает, выпускать новые функции всё сложнее, клиенты недовольны, инженеры устают от работы больше, чем когда-либо прежде, и призывают переписать всё с нуля. Время паники. Что случилось?
Первые признаки ухудшения
Команды похожи на огороды. Вначале растения мелкие, сорняков мало. Затем, из-за того, что вы не пропалывали, не поливали и не подкармливали, половина растений погибла, а другая превратилась в джунгли. Три вещи заставляют команды переходить в режим бурлаков:
- Первоначальные архитектурные решения были неверны или основывались на несовершенных предпосылках.
- Команда вынуждена выпускать продукт любой ценой, откладывая работу над техническим долгом.
- У команды нет системного плана решения проблем долга по мере роста системы.
Технический долг — убийца команд. Думайте о функциях и долге как о кредитной карте. Залезать в долги по кредитке каждый месяц — это нормально. Однако высокая процентная ставка разорит вас, если вы не выплатите долг.
Уменьшение объёмов предоставляемых функций при увеличении серьёзности возникающих проблем указывает на то, что команда в опасности. Если команда замедлилась с выпуска пяти средних и крупных функций в квартал до 1 функции с 3-кратным увеличением количества серьёзных ошибок за тот же период без изменений в составе команды, она движется к провалу. Задача для любого хорошего лидера в том, чтобы постоянно поддерживать минимальный уровень технического долга, позволяя команде продолжать выпускать функции.
Хорошая практика №1: постоянные обзоры архитектуры
Обзоры архитектуры распространены в начале проекта. Сначала команда придерживается надёжных архитектурных принципов, система не слишком сложна в обслуживании и т. д. Как только выходит версия 1.0, команда обычно прекращает рассмотрение новых функций с точки зрения влияния на архитектуру в пользу быстрой доставки. Это компромисс. Нет времени пересматривать архитектурные изменения. Но правильно ли это? Понимаем ли мы растущую систему?
Что делать?
Необходим официальный анализ архитектуры каждой новой функции среднего и крупного размера. Назначьте команде фиксированное время для рассмотрения влияния на архитектуру всех новых функций. 3-5 страниц или слайдов обзора с 1-3 диаграммами архитектуры вполне достаточно. Включите требование о проведении архитектурного анализа во все планы проекта. Все участвуют в рассмотрении, и все оценивают.
Зачем?
- Все в команде понимают, что делают все члены команды.
- Команда может взвесить технические компромиссы до того, как код будет написан и помещён в репозиторий — тогда обычно уже слишком поздно.
- Сложность системы и потенциальные проблемы со стабильностью, производительностью и масштабируемостью выявляются заранее.
- Команда создаёт архив диаграмм, чтобы будущим товарищам по команде было проще адаптироваться.
- Младшие инженеры узнают, как легко создавать более сложные системы.
Непрерывные обзоры архитектуры — первая защита от деградации проекта. В конечном счёте 30-минутная встреча в будущем сэкономит месяцы. Поэтому обозревайте архитектуру заранее, регулярно и используйте обзоры как средство раннего предупреждения.
Продолжение следует…
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
👍13👎1
День 1623. #ProjectManagement
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Продолжение
Начало
Хорошая практика №2: Журнал ошибок и постоянные исправления
Журнал ошибок указывает на проблемы продукта. Разберитесь со списком ошибок. Это требует времени, но сделайте это всё равно.
Обработка ошибок – принудительная функция, как соглашение об уровне обслуживания (SLA), в котором мы объявляем обязательство по исправлению ошибок перед с нашими внутренними клиентами. И не все ошибки равны. Некоторые более сложны или более важны:
1. Система неработоспособна
- Затронуты все пользователи: Критическая ошибка - Исправлять немедленно!
- Некоторые пользователи: Серьёзная – 3-5 часов.
- Мало пользователей: Средняя – 2-3 дня.
2. Система сильно повреждена
- Все: Серьёзная – 3-5 часов.
- Некоторые: Средняя – 2-3 дня.
- Мало: Средняя – 2-3 дня.
3. У пользователей есть альтернативное решение
- Все: Серьёзная – 3-5 часов.
- Некоторые: Незначительная – 1-2 недели.
- Мало: В период исправления ошибок – 1 месяц.
4. Не влияет на систему
- Все: Незначительная – 1-2 недели.
- Некоторые: В период исправления ошибок – 1 месяц.
- Мало: Можно игнорировать
Журнал ошибок должен содержать список ошибок с их уровнем критичности. Кроме того, за состоянием проекта можно следить, отмечая на графике оценку количества ошибок с коэффициентом их критичности:
- Критическая – 2х
- Серьёзная – 1,5х
- Средняя – 1х
- Незначительная – 0,5х
Тогда, если на 1й неделе случилось 5 средних и одна серьёзная ошибка – это 5*1 + 1*1,5 = 6,5. На второй неделе 1 серьёзная и 6 незначительных – 1*1,5 + 6*0,5 = 4,5. Со временем этот график будет показывать состояние продукта.
Что делать?
- Определите SLA ошибки. Каждый продукт и каждая команда отличаются, но мы можем установить внутренние ожидания в отношении времени обработки для серьёзных, но не критических проблем. Мы быстро исправим серьёзные ошибки, а ошибки с более низким приоритетом будут исправлены или подвергнуты рефакторингу позже.
- Каждый спринт члены команды просматривают журнал ошибок и назначают исправления, чтобы обеспечить постоянный цикл исправления и сокращения количества ошибок.
- Сообщайте об исправлениях ошибок в заметках о выпуске, публикации во внутреннем чате или в каком-либо другом средстве. Например, сделайте «день выпуска отчёта об ошибках» и публикуйте этот отчёт.
- Используйте простые формулы для расчёта количества ошибок и удерживайте количество ошибок как можно более равномерным спринт за спринтом. Отслеживайте это желательно на общих дашбордах о состоянии проекта.
Зачем?
- Создаёт «систему раннего предупреждения». Команда привыкает к ритму и осознанию своих невыполненных работ по ошибкам и рабочей нагрузке. В результате разработчики могут определить, когда ошибки накапливаются, и спланировать их исправление.
- Внутренние клиенты имеют чёткие ожидания относительно того, когда появятся исправления ошибок, и у них есть возможность видеть работу команды.
- Команда узнаёт о горячих точках продукта раньше и может использовать эту информацию для следующего раунда планирования спринта. Чем короче время, чтобы избежать проблемы, тем меньше времени тратится впустую.
Примечание: сделайте так, чтобы ваши клиенты могли легко сообщать об ошибках! Не прячьте средство сообщения об ошибках, вы не всегда будете ловить ошибки в журналах.
Окончание следует…
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Продолжение
Начало
Хорошая практика №2: Журнал ошибок и постоянные исправления
Журнал ошибок указывает на проблемы продукта. Разберитесь со списком ошибок. Это требует времени, но сделайте это всё равно.
Обработка ошибок – принудительная функция, как соглашение об уровне обслуживания (SLA), в котором мы объявляем обязательство по исправлению ошибок перед с нашими внутренними клиентами. И не все ошибки равны. Некоторые более сложны или более важны:
1. Система неработоспособна
- Затронуты все пользователи: Критическая ошибка - Исправлять немедленно!
- Некоторые пользователи: Серьёзная – 3-5 часов.
- Мало пользователей: Средняя – 2-3 дня.
2. Система сильно повреждена
- Все: Серьёзная – 3-5 часов.
- Некоторые: Средняя – 2-3 дня.
- Мало: Средняя – 2-3 дня.
3. У пользователей есть альтернативное решение
- Все: Серьёзная – 3-5 часов.
- Некоторые: Незначительная – 1-2 недели.
- Мало: В период исправления ошибок – 1 месяц.
4. Не влияет на систему
- Все: Незначительная – 1-2 недели.
- Некоторые: В период исправления ошибок – 1 месяц.
- Мало: Можно игнорировать
Журнал ошибок должен содержать список ошибок с их уровнем критичности. Кроме того, за состоянием проекта можно следить, отмечая на графике оценку количества ошибок с коэффициентом их критичности:
- Критическая – 2х
- Серьёзная – 1,5х
- Средняя – 1х
- Незначительная – 0,5х
Тогда, если на 1й неделе случилось 5 средних и одна серьёзная ошибка – это 5*1 + 1*1,5 = 6,5. На второй неделе 1 серьёзная и 6 незначительных – 1*1,5 + 6*0,5 = 4,5. Со временем этот график будет показывать состояние продукта.
Что делать?
- Определите SLA ошибки. Каждый продукт и каждая команда отличаются, но мы можем установить внутренние ожидания в отношении времени обработки для серьёзных, но не критических проблем. Мы быстро исправим серьёзные ошибки, а ошибки с более низким приоритетом будут исправлены или подвергнуты рефакторингу позже.
- Каждый спринт члены команды просматривают журнал ошибок и назначают исправления, чтобы обеспечить постоянный цикл исправления и сокращения количества ошибок.
- Сообщайте об исправлениях ошибок в заметках о выпуске, публикации во внутреннем чате или в каком-либо другом средстве. Например, сделайте «день выпуска отчёта об ошибках» и публикуйте этот отчёт.
- Используйте простые формулы для расчёта количества ошибок и удерживайте количество ошибок как можно более равномерным спринт за спринтом. Отслеживайте это желательно на общих дашбордах о состоянии проекта.
Зачем?
- Создаёт «систему раннего предупреждения». Команда привыкает к ритму и осознанию своих невыполненных работ по ошибкам и рабочей нагрузке. В результате разработчики могут определить, когда ошибки накапливаются, и спланировать их исправление.
- Внутренние клиенты имеют чёткие ожидания относительно того, когда появятся исправления ошибок, и у них есть возможность видеть работу команды.
- Команда узнаёт о горячих точках продукта раньше и может использовать эту информацию для следующего раунда планирования спринта. Чем короче время, чтобы избежать проблемы, тем меньше времени тратится впустую.
Примечание: сделайте так, чтобы ваши клиенты могли легко сообщать об ошибках! Не прячьте средство сообщения об ошибках, вы не всегда будете ловить ошибки в журналах.
Окончание следует…
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
👍9
День 1624. #ProjectManagement
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Окончание
Начало
Продолжение
Хорошая практика №3: дисциплинированное исправление/рефакторинг
Организуйте ротацию дежурных в момент отправки продукта. Несмотря на то, что в продукте мало ошибок, может быть, мало клиентов и нет шансов выхода из строя под нагрузкой, назначение дежурных и их ротация заранее запускает «мышечную память».
Дежурство в команде с небольшим продуктом, пользовательской базой или активностью кажется контрпродуктивным, поскольку дежурные не создают новых функций. Кажется, что нужно задействовать всех на улучшение продукта, и не беспокоиться о поддержке, пока это не понадобится. Но так вы лишаете себя хорошего и простого средства управления техническим долгом и поддержания здоровья команды.
Что делать?
- Установите ротацию в тот момент, когда пользователи продукта смогут получить доступ к продукту. Наличие пользователей – это сообщения об ошибках.
- Установите разумную продолжительность (1 неделя, 1 спринт), чёткие процедуры передачи задач и расписание, чтобы все знали, когда они будут дежурить.
- Дежурство — это устранение инцидентов, исправление ошибок, снижение сложности кода (рефакторинг), а только затем работа над новыми функциями. Если бэклог ошибок заполняет всё дежурство, этот инженер не работает над новыми функциями.
- Не назначайте дежурному инженеру ничего, кроме дежурных задач.
Зачем?
- Команда методично устраняет ошибки, и технический долг стабилизируется.
- Команда выполняет SLA по ошибкам — внутренние и внешние клиенты довольны.
- Более стабильный продукт => меньше пожаров в продакшене и меньше простоев.
- Младшие инженеры получают возможность исправлять ошибки во всех частях системы, быстрее повышая свой уровень.
- Ещё одна система раннего предупреждения о здоровье команды. Если дежурство занято сложными, серьёзными ошибками, мы узнаём о проблемах сразу, а не через несколько месяцев.
Помните о компромиссе: команда предоставит меньше функций за счёт более стабильного продукта. Устанавливайте ожидания относительно ротации дежурных не в команде, а в организации в целом.
Переписывать ли заново?
Вышеупомянутые принципы должны создать систему раннего предупреждения и сосредоточить команду на поиске рефакторинга архитектуры из-за изменения технологии или бизнес-условий задолго до того, как вы достигнете этого состояния.
Инженеры любят работать над чистой кодовой базой и всегда агитируют начать все сначала. Но почти никогда не следует начинать заново, потому что это сопряжено с невероятными рисками.
Но иногда приходится:
- Нужно объединить два или более продукта в один с перекрывающимися возможностями и множеством новых требований. Создать новый продукт чаще намного быстрее.
- Первоначальные архитектурные предположения настолько ошибочны, или проблемы безопасности/конфиденциальности/соответствия настолько серьёзны, что единственным решением является создание нового продукта.
- Компания так далеко отошла от первоначальной основной миссии, что рефакторинг не спасёт кодовую базу.
Это серьёзное событие. Риски сумасшедшие: клиенты могут не захотеть использовать переписанный продукт. Команда может развалиться до или во время переписывания. Компания может рухнуть или у неё закончатся деньги. Переписать на новую архитектуру может не получиться по какой-то технической причине. Рассмотрите все компромиссы и убедитесь, что все согласны с вашим решением.
Итого
Большая часть этого процесса происходит за счёт времени команды на создание функций, но время, потерянное при этом, намного меньше, чем потеря всей команды. Держите технический долг под контролем.
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Окончание
Начало
Продолжение
Хорошая практика №3: дисциплинированное исправление/рефакторинг
Организуйте ротацию дежурных в момент отправки продукта. Несмотря на то, что в продукте мало ошибок, может быть, мало клиентов и нет шансов выхода из строя под нагрузкой, назначение дежурных и их ротация заранее запускает «мышечную память».
Дежурство в команде с небольшим продуктом, пользовательской базой или активностью кажется контрпродуктивным, поскольку дежурные не создают новых функций. Кажется, что нужно задействовать всех на улучшение продукта, и не беспокоиться о поддержке, пока это не понадобится. Но так вы лишаете себя хорошего и простого средства управления техническим долгом и поддержания здоровья команды.
Что делать?
- Установите ротацию в тот момент, когда пользователи продукта смогут получить доступ к продукту. Наличие пользователей – это сообщения об ошибках.
- Установите разумную продолжительность (1 неделя, 1 спринт), чёткие процедуры передачи задач и расписание, чтобы все знали, когда они будут дежурить.
- Дежурство — это устранение инцидентов, исправление ошибок, снижение сложности кода (рефакторинг), а только затем работа над новыми функциями. Если бэклог ошибок заполняет всё дежурство, этот инженер не работает над новыми функциями.
- Не назначайте дежурному инженеру ничего, кроме дежурных задач.
Зачем?
- Команда методично устраняет ошибки, и технический долг стабилизируется.
- Команда выполняет SLA по ошибкам — внутренние и внешние клиенты довольны.
- Более стабильный продукт => меньше пожаров в продакшене и меньше простоев.
- Младшие инженеры получают возможность исправлять ошибки во всех частях системы, быстрее повышая свой уровень.
- Ещё одна система раннего предупреждения о здоровье команды. Если дежурство занято сложными, серьёзными ошибками, мы узнаём о проблемах сразу, а не через несколько месяцев.
Помните о компромиссе: команда предоставит меньше функций за счёт более стабильного продукта. Устанавливайте ожидания относительно ротации дежурных не в команде, а в организации в целом.
Переписывать ли заново?
Вышеупомянутые принципы должны создать систему раннего предупреждения и сосредоточить команду на поиске рефакторинга архитектуры из-за изменения технологии или бизнес-условий задолго до того, как вы достигнете этого состояния.
Инженеры любят работать над чистой кодовой базой и всегда агитируют начать все сначала. Но почти никогда не следует начинать заново, потому что это сопряжено с невероятными рисками.
Но иногда приходится:
- Нужно объединить два или более продукта в один с перекрывающимися возможностями и множеством новых требований. Создать новый продукт чаще намного быстрее.
- Первоначальные архитектурные предположения настолько ошибочны, или проблемы безопасности/конфиденциальности/соответствия настолько серьёзны, что единственным решением является создание нового продукта.
- Компания так далеко отошла от первоначальной основной миссии, что рефакторинг не спасёт кодовую базу.
Это серьёзное событие. Риски сумасшедшие: клиенты могут не захотеть использовать переписанный продукт. Команда может развалиться до или во время переписывания. Компания может рухнуть или у неё закончатся деньги. Переписать на новую архитектуру может не получиться по какой-то технической причине. Рассмотрите все компромиссы и убедитесь, что все согласны с вашим решением.
Итого
Большая часть этого процесса происходит за счёт времени команды на создание функций, но время, потерянное при этом, намного меньше, чем потеря всей команды. Держите технический долг под контролем.
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
👍8
День 1733. #BestPractices #ProjectManagement
Принципы Бережливой Разработки ПО
Бережливая Разработка ПО (Lean Software Development) — это гибкая система управления проектами и разработки продуктов, основанная на принципах бережливого производства. Основное внимание уделяется обеспечению ценности для клиента путём оптимизации ресурсов, рабочих потоков и процессов. Ниже рассмотрим основные принципы бережливой разработки.
1. Устранение потерь
Эта концепция заимствована из мира бережливого производства, где она известна как «муда» (от японского бесполезность, расточительность). В разработке ПО потерями может быть что угодно: от написания ненужного кода до чрезмерных совещаний, которые не приносят никакой пользы. Цель состоит в том, чтобы оптимизировать рабочий процесс, выявляя и удаляя всё, что не помогает конечному продукту или не удовлетворяет потребностям клиента.
2. Усиленное обучение
Обучение является неотъемлемой частью разработки. Принцип усиленного обучения подчёркивает, что команда всегда должна находиться в состоянии непрерывного обучения. Будь то проверка кода, обратная связь или изучение новых материалов, этот принцип предполагает, что более информированная команда производит продукт более высокого качества. Такие практики, как предметно-ориентированное проектирование (DDD), помогают команде сосредоточиться на изучении и правильном моделировании предметной области.
3. Принятие решения как можно позже
Слишком раннее принятие решений может привести к переработке, если эти решения окажутся неправильными. Этот принцип советует отложить принятие решения до последнего ответственного момента. Это позволит команде получить максимальное количество информации и контекста перед принятием решения, тем самым снижая вероятность дорогостоящих ошибок.
4. Максимально быстрая поставка
Скорость и эффективность являются ключевыми факторами в бережливой разработке программного обеспечения. Этот принцип направлен на максимально быструю поставку функционального продукта покупателю. Речь идет не о спешке, а о поиске оптимального потока, который позволит выполнить быструю поставку без ущерба для качества. Важными показателями, которые команды могут отслеживать, чтобы определить скорость поставки готовых продуктов, являются
- время цикла (cycle time) - время, которое нужно команде, чтобы создать продукт,
- время поставки (lead time) – время между выставлением заказа клиентом и исполнением заказа.
5. Расширение возможностей команды
В рамках бережливой разработки ПО мотивированная и самостоятельная команда считается более эффективной и гибкой. Расширение прав и возможностей команды предполагает предоставление им автономии в принятии решений и ответственности за выполнение своих задач. Это создаёт чувство ответственности среди членов команды, повышая их производительность и продуктивность.
6. Обеспечение целостности
Качество не должно быть второстепенным вопросом; оно должно быть интегрировано в продукт с самого начала. Обеспечение целостности означает создание надёжной, удобной в обслуживании и адаптируемой системы с самого начала. Это требует стремления к совершенству от каждого члена команды на каждом этапе процесса разработки.
7. Оптимизация всего
Принципы бережливого производства подчеркивают важность рассмотрения процесса разработки как единого целого. Вместо того, чтобы сосредотачиваться исключительно на отдельных задачах или модулях, важно понять, как каждый элемент вписывается в общую картину. Оптимизируя всю систему, а не её части, вы можете обеспечить максимальную эффективность всего процесса.
Помните: «система, порождающая дефекты, является дефектной системой» - Джеффри Палермо. Обеспечьте качество всего процесса и выявляйте проблемы до того, как они покинут процесс.
Источник: https://ardalis.com/principles-lean-software-development/
Принципы Бережливой Разработки ПО
Бережливая Разработка ПО (Lean Software Development) — это гибкая система управления проектами и разработки продуктов, основанная на принципах бережливого производства. Основное внимание уделяется обеспечению ценности для клиента путём оптимизации ресурсов, рабочих потоков и процессов. Ниже рассмотрим основные принципы бережливой разработки.
1. Устранение потерь
Эта концепция заимствована из мира бережливого производства, где она известна как «муда» (от японского бесполезность, расточительность). В разработке ПО потерями может быть что угодно: от написания ненужного кода до чрезмерных совещаний, которые не приносят никакой пользы. Цель состоит в том, чтобы оптимизировать рабочий процесс, выявляя и удаляя всё, что не помогает конечному продукту или не удовлетворяет потребностям клиента.
2. Усиленное обучение
Обучение является неотъемлемой частью разработки. Принцип усиленного обучения подчёркивает, что команда всегда должна находиться в состоянии непрерывного обучения. Будь то проверка кода, обратная связь или изучение новых материалов, этот принцип предполагает, что более информированная команда производит продукт более высокого качества. Такие практики, как предметно-ориентированное проектирование (DDD), помогают команде сосредоточиться на изучении и правильном моделировании предметной области.
3. Принятие решения как можно позже
Слишком раннее принятие решений может привести к переработке, если эти решения окажутся неправильными. Этот принцип советует отложить принятие решения до последнего ответственного момента. Это позволит команде получить максимальное количество информации и контекста перед принятием решения, тем самым снижая вероятность дорогостоящих ошибок.
4. Максимально быстрая поставка
Скорость и эффективность являются ключевыми факторами в бережливой разработке программного обеспечения. Этот принцип направлен на максимально быструю поставку функционального продукта покупателю. Речь идет не о спешке, а о поиске оптимального потока, который позволит выполнить быструю поставку без ущерба для качества. Важными показателями, которые команды могут отслеживать, чтобы определить скорость поставки готовых продуктов, являются
- время цикла (cycle time) - время, которое нужно команде, чтобы создать продукт,
- время поставки (lead time) – время между выставлением заказа клиентом и исполнением заказа.
5. Расширение возможностей команды
В рамках бережливой разработки ПО мотивированная и самостоятельная команда считается более эффективной и гибкой. Расширение прав и возможностей команды предполагает предоставление им автономии в принятии решений и ответственности за выполнение своих задач. Это создаёт чувство ответственности среди членов команды, повышая их производительность и продуктивность.
6. Обеспечение целостности
Качество не должно быть второстепенным вопросом; оно должно быть интегрировано в продукт с самого начала. Обеспечение целостности означает создание надёжной, удобной в обслуживании и адаптируемой системы с самого начала. Это требует стремления к совершенству от каждого члена команды на каждом этапе процесса разработки.
7. Оптимизация всего
Принципы бережливого производства подчеркивают важность рассмотрения процесса разработки как единого целого. Вместо того, чтобы сосредотачиваться исключительно на отдельных задачах или модулях, важно понять, как каждый элемент вписывается в общую картину. Оптимизируя всю систему, а не её части, вы можете обеспечить максимальную эффективность всего процесса.
Помните: «система, порождающая дефекты, является дефектной системой» - Джеффри Палермо. Обеспечьте качество всего процесса и выявляйте проблемы до того, как они покинут процесс.
Источник: https://ardalis.com/principles-lean-software-development/
👍11
День 1739. #BestPractices #ProjectManagement
Раздувание Процессов: Тихий Убийца Продуктивности Разработчиков
На начальных стадиях проекта разработки команды отличаются гибкостью, быстрым принятием решений и стремлением предоставлять ценные функции. Однако по мере того, как проекты усложняются и масштабируются, многие из них становятся жертвами коварного антипаттерна: раздувания процессов.
Факторов, приводящих к этому, множество:
1. Организационная культура.
Слишком осторожная организация может создать несколько уровней бюрократии, предполагая, что чем больше формализованы процессы тем меньше риск.
2. Недостаток доверия.
Руководство, которому не хватает уверенности в возможностях разработчиков, может навязать несколько уровней утверждения и документацию.
3. Сложность масштаба.
Расширение проектов часто влечёт увеличение числа заинтересованных сторон, каждая из которых добавляет свой уровень сложности и свои процессы.
4. Устаревший багаж.
Иногда ненужные процессы задерживаются просто потому, что «так было всегда».
Последствия
1. Снижение производительности.
Разработчики часто тратят больше времени на административную работу, чем на фактическую разработку.
2. Утечка инноваций.
Бюрократия может подавить творчество и ограничить эксперименты.
3. Задержка вывода продукта на рынок.
Сложные процессы удлиняют циклы разработки.
4. Снижение морального духа.
Потеря гибкости и рутина процессов могут подорвать моральный дух команды.
Примеры раздувания процессов
1. Чрезмерные проверки кода.
Обязательное проведение нескольких уровней проверок даже для тривиальных изменений может серьёзно замедлить цикл разработки.
2. Слишком сложные системы заявок.
Сложные системы тикетов, требующие заполнения множества полей ещё до того, как задача будет одобрена, могут занять столько же времени, сколько и исполнение задачи.
3. Обязательные отчеты.
Требование подробных отчетов с описанием каждой потраченной минуты может отнять время и отвлечь внимание от фактического кодирования.
4. Чрезмерное количество совещаний
Борьба с раздуванием процессов
1. Регулярные аудиты.
Последовательно анализируйте существующие процессы для оценки их актуальности и эффективности. Это следует делать в рамках регулярных командных (и организационных) ретроспектив. Но убедитесь, что такие аудиты полезны, а не усугубляют проблему раздувания процессов!
2. Принципы бережливости и гибкости.
Примите методологии, направленные на получение максимальной отдачи при минимальных затратах на процессы. Многие agile-практики, подчёркивают важность обеспечения быстрого прохождения процесса с минимальными церемониями.
3. Поощряйте доверие и автономию.
Дайте разработчикам полномочия принимать решения без ненужных бюрократических одобрений. Ваша команда не сможет заслужить ваше доверие, если вы как менеджер первый не доверитесь ей.
4. Минимально жизнеспособный процесс.
Внедряйте только те процессы, которые абсолютно необходимы для поддержания качества и контроля. Если сомневаетесь, выбросьте. Если есть возможность сократить процессы и повысить производительность, поэкспериментируйте с этим и посмотрите, сработает ли это для вашей команды и организации.
Итого
Раздувание процессов — это тихий, но смертоносный фактор, подрывающий продуктивность разработки ПО. Распознав его симптомы и приняв упреждающие меры, команды смогут вернуть себе гибкость и дух творчества, а проекты вернуть на путь эффективности и инноваций.
Источник: https://ardalis.com/process-bloat-silent-killer-developer-productivity/
Раздувание Процессов: Тихий Убийца Продуктивности Разработчиков
На начальных стадиях проекта разработки команды отличаются гибкостью, быстрым принятием решений и стремлением предоставлять ценные функции. Однако по мере того, как проекты усложняются и масштабируются, многие из них становятся жертвами коварного антипаттерна: раздувания процессов.
Факторов, приводящих к этому, множество:
1. Организационная культура.
Слишком осторожная организация может создать несколько уровней бюрократии, предполагая, что чем больше формализованы процессы тем меньше риск.
2. Недостаток доверия.
Руководство, которому не хватает уверенности в возможностях разработчиков, может навязать несколько уровней утверждения и документацию.
3. Сложность масштаба.
Расширение проектов часто влечёт увеличение числа заинтересованных сторон, каждая из которых добавляет свой уровень сложности и свои процессы.
4. Устаревший багаж.
Иногда ненужные процессы задерживаются просто потому, что «так было всегда».
Последствия
1. Снижение производительности.
Разработчики часто тратят больше времени на административную работу, чем на фактическую разработку.
2. Утечка инноваций.
Бюрократия может подавить творчество и ограничить эксперименты.
3. Задержка вывода продукта на рынок.
Сложные процессы удлиняют циклы разработки.
4. Снижение морального духа.
Потеря гибкости и рутина процессов могут подорвать моральный дух команды.
Примеры раздувания процессов
1. Чрезмерные проверки кода.
Обязательное проведение нескольких уровней проверок даже для тривиальных изменений может серьёзно замедлить цикл разработки.
2. Слишком сложные системы заявок.
Сложные системы тикетов, требующие заполнения множества полей ещё до того, как задача будет одобрена, могут занять столько же времени, сколько и исполнение задачи.
3. Обязательные отчеты.
Требование подробных отчетов с описанием каждой потраченной минуты может отнять время и отвлечь внимание от фактического кодирования.
4. Чрезмерное количество совещаний
Борьба с раздуванием процессов
1. Регулярные аудиты.
Последовательно анализируйте существующие процессы для оценки их актуальности и эффективности. Это следует делать в рамках регулярных командных (и организационных) ретроспектив. Но убедитесь, что такие аудиты полезны, а не усугубляют проблему раздувания процессов!
2. Принципы бережливости и гибкости.
Примите методологии, направленные на получение максимальной отдачи при минимальных затратах на процессы. Многие agile-практики, подчёркивают важность обеспечения быстрого прохождения процесса с минимальными церемониями.
3. Поощряйте доверие и автономию.
Дайте разработчикам полномочия принимать решения без ненужных бюрократических одобрений. Ваша команда не сможет заслужить ваше доверие, если вы как менеджер первый не доверитесь ей.
4. Минимально жизнеспособный процесс.
Внедряйте только те процессы, которые абсолютно необходимы для поддержания качества и контроля. Если сомневаетесь, выбросьте. Если есть возможность сократить процессы и повысить производительность, поэкспериментируйте с этим и посмотрите, сработает ли это для вашей команды и организации.
Итого
Раздувание процессов — это тихий, но смертоносный фактор, подрывающий продуктивность разработки ПО. Распознав его симптомы и приняв упреждающие меры, команды смогут вернуть себе гибкость и дух творчества, а проекты вернуть на путь эффективности и инноваций.
Источник: https://ardalis.com/process-bloat-silent-killer-developer-productivity/
👍7
День 1745. #Карьера #ProjectManagement
Как Дать Эффективную Обратную Связь Сложному Человеку. Начало
Если слишком долго позволять трудным в общении людям делать всё по-своему, это может нанести непоправимый ущерб. Предоставление им обратной связи будет неэффективным, если она не будет правильной. Рассмотрим стратегии предоставления обратной связи таким трудным людям.
В коллективах бывают умные, талантливые и результативные люди. Они умеют решать сложные проблемы, и на них можно положиться для достижения цели. Но что, если они хороши только при самостоятельном выполнении работы? Что, если команде трудно общаться и сотрудничать с ними, что снижает продуктивность и результативность команды? Что, если они:
- Унижают других, когда их идеи неудачны.
- Занимают оборонительную позицию, когда другие с ними не согласны.
- Устанавливают высокие стандарты и ожидают, что другие будут им соответствовать.
- Выражают недовольство криком и гневом.
- Перебивают других и не позволяя им говорить.
- Ожидают особого к себе отношения.
То, что они хороши в том, что они делают, не дает им права действовать бездумно по отношению к другим. Каждый заслуживает уважения, и ни от кого не следует ожидать толерантности к плохому поведению.
Роберт Саттон в книге «Хороший босс, плохой босс» говорит, что лучшие начальники делают больше, чем просто заряжают людей, набирают и воспитывают работяг. Они устраняют негатив, потому что даже один токсичный человек или несколько деструктивных поступков могут навредить множеству хороших людей и конструктивных действий.
Это не значит, что надо избавиться от них. Это последний выход, когда ничего больше не помогает. Сначала возьмите на себя сложную задачу дать обратную связь этим трудным людям.
Именно здесь большинство менеджеров допускают ошибки. Они либо слишком долго позволяют трудным людям делать всё по-своему, причиняя непоправимый ущерб, либо дают обратную связь в неправильной форме. Тогда трудные люди отказываются её принимать, занимают оборонительную позицию и могут даже ожесточиться, что только больше усложнит работу с ними.
Вот 4 стратегии дать обратную связь сложному человеку, чтобы он не бросил работу или не создал ещё больше проблем.
1. Тщательно выбирайте слова
Для сложного человека определённые слова в обратной связи вызывают сильные негативные чувства, которые заставляют его защищаться:
- Обобщающие, типа «всегда» и «никогда».
- Навязывающие, как «не могу», «не должен», «должен», «подчиняться».
- Бросающие вызов: «плохой», «требовательный», «непрофессиональный», «грубый».
- Осуждающие: «ошибка», «неудача», «неприемлемо».
Селеста Хэдли пишет в книге «Нам надо поговорить»: «Высокообразованные люди склонны придавать большое значение логике и преуменьшать важность эмоций. Конечно, вы не можете выиграть дебаты с помощью эмоциональных аргументов, но разговор — это не дебаты, а люди по своей сути нелогичны. Мы эмоциональные существа. Удалить или попытаться удалить эмоции из вашего разговора — значит извлечь большую часть смысла и важности».
Будьте внимательны, тщательно обдумайте эффект того, что вы говорите, и избегайте эмоционально заряженных слов, которые делают обратную связь неэффективной.
Например:
Вместо: Вы всегда опаздываете на встречи. Ваше поведение испортит и других членов команды.
Скажите: На последних двух встречах я заметил, что вы приходили через 10-15 минут после начала. Вы можете приходить на собрания вовремя и подать хороший пример другим?
Вместо: Вы должны позволить другим высказываться в обсуждениях. Перебивать их – это грубо.
Скажите: Выслушивание различных точек зрения поможет нам принимать более правильные решения. Давайте попробуем стимулировать участие других в обсуждениях.
Продолжение следует…
Источник: https://www.techtello.com/give-feedback-to-a-difficult-person/
Как Дать Эффективную Обратную Связь Сложному Человеку. Начало
Если слишком долго позволять трудным в общении людям делать всё по-своему, это может нанести непоправимый ущерб. Предоставление им обратной связи будет неэффективным, если она не будет правильной. Рассмотрим стратегии предоставления обратной связи таким трудным людям.
В коллективах бывают умные, талантливые и результативные люди. Они умеют решать сложные проблемы, и на них можно положиться для достижения цели. Но что, если они хороши только при самостоятельном выполнении работы? Что, если команде трудно общаться и сотрудничать с ними, что снижает продуктивность и результативность команды? Что, если они:
- Унижают других, когда их идеи неудачны.
- Занимают оборонительную позицию, когда другие с ними не согласны.
- Устанавливают высокие стандарты и ожидают, что другие будут им соответствовать.
- Выражают недовольство криком и гневом.
- Перебивают других и не позволяя им говорить.
- Ожидают особого к себе отношения.
То, что они хороши в том, что они делают, не дает им права действовать бездумно по отношению к другим. Каждый заслуживает уважения, и ни от кого не следует ожидать толерантности к плохому поведению.
Роберт Саттон в книге «Хороший босс, плохой босс» говорит, что лучшие начальники делают больше, чем просто заряжают людей, набирают и воспитывают работяг. Они устраняют негатив, потому что даже один токсичный человек или несколько деструктивных поступков могут навредить множеству хороших людей и конструктивных действий.
Это не значит, что надо избавиться от них. Это последний выход, когда ничего больше не помогает. Сначала возьмите на себя сложную задачу дать обратную связь этим трудным людям.
Именно здесь большинство менеджеров допускают ошибки. Они либо слишком долго позволяют трудным людям делать всё по-своему, причиняя непоправимый ущерб, либо дают обратную связь в неправильной форме. Тогда трудные люди отказываются её принимать, занимают оборонительную позицию и могут даже ожесточиться, что только больше усложнит работу с ними.
Вот 4 стратегии дать обратную связь сложному человеку, чтобы он не бросил работу или не создал ещё больше проблем.
1. Тщательно выбирайте слова
Для сложного человека определённые слова в обратной связи вызывают сильные негативные чувства, которые заставляют его защищаться:
- Обобщающие, типа «всегда» и «никогда».
- Навязывающие, как «не могу», «не должен», «должен», «подчиняться».
- Бросающие вызов: «плохой», «требовательный», «непрофессиональный», «грубый».
- Осуждающие: «ошибка», «неудача», «неприемлемо».
Селеста Хэдли пишет в книге «Нам надо поговорить»: «Высокообразованные люди склонны придавать большое значение логике и преуменьшать важность эмоций. Конечно, вы не можете выиграть дебаты с помощью эмоциональных аргументов, но разговор — это не дебаты, а люди по своей сути нелогичны. Мы эмоциональные существа. Удалить или попытаться удалить эмоции из вашего разговора — значит извлечь большую часть смысла и важности».
Будьте внимательны, тщательно обдумайте эффект того, что вы говорите, и избегайте эмоционально заряженных слов, которые делают обратную связь неэффективной.
Например:
Вместо: Вы всегда опаздываете на встречи. Ваше поведение испортит и других членов команды.
Скажите: На последних двух встречах я заметил, что вы приходили через 10-15 минут после начала. Вы можете приходить на собрания вовремя и подать хороший пример другим?
Вместо: Вы должны позволить другим высказываться в обсуждениях. Перебивать их – это грубо.
Скажите: Выслушивание различных точек зрения поможет нам принимать более правильные решения. Давайте попробуем стимулировать участие других в обсуждениях.
Продолжение следует…
Источник: https://www.techtello.com/give-feedback-to-a-difficult-person/
👍11
День 1746. #Карьера #ProjectManagement
Как Дать Эффективную Обратную Связь Сложному Человеку. Продолжение
Начало
2. Делитесь наблюдениями, а не осуждайте
Человек, получающий обратную связь, может почувствовать, что вы осуждаете его, в течение первых нескольких минут, основываясь на вашем тоне и языке тела. Это заставляет его либо замолчать (полагая, что ничто сказанное не изменит вашего мнения), либо превратить разговор в спор, чтобы доказать, что он прав, а вы нет.
Керри Паттерсон говорит в книге «Ключевые переговоры»: «Уважение подобно воздуху. Пока оно есть, об этом никто не думает. Но если убрать его, это все, о чём люди смогут думать. В тот момент, когда люди чувствуют неуважение в разговоре, взаимодействие больше не имеет первоначальной цели — теперь речь идёт о защите достоинства».
Давая обратную связь сложному человеку, оставьте свои мнения и суждения за дверью и вступайте в дискуссию непредвзято — думайте о диалоге, а не о монологе.
Ваша цель не в том, чтобы заставить его чувствовать себя плохо, бросить вызов его поведению или способам работы — это только сделает его невосприимчивым ко всему, что вы говорите. Вместо этого сделайте следующее:
- Поделитесь наблюдениями. «Я заметил, я услышал, я наблюдал, я увидел, мне сказали» вместо «Ты сделал, ты сказал».
- Продолжайте обсуждение конкретной проблемы, а не человека.
- Придерживайтесь фактов.
- Говорите о влиянии на команду.
- Предоставьте человеку возможность найти решение.
Если человек станет частью решения, это даст ему возможность переосмыслить свои действия. Не чувствуя давления на себя, он с большей вероятностью увидит влияние своего поведения на других.
Вместо: Вы кричите на других. Это не поможет. Научитесь контролировать свой характер.
Скажите: Мне сказали, что на последней встрече вы повысили голос (факт). Из-за этого другие в комнате не захотели высказываться. Без их вклада и согласия мы не сможем принять решение, что задержит реализацию проекта. Давайте попробуем поддерживать идеи других и побудить их делиться мыслями. (решение)
Вместо: Вы очень грубы и постоянно перебиваете других. Это неприемлемо.
Скажите: В последнем обсуждении я заметил, что, когда Рея делилась решением, вы несколько раз перебивали её и уводили разговор в сторону (факт). Когда вы не позволяете другим договорить, они чувствуют себя неуслышанными, что подрывает их уверенность. Мы можем расти как команда только тогда, когда каждый имеет возможность делиться своим мнением. Что вы можете сделать, чтобы этому поспособствовать? (решение)
Вместо: Ты сказал Карлу, что он тупой. Это непрофессионально.
Скажите: Мне сказали, что ты назвал дизайн Карла тупым (факт). Карл — очень преданный своему делу сотрудник, который всегда стремится учиться. Это нормально чего-то не знать. Это не делает человека тупым. Вместо того, чтобы разочаровывать людей, когда они чего-то не знают, нам нужно поощрять их учиться. Давайте решим, как вы можете работать с командой так, чтобы поощрять коллег, а не разочаровывать? (решение)
Окончание следует…
Источник: https://www.techtello.com/give-feedback-to-a-difficult-person/
Как Дать Эффективную Обратную Связь Сложному Человеку. Продолжение
Начало
2. Делитесь наблюдениями, а не осуждайте
Человек, получающий обратную связь, может почувствовать, что вы осуждаете его, в течение первых нескольких минут, основываясь на вашем тоне и языке тела. Это заставляет его либо замолчать (полагая, что ничто сказанное не изменит вашего мнения), либо превратить разговор в спор, чтобы доказать, что он прав, а вы нет.
Керри Паттерсон говорит в книге «Ключевые переговоры»: «Уважение подобно воздуху. Пока оно есть, об этом никто не думает. Но если убрать его, это все, о чём люди смогут думать. В тот момент, когда люди чувствуют неуважение в разговоре, взаимодействие больше не имеет первоначальной цели — теперь речь идёт о защите достоинства».
Давая обратную связь сложному человеку, оставьте свои мнения и суждения за дверью и вступайте в дискуссию непредвзято — думайте о диалоге, а не о монологе.
Ваша цель не в том, чтобы заставить его чувствовать себя плохо, бросить вызов его поведению или способам работы — это только сделает его невосприимчивым ко всему, что вы говорите. Вместо этого сделайте следующее:
- Поделитесь наблюдениями. «Я заметил, я услышал, я наблюдал, я увидел, мне сказали» вместо «Ты сделал, ты сказал».
- Продолжайте обсуждение конкретной проблемы, а не человека.
- Придерживайтесь фактов.
- Говорите о влиянии на команду.
- Предоставьте человеку возможность найти решение.
Если человек станет частью решения, это даст ему возможность переосмыслить свои действия. Не чувствуя давления на себя, он с большей вероятностью увидит влияние своего поведения на других.
Вместо: Вы кричите на других. Это не поможет. Научитесь контролировать свой характер.
Скажите: Мне сказали, что на последней встрече вы повысили голос (факт). Из-за этого другие в комнате не захотели высказываться. Без их вклада и согласия мы не сможем принять решение, что задержит реализацию проекта. Давайте попробуем поддерживать идеи других и побудить их делиться мыслями. (решение)
Вместо: Вы очень грубы и постоянно перебиваете других. Это неприемлемо.
Скажите: В последнем обсуждении я заметил, что, когда Рея делилась решением, вы несколько раз перебивали её и уводили разговор в сторону (факт). Когда вы не позволяете другим договорить, они чувствуют себя неуслышанными, что подрывает их уверенность. Мы можем расти как команда только тогда, когда каждый имеет возможность делиться своим мнением. Что вы можете сделать, чтобы этому поспособствовать? (решение)
Вместо: Ты сказал Карлу, что он тупой. Это непрофессионально.
Скажите: Мне сказали, что ты назвал дизайн Карла тупым (факт). Карл — очень преданный своему делу сотрудник, который всегда стремится учиться. Это нормально чего-то не знать. Это не делает человека тупым. Вместо того, чтобы разочаровывать людей, когда они чего-то не знают, нам нужно поощрять их учиться. Давайте решим, как вы можете работать с командой так, чтобы поощрять коллег, а не разочаровывать? (решение)
Окончание следует…
Источник: https://www.techtello.com/give-feedback-to-a-difficult-person/
👍9
День 1747. #Карьера #ProjectManagement
Как Дать Эффективную Обратную Связь Сложному Человеку. Окончание
Начало
Продолжение
3. Слушайте, дайте человеку почувствовать себя услышанным
Доктор Ральф Николс, пионер изучения умения слушать, сказал: «Самая основная из всех человеческих потребностей — это потребность понимать и быть понятым. Лучший способ понять людей — это слушать их». Слушать не означает соглашаться с их точкой зрения, это просто даёт им понять, что вы их услышали.
Чувство того, что вас не слышат, вызывает негативные эмоции, которые омрачают способность ясно мыслить и участвовать в конструктивной дискуссии. Как только человек чувствует неодобрение, срабатывает защитная реакция, спасающая его от риска эмоционального воздействия: он отказывается брать на себя ответственность или перекладывает вину на кого-то другого.
С другой стороны, будучи услышанным, человек ослабляет бдительность — это заставляет его принять эти страхи. Он готов участвовать, выслушивать и направлять свою энергию на поиск решения, а не зацикливаться на том, что вы сказали.
Вот несколько дополнительных вопросов для взаимодействия и общения:
- Расскажите подробнее об этом.
- Что вы об этом думаете?
- Как бы вы это решили?
- Как вы думаете, почему это произошло?
- Какой может быть альтернативная точка зрения на это?
- Если бы вы оказались в такой ситуации, как бы вы себя почувствовали?
Дать обратную связь сложному человеку будет легче, если вы перестанете притворяться, что слушаете, и действительно дадите ему почувствовать себя услышанным.
4. Установите дедлайн изменений
Джоко Виллинк говорит в книге «Экстремальная ответственность»: «Важно не то, что вы проповедуете, а то, что вы терпите».
Здоровые границы необходимы для психического благополучия всех сотрудников на работе. Когда эти границы нарушаются трудными людьми — либо потому, что не установлены соответствующие ожидания того, что представляет собой токсичность, либо потому, что у них просто проблемы с отношением к работе, не важно — чем больше времени кто-то проводит с ними, тем больше вреда они терпят.
Если позволить трудным людям оставаться в системе слишком долго, это подрывает усилия многих других. Эмоциональное истощение от пребывания рядом с трудными людьми влияет на то, как люди работают, что делают, и, наконец, на то, чего добивается коллектив в целом.
Когда вы даёте обратную связь сложному человеку, не говорите просто «о проблеме». Установите время на взаимно согласованные изменения и дайте понять, что человек должен быть готов столкнуться с последствиями, если не сможет учиться и совершенствоваться.
Для этого скажите: «Давайте убедимся, что мы друг друга поняли. Через [сколько-то времени] вы [излагаете ваши ожидания]. Я готов помочь вам, если вы захотите обсудить что-нибудь ещё. Но имейте в виду, что я не отношусь к этому легкомысленно, и, если ситуация не улучшится, будут последствия».
Итого
«Трудные» люди, особенно те, у которых к тому же все хорошо на работе, плохо воспринимают обратную связь. Чтобы разговор был эффективным:
1. Будьте аккуратны в выборе слов. Эмоционально заряженные слова могут вызвать негативные эмоции и заставить человека защищаться.
2. Исключите обратную связь, которая воспринимается как осуждение. Поделитесь наблюдениями, поговорите о влиянии на команду и предложите человеку найти решение.
3. Послушайте человека. Дайте ему возможность подумать, поразмышлять и найти собственное решение.
4. Не оставляйте отзыв без чётких ожиданий относительно желаемых изменений, сроков и последствий несерьёзного отношения к критике.
Источник: https://www.techtello.com/give-feedback-to-a-difficult-person/
Как Дать Эффективную Обратную Связь Сложному Человеку. Окончание
Начало
Продолжение
3. Слушайте, дайте человеку почувствовать себя услышанным
Доктор Ральф Николс, пионер изучения умения слушать, сказал: «Самая основная из всех человеческих потребностей — это потребность понимать и быть понятым. Лучший способ понять людей — это слушать их». Слушать не означает соглашаться с их точкой зрения, это просто даёт им понять, что вы их услышали.
Чувство того, что вас не слышат, вызывает негативные эмоции, которые омрачают способность ясно мыслить и участвовать в конструктивной дискуссии. Как только человек чувствует неодобрение, срабатывает защитная реакция, спасающая его от риска эмоционального воздействия: он отказывается брать на себя ответственность или перекладывает вину на кого-то другого.
С другой стороны, будучи услышанным, человек ослабляет бдительность — это заставляет его принять эти страхи. Он готов участвовать, выслушивать и направлять свою энергию на поиск решения, а не зацикливаться на том, что вы сказали.
Вот несколько дополнительных вопросов для взаимодействия и общения:
- Расскажите подробнее об этом.
- Что вы об этом думаете?
- Как бы вы это решили?
- Как вы думаете, почему это произошло?
- Какой может быть альтернативная точка зрения на это?
- Если бы вы оказались в такой ситуации, как бы вы себя почувствовали?
Дать обратную связь сложному человеку будет легче, если вы перестанете притворяться, что слушаете, и действительно дадите ему почувствовать себя услышанным.
4. Установите дедлайн изменений
Джоко Виллинк говорит в книге «Экстремальная ответственность»: «Важно не то, что вы проповедуете, а то, что вы терпите».
Здоровые границы необходимы для психического благополучия всех сотрудников на работе. Когда эти границы нарушаются трудными людьми — либо потому, что не установлены соответствующие ожидания того, что представляет собой токсичность, либо потому, что у них просто проблемы с отношением к работе, не важно — чем больше времени кто-то проводит с ними, тем больше вреда они терпят.
Если позволить трудным людям оставаться в системе слишком долго, это подрывает усилия многих других. Эмоциональное истощение от пребывания рядом с трудными людьми влияет на то, как люди работают, что делают, и, наконец, на то, чего добивается коллектив в целом.
Когда вы даёте обратную связь сложному человеку, не говорите просто «о проблеме». Установите время на взаимно согласованные изменения и дайте понять, что человек должен быть готов столкнуться с последствиями, если не сможет учиться и совершенствоваться.
Для этого скажите: «Давайте убедимся, что мы друг друга поняли. Через [сколько-то времени] вы [излагаете ваши ожидания]. Я готов помочь вам, если вы захотите обсудить что-нибудь ещё. Но имейте в виду, что я не отношусь к этому легкомысленно, и, если ситуация не улучшится, будут последствия».
Итого
«Трудные» люди, особенно те, у которых к тому же все хорошо на работе, плохо воспринимают обратную связь. Чтобы разговор был эффективным:
1. Будьте аккуратны в выборе слов. Эмоционально заряженные слова могут вызвать негативные эмоции и заставить человека защищаться.
2. Исключите обратную связь, которая воспринимается как осуждение. Поделитесь наблюдениями, поговорите о влиянии на команду и предложите человеку найти решение.
3. Послушайте человека. Дайте ему возможность подумать, поразмышлять и найти собственное решение.
4. Не оставляйте отзыв без чётких ожиданий относительно желаемых изменений, сроков и последствий несерьёзного отношения к критике.
Источник: https://www.techtello.com/give-feedback-to-a-difficult-person/
👍6
День 1838. #ProjectManagement
Чтобы Избавиться Технического Долга, Оцените Его. Начало
Когда Уорд Каннингем придумал метафору технического долга, ему нужен был способ обсудить решения, принятые на ранних этапах проекта, которые мешали инженерам в дальнейшей работе над проектом. Он занимался финансовым ПО - отсюда финансовая метафора. Технические решения, которые команда приняла на раннем этапе ради вывода продукта на рынок, возможно, вредят впоследствии, и, если их не исправить, производительность команды пострадает, а новые функции будут выпускаться медленнее.
Многие успешные компании использовали технологический долг, чтобы начать работу, только чтобы погасить его позже. Например, Facebook изначально был написан на PHP. Стоит отметить, что техдолг не обязательно означает, что первоначальный выбор был ошибочным. Написание сайта на PHP поначалу не было плохим решением — это не тот случай, когда плохой код в дальнейшем им мешал. Это прекрасный язык, который Facebook просто перерос.
На самом деле, проблема обновления устаревшего фреймворка или библиотеки не является технической. Как и в метафоре, она финансовая. Множество обновлений откладываются на долгие годы из-за необходимости установки нового ПО, переписывания кода и проверки последствий обновления. При этом неисправленные дыры в безопасности могут сделать проект уязвимым, а сложность выпуска новых функций может поставить приложение в невыгодное положение на рынке. Когда-нибудь этот счёт придётся оплатить.
Технический долг – это не только обновления языка и инструментов. Это могут быть добросовестные решения при написании кода, принятые ради немедленной выгоды. Чем раньше вы сможете вернуть долги, тем лучше. Но возврат долгов требует точного определения размера долга, который несёт команда.
Стоимость времени обслуживания
Разработчики любят решать проблемы, но эта любовь не всегда распространяется на поиск ошибок и замену устаревших технологий. Однако, какие тикеты попадут в следующий спринт, определяет менеджмент. Разработчики могут стремиться писать наиболее элегантный и чистый код, но менеджер служит бизнесу, а бизнес часто фокусируется на прибылях и убытках. Чтобы погасить технологический долг, сначала необходимо оценить его с точки зрения затрат и выгод.
Экономические последствия технического долга вполне реальны. В 2018 году Stripe провела исследование влияния техдолга и других эффектов «плохого кода». Они обнаружили, что средний разработчик в неделю тратил 13,5 часов на техдолг и ещё почти 4 часа на «плохой код». Т.е. почти половину рабочего времени! Если вы умножите это на зарплату разработчика, то получите серьёзные затраты на техдолг.
Поддержка некачественного кода часто занимает значительно больше времени из-за сложности, а также обычно влечёт больше ошибок. Таким образом, низкое качество в итоге серьёзно влияет на то, что ценят менеджеры. Большинство компаний уже используют какую-либо систему отслеживания проблем, поэтому разработчики, которые хотят обосновать стремление избавиться от техдолга, могут использовать её. Это просто требует дисциплины в отслеживании тикетов, оценке стори-пойнтов и подтверждении времени, потраченного на обслуживание техдолга.
Также можно просто спросить команду. Если команда признаёт что-то важным, они, вероятно, либо потратили некоторое время на это недавно (т.е. это свежо у них в голове), либо код настолько плох, что работа над ним надолго запомнилась.
Описанное выше - это всего лишь затраты на написание кода для избавления от техдолга. Ещё одна важная метрика — это код, который вы НЕ написали.
Окончание следует…
Источник: https://stackoverflow.blog/2023/08/24/if-you-want-to-address-tech-debt-quantify-it-first/
Чтобы Избавиться Технического Долга, Оцените Его. Начало
Когда Уорд Каннингем придумал метафору технического долга, ему нужен был способ обсудить решения, принятые на ранних этапах проекта, которые мешали инженерам в дальнейшей работе над проектом. Он занимался финансовым ПО - отсюда финансовая метафора. Технические решения, которые команда приняла на раннем этапе ради вывода продукта на рынок, возможно, вредят впоследствии, и, если их не исправить, производительность команды пострадает, а новые функции будут выпускаться медленнее.
Многие успешные компании использовали технологический долг, чтобы начать работу, только чтобы погасить его позже. Например, Facebook изначально был написан на PHP. Стоит отметить, что техдолг не обязательно означает, что первоначальный выбор был ошибочным. Написание сайта на PHP поначалу не было плохим решением — это не тот случай, когда плохой код в дальнейшем им мешал. Это прекрасный язык, который Facebook просто перерос.
На самом деле, проблема обновления устаревшего фреймворка или библиотеки не является технической. Как и в метафоре, она финансовая. Множество обновлений откладываются на долгие годы из-за необходимости установки нового ПО, переписывания кода и проверки последствий обновления. При этом неисправленные дыры в безопасности могут сделать проект уязвимым, а сложность выпуска новых функций может поставить приложение в невыгодное положение на рынке. Когда-нибудь этот счёт придётся оплатить.
Технический долг – это не только обновления языка и инструментов. Это могут быть добросовестные решения при написании кода, принятые ради немедленной выгоды. Чем раньше вы сможете вернуть долги, тем лучше. Но возврат долгов требует точного определения размера долга, который несёт команда.
Стоимость времени обслуживания
Разработчики любят решать проблемы, но эта любовь не всегда распространяется на поиск ошибок и замену устаревших технологий. Однако, какие тикеты попадут в следующий спринт, определяет менеджмент. Разработчики могут стремиться писать наиболее элегантный и чистый код, но менеджер служит бизнесу, а бизнес часто фокусируется на прибылях и убытках. Чтобы погасить технологический долг, сначала необходимо оценить его с точки зрения затрат и выгод.
Экономические последствия технического долга вполне реальны. В 2018 году Stripe провела исследование влияния техдолга и других эффектов «плохого кода». Они обнаружили, что средний разработчик в неделю тратил 13,5 часов на техдолг и ещё почти 4 часа на «плохой код». Т.е. почти половину рабочего времени! Если вы умножите это на зарплату разработчика, то получите серьёзные затраты на техдолг.
Поддержка некачественного кода часто занимает значительно больше времени из-за сложности, а также обычно влечёт больше ошибок. Таким образом, низкое качество в итоге серьёзно влияет на то, что ценят менеджеры. Большинство компаний уже используют какую-либо систему отслеживания проблем, поэтому разработчики, которые хотят обосновать стремление избавиться от техдолга, могут использовать её. Это просто требует дисциплины в отслеживании тикетов, оценке стори-пойнтов и подтверждении времени, потраченного на обслуживание техдолга.
Также можно просто спросить команду. Если команда признаёт что-то важным, они, вероятно, либо потратили некоторое время на это недавно (т.е. это свежо у них в голове), либо код настолько плох, что работа над ним надолго запомнилась.
Описанное выше - это всего лишь затраты на написание кода для избавления от техдолга. Ещё одна важная метрика — это код, который вы НЕ написали.
Окончание следует…
Источник: https://stackoverflow.blog/2023/08/24/if-you-want-to-address-tech-debt-quantify-it-first/
👍11
День 1839. #ProjectManagement
Чтобы Избавиться Технического Долга, Оцените Его. Окончание
Начало
Стоимость возможностей
Если разработчики тратят время на техдолг и плохой код, значит они не предоставляют новые функции. В индустрии ПО чем быстрее вы сможете внедрять новые функции, тем лучше сможете удовлетворять требования клиентов и большую ценность добавите продукту.
Техдолг влияет на то, сколько времени потребуется на написание нового кода, особенно если, избегая избавления от техдолга, вы добавляете костыли, которые увеличивают количество путей прохождения кода (цикломатическую сложность). Эта сложность сама по себе становится частью долга, который придётся в какой-то момент оплатить.
Существует связь между этой сложностью и продуктивностью разработчиков. Т.к. код становится сложнее поддерживать, новые функции занимают больше времени. Чем больше мест в коде необходимо затронуть, чтобы изменение заработало, тем больше времени это занимает.
Иногда техдолг возникает из-за добросовестных решений, которые устарели или основаны на старых версиях ПО. Их обновление может потребовать серьёзного переписывания, а не просто рефакторинга. Вот несколько признаков того, что код требуется переписать:
- ПО устарело или скоро потеряет поддержку, или доступна версия лучше.
- Вы не можете автоматизировать развёртывание.
- Тестирование занимает слишком много времени, не может быть автоматизировано или не может охватить важные функции.
Если у вас есть такая статистика, вы можете сравнить вашу текущую скорость выпуска новых функций с лучшим спринтом, который часто приходится на начало жизненного цикла ПО. Разницу можно считать процентами по техническому долгу. По мере роста долга растут и время, и усилия, затрачиваемые на погашение этих процентов. Чем медленнее общая скорость разработки, тем меньше новых функций будет поставлено клиентам.
Человеческая стоимость
Компании конкурируют за лучшие технические таланты. Трудоустройство нового сотрудника может стоить от шести до девяти его зарплат. Потому компаний уделяют особое внимание опыту адаптации разработчиков.
Адаптация — первая и самая важная часть опыта сотрудника в компании. Чтобы освоиться новому сотруднику может потребоваться до двух месяцев. Неудачный опыт адаптации может отпугнуть разработчика. 20% уходят в течение первых 45 дней. Т.е. плавный процесс адаптации может означать разницу между получением хорошего специалиста и новым поиском.
Время адаптации разработчика будет зависеть как от имеющейся документации и налаженных процессов, так и от сложности и читаемости кода. Отсутствие документации тоже форма долга. Вы знаете, что в какой-то момент она вам понадобится, но, чтобы двигаться быстрее, вы не стали её писать. Новым сотрудникам придётся расспрашивать и тратить время старших инженеров, чтобы адаптироваться.
Новый разработчик может разочароваться, увидев методы написания кода, принятые в команде, которые затрудняют анализ кода. Это расстраивает и деморализует, поскольку вы постоянно тратите время, пытаясь понять, что происходит в коде.
Очевидно, техдолг — не просто код, который требует рефакторинга для соответствия лучшим практикам: устаревшие или неэффективные инструменты и зависимости тоже считаются. В опросе StackOverflow о том, почему разработчики решают остаться на работе или уйти 35-40% сказали, что ищут новую работу, чтобы использовать новые технологии.
Т.е., если ваша компания страдает от частых уходов людей в течение первого года, то возможно проблема в техдолге. Проводите выходные интервью и отслеживайте отзывы. Если долг стоит вам хороших сотрудников, это веская причина пересмотреть приоритеты в следующем спринте.
Источник: https://stackoverflow.blog/2023/08/24/if-you-want-to-address-tech-debt-quantify-it-first/
Чтобы Избавиться Технического Долга, Оцените Его. Окончание
Начало
Стоимость возможностей
Если разработчики тратят время на техдолг и плохой код, значит они не предоставляют новые функции. В индустрии ПО чем быстрее вы сможете внедрять новые функции, тем лучше сможете удовлетворять требования клиентов и большую ценность добавите продукту.
Техдолг влияет на то, сколько времени потребуется на написание нового кода, особенно если, избегая избавления от техдолга, вы добавляете костыли, которые увеличивают количество путей прохождения кода (цикломатическую сложность). Эта сложность сама по себе становится частью долга, который придётся в какой-то момент оплатить.
Существует связь между этой сложностью и продуктивностью разработчиков. Т.к. код становится сложнее поддерживать, новые функции занимают больше времени. Чем больше мест в коде необходимо затронуть, чтобы изменение заработало, тем больше времени это занимает.
Иногда техдолг возникает из-за добросовестных решений, которые устарели или основаны на старых версиях ПО. Их обновление может потребовать серьёзного переписывания, а не просто рефакторинга. Вот несколько признаков того, что код требуется переписать:
- ПО устарело или скоро потеряет поддержку, или доступна версия лучше.
- Вы не можете автоматизировать развёртывание.
- Тестирование занимает слишком много времени, не может быть автоматизировано или не может охватить важные функции.
Если у вас есть такая статистика, вы можете сравнить вашу текущую скорость выпуска новых функций с лучшим спринтом, который часто приходится на начало жизненного цикла ПО. Разницу можно считать процентами по техническому долгу. По мере роста долга растут и время, и усилия, затрачиваемые на погашение этих процентов. Чем медленнее общая скорость разработки, тем меньше новых функций будет поставлено клиентам.
Человеческая стоимость
Компании конкурируют за лучшие технические таланты. Трудоустройство нового сотрудника может стоить от шести до девяти его зарплат. Потому компаний уделяют особое внимание опыту адаптации разработчиков.
Адаптация — первая и самая важная часть опыта сотрудника в компании. Чтобы освоиться новому сотруднику может потребоваться до двух месяцев. Неудачный опыт адаптации может отпугнуть разработчика. 20% уходят в течение первых 45 дней. Т.е. плавный процесс адаптации может означать разницу между получением хорошего специалиста и новым поиском.
Время адаптации разработчика будет зависеть как от имеющейся документации и налаженных процессов, так и от сложности и читаемости кода. Отсутствие документации тоже форма долга. Вы знаете, что в какой-то момент она вам понадобится, но, чтобы двигаться быстрее, вы не стали её писать. Новым сотрудникам придётся расспрашивать и тратить время старших инженеров, чтобы адаптироваться.
Новый разработчик может разочароваться, увидев методы написания кода, принятые в команде, которые затрудняют анализ кода. Это расстраивает и деморализует, поскольку вы постоянно тратите время, пытаясь понять, что происходит в коде.
Очевидно, техдолг — не просто код, который требует рефакторинга для соответствия лучшим практикам: устаревшие или неэффективные инструменты и зависимости тоже считаются. В опросе StackOverflow о том, почему разработчики решают остаться на работе или уйти 35-40% сказали, что ищут новую работу, чтобы использовать новые технологии.
Т.е., если ваша компания страдает от частых уходов людей в течение первого года, то возможно проблема в техдолге. Проводите выходные интервью и отслеживайте отзывы. Если долг стоит вам хороших сотрудников, это веская причина пересмотреть приоритеты в следующем спринте.
Источник: https://stackoverflow.blog/2023/08/24/if-you-want-to-address-tech-debt-quantify-it-first/
👍14
День 1849. #ProjectManagement
Отслеживаем Архитектурные Решения через ADR
При проектировании архитектуры системы у вас есть много вариантов выбора. Вы архитектор, делаете некоторый выбор, всё идёт хорошо несколько месяцев. И вдруг появляется новое требование. Оно заставляет задуматься: «Правильна ли эта архитектура? Стоит ли что-то менять?». Вы уже не помните причины своего выбора. Нужно что-то, что напоминало бы вам, почему вы сделали тот или иной выбор…
Реестр Архитектурных Решений (Architecture Decision Records, ADR) — это способ описания, отслеживания и обсуждения архитектурных и проектных решений. Он позволяет иметь чётко определённый процесс принятия обоснованных решений и отслеживать причины вашего выбора.
Структура
ADR — это не просто список решений. Это документ, в котором также отслеживается текущий контекст, рассматриваемые альтернативы и последствия окончательного выбора. ADR состоит из набора файлов, каждый из которых описывает решение.
1. Суть решения
Например, «Использовать Azure Service Bus для очередей».
2. Статус
Например, «На обсуждении», «Принято» и «Заменено».
3. Время принятия решения
Когда ADR создан и когда получал каждый статус.
4. Контекст
Например: «В настоящее время мы используем Azure в качестве основного поставщика».
5. Последствия
Например: «Мы согласны с привязкой к поставщику. Так будет легче получить поддержку со стороны команды по инфраструктуре».
Статусы
Обычно должен быть строгий набор статусов, гарантирующий, что после достижения одного из окончательных статусов решение в ADR не может быть изменено.
Первичные
- Черновик: первичное описание решения, вы пока не готовы его обсуждать.
- Предложение: объяснены все детали решения для официального обсуждения.
- Открыто: каждый может добавлять комментарии к решению, что позволит учесть другие точки зрения и указать слабые места.
Окончательные
- Принято: команда согласна с решением, и теперь можно его реализовать.
- Отклонено: решение неосуществимо, реализация невозможна.
- Устарело: решение больше не является полезным или необходимым.
- Заменено: другой ADR заменяет нынешний. Обязательно нужно указать номер нового ADR, а в новом сослаться на тот, который он заменяет. Так можно восстановить историю конкретного выбора.
Рекомендации
1. Используйте единый формат и структуру для каждого ADR.
2. Храните ADR в текстовом файле рядом с кодом, соответствующим этому решению, или в центральном репозитории, чтобы можно было просмотреть историю обновлений.
3. Используйте понятное и описательное имя файла, например ADR-001-use-azure-service-bus.md.
4. Делайте ADR кратким и сосредоточенными на одном решении. Добавляйте только необходимую информацию, чтобы понять причину решения.
5. Обновляйте ADR по мере развития или изменения решения, указывая причину изменений.
6. Периодически проверяйте актуальность ADR текущему состоянию архитектуры и потребностям бизнеса.
Вот хороший список шаблонов ADR.
Инструменты
- adr-cli - инструмент CLI, написанный на .NET, который автоматически создаёт и управляет историей ваших ADR.
- ADR Manager - UI инструмент, который подключается к вашему репозиторию GitHub и генерирует файлы ADR.
Итого
ADR — отличный инструмент, особенно для проектов, требования которых не определены заранее и которые, как ожидается, будут иметь длительный срок службы. Одним из наиболее важных этапов принятия архитектурных решений является обсуждение решения. Архитектор не должен навязывать архитектуру команде. Другие заинтересованные стороны, например разработчики, могут иметь некоторые опасения или заметить случай, который не может быть охвачен решением.
Источник: https://www.code4it.dev/architecture-notes/architecture-decision-records/
Отслеживаем Архитектурные Решения через ADR
При проектировании архитектуры системы у вас есть много вариантов выбора. Вы архитектор, делаете некоторый выбор, всё идёт хорошо несколько месяцев. И вдруг появляется новое требование. Оно заставляет задуматься: «Правильна ли эта архитектура? Стоит ли что-то менять?». Вы уже не помните причины своего выбора. Нужно что-то, что напоминало бы вам, почему вы сделали тот или иной выбор…
Реестр Архитектурных Решений (Architecture Decision Records, ADR) — это способ описания, отслеживания и обсуждения архитектурных и проектных решений. Он позволяет иметь чётко определённый процесс принятия обоснованных решений и отслеживать причины вашего выбора.
Структура
ADR — это не просто список решений. Это документ, в котором также отслеживается текущий контекст, рассматриваемые альтернативы и последствия окончательного выбора. ADR состоит из набора файлов, каждый из которых описывает решение.
1. Суть решения
Например, «Использовать Azure Service Bus для очередей».
2. Статус
Например, «На обсуждении», «Принято» и «Заменено».
3. Время принятия решения
Когда ADR создан и когда получал каждый статус.
4. Контекст
Например: «В настоящее время мы используем Azure в качестве основного поставщика».
5. Последствия
Например: «Мы согласны с привязкой к поставщику. Так будет легче получить поддержку со стороны команды по инфраструктуре».
Статусы
Обычно должен быть строгий набор статусов, гарантирующий, что после достижения одного из окончательных статусов решение в ADR не может быть изменено.
Первичные
- Черновик: первичное описание решения, вы пока не готовы его обсуждать.
- Предложение: объяснены все детали решения для официального обсуждения.
- Открыто: каждый может добавлять комментарии к решению, что позволит учесть другие точки зрения и указать слабые места.
Окончательные
- Принято: команда согласна с решением, и теперь можно его реализовать.
- Отклонено: решение неосуществимо, реализация невозможна.
- Устарело: решение больше не является полезным или необходимым.
- Заменено: другой ADR заменяет нынешний. Обязательно нужно указать номер нового ADR, а в новом сослаться на тот, который он заменяет. Так можно восстановить историю конкретного выбора.
Рекомендации
1. Используйте единый формат и структуру для каждого ADR.
2. Храните ADR в текстовом файле рядом с кодом, соответствующим этому решению, или в центральном репозитории, чтобы можно было просмотреть историю обновлений.
3. Используйте понятное и описательное имя файла, например ADR-001-use-azure-service-bus.md.
4. Делайте ADR кратким и сосредоточенными на одном решении. Добавляйте только необходимую информацию, чтобы понять причину решения.
5. Обновляйте ADR по мере развития или изменения решения, указывая причину изменений.
6. Периодически проверяйте актуальность ADR текущему состоянию архитектуры и потребностям бизнеса.
Вот хороший список шаблонов ADR.
Инструменты
- adr-cli - инструмент CLI, написанный на .NET, который автоматически создаёт и управляет историей ваших ADR.
- ADR Manager - UI инструмент, который подключается к вашему репозиторию GitHub и генерирует файлы ADR.
Итого
ADR — отличный инструмент, особенно для проектов, требования которых не определены заранее и которые, как ожидается, будут иметь длительный срок службы. Одним из наиболее важных этапов принятия архитектурных решений является обсуждение решения. Архитектор не должен навязывать архитектуру команде. Другие заинтересованные стороны, например разработчики, могут иметь некоторые опасения или заметить случай, который не может быть охвачен решением.
Источник: https://www.code4it.dev/architecture-notes/architecture-decision-records/
👍13👎1
День 1888. #ProjectManagement
Что Такое SLI, SLO и SLA
При проектировании архитектуры ПО мы должны учитывать как функциональные, так и нефункциональные требования. Сегодня разберём SLO, SLA и SLI и как они влияют на жизненный цикл ПО.
1. Индикатор уровня обслуживания (Service Level Indicator - SLI)
Измеримая мера некоторого аспекта уровня предоставляемого обслуживания: процент времени безотказной работы, время ответа или частота сообщений об ошибках. SLI используются для объективного измерения производительности сервиса и для проверки SLO.
Как отслеживать?
- Тщательно определите проверяемые метрики. Например «ошибки HTTP» - недостаточно чётко. Какие именно? 404, 401 и 500 — обозначают ошибки, но их появление может как указывать, так и не указывать на ошибки в системе.
- Определите функции для проверки качества релизов, чтобы гарантировать, что новый релиз не ухудшит существующие значения SLI.
2. Целевой уровень обслуживания (Service Level Objective - SLO)
Целевой уровень обслуживания между поставщиком услуг и конечным пользователем, который измеряется конкретными показателями. Если SLI —фактическое значение измерения, SLO — конечная цель, которую необходимо достичь для этого SLI. SLO - желаемая цель для некоторых показателей (обычно производительности и надёжности), которых стремится достичь сервис. Вы можете указать значение SLO для каждой метрики, которая важна для вас и ваших клиентов. Например:
- 99% запросов к веб-сервису должны иметь задержку менее 300 мс;
- 99,9% запросов к определённой конечной точке должны иметь задержку менее 100 мс;
- 99,9% запросов должны возвращать успешный код состояния.
SLO являются конкретными, подробными и измеримыми. Например, заявление: «Запросы, как правило, должны быть быстрыми» - слишком расплывчато, и его невозможно измерить.
Как отслеживать?
- Создайте информационную панель для измерения каждого из определённых вами SLO.
- Отправляйте оповещения, если значение достигает порога.
- Спроектируйте архитектуру с учётом значений SLO: например, если необходимо обеспечить низкую задержку для запросов, можно спроектировать асинхронную связь между сервисами или решить развернуть приложение близко к местоположению пользователей.
3. Соглашение об уровне обслуживания (Service Level Agreement - SLA)
Официальное соглашение между поставщиком услуг и клиентом. В отличие от SLO, SLA имеют юридическую силу и предусматривают последствия несоблюдения. Если продукт не соответствует SLA, это может вести к штрафам, неустойкам и т.п. Примером SLA является скорость реагирования техподдержки, например, закрывать открытую клиентом заявку в течение 24 часов.
Взаимодействие между SLO, SLA и SLI существенно влияет на решения по архитектуре ПО:
- SLO и SLI помогают архитекторам определить показатели надёжности и производительности, которым должна соответствовать система. Это влияет на выбор технологий и шаблонов, позволяющих достичь этих показателей. Микросервис или монолит? С# или Rust? Локально или в облаке?
- Для соблюдения требований SLO системе может потребоваться обрабатывать большое количество запросов в секунду, что требует масштабируемых архитектур, таких как микросервисы или бессерверные вычисления.
- Необходимость соблюдения SLA может привести к внедрению механизмов резервирования и аварийного переключения для обеспечения высокой доступности и минимизации времени простоя.
- SLI требуют надёжных систем мониторинга и оповещения для отслеживания производительности услуги в режиме реального времени и уведомления, когда SLO подвергаются риску нарушения.
- Необходимость удовлетворять SLO может влиять на распределение ресурсов, что приводит к принятию решений о балансировке нагрузки, сегментировании базы данных или использовании сетей доставки контента (CDN).
- Штрафы, связанные с SLA, могут повлиять на стоимость, побуждая архитектуру быть более экономичной, при этом соответствуя уровням обслуживания.
Источник: https://www.code4it.dev/architecture-notes/sli-vs-slo-vs-sla/
Что Такое SLI, SLO и SLA
При проектировании архитектуры ПО мы должны учитывать как функциональные, так и нефункциональные требования. Сегодня разберём SLO, SLA и SLI и как они влияют на жизненный цикл ПО.
1. Индикатор уровня обслуживания (Service Level Indicator - SLI)
Измеримая мера некоторого аспекта уровня предоставляемого обслуживания: процент времени безотказной работы, время ответа или частота сообщений об ошибках. SLI используются для объективного измерения производительности сервиса и для проверки SLO.
Как отслеживать?
- Тщательно определите проверяемые метрики. Например «ошибки HTTP» - недостаточно чётко. Какие именно? 404, 401 и 500 — обозначают ошибки, но их появление может как указывать, так и не указывать на ошибки в системе.
- Определите функции для проверки качества релизов, чтобы гарантировать, что новый релиз не ухудшит существующие значения SLI.
2. Целевой уровень обслуживания (Service Level Objective - SLO)
Целевой уровень обслуживания между поставщиком услуг и конечным пользователем, который измеряется конкретными показателями. Если SLI —фактическое значение измерения, SLO — конечная цель, которую необходимо достичь для этого SLI. SLO - желаемая цель для некоторых показателей (обычно производительности и надёжности), которых стремится достичь сервис. Вы можете указать значение SLO для каждой метрики, которая важна для вас и ваших клиентов. Например:
- 99% запросов к веб-сервису должны иметь задержку менее 300 мс;
- 99,9% запросов к определённой конечной точке должны иметь задержку менее 100 мс;
- 99,9% запросов должны возвращать успешный код состояния.
SLO являются конкретными, подробными и измеримыми. Например, заявление: «Запросы, как правило, должны быть быстрыми» - слишком расплывчато, и его невозможно измерить.
Как отслеживать?
- Создайте информационную панель для измерения каждого из определённых вами SLO.
- Отправляйте оповещения, если значение достигает порога.
- Спроектируйте архитектуру с учётом значений SLO: например, если необходимо обеспечить низкую задержку для запросов, можно спроектировать асинхронную связь между сервисами или решить развернуть приложение близко к местоположению пользователей.
3. Соглашение об уровне обслуживания (Service Level Agreement - SLA)
Официальное соглашение между поставщиком услуг и клиентом. В отличие от SLO, SLA имеют юридическую силу и предусматривают последствия несоблюдения. Если продукт не соответствует SLA, это может вести к штрафам, неустойкам и т.п. Примером SLA является скорость реагирования техподдержки, например, закрывать открытую клиентом заявку в течение 24 часов.
Взаимодействие между SLO, SLA и SLI существенно влияет на решения по архитектуре ПО:
- SLO и SLI помогают архитекторам определить показатели надёжности и производительности, которым должна соответствовать система. Это влияет на выбор технологий и шаблонов, позволяющих достичь этих показателей. Микросервис или монолит? С# или Rust? Локально или в облаке?
- Для соблюдения требований SLO системе может потребоваться обрабатывать большое количество запросов в секунду, что требует масштабируемых архитектур, таких как микросервисы или бессерверные вычисления.
- Необходимость соблюдения SLA может привести к внедрению механизмов резервирования и аварийного переключения для обеспечения высокой доступности и минимизации времени простоя.
- SLI требуют надёжных систем мониторинга и оповещения для отслеживания производительности услуги в режиме реального времени и уведомления, когда SLO подвергаются риску нарушения.
- Необходимость удовлетворять SLO может влиять на распределение ресурсов, что приводит к принятию решений о балансировке нагрузки, сегментировании базы данных или использовании сетей доставки контента (CDN).
- Штрафы, связанные с SLA, могут повлиять на стоимость, побуждая архитектуру быть более экономичной, при этом соответствуя уровням обслуживания.
Источник: https://www.code4it.dev/architecture-notes/sli-vs-slo-vs-sla/
👍13
День 1981. #ProjectManagement
Настоящий 10х-Разработчик Делает Всю Команду Лучше
Все знакомы с концепцией 10х-инженера: «занудного, асоциального гения, который создаёт новаторские продукты почти случайно». Суперразработчик, который в десять раз умнее и продуктивнее своих коллег, о котором ходят мифы и на которого идут венчурные инвесторы.
Истина в том, что отдельные люди имеют меньшее значение для успеха или провала проекта, чем вы думаете (и это хорошо, иначе уровень выгорания будет зашкаливать). Гораздо важнее качество сообществ обучения, к которым имеют доступ ваши сотрудники. Вместо инженера, который на порядок «лучше» своих коллег, лидеры должны искать людей, которые хотят и способны учиться, а также помогать всей команде учиться и работать.
Успешные инженерные организации требуют сильной культуры общего обучения. Им нужен способ сбора и распространения знаний, одновременно обеспечивающий общение и сотрудничество между командами. Поэтому организациям нужно инвестировать в создание сообществ практиков вокруг своих продуктов, а также инструментов и технологий, которые они используют.
Сообщества практиков — это отдельные группы по интересам: язык программирования, кибербезопасность, ИИ и т.п. С точки зрения бизнеса, такие группы выполняют несколько функций: разрушают разрозненность и поощряют межфункциональное сотрудничество, укрепляя доверие и уверенность среди сотрудников, а также ускоряя инновации. Сообщества позволяют коллегам из разных команд обсуждать конкретные темы, делиться опытом и ресурсами, использовать коллективный опыт для решения проблем и совершенствования. Участники могут раскрыть важный контекст и установить связи, которые они, возможно, не установили бы сами.
Это требует времени и энергии сотрудников. Не отвлекает ли это их от основных должностных обязанностей?
Формирование культуры общего обучения является одной из их основных должностных обязанностей. Это улучшает результаты и отдельных разработчиков, и команд. Сообщества практиков поощряют разработчиков делиться своими ошибками и тем, чему они научились на их основе, чтобы всё сообщество могло извлечь пользу из этих знаний. Это возможность учиться на работе. Недавний опрос Stack Overflow показал, что для половины разработчиков доступ к возможностям обучения способствует их счастью на работе.
Вот некоторые конкретные способы, с помощью которых разработчики (и их менеджеры) могут построить культуру общего обучения:
- Если вы менеджер или старший сотрудник, подавайте пример, уделяя приоритетное внимание собственному обучению. Как бы вы ни были заняты, старайтесь уделять регулярное время изучению и отработке новых навыков. Сообщайте подчинённым, что вы делали и что вы узнали, чтобы они осознали, что постоянное обучение приветствуется в организации.
- Убедитесь, что сотрудники уделяют время обучению. Предоставьте командам возможность выделять время для обучения. Иначе им придётся посвящать личное время обучению, а не делать обучение неотъемлемой частью вашей организационной культуры и повседневной работы.
- Делитесь ошибками с коллегами. Любая ошибка — это возможность учиться — не только для того, кто допустил ошибку, но и для остальных участников проекта. А когда старшие разработчики и менеджеры бесстрашно признают свои ошибки, перспектива становится менее пугающей для младших разработчиков.
- Предоставьте учебные ресурсы. Это ключ к развитию культуры обучения.
Блестящие, одаренные люди играют важную роль в командах разработчиков, но ожидать, что кто-то будет 10х-разработчиком — или ожидать этого от себя — контрпродуктивно. Заставить себя ускориться в 10 раз — надёжный рецепт выгорания. Сообщества практиков, основанные на культуре общего обучения, приводят к созданию высокопроизводительных команд, не возлагая всю ответственность на одного мифического 10х-разработчика.
Источник: https://stackoverflow.blog/2024/06/19/the-real-10x-developer-makes-their-whole-team-better/
Настоящий 10х-Разработчик Делает Всю Команду Лучше
Все знакомы с концепцией 10х-инженера: «занудного, асоциального гения, который создаёт новаторские продукты почти случайно». Суперразработчик, который в десять раз умнее и продуктивнее своих коллег, о котором ходят мифы и на которого идут венчурные инвесторы.
Истина в том, что отдельные люди имеют меньшее значение для успеха или провала проекта, чем вы думаете (и это хорошо, иначе уровень выгорания будет зашкаливать). Гораздо важнее качество сообществ обучения, к которым имеют доступ ваши сотрудники. Вместо инженера, который на порядок «лучше» своих коллег, лидеры должны искать людей, которые хотят и способны учиться, а также помогать всей команде учиться и работать.
Успешные инженерные организации требуют сильной культуры общего обучения. Им нужен способ сбора и распространения знаний, одновременно обеспечивающий общение и сотрудничество между командами. Поэтому организациям нужно инвестировать в создание сообществ практиков вокруг своих продуктов, а также инструментов и технологий, которые они используют.
Сообщества практиков — это отдельные группы по интересам: язык программирования, кибербезопасность, ИИ и т.п. С точки зрения бизнеса, такие группы выполняют несколько функций: разрушают разрозненность и поощряют межфункциональное сотрудничество, укрепляя доверие и уверенность среди сотрудников, а также ускоряя инновации. Сообщества позволяют коллегам из разных команд обсуждать конкретные темы, делиться опытом и ресурсами, использовать коллективный опыт для решения проблем и совершенствования. Участники могут раскрыть важный контекст и установить связи, которые они, возможно, не установили бы сами.
Это требует времени и энергии сотрудников. Не отвлекает ли это их от основных должностных обязанностей?
Формирование культуры общего обучения является одной из их основных должностных обязанностей. Это улучшает результаты и отдельных разработчиков, и команд. Сообщества практиков поощряют разработчиков делиться своими ошибками и тем, чему они научились на их основе, чтобы всё сообщество могло извлечь пользу из этих знаний. Это возможность учиться на работе. Недавний опрос Stack Overflow показал, что для половины разработчиков доступ к возможностям обучения способствует их счастью на работе.
Вот некоторые конкретные способы, с помощью которых разработчики (и их менеджеры) могут построить культуру общего обучения:
- Если вы менеджер или старший сотрудник, подавайте пример, уделяя приоритетное внимание собственному обучению. Как бы вы ни были заняты, старайтесь уделять регулярное время изучению и отработке новых навыков. Сообщайте подчинённым, что вы делали и что вы узнали, чтобы они осознали, что постоянное обучение приветствуется в организации.
- Убедитесь, что сотрудники уделяют время обучению. Предоставьте командам возможность выделять время для обучения. Иначе им придётся посвящать личное время обучению, а не делать обучение неотъемлемой частью вашей организационной культуры и повседневной работы.
- Делитесь ошибками с коллегами. Любая ошибка — это возможность учиться — не только для того, кто допустил ошибку, но и для остальных участников проекта. А когда старшие разработчики и менеджеры бесстрашно признают свои ошибки, перспектива становится менее пугающей для младших разработчиков.
- Предоставьте учебные ресурсы. Это ключ к развитию культуры обучения.
Блестящие, одаренные люди играют важную роль в командах разработчиков, но ожидать, что кто-то будет 10х-разработчиком — или ожидать этого от себя — контрпродуктивно. Заставить себя ускориться в 10 раз — надёжный рецепт выгорания. Сообщества практиков, основанные на культуре общего обучения, приводят к созданию высокопроизводительных команд, не возлагая всю ответственность на одного мифического 10х-разработчика.
Источник: https://stackoverflow.blog/2024/06/19/the-real-10x-developer-makes-their-whole-team-better/
👍16👎1
День 2201. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Начало
Как определить, что проект на пути к успеху или скатывается? Рассмотрим 10 предупреждающих знаков, которые сигнализируют о том, что вы можете сбиться с пути, и несколько идей, как это исправить.
1. Успех зависит от идеального выполнения плана
Планирование - это хорошо, но все планы неверны. Мы должны оставлять место в любом плане, чтобы исправить неизбежные ошибки по мере их обнаружения. Когда мы планируем, мы знаем о нашем проекте меньше всего. Даже если план идеален, внешние факторы изменятся и сделают его не идеальным. В краткосрочной перспективе наши планы могут быть довольно точными, потому что есть небольшой диапазон для вариаций. Но чем дальше мы планируем, тем менее определённо можем судить.
Красные флаги
- Мы вынуждены рассматривать и сроки, и объём работ как фиксированные.
- План включает некоторую подробно описанную работу далеко в будущем.
Что делать?
- Рассматривайте долгосрочные планы как результаты, особенности или пользовательские истории.
- Отслеживайте прогресс и чаще пересматривайте план, т.к. мы узнаём больше по ходу работы. Цель в том, чтобы делать подробные описания работ только внутри команды разработчиков, но не включать их как часть большого плана. Так вы сможете легче корректировать вещи, вы меньше привязаны к деталям какого-то будущего воображаемого способа реализации.
- Разделяйте план на планирование результатов и планирование работы. Если план охватывает обе части – это красный флаг. Это приводит к поведению, вроде «арбузного статуса»: зелёный снаружи, но красный в середине. Мы сообщаем зелёные части руководству, но на самом деле заняты срезанием углов, чтобы уложиться в искусственные сроки, установленные планом. А также тратим время и усилия на то, чтобы разобраться с беспорядком, которой создали, срезая углы в прошлый раз.
- Никогда не пытайтесь уложиться и в жёсткий график, и в жёсткий объём работ. Это нереально. Если невозможно сдвинуть сроки, дайте свободу команде разработчиков для сокращения объёма, чтобы уложиться в них.
Либо зафиксируйте объём, но позвольте команде определить даты релиза, когда целевой объём будет реализован.
- Составляйте любой план работы, которая выходит за рамки одной итерации или спринта только на уровне результатов. Не пытайтесь спланировать работу, необходимую для достижения этих результатов. Позволяйте людям, выполняющим работу, выяснить, что делать для достижения целей.
2. Слишком много людей, решающих проблему
Как сказал Фред Брукс в 1970-х: «9 женщин не родят ребенка за 1 месяц». Увеличение количества разработчиков замедляет проект, добавляет сложности и почти никогда не помогают двигаться быстрее. Масштабирование – это децентрализация принятия решений, разделение работы на более мелкие автономные команды, а не добавление людей. Добавление людей обычно происходит, когда менеджеры начинают паниковать из-за пропущенных сроков или нереалистичных ожиданий масштаба проекта.
Красный флаг
- Руководство внезапно нанимает кучу разработчиков в спешке, чтобы выполнить какой-то нереальный план.
Что делать?
- Решить, что важнее: время или объём работы, - и оптимизировать разработку под это. Если необходим фиксированный объём, стоило бы усомниться в этом с самого начала, т.к. это редко бывает правдой. Объём, который мы думаем, что нам нужен в начале проекта, почти наверняка будет неверным. Мы упустим вещи, которые узнаем по ходу, мир вокруг изменится, пока мы работаем над проектом. На самом деле, если вы не меняете своё мнение об объёме работ по мере продвижения проекта, вы почти наверняка что-то делаете неправильно.
- Расставьте приоритеты в функциональности, которая наиболее важна для ваших пользователей, а затем выпустите её как можно раньше. Так что, даже если список требуемой функциональности в начале проекта не полный, самая главная функциональность, которую от вас ждут, будет доступна пользователям.
Продолжение следует…
Источник: https://youtu.be/-6KHhwEMtqs
10 Признаков Того, Что Проект на Пути к Провалу. Начало
Как определить, что проект на пути к успеху или скатывается? Рассмотрим 10 предупреждающих знаков, которые сигнализируют о том, что вы можете сбиться с пути, и несколько идей, как это исправить.
1. Успех зависит от идеального выполнения плана
Планирование - это хорошо, но все планы неверны. Мы должны оставлять место в любом плане, чтобы исправить неизбежные ошибки по мере их обнаружения. Когда мы планируем, мы знаем о нашем проекте меньше всего. Даже если план идеален, внешние факторы изменятся и сделают его не идеальным. В краткосрочной перспективе наши планы могут быть довольно точными, потому что есть небольшой диапазон для вариаций. Но чем дальше мы планируем, тем менее определённо можем судить.
Красные флаги
- Мы вынуждены рассматривать и сроки, и объём работ как фиксированные.
- План включает некоторую подробно описанную работу далеко в будущем.
Что делать?
- Рассматривайте долгосрочные планы как результаты, особенности или пользовательские истории.
- Отслеживайте прогресс и чаще пересматривайте план, т.к. мы узнаём больше по ходу работы. Цель в том, чтобы делать подробные описания работ только внутри команды разработчиков, но не включать их как часть большого плана. Так вы сможете легче корректировать вещи, вы меньше привязаны к деталям какого-то будущего воображаемого способа реализации.
- Разделяйте план на планирование результатов и планирование работы. Если план охватывает обе части – это красный флаг. Это приводит к поведению, вроде «арбузного статуса»: зелёный снаружи, но красный в середине. Мы сообщаем зелёные части руководству, но на самом деле заняты срезанием углов, чтобы уложиться в искусственные сроки, установленные планом. А также тратим время и усилия на то, чтобы разобраться с беспорядком, которой создали, срезая углы в прошлый раз.
- Никогда не пытайтесь уложиться и в жёсткий график, и в жёсткий объём работ. Это нереально. Если невозможно сдвинуть сроки, дайте свободу команде разработчиков для сокращения объёма, чтобы уложиться в них.
Либо зафиксируйте объём, но позвольте команде определить даты релиза, когда целевой объём будет реализован.
- Составляйте любой план работы, которая выходит за рамки одной итерации или спринта только на уровне результатов. Не пытайтесь спланировать работу, необходимую для достижения этих результатов. Позволяйте людям, выполняющим работу, выяснить, что делать для достижения целей.
2. Слишком много людей, решающих проблему
Как сказал Фред Брукс в 1970-х: «9 женщин не родят ребенка за 1 месяц». Увеличение количества разработчиков замедляет проект, добавляет сложности и почти никогда не помогают двигаться быстрее. Масштабирование – это децентрализация принятия решений, разделение работы на более мелкие автономные команды, а не добавление людей. Добавление людей обычно происходит, когда менеджеры начинают паниковать из-за пропущенных сроков или нереалистичных ожиданий масштаба проекта.
Красный флаг
- Руководство внезапно нанимает кучу разработчиков в спешке, чтобы выполнить какой-то нереальный план.
Что делать?
- Решить, что важнее: время или объём работы, - и оптимизировать разработку под это. Если необходим фиксированный объём, стоило бы усомниться в этом с самого начала, т.к. это редко бывает правдой. Объём, который мы думаем, что нам нужен в начале проекта, почти наверняка будет неверным. Мы упустим вещи, которые узнаем по ходу, мир вокруг изменится, пока мы работаем над проектом. На самом деле, если вы не меняете своё мнение об объёме работ по мере продвижения проекта, вы почти наверняка что-то делаете неправильно.
- Расставьте приоритеты в функциональности, которая наиболее важна для ваших пользователей, а затем выпустите её как можно раньше. Так что, даже если список требуемой функциональности в начале проекта не полный, самая главная функциональность, которую от вас ждут, будет доступна пользователям.
Продолжение следует…
Источник: https://youtu.be/-6KHhwEMtqs
👍17
День 2202. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Продолжение
Начало
3. Фокус на процессе вместо результатов
Наша цель — поставить пользователям хорошее работающее ПО и постоянно поддерживать способность делать это. Не имеет значения, сколько историй мы поставляем в спринте, если они не представляют ценности для пользователей. Насколько хорошо наше тестовое покрытие не имеет значения, если у нас всё ещё много ошибок, которые мешают пользователям использовать ПО. Тот факт, что каждая функция имеет аккуратные комментарии, не имеет значения, если наш код все ещё трудно изменять.
Красный флаг
Команды, оцениваемые по тому, сколько стори-пойнтов они поставляют, если при этом никто не проверяет, действительно ли эти функции приносят пользу пользователям.
Что делать?
Измерять реальные результаты:
- Сколько времени требуется для поставки изменений в производство?
- Довольны ли пользователи?
- Минимально ли количество ошибок и быстро ли они устраняются?
Эти вещи сложнее измерить, но они гораздо важнее. Поэтому, если ваш проект измеряется по тому, насколько хорошо вы содействуете какому-то процессу, но вы не можете ответить на вопросы вроде перечисленных выше, это предупреждающий знак, что вы сбиваетесь с пути. Начните измерять вещи, которые действительно имеют значение, а затем принимайте решения на основе результатов этих измерений.
4. Медленное внесение простых изменений
Если простое изменение, вроде создания нового класса, приводит к бюрократическому ужасу согласований, изменений конфигурации и документации, это даже не красный флаг, а пожарная тревога. Высокопроизводительные команды имеют свободу быстро и легко принимать решения, не спрашивая разрешения у кого-либо.
Красный флаг
Чрезмерная бюрократия или отсутствие доверия командам разработчиков в принятии собственных решений.
Что делать?
Предоставить разработчикам автономию для принятия решений по проектированию и реализации, не дожидаясь одобрения на каждом этапе.
5. Моральный дух команд разработчиков
Если команды разработчиков думают, что их система плохая, они обычно правы. Те, кто производит отличное ПО, как правило, знают, что они преуспевают, поэтому если моральный дух команды низкий, это должно быть большим предупреждающим знаком того, что что-то фундаментально не так.
Красный флаг
Разработчики чувствуют себя деморализованными, не заслуживающими доверия или подверженными микроменеджменту, и не рекомендуют своего работодателя друзьям.
Что делать?
Повысить автономность. Мастерство и чётко обозначенная цель позволяют командам принимать ключевые решения, поощрять обучение и гарантировать, что все знают, почему работа, которую они делают, действительно важна.
6. Зависимость от героев
Если судьба проекта зависит от разработчиков-«рок звёзд», это очень серьезный предупреждающий знак.
Красный флаг
Один человек, который является единственным, кто может исправить или понять определённые области кода или определённые практики.
Что делать?
Распространять эти знания. Это можно делать это с помощью таких методов, как парное или групповое программирование, обзоры кода, митапы и т.п.
Окончание следует…
Источник: https://youtu.be/-6KHhwEMtqs
10 Признаков Того, Что Проект на Пути к Провалу. Продолжение
Начало
3. Фокус на процессе вместо результатов
Наша цель — поставить пользователям хорошее работающее ПО и постоянно поддерживать способность делать это. Не имеет значения, сколько историй мы поставляем в спринте, если они не представляют ценности для пользователей. Насколько хорошо наше тестовое покрытие не имеет значения, если у нас всё ещё много ошибок, которые мешают пользователям использовать ПО. Тот факт, что каждая функция имеет аккуратные комментарии, не имеет значения, если наш код все ещё трудно изменять.
Красный флаг
Команды, оцениваемые по тому, сколько стори-пойнтов они поставляют, если при этом никто не проверяет, действительно ли эти функции приносят пользу пользователям.
Что делать?
Измерять реальные результаты:
- Сколько времени требуется для поставки изменений в производство?
- Довольны ли пользователи?
- Минимально ли количество ошибок и быстро ли они устраняются?
Эти вещи сложнее измерить, но они гораздо важнее. Поэтому, если ваш проект измеряется по тому, насколько хорошо вы содействуете какому-то процессу, но вы не можете ответить на вопросы вроде перечисленных выше, это предупреждающий знак, что вы сбиваетесь с пути. Начните измерять вещи, которые действительно имеют значение, а затем принимайте решения на основе результатов этих измерений.
4. Медленное внесение простых изменений
Если простое изменение, вроде создания нового класса, приводит к бюрократическому ужасу согласований, изменений конфигурации и документации, это даже не красный флаг, а пожарная тревога. Высокопроизводительные команды имеют свободу быстро и легко принимать решения, не спрашивая разрешения у кого-либо.
Красный флаг
Чрезмерная бюрократия или отсутствие доверия командам разработчиков в принятии собственных решений.
Что делать?
Предоставить разработчикам автономию для принятия решений по проектированию и реализации, не дожидаясь одобрения на каждом этапе.
5. Моральный дух команд разработчиков
Если команды разработчиков думают, что их система плохая, они обычно правы. Те, кто производит отличное ПО, как правило, знают, что они преуспевают, поэтому если моральный дух команды низкий, это должно быть большим предупреждающим знаком того, что что-то фундаментально не так.
Красный флаг
Разработчики чувствуют себя деморализованными, не заслуживающими доверия или подверженными микроменеджменту, и не рекомендуют своего работодателя друзьям.
Что делать?
Повысить автономность. Мастерство и чётко обозначенная цель позволяют командам принимать ключевые решения, поощрять обучение и гарантировать, что все знают, почему работа, которую они делают, действительно важна.
6. Зависимость от героев
Если судьба проекта зависит от разработчиков-«рок звёзд», это очень серьезный предупреждающий знак.
Красный флаг
Один человек, который является единственным, кто может исправить или понять определённые области кода или определённые практики.
Что делать?
Распространять эти знания. Это можно делать это с помощью таких методов, как парное или групповое программирование, обзоры кода, митапы и т.п.
Окончание следует…
Источник: https://youtu.be/-6KHhwEMtqs
👍8
День 2203. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Окончание
Начало
Продолжение
7. Низкие баллы по метрикам DORA
Метрики DevOps Research and Assessment (DORA) измеряют стабильность и пропускную способность, т.е. качество ПО, которое мы производим, и эффективность, с которой мы можем создавать ПО такого качества. Если у вас низкие баллы по обоим метрикам, то вы поставляете некачественное ПО и делаете это медленно. Это почти гарантированный путь к провалу.
Красные флаги
- низкая частота развертывания,
- большие сроки выполнения,
- высокая частота отказов,
- большое время восстановления после сбоев.
Что делать?
Начать внедрять такие методы, как непрерывная интеграция, автоматизированное тестирование, частые релизы и быстрые откаты или исправления для повышения скорости и качества циклов обратной связи и раннего обнаружения проблем.
8. Достижение прогресса большими шагами
Большие многомесячные планы уменьшают ваши возможности учиться и адаптироваться. Лучшая альтернатива – рассматривать разработку как постоянный цикл экспериментов и открытий, а не пытаться найти и затем воплотить в каком-то плане то, что, по вашему мнению, является лучшими идеями. Гораздо эффективнее предположить, что ваши идеи в начале проекта неправильны, поэтому продумайте, что делать, если ваши идеи потерпят неудачу. Также создавайте системы так, чтобы их было легко изменить, чтобы вы могли исправить ошибки, когда вы их обнаружите.
Красный флаг
Обычно виден как функции, запланированные далеко на будущее и не выпущенные или не протестированные в течение месяцев или лет.
Что делать?
Работать небольшими итерациями. Выпускать чаще и получать быструю обратную связь от реальных пользователей. Если вы обнаружите, что ваша команда работает над подробными планами работы, которая будет выполнена через несколько месяцев, или функциями, которые не будут выпущены в течение недель, месяцев или даже лет, это большой предупреждающий знак. Выясните, как оптимизировать ваш процесс разработки, чтобы вы могли выпускать функциональность в любое время. Быстрая обратная связь и другие методы непрерывной доставки, позволяют работать более размеренно, развивая ПО пошагово. Это даёт больше возможностей для обучения и корректировки курса, когда мы обнаруживаем ошибку.
9. Плохая или отсутствующая обратная связь
Хорошие короткие циклы обратной связи позволяют направлять наши проекты к успеху. Если мы не знаем, работают ли наши новые функции для пользователей, то мы двигаемся вслепую.
Красные флаги
- Редкая или отсутствующая обратная связь от пользователей.
- Отсутствие автоматизированных проверок.
Что делать?
Сократить циклы обратной связи на каждом уровне. Автоматизированная сборка обратной связи от пользователей, непрерывная интеграция и частые выпуски - всё это инструменты, которые помогают нам достичь этого.
10. Разработка неправильной вещи
Это может показаться очевидной ошибкой, которую никто никогда не сделает, но на самом деле это чрезвычайно распространено. В своём исследовании Microsoft обнаружили, что 2/3 их идей дали нулевой или отрицательный выхлоп. Оценки того, как часто функции, которые мы производим как отрасль, вообще никогда не используются, варьируются от 40 до 90%. Поэтому создание неправильных вещей, по крайней мере, так же, а то и более распространено, чем создание вещей, которые люди хотят.
Красные флаги
- Отсутствие пользователей и обратной связи.
- Отсутствие отчётов об ошибках, хотя мы знаем, что наше ПО работает неверно.
Что делать?
Вовлекать реальных пользователей в процесс разработки, либо набирать тестовых пользователей, которые могут давать вам предложения и отзывы по мере создания ПО. Либо более частый выпуск ПО в производство и наблюдение за ним, чтобы определить, как оно используется и какие части игнорируются.
Источник: https://youtu.be/-6KHhwEMtqs
10 Признаков Того, Что Проект на Пути к Провалу. Окончание
Начало
Продолжение
7. Низкие баллы по метрикам DORA
Метрики DevOps Research and Assessment (DORA) измеряют стабильность и пропускную способность, т.е. качество ПО, которое мы производим, и эффективность, с которой мы можем создавать ПО такого качества. Если у вас низкие баллы по обоим метрикам, то вы поставляете некачественное ПО и делаете это медленно. Это почти гарантированный путь к провалу.
Красные флаги
- низкая частота развертывания,
- большие сроки выполнения,
- высокая частота отказов,
- большое время восстановления после сбоев.
Что делать?
Начать внедрять такие методы, как непрерывная интеграция, автоматизированное тестирование, частые релизы и быстрые откаты или исправления для повышения скорости и качества циклов обратной связи и раннего обнаружения проблем.
8. Достижение прогресса большими шагами
Большие многомесячные планы уменьшают ваши возможности учиться и адаптироваться. Лучшая альтернатива – рассматривать разработку как постоянный цикл экспериментов и открытий, а не пытаться найти и затем воплотить в каком-то плане то, что, по вашему мнению, является лучшими идеями. Гораздо эффективнее предположить, что ваши идеи в начале проекта неправильны, поэтому продумайте, что делать, если ваши идеи потерпят неудачу. Также создавайте системы так, чтобы их было легко изменить, чтобы вы могли исправить ошибки, когда вы их обнаружите.
Красный флаг
Обычно виден как функции, запланированные далеко на будущее и не выпущенные или не протестированные в течение месяцев или лет.
Что делать?
Работать небольшими итерациями. Выпускать чаще и получать быструю обратную связь от реальных пользователей. Если вы обнаружите, что ваша команда работает над подробными планами работы, которая будет выполнена через несколько месяцев, или функциями, которые не будут выпущены в течение недель, месяцев или даже лет, это большой предупреждающий знак. Выясните, как оптимизировать ваш процесс разработки, чтобы вы могли выпускать функциональность в любое время. Быстрая обратная связь и другие методы непрерывной доставки, позволяют работать более размеренно, развивая ПО пошагово. Это даёт больше возможностей для обучения и корректировки курса, когда мы обнаруживаем ошибку.
9. Плохая или отсутствующая обратная связь
Хорошие короткие циклы обратной связи позволяют направлять наши проекты к успеху. Если мы не знаем, работают ли наши новые функции для пользователей, то мы двигаемся вслепую.
Красные флаги
- Редкая или отсутствующая обратная связь от пользователей.
- Отсутствие автоматизированных проверок.
Что делать?
Сократить циклы обратной связи на каждом уровне. Автоматизированная сборка обратной связи от пользователей, непрерывная интеграция и частые выпуски - всё это инструменты, которые помогают нам достичь этого.
10. Разработка неправильной вещи
Это может показаться очевидной ошибкой, которую никто никогда не сделает, но на самом деле это чрезвычайно распространено. В своём исследовании Microsoft обнаружили, что 2/3 их идей дали нулевой или отрицательный выхлоп. Оценки того, как часто функции, которые мы производим как отрасль, вообще никогда не используются, варьируются от 40 до 90%. Поэтому создание неправильных вещей, по крайней мере, так же, а то и более распространено, чем создание вещей, которые люди хотят.
Красные флаги
- Отсутствие пользователей и обратной связи.
- Отсутствие отчётов об ошибках, хотя мы знаем, что наше ПО работает неверно.
Что делать?
Вовлекать реальных пользователей в процесс разработки, либо набирать тестовых пользователей, которые могут давать вам предложения и отзывы по мере создания ПО. Либо более частый выпуск ПО в производство и наблюдение за ним, чтобы определить, как оно используется и какие части игнорируются.
Источник: https://youtu.be/-6KHhwEMtqs
👍6
День 2366. #ProjectManagement
Измеряем Продуктивность Разработчиков. Начало
В мире разработки ПО измерение продуктивности остаётся одним из самых сложных, но в то же время критически важных аспектов управления командами разработчиков. В то время как другие бизнес-функции часто можно оценить с помощью простых метрик, разработка ПО представляет собой уникальную задачу из-за своей командной, сложной и творческой природы.
Организации в любой отрасли всё больше зависят от ПО, поэтому руководителям нужны надёжные способы оценки эффективности работы их команд разработчиков. Но остаётся вопрос: какие метрики действительно важны, а какие могут принести больше вреда, чем пользы?
Проблема измерения продуктивности
Измерение производительности труда разработчиков - сложная задача по нескольким причинам:
- Разработка ПО предполагает творческое решение задач, которое сложно выразить количественными показателями;
- Связь между входными и выходными данными значительно менее очевидна, чем в других бизнес-функциях;
- Разработка в значительной степени предполагает совместную работу, что затрудняет оценку индивидуального вклада;
- Различные уровни работы (системы, команды, отдельные лица) требуют разных подходов к измерению.
Как заметил один из руководителей инженерных отделов Microsoft: «Многие специалисты в сфере технологий давно убеждены, что невозможно правильно измерить производительность труда разработчиков и что только квалифицированные инженеры обладают достаточными знаниями, чтобы оценить работу своих коллег».
Однако по мере роста команд разработки и увеличения инвестиций организаций в инженерных специалистов подход «мы не можем это измерить» становится всё более несостоятельным.
Метрики, которые не работают (и почему)
Прежде чем углубляться в практические подходы к измерению, давайте рассмотрим некоторые распространённые, но проблемные метрики.
1. Строки кода (KLOC)
Хотя их легко измерить, строки кода — самый известный пример метрики тщеславия. Больше кода не обязательно означает лучше, и эта метрика может активно поощрять неэффективные практики:
- Поощряет многословный, неэффективный код;
- Игнорирует качество и поддерживаемость кода;
- Сильно варьируется в зависимости от языка программирования;
- Легко поддаётся манипуляциям.
2. Количество коммитов
Как и количество строк кода, измерение чистого количества коммитов мало что даёт знать о фактической производительности:
- Разработчики могут чаще вносить незначительные изменения, чтобы «обмануть» систему;
- Не отражает качество или ценность изменений;
- Игнорирует разницу в сложности между коммитами.
3. Отработанные часы
Время, затраченное на кодирование, не обязательно коррелирует с полученной ценностью:
- Поощряет презентеизм (видимость присутствия на работе), а не эффективность;
- Игнорирует качество выполненной работы;
- Может привести к выгоранию и снижению долгосрочной производительности.
Продолжение следует…
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
Измеряем Продуктивность Разработчиков. Начало
В мире разработки ПО измерение продуктивности остаётся одним из самых сложных, но в то же время критически важных аспектов управления командами разработчиков. В то время как другие бизнес-функции часто можно оценить с помощью простых метрик, разработка ПО представляет собой уникальную задачу из-за своей командной, сложной и творческой природы.
Организации в любой отрасли всё больше зависят от ПО, поэтому руководителям нужны надёжные способы оценки эффективности работы их команд разработчиков. Но остаётся вопрос: какие метрики действительно важны, а какие могут принести больше вреда, чем пользы?
Проблема измерения продуктивности
Измерение производительности труда разработчиков - сложная задача по нескольким причинам:
- Разработка ПО предполагает творческое решение задач, которое сложно выразить количественными показателями;
- Связь между входными и выходными данными значительно менее очевидна, чем в других бизнес-функциях;
- Разработка в значительной степени предполагает совместную работу, что затрудняет оценку индивидуального вклада;
- Различные уровни работы (системы, команды, отдельные лица) требуют разных подходов к измерению.
Как заметил один из руководителей инженерных отделов Microsoft: «Многие специалисты в сфере технологий давно убеждены, что невозможно правильно измерить производительность труда разработчиков и что только квалифицированные инженеры обладают достаточными знаниями, чтобы оценить работу своих коллег».
Однако по мере роста команд разработки и увеличения инвестиций организаций в инженерных специалистов подход «мы не можем это измерить» становится всё более несостоятельным.
Метрики, которые не работают (и почему)
Прежде чем углубляться в практические подходы к измерению, давайте рассмотрим некоторые распространённые, но проблемные метрики.
1. Строки кода (KLOC)
Хотя их легко измерить, строки кода — самый известный пример метрики тщеславия. Больше кода не обязательно означает лучше, и эта метрика может активно поощрять неэффективные практики:
- Поощряет многословный, неэффективный код;
- Игнорирует качество и поддерживаемость кода;
- Сильно варьируется в зависимости от языка программирования;
- Легко поддаётся манипуляциям.
2. Количество коммитов
Как и количество строк кода, измерение чистого количества коммитов мало что даёт знать о фактической производительности:
- Разработчики могут чаще вносить незначительные изменения, чтобы «обмануть» систему;
- Не отражает качество или ценность изменений;
- Игнорирует разницу в сложности между коммитами.
3. Отработанные часы
Время, затраченное на кодирование, не обязательно коррелирует с полученной ценностью:
- Поощряет презентеизм (видимость присутствия на работе), а не эффективность;
- Игнорирует качество выполненной работы;
- Может привести к выгоранию и снижению долгосрочной производительности.
Продолжение следует…
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
👍8
День 2367. #ProjectManagement
Измеряем Продуктивность Разработчиков. Продолжение
Начало
Метрики, которые действительно имеют значение
Эффективное измерение производительности требует более тонкого подхода, учитывающего как количественные, так и качественные факторы. Вот метрики, которые дают ценную информацию.
1. Метрики DORA
Метрики DevOps Research and Assessment (DORA) стали отраслевым стандартом для измерения эффективности поставки ПО:
1) Частота развёртывания (DF): как часто код успешно развёртывается в рабочей среде
- Элитные команды: несколько в день,
- Высокопроизводительные команды: от 1 в день до 1 в неделю,
2) Время внесения изменений (LTFC): от коммита до запуска в рабочей среде
- Элитные команды: менее 1 дня
- Высокопроизводительные команды: менее 1 недели
3) Процент ошибок в изменениях (CFR): процент изменений, приводящих к снижению качества обслуживания
- Элитные команды: 0–15%
- Высокопроизводительные команды: 16–30%
4) Среднее время восстановления (MTTR): время, необходимое для восстановления обслуживания после инцидента
- Элитные команды: менее часа
- Высокопроизводительные команды: менее дня
Эти метрики дают сбалансированное представление о скорости и стабильности, помогая командам оценить своё положение по сравнению с отраслевыми эталонами.
2. Фреймворк SPACE
Фреймворк SPACE предлагает более комплексный подход к измерению производительности:
- Удовлетворенность разработчиков: мотивация и баланс между работой и личной жизнью.
- Производительность: ощутимые результаты и эффективность, включая качество кода и скорость устранения ошибок.
- Действия: виды и уровни ежедневной работы по разработке, включая кодирование, отладку и совместную работу.
- Коммуникация и сотрудничество: насколько эффективно разработчики обмениваются информацией и работают вместе.
- Эффективность: насколько эффективно разработчики используют время и ресурсы для достижения целевой производительности.
SPACE признаёт, что продуктивность разработчиков включает в себя не только результаты, но и опыт, динамику работы команды и устойчивые методы работы.
Метрики процесса
Несколько метрик процесса могут дать ценную информацию:
1) Время цикла
Время для переноса кода пул-реквеста в эксплуатацию. Измеряет весь процесс PR — часто самый сложный этап разработки ПО.
2) Размер PR и время проверки
Небольшие PR (<200 строк) тесно связаны с более быстрым временем проверки и более быстрой интеграцией, т.к. обычно проверяются быстрее и тщательнее. Время проверки показывает, насколько быстро предоставляется и учитывается обратная связь.
3) Изменение и доработка кода
Объём кода, переписанного вскоре после написания, может указывать на нечёткие требования или проблемы процесса. Высокое изменение кода (>30%) может сигнализировать о проблемах с требованиями или дизайном. Отслеживание тенденций с течением времени важнее абсолютных цифр.
Внедрение эффективных измерений
Для эффективного измерения производительности требуется не просто выбор правильных метрик, а продуманный подход к их внедрению.
1. Сосредоточьтесь на командных, а не на индивидуальных метриках
Измерение производительности лучше работает на уровне команды, а не отдельного человека, т.к. разработка ПО - совместный процесс. Индивидуальные метрики часто создают нездоровую конкуренцию. Метрики на уровне команды поощряют сотрудничество и совместное владение.
2. Сочетайте опережающие и запаздывающие показатели
- Опережающие (например, размер PR или время проверки) помогают прогнозировать будущие результаты.
- Запаздывающие (частота развёртываний или процент ошибок в изменениях) подтверждают прошлые результаты.
3. Используйте данные для улучшения, а не для наказания
Основной целью должно быть постоянное совершенствование. Используйте данные для выявления узких мест. Сосредоточьте обсуждение на системных улучшениях, а не на индивидуальных показателях эффективности. Отмечайте улучшения и извлекайте уроки из неудач.
Окончание следует…
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
Измеряем Продуктивность Разработчиков. Продолжение
Начало
Метрики, которые действительно имеют значение
Эффективное измерение производительности требует более тонкого подхода, учитывающего как количественные, так и качественные факторы. Вот метрики, которые дают ценную информацию.
1. Метрики DORA
Метрики DevOps Research and Assessment (DORA) стали отраслевым стандартом для измерения эффективности поставки ПО:
1) Частота развёртывания (DF): как часто код успешно развёртывается в рабочей среде
- Элитные команды: несколько в день,
- Высокопроизводительные команды: от 1 в день до 1 в неделю,
2) Время внесения изменений (LTFC): от коммита до запуска в рабочей среде
- Элитные команды: менее 1 дня
- Высокопроизводительные команды: менее 1 недели
3) Процент ошибок в изменениях (CFR): процент изменений, приводящих к снижению качества обслуживания
- Элитные команды: 0–15%
- Высокопроизводительные команды: 16–30%
4) Среднее время восстановления (MTTR): время, необходимое для восстановления обслуживания после инцидента
- Элитные команды: менее часа
- Высокопроизводительные команды: менее дня
Эти метрики дают сбалансированное представление о скорости и стабильности, помогая командам оценить своё положение по сравнению с отраслевыми эталонами.
2. Фреймворк SPACE
Фреймворк SPACE предлагает более комплексный подход к измерению производительности:
- Удовлетворенность разработчиков: мотивация и баланс между работой и личной жизнью.
- Производительность: ощутимые результаты и эффективность, включая качество кода и скорость устранения ошибок.
- Действия: виды и уровни ежедневной работы по разработке, включая кодирование, отладку и совместную работу.
- Коммуникация и сотрудничество: насколько эффективно разработчики обмениваются информацией и работают вместе.
- Эффективность: насколько эффективно разработчики используют время и ресурсы для достижения целевой производительности.
SPACE признаёт, что продуктивность разработчиков включает в себя не только результаты, но и опыт, динамику работы команды и устойчивые методы работы.
Метрики процесса
Несколько метрик процесса могут дать ценную информацию:
1) Время цикла
Время для переноса кода пул-реквеста в эксплуатацию. Измеряет весь процесс PR — часто самый сложный этап разработки ПО.
2) Размер PR и время проверки
Небольшие PR (<200 строк) тесно связаны с более быстрым временем проверки и более быстрой интеграцией, т.к. обычно проверяются быстрее и тщательнее. Время проверки показывает, насколько быстро предоставляется и учитывается обратная связь.
3) Изменение и доработка кода
Объём кода, переписанного вскоре после написания, может указывать на нечёткие требования или проблемы процесса. Высокое изменение кода (>30%) может сигнализировать о проблемах с требованиями или дизайном. Отслеживание тенденций с течением времени важнее абсолютных цифр.
Внедрение эффективных измерений
Для эффективного измерения производительности требуется не просто выбор правильных метрик, а продуманный подход к их внедрению.
1. Сосредоточьтесь на командных, а не на индивидуальных метриках
Измерение производительности лучше работает на уровне команды, а не отдельного человека, т.к. разработка ПО - совместный процесс. Индивидуальные метрики часто создают нездоровую конкуренцию. Метрики на уровне команды поощряют сотрудничество и совместное владение.
2. Сочетайте опережающие и запаздывающие показатели
- Опережающие (например, размер PR или время проверки) помогают прогнозировать будущие результаты.
- Запаздывающие (частота развёртываний или процент ошибок в изменениях) подтверждают прошлые результаты.
3. Используйте данные для улучшения, а не для наказания
Основной целью должно быть постоянное совершенствование. Используйте данные для выявления узких мест. Сосредоточьте обсуждение на системных улучшениях, а не на индивидуальных показателях эффективности. Отмечайте улучшения и извлекайте уроки из неудач.
Окончание следует…
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
👎6
День 2368. #ProjectManagement
Измеряем Продуктивность Разработчиков. Окончание
Начало
Продолжение
Рекомендации по повышению продуктивности
Несколько практик, которые могут значительно повысить продуктивность разработчиков:
1. Снижение когнитивной нагрузки
Минимизация ненужной умственной нагрузки помогает сосредоточиться на самом важном:
- Ограничьте количество встреч, чтобы обеспечить непрерывное время для концентрации;
- По возможности поощряйте асинхронное общение;
- Создайте понятную документацию, чтобы снизить умственные затраты на переключение контекста.
2. Внедрите руководства
Структурированные рекомендации помогают снизить усталость от принятия решений:
- Создайте стандартизированные процедуры для повседневных задач;
- Разработайте стандарты и шаблоны кодирования;
- Документируйте рекомендации для обеспечения согласованности.
3. Автоматизируйте повторяющиеся задачи
Автоматизация позволяет разработчикам сосредоточиться на творческом решении проблем:
- Автоматизируйте процессы сборки, тестирования и развёртывания;
- Используйте инструменты, оптимизирующие проверку кода и управление PR;
- Внедряйте конвейеры CI/CD для снижения ручного труда.
4. Сопоставляйте сильные стороны разработчиков с проектами
Согласование работы с экспертными знаниями повышает как производительность, так и удовлетворённость:
- Создайте профили навыков для понимания потребностей разработчиков;
- Назначайте задачи на основе знаний и интересов;
- Предоставляйте возможности для роста в областях, представляющих интерес.
Реальные примеры повышения производительности
Модель «Squad» от Spotify
Spotify организовал команды в небольшие кросс-функциональные «отряды», каждый из которых отвечает за определённые функции или сервисы на всех этапах. Такой подход снизил зависимость между командами и сократил время цикла на 35%.
Опрос удовлетворённости разработчиков от Google
Google регулярно опрашивает разработчиков об их производительности и удовлетворённости. Обнаружив, что время сборки является основной проблемой, компания инвестировала в усовершенствования системы сборки, что позволило сэкономить примерно 3–5 часов на разработчика в неделю.
Индекс скорости разработки от Microsoft
В Microsoft разработали комплексную систему для измерения продуктивности разработчиков, учитывающую технические, процессные и культурные факторы. Компании, находящиеся в верхнем квартиле этого индекса, быстрее внедряют инновации и демонстрируют в 4–5 раз более высокую эффективность бизнеса.
Итого
Для эффективного измерения продуктивности разработчиков необходимо выйти за рамки простых показателей, таких как количество строк кода или отработанных часов. Вместо этого сосредоточьтесь на сбалансированных фреймворках, таких как DORA и SPACE, которые учитывают как количественные, так и качественные аспекты разработки.
Помните, что целью измерения должно быть постоянное совершенствование, а не наказание или нездоровая конкуренция. Используйте метрики для выявления узких мест на системном уровне и возможностей для улучшения, а не для оценки индивидуальной работы в отрыве от других.
Наиболее продуктивные команды разработки сочетают продуманное измерение с практиками, которые снижают трения и облегчают работу. Сосредоточившись на том, что действительно важно — эффективном создании ценности при сохранении удовлетворённости разработчиков, — организации могут создать устойчивую, высокопроизводительную инженерную культуру.
Совершенствуя свой подход к измерению и повышению продуктивности разработчиков, помните, что важнейшей метрикой является ценность, предоставляемая пользователям. Когда разработчики могут эффективно работать над значимыми задачами, производительность и удовлетворённость естественным образом растут.
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
Измеряем Продуктивность Разработчиков. Окончание
Начало
Продолжение
Рекомендации по повышению продуктивности
Несколько практик, которые могут значительно повысить продуктивность разработчиков:
1. Снижение когнитивной нагрузки
Минимизация ненужной умственной нагрузки помогает сосредоточиться на самом важном:
- Ограничьте количество встреч, чтобы обеспечить непрерывное время для концентрации;
- По возможности поощряйте асинхронное общение;
- Создайте понятную документацию, чтобы снизить умственные затраты на переключение контекста.
2. Внедрите руководства
Структурированные рекомендации помогают снизить усталость от принятия решений:
- Создайте стандартизированные процедуры для повседневных задач;
- Разработайте стандарты и шаблоны кодирования;
- Документируйте рекомендации для обеспечения согласованности.
3. Автоматизируйте повторяющиеся задачи
Автоматизация позволяет разработчикам сосредоточиться на творческом решении проблем:
- Автоматизируйте процессы сборки, тестирования и развёртывания;
- Используйте инструменты, оптимизирующие проверку кода и управление PR;
- Внедряйте конвейеры CI/CD для снижения ручного труда.
4. Сопоставляйте сильные стороны разработчиков с проектами
Согласование работы с экспертными знаниями повышает как производительность, так и удовлетворённость:
- Создайте профили навыков для понимания потребностей разработчиков;
- Назначайте задачи на основе знаний и интересов;
- Предоставляйте возможности для роста в областях, представляющих интерес.
Реальные примеры повышения производительности
Модель «Squad» от Spotify
Spotify организовал команды в небольшие кросс-функциональные «отряды», каждый из которых отвечает за определённые функции или сервисы на всех этапах. Такой подход снизил зависимость между командами и сократил время цикла на 35%.
Опрос удовлетворённости разработчиков от Google
Google регулярно опрашивает разработчиков об их производительности и удовлетворённости. Обнаружив, что время сборки является основной проблемой, компания инвестировала в усовершенствования системы сборки, что позволило сэкономить примерно 3–5 часов на разработчика в неделю.
Индекс скорости разработки от Microsoft
В Microsoft разработали комплексную систему для измерения продуктивности разработчиков, учитывающую технические, процессные и культурные факторы. Компании, находящиеся в верхнем квартиле этого индекса, быстрее внедряют инновации и демонстрируют в 4–5 раз более высокую эффективность бизнеса.
Итого
Для эффективного измерения продуктивности разработчиков необходимо выйти за рамки простых показателей, таких как количество строк кода или отработанных часов. Вместо этого сосредоточьтесь на сбалансированных фреймворках, таких как DORA и SPACE, которые учитывают как количественные, так и качественные аспекты разработки.
Помните, что целью измерения должно быть постоянное совершенствование, а не наказание или нездоровая конкуренция. Используйте метрики для выявления узких мест на системном уровне и возможностей для улучшения, а не для оценки индивидуальной работы в отрыве от других.
Наиболее продуктивные команды разработки сочетают продуманное измерение с практиками, которые снижают трения и облегчают работу. Сосредоточившись на том, что действительно важно — эффективном создании ценности при сохранении удовлетворённости разработчиков, — организации могут создать устойчивую, высокопроизводительную инженерную культуру.
Совершенствуя свой подход к измерению и повышению продуктивности разработчиков, помните, что важнейшей метрикой является ценность, предоставляемая пользователям. Когда разработчики могут эффективно работать над значимыми задачами, производительность и удовлетворённость естественным образом растут.
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
👍1