[Agile, Управление продуктом] Лучшая метрика для команды, работающей над продуктом (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Иногда при обсуждении продукта метрики только мешают
Пару недель назад я познакомился с коллегой-коучем, мы разговорились и обсудили несколько аспектов нашей профессии. В какой-то момент он задал мне вопрос, на который оказалось трудно ответить.
Точнее говоря, ответил я сразу же, но потом этот вопрос несколько недель не давал мне покоя, я снова и снова его обдумывал. В итоге, основательно всё взвесив, я в пришел к более обоснованному ответу.
Итак, меня спросили: «Если бы для agile-команды можно было бы отслеживать только две метрики, что бы вы выбрали?»
Меня сразу смутило слово «метрики», поскольку мой опыт работы с ними был не очень положительным, мягко говоря: они слишком часто используются как оружие, а не как средство улучшения работы. При их использовании коллектив более склонен чувствовать себя чем-то вроде лабораторных крыс.
Однако я всё-таки ответил на вопрос — назвал первое, пришло в голову. И нельзя сказать, чтобы я этим ответом гордился. Задай мне этот вопрос сегодня, я ответил бы гораздо более продуманно…
Итак, мой изначальный ответ был таким: «Это же очевидно: нужно отслеживать метрики для освоения продукта пользователем и времени выполнения истории».
Теперь я понимаю, что поспешил. Я попал в ловушку, в которую попадают все, кто начинает заниматься метриками: в спешке дать ответ я забыл кое-что важное — более важное, чем всякий индикатор времени выхода на рынок или конечного результата.
Но о том, что прошло мимо моего сознания, мы поговорим позже. Сейчас же давайте разберемся в общих чертах в метриках и в том, какую опасность может представлять их использование. А потом я скажу, как бы я ответил на этот вопрос сегодня.
Опасность использования метрик
При работе с метриками можно быстро сойти с правильного пути — пусть мы и начинаем их использовать с благими намерениями. Сосредотачиваясь на цифрах, мы часто забываем о людях — тех, кто разрабатывает продукт, и тех, кто им пользуется. Работать с цифрами проще, и это соблазнительно.
Рассмотрим три ловушки, в которые можно попасть, используя метрики.
№ 1. Избыток метрик
А давайте отслеживать всё подряд! Зачем ограничиваться одним показателем эффективности, если можно использовать больше? Чем больше, тем лучше, верно? Конечно же нет — если речь идет о командах, разрабатывающих продукт.
Допустим, отслеживаются такие метрики:
- Освоение пользователем по функциям.
- Потеря пользователей с течением времени.
- Новые пользователи по регионам.
- Средняя скорость с течением времени.
- Время цикла.
- Время выполнения задачи.
- Суммарный поток.
- Незавершенная работа.
- Среднее время существования элементов бэклога.
- Объем задач, оставшихся в спринте.
- Объем задач, оставшихся до релиза.
- Среднее время восстановления работы при сбое.
- Процент пропущенных дефектов.
- Процент покрытия кода модульными тестами.
Когда и на какой метрике команде нужно сосредотачиваться? Ответить на такой вопрос непросто — ведь это зависит от постоянно меняющегося контекста. Улучшение по одной метрике может отрицательно повлиять на другую. Обычно всё сводится к тому, какая метрика больше остальных волнует менеджмент в данный момент.
«Представление о том, что если что-то нельзя измерить, то этим нельзя управлять, — это миф, который дорого обходится».
— Уильям Эдвардс Деминг
Чем больше метрик, тем больше усилий и людей требуется для сбора соответствующих данных. При этом мы даже не пробуем оценить, стоит ли отслеживать каждый конкретный показатель. Но несмотря на всё это, мы пытаемся выжать из отслеживания данных максимум.
Часто дело заходит настолько далеко, что приходится выделять специальные команды для отслеживания и анализа данных и составления отчетов по ним. К сожалению, такие аналитические команды часто изолированы и от тех, кто непосредственно разрабатывает продукт, и от конечных пользователей. Интерпретация данных становится сродни лабораторному анализу проб и образцов: человеческий контакт отсутствует, нет ни контекста, ни вникания в ситуацию.
Поэтому число показателей лучше всё-таки сокращать — несмотря на то, что интуиция говорит нам обратное.
№ 2. Сравнение между командами
Как только вы начали сравнивать команды по какой-то метрике, она сразу же становится бесполезной — начинается соревнование по этой метрике, в результате чего фокус смещается на нее нездоровым образом.
Согласно принципу Гудхарта, когда вы сравниваете команды по некоему целевому показателю, они подстраиваются так, чтобы давать лучший результат по нему — и начинают находить для этого обходные пути. И первоначальный смысл отслеживания метрики исчезает.
«Скажи мне, как ты меня будешь оценивать, и я скажу, как я буду себя вести».
— Эли Голдратт
Если нам кажется, что за нами наблюдают, мы начинаем вести себя иначе — это называется хоторнским эффектом.
Возьмем метрику, которой часто таким образом злоупотребляют, — скорость. Для команды этот показатель представляет собой сумму баллов за истории, доведенные командой до состояния «выполнено» в спринте. Скорость — это лишь инструмент планирования для команд, ничего более. Обычно рассчитывают среднюю скорость как минимум за последних три спринта, и на базе этого значения прогнозируют, сколько и каких историй можно будет выполнить в будущих спринтах.
К сожалению, те, кого интересует продуктивность команды, используют метрику скорости не так: часто «наверху» с ее помощью сравнивают результативность команд. В результате отличный инструмент прогнозирования превращается в показатель, привязанный к продуктивности, — и между командами начинается нездоровая конкуренция.
В итоге метрикой скорости начинают манипулировать так, что она становится бессмысленной. Наиболее распространены такие манипуляции:
- История не делится на более мелкие — потому что у больших историй и баллов больше.
- Завышается сложность истории — чтобы получить больше баллов.
- Команда жертвует качеством, стремясь побыстрее перевести историю в категорию выполненных в спринте.
- Команда снижает прозрачность работы и старается находить как можно меньше проблем — чтобы как можно раньше «сдать» историю.
Такое поведение в результате снижает продуктивность команды. Кроме того, теряется изначальный смысл показателя «скорость» как инструмента планирования.
И такое может произойти и с любой метрикой, если она становится внешней целью.
№ 3. Чрезмерный акцент на объективных данных
С юных лет в школах нас учат быть объективными. Мы знаем, что в принятии решений предвзятость недопустима, и в деловом мире такой подход только приветствуется. В итоге же мы оказываемся одержимы объективными количественными данными — и часто игнорируем качественные данные или недооцениваем их.
Если у команды нет ощущения психологической защищенности, прозрачность в процессах снижается, из-за чего доверие к полноте качественных данных падает, и их стараются использовать меньше.
«Если есть страх, цифры будут врать».
— Уильям Эдвардс Деминг
Понемногу углубляясь в цифры, графики, диаграммы и другие показатели эффективности, мы всё реже общаемся с командой. И это никак не повышает чувство защищенности коллектива — а лишь еще больше снижает его.
Помню, как-то компания, в которой я работал коучем, решила автоматизировать отслеживание продуктивности команды. Они проанализировали журналы из Jira, данные из конвейера непрерывной поставки и от службы поддержки. Ценой больших усилий было налажено автоматическое отслеживание этих данных без вмешательства человека.
И всё это было сделано потому, что руководство не доверяло информации, поступавшей от сотрудников. Они попытались исключить человеческий фактор, обратились к цифрам и в итоге стали меньше общаться с командами. Но основная проблема психологической защищенности не была решена — ее уровень снизился еще больше, поскольку руководство стало меньше советоваться с сотрудниками.
Единственная нужная метрика
Вы наверняка теперь думаете, что я не люблю данные. Давайте я проясню: я не хочу сказать, что данные — это плохо; данные необходимы. В принятии решения без фактов — никуда.
«Без данных ваши слова — просто очередное мнение».
— Уильям Эдвардс Деминг
Но перечисленные три проблемы — избыточное количество метрик, сравнение между командами и увлечение объективностью — не дают использовать данные эффективно. Так что же делать?
Именно этот вопрос я обдумывал последние несколько недель. И я пришел к выводу, что ответ лежит в таком понятии, как вовлеченность команды.
Метрика «вовлеченность команды»
Лучший показатель успеха продукта — это вовлеченность команды. Она оценивается по уровню автономности, профессионального мастерства и целенаправленности команды.
Чем больше вовлеченность, тем больше удовольствие от работы. Команды с высоким уровнем вовлеченности сами определяют, какая внутренняя организация необходима для достижения цели. Ее сотрудники повышают свое профессиональное мастерство, учатся эффективнее поставлять продукт и управлять им, у них есть цель, к которой они стремятся, которая ведет их вперед и удерживает в команде.
Остальные метрики по-прежнему остаются ценными, но они должны быть строго внутренними: автономная команда будет отслеживать метрики согласно контексту их использования. Повышая профессиональный уровень, команда адаптируется сама и направляет продукт так, чтобы достигать более высоких результатов. Стремясь к цели, команда будет отслеживать нужные метрики в зависимости от контекста.
Означает ли это, что нужно запустить систему отслеживания вовлеченности команды, или, например, начать работу над информационной панелью для показателя удовлетворенности команды? Нет. Если это сделать, мы вернемся к трем описанным выше проблемам. А что тогда делать?
Общайтесь с коллективом.
Выберитесь из своего кабинета и побеседуйте там, где идет непосредственная работа: зайдите в кабинет к разработчикам, ходите на обзоры спринтов, участвуйте в обсуждении бэклога. Присмотритесь, где им нужна помощь. Поспрашивайте, чувствуют ли они вовлеченность в своей работе.
Не просто так мы общаемся словами, а не цифрами и графиками: общение — намного более важный фактор, чем какие бы то ни были метрики и графики. Из разговора можно многое узнать, он облегчает понимание. Метрики и диаграммы могут помочь в разговоре, но не заменят его.
Дайте командам самостоятельно отслеживать метрики и реагировать на них. Вовлеченный коллектив, обладающий автономией, профессиональным мастерством и целеустремленностью, будет сам заботиться о приносимой пользе и будет знать, какие показатели для этого лучше использовать.
Заходите к командам и регулярно общайтесь с ними, поддерживайте, если нужна помощь — и вы увидите, как они начнут чувствовать себя более защищенными, и одновременно с этим вырастет вовлеченность. И никакие метрики не понадобятся.
Итак, мой окончательный ответ
Эта статья началась с моего разговора с другим коучем, который спросил, какие две метрики я бы отслеживал.
Теперь, тщательно всё обдумав, я бы дал более взвешенный ответ:
«Пусть решают сами команды. Нужно почаще заходить к ним и общаться — чтобы они ощущали участие и поддержку».
Методология Agile ориентирована на то, чтобы команда работала сообща и совершенствовалась. Главное здесь — не цифры, диаграммы или графики.
Пришло время сосредоточиться на том, чтобы повысить вовлеченность команды: поощрять автономность, целеустремленность и развитие профессионального мастерства. В том числе команде нужно отдать работу с метриками. Тогда можно будет заняться тем, чтобы создать рабочую среду и дать поддержку, необходимые для работы.
Особая благодарность Мацею Ярошу и Маартену Далмийну за их вклад в эту статью.
О переводчике
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
→ Подробнее
===========
Источник:
habr.com
===========
===========
Автор оригинала: Todd Lankford
===========Похожие новости:
- [Управление разработкой, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] Создание программного продукта и управление его развитием. Как определить пользовательских персон для вашего продукта
- [Управление разработкой, Управление проектами, Agile, Atlassian] Проектные решения: игра по твоим правилам
- [Анализ и проектирование систем, Управление продуктом, Конференции] Стираем границы на первой онлайн-конференции аналитиков
- [IT-инфраструктура, ERP-системы, CRM-системы, Управление проектами, Управление продуктом] Новый формат отдела разработки ПО
- [Управление продуктом] Product Manager & Product Designer: поиск сходств и отличий
- [Анализ и проектирование систем, Проектирование и рефакторинг, Управление продуктом] Смешение уровней абстракции закладывает бомбу в основание вашего проекта
- [Работа с видео, Разработка мобильных приложений] Как создавались ролики о приложении «ПоЗнакомым»: факты, задачи, тонкости + комментарий клиента
- [Управление продуктом, Карьера в IT-индустрии, Финансы в IT, IT-компании] Mozilla сократит 250 человек из-за пандемии
- [Управление проектами, Управление продуктом, Искусственный интеллект] Разработка AI-продукта на основе машинного зрения. Промежуточная ретроспектива: мысли, боль, страдания
- [Программирование, Управление разработкой, Управление проектами, Управление продуктом, DevOps] Типовые ситуации при непрерывной интеграции (перевод)
Теги для поиска: #_agile, #_upravlenie_produktom (Управление продуктом), #_alconost, #_team_management, #_product_management, #_agile, #_agile_results, #_scrum, #_produktovaja_komanda (продуктовая команда), #_upravlenie_komandoj (управление командой), #_upravlenie_komandoj_razrabotki (управление командой разработки), #_kpi, #_kpi_pokazateli (kpi показатели), #_effektivnost (эффективность), #_blog_kompanii_alconost (
Блог компании Alconost
), #_agile, #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:26
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Иногда при обсуждении продукта метрики только мешают  Пару недель назад я познакомился с коллегой-коучем, мы разговорились и обсудили несколько аспектов нашей профессии. В какой-то момент он задал мне вопрос, на который оказалось трудно ответить. Точнее говоря, ответил я сразу же, но потом этот вопрос несколько недель не давал мне покоя, я снова и снова его обдумывал. В итоге, основательно всё взвесив, я в пришел к более обоснованному ответу. Итак, меня спросили: «Если бы для agile-команды можно было бы отслеживать только две метрики, что бы вы выбрали?»
Однако я всё-таки ответил на вопрос — назвал первое, пришло в голову. И нельзя сказать, чтобы я этим ответом гордился. Задай мне этот вопрос сегодня, я ответил бы гораздо более продуманно… Итак, мой изначальный ответ был таким: «Это же очевидно: нужно отслеживать метрики для освоения продукта пользователем и времени выполнения истории».
Но о том, что прошло мимо моего сознания, мы поговорим позже. Сейчас же давайте разберемся в общих чертах в метриках и в том, какую опасность может представлять их использование. А потом я скажу, как бы я ответил на этот вопрос сегодня. Опасность использования метрик При работе с метриками можно быстро сойти с правильного пути — пусть мы и начинаем их использовать с благими намерениями. Сосредотачиваясь на цифрах, мы часто забываем о людях — тех, кто разрабатывает продукт, и тех, кто им пользуется. Работать с цифрами проще, и это соблазнительно. Рассмотрим три ловушки, в которые можно попасть, используя метрики. № 1. Избыток метрик А давайте отслеживать всё подряд! Зачем ограничиваться одним показателем эффективности, если можно использовать больше? Чем больше, тем лучше, верно? Конечно же нет — если речь идет о командах, разрабатывающих продукт. Допустим, отслеживаются такие метрики:
Когда и на какой метрике команде нужно сосредотачиваться? Ответить на такой вопрос непросто — ведь это зависит от постоянно меняющегося контекста. Улучшение по одной метрике может отрицательно повлиять на другую. Обычно всё сводится к тому, какая метрика больше остальных волнует менеджмент в данный момент. «Представление о том, что если что-то нельзя измерить, то этим нельзя управлять, — это миф, который дорого обходится».
— Уильям Эдвардс Деминг Часто дело заходит настолько далеко, что приходится выделять специальные команды для отслеживания и анализа данных и составления отчетов по ним. К сожалению, такие аналитические команды часто изолированы и от тех, кто непосредственно разрабатывает продукт, и от конечных пользователей. Интерпретация данных становится сродни лабораторному анализу проб и образцов: человеческий контакт отсутствует, нет ни контекста, ни вникания в ситуацию. Поэтому число показателей лучше всё-таки сокращать — несмотря на то, что интуиция говорит нам обратное. № 2. Сравнение между командами Как только вы начали сравнивать команды по какой-то метрике, она сразу же становится бесполезной — начинается соревнование по этой метрике, в результате чего фокус смещается на нее нездоровым образом. Согласно принципу Гудхарта, когда вы сравниваете команды по некоему целевому показателю, они подстраиваются так, чтобы давать лучший результат по нему — и начинают находить для этого обходные пути. И первоначальный смысл отслеживания метрики исчезает. «Скажи мне, как ты меня будешь оценивать, и я скажу, как я буду себя вести».
— Эли Голдратт Возьмем метрику, которой часто таким образом злоупотребляют, — скорость. Для команды этот показатель представляет собой сумму баллов за истории, доведенные командой до состояния «выполнено» в спринте. Скорость — это лишь инструмент планирования для команд, ничего более. Обычно рассчитывают среднюю скорость как минимум за последних три спринта, и на базе этого значения прогнозируют, сколько и каких историй можно будет выполнить в будущих спринтах. К сожалению, те, кого интересует продуктивность команды, используют метрику скорости не так: часто «наверху» с ее помощью сравнивают результативность команд. В результате отличный инструмент прогнозирования превращается в показатель, привязанный к продуктивности, — и между командами начинается нездоровая конкуренция. В итоге метрикой скорости начинают манипулировать так, что она становится бессмысленной. Наиболее распространены такие манипуляции:
Такое поведение в результате снижает продуктивность команды. Кроме того, теряется изначальный смысл показателя «скорость» как инструмента планирования. И такое может произойти и с любой метрикой, если она становится внешней целью. № 3. Чрезмерный акцент на объективных данных С юных лет в школах нас учат быть объективными. Мы знаем, что в принятии решений предвзятость недопустима, и в деловом мире такой подход только приветствуется. В итоге же мы оказываемся одержимы объективными количественными данными — и часто игнорируем качественные данные или недооцениваем их. Если у команды нет ощущения психологической защищенности, прозрачность в процессах снижается, из-за чего доверие к полноте качественных данных падает, и их стараются использовать меньше. «Если есть страх, цифры будут врать».
— Уильям Эдвардс Деминг Помню, как-то компания, в которой я работал коучем, решила автоматизировать отслеживание продуктивности команды. Они проанализировали журналы из Jira, данные из конвейера непрерывной поставки и от службы поддержки. Ценой больших усилий было налажено автоматическое отслеживание этих данных без вмешательства человека. И всё это было сделано потому, что руководство не доверяло информации, поступавшей от сотрудников. Они попытались исключить человеческий фактор, обратились к цифрам и в итоге стали меньше общаться с командами. Но основная проблема психологической защищенности не была решена — ее уровень снизился еще больше, поскольку руководство стало меньше советоваться с сотрудниками. Единственная нужная метрика Вы наверняка теперь думаете, что я не люблю данные. Давайте я проясню: я не хочу сказать, что данные — это плохо; данные необходимы. В принятии решения без фактов — никуда. «Без данных ваши слова — просто очередное мнение».
— Уильям Эдвардс Деминг Именно этот вопрос я обдумывал последние несколько недель. И я пришел к выводу, что ответ лежит в таком понятии, как вовлеченность команды. Метрика «вовлеченность команды» Лучший показатель успеха продукта — это вовлеченность команды. Она оценивается по уровню автономности, профессионального мастерства и целенаправленности команды. Чем больше вовлеченность, тем больше удовольствие от работы. Команды с высоким уровнем вовлеченности сами определяют, какая внутренняя организация необходима для достижения цели. Ее сотрудники повышают свое профессиональное мастерство, учатся эффективнее поставлять продукт и управлять им, у них есть цель, к которой они стремятся, которая ведет их вперед и удерживает в команде. Остальные метрики по-прежнему остаются ценными, но они должны быть строго внутренними: автономная команда будет отслеживать метрики согласно контексту их использования. Повышая профессиональный уровень, команда адаптируется сама и направляет продукт так, чтобы достигать более высоких результатов. Стремясь к цели, команда будет отслеживать нужные метрики в зависимости от контекста. Означает ли это, что нужно запустить систему отслеживания вовлеченности команды, или, например, начать работу над информационной панелью для показателя удовлетворенности команды? Нет. Если это сделать, мы вернемся к трем описанным выше проблемам. А что тогда делать? Общайтесь с коллективом. Выберитесь из своего кабинета и побеседуйте там, где идет непосредственная работа: зайдите в кабинет к разработчикам, ходите на обзоры спринтов, участвуйте в обсуждении бэклога. Присмотритесь, где им нужна помощь. Поспрашивайте, чувствуют ли они вовлеченность в своей работе. Не просто так мы общаемся словами, а не цифрами и графиками: общение — намного более важный фактор, чем какие бы то ни были метрики и графики. Из разговора можно многое узнать, он облегчает понимание. Метрики и диаграммы могут помочь в разговоре, но не заменят его. Дайте командам самостоятельно отслеживать метрики и реагировать на них. Вовлеченный коллектив, обладающий автономией, профессиональным мастерством и целеустремленностью, будет сам заботиться о приносимой пользе и будет знать, какие показатели для этого лучше использовать. Заходите к командам и регулярно общайтесь с ними, поддерживайте, если нужна помощь — и вы увидите, как они начнут чувствовать себя более защищенными, и одновременно с этим вырастет вовлеченность. И никакие метрики не понадобятся. Итак, мой окончательный ответ Эта статья началась с моего разговора с другим коучем, который спросил, какие две метрики я бы отслеживал. Теперь, тщательно всё обдумав, я бы дал более взвешенный ответ: «Пусть решают сами команды. Нужно почаще заходить к ним и общаться — чтобы они ощущали участие и поддержку».
Методология Agile ориентирована на то, чтобы команда работала сообща и совершенствовалась. Главное здесь — не цифры, диаграммы или графики. Пришло время сосредоточиться на том, чтобы повысить вовлеченность команды: поощрять автономность, целеустремленность и развитие профессионального мастерства. В том числе команде нужно отдать работу с метриками. Тогда можно будет заняться тем, чтобы создать рабочую среду и дать поддержку, необходимые для работы. Особая благодарность Мацею Ярошу и Маартену Далмийну за их вклад в эту статью. О переводчике Перевод статьи выполнен в Alconost. Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов. Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store. → Подробнее =========== Источник: habr.com =========== =========== Автор оригинала: Todd Lankford ===========Похожие новости:
Блог компании Alconost ), #_agile, #_upravlenie_produktom ( Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:26
Часовой пояс: UTC + 5