Русский
Русский
English
Статистика
Реклама

Управление командой разработки

Перевод Лучшая метрика для команды, работающей над продуктом

18.08.2020 14:15:47 | Автор: admin

Иногда при обсуждении продукта метрики только мешают




Пару недель назад я познакомился с коллегой-коучем, мы разговорились и обсудили несколько аспектов нашей профессии. В какой-то момент он задал мне вопрос, на который оказалось трудно ответить.

Точнее говоря, ответил я сразу же, но потом этот вопрос несколько недель не давал мне покоя, я снова и снова его обдумывал. В итоге, основательно всё взвесив, я в пришел к более обоснованному ответу.
Итак, меня спросили: Если бы для agile-команды можно было бы отслеживать только две метрики, что бы вы выбрали?
Меня сразу смутило слово метрики, поскольку мой опыт работы с ними был не очень положительным, мягко говоря: они слишком часто используются как оружие, а не как средство улучшения работы. При их использовании коллектив более склонен чувствовать себя чем-то вроде лабораторных крыс.

Однако я всё-таки ответил на вопрос назвал первое, пришло в голову. И нельзя сказать, чтобы я этим ответом гордился. Задай мне этот вопрос сегодня, я ответил бы гораздо более продуманно

Итак, мой изначальный ответ был таким: Это же очевидно: нужно отслеживать метрики для освоения продукта пользователем и времени выполнения истории.
Теперь я понимаю, что поспешил. Я попал в ловушку, в которую попадают все, кто начинает заниматься метриками: в спешке дать ответ я забыл кое-что важное более важное, чем всякий индикатор времени выхода на рынок или конечного результата.

Но о том, что прошло мимо моего сознания, мы поговорим позже. Сейчас же давайте разберемся в общих чертах в метриках и в том, какую опасность может представлять их использование. А потом я скажу, как бы я ответил на этот вопрос сегодня.

Опасность использования метрик


При работе с метриками можно быстро сойти с правильного пути пусть мы и начинаем их использовать с благими намерениями. Сосредотачиваясь на цифрах, мы часто забываем о людях тех, кто разрабатывает продукт, и тех, кто им пользуется. Работать с цифрами проще, и это соблазнительно.

Рассмотрим три ловушки, в которые можно попасть, используя метрики.

1. Избыток метрик


А давайте отслеживать всё подряд! Зачем ограничиваться одним показателем эффективности, если можно использовать больше? Чем больше, тем лучше, верно? Конечно же нет если речь идет о командах, разрабатывающих продукт.

Допустим, отслеживаются такие метрики:

  • Освоение пользователем по функциям.
  • Потеря пользователей с течением времени.
  • Новые пользователи по регионам.
  • Средняя скорость с течением времени.
  • Время цикла.
  • Время выполнения задачи.
  • Суммарный поток.
  • Незавершенная работа.
  • Среднее время существования элементов бэклога.
  • Объем задач, оставшихся в спринте.
  • Объем задач, оставшихся до релиза.
  • Среднее время восстановления работы при сбое.
  • Процент пропущенных дефектов.
  • Процент покрытия кода модульными тестами.

Когда и на какой метрике команде нужно сосредотачиваться? Ответить на такой вопрос непросто ведь это зависит от постоянно меняющегося контекста. Улучшение по одной метрике может отрицательно повлиять на другую. Обычно всё сводится к тому, какая метрика больше остальных волнует менеджмент в данный момент.
Представление о том, что если что-то нельзя измерить, то этим нельзя управлять, это миф, который дорого обходится.

Уильям Эдвардс Деминг
Чем больше метрик, тем больше усилий и людей требуется для сбора соответствующих данных. При этом мы даже не пробуем оценить, стоит ли отслеживать каждый конкретный показатель. Но несмотря на всё это, мы пытаемся выжать из отслеживания данных максимум.

Часто дело заходит настолько далеко, что приходится выделять специальные команды для отслеживания и анализа данных и составления отчетов по ним. К сожалению, такие аналитические команды часто изолированы и от тех, кто непосредственно разрабатывает продукт, и от конечных пользователей. Интерпретация данных становится сродни лабораторному анализу проб и образцов: человеческий контакт отсутствует, нет ни контекста, ни вникания в ситуацию.

Поэтому число показателей лучше всё-таки сокращать несмотря на то, что интуиция говорит нам обратное.

2. Сравнение между командами


Как только вы начали сравнивать команды по какой-то метрике, она сразу же становится бесполезной начинается соревнование по этой метрике, в результате чего фокус смещается на нее нездоровым образом.

Согласно принципу Гудхарта, когда вы сравниваете команды по некоему целевому показателю, они подстраиваются так, чтобы давать лучший результат по нему и начинают находить для этого обходные пути. И первоначальный смысл отслеживания метрики исчезает.
Скажи мне, как ты меня будешь оценивать, и я скажу, как я буду себя вести.

Эли Голдратт
Если нам кажется, что за нами наблюдают, мы начинаем вести себя иначе это называется хоторнским эффектом.

Возьмем метрику, которой часто таким образом злоупотребляют, скорость. Для команды этот показатель представляет собой сумму баллов за истории, доведенные командой до состояния выполнено в спринте. Скорость это лишь инструмент планирования для команд, ничего более. Обычно рассчитывают среднюю скорость как минимум за последних три спринта, и на базе этого значения прогнозируют, сколько и каких историй можно будет выполнить в будущих спринтах.

К сожалению, те, кого интересует продуктивность команды, используют метрику скорости не так: часто наверху с ее помощью сравнивают результативность команд. В результате отличный инструмент прогнозирования превращается в показатель, привязанный к продуктивности, и между командами начинается нездоровая конкуренция.

В итоге метрикой скорости начинают манипулировать так, что она становится бессмысленной. Наиболее распространены такие манипуляции:

  • История не делится на более мелкие потому что у больших историй и баллов больше.
  • Завышается сложность истории чтобы получить больше баллов.
  • Команда жертвует качеством, стремясь побыстрее перевести историю в категорию выполненных в спринте.
  • Команда снижает прозрачность работы и старается находить как можно меньше проблем чтобы как можно раньше сдать историю.

Такое поведение в результате снижает продуктивность команды. Кроме того, теряется изначальный смысл показателя скорость как инструмента планирования.

И такое может произойти и с любой метрикой, если она становится внешней целью.

3. Чрезмерный акцент на объективных данных


С юных лет в школах нас учат быть объективными. Мы знаем, что в принятии решений предвзятость недопустима, и в деловом мире такой подход только приветствуется. В итоге же мы оказываемся одержимы объективными количественными данными и часто игнорируем качественные данные или недооцениваем их.

Если у команды нет ощущения психологической защищенности, прозрачность в процессах снижается, из-за чего доверие к полноте качественных данных падает, и их стараются использовать меньше.
Если есть страх, цифры будут врать.

Уильям Эдвардс Деминг
Понемногу углубляясь в цифры, графики, диаграммы и другие показатели эффективности, мы всё реже общаемся с командой. И это никак не повышает чувство защищенности коллектива а лишь еще больше снижает его.

Помню, как-то компания, в которой я работал коучем, решила автоматизировать отслеживание продуктивности команды. Они проанализировали журналы из Jira, данные из конвейера непрерывной поставки и от службы поддержки. Ценой больших усилий было налажено автоматическое отслеживание этих данных без вмешательства человека.

И всё это было сделано потому, что руководство не доверяло информации, поступавшей от сотрудников. Они попытались исключить человеческий фактор, обратились к цифрам и в итоге стали меньше общаться с командами. Но основная проблема психологической защищенности не была решена ее уровень снизился еще больше, поскольку руководство стало меньше советоваться с сотрудниками.

Единственная нужная метрика


Вы наверняка теперь думаете, что я не люблю данные. Давайте я проясню: я не хочу сказать, что данные это плохо; данные необходимы. В принятии решения без фактов никуда.
Без данных ваши слова просто очередное мнение.

Уильям Эдвардс Деминг
Но перечисленные три проблемы избыточное количество метрик, сравнение между командами и увлечение объективностью не дают использовать данные эффективно. Так что же делать?

Именно этот вопрос я обдумывал последние несколько недель. И я пришел к выводу, что ответ лежит в таком понятии, как вовлеченность команды.

Метрика вовлеченность команды


Лучший показатель успеха продукта это вовлеченность команды. Она оценивается по уровню автономности, профессионального мастерства и целенаправленности команды.

Чем больше вовлеченность, тем больше удовольствие от работы. Команды с высоким уровнем вовлеченности сами определяют, какая внутренняя организация необходима для достижения цели. Ее сотрудники повышают свое профессиональное мастерство, учатся эффективнее поставлять продукт и управлять им, у них есть цель, к которой они стремятся, которая ведет их вперед и удерживает в команде.

Остальные метрики по-прежнему остаются ценными, но они должны быть строго внутренними: автономная команда будет отслеживать метрики согласно контексту их использования. Повышая профессиональный уровень, команда адаптируется сама и направляет продукт так, чтобы достигать более высоких результатов. Стремясь к цели, команда будет отслеживать нужные метрики в зависимости от контекста.

Означает ли это, что нужно запустить систему отслеживания вовлеченности команды, или, например, начать работу над информационной панелью для показателя удовлетворенности команды? Нет. Если это сделать, мы вернемся к трем описанным выше проблемам. А что тогда делать?

Общайтесь с коллективом.

Выберитесь из своего кабинета и побеседуйте там, где идет непосредственная работа: зайдите в кабинет к разработчикам, ходите на обзоры спринтов, участвуйте в обсуждении бэклога. Присмотритесь, где им нужна помощь. Поспрашивайте, чувствуют ли они вовлеченность в своей работе.

Не просто так мы общаемся словами, а не цифрами и графиками: общение намного более важный фактор, чем какие бы то ни были метрики и графики. Из разговора можно многое узнать, он облегчает понимание. Метрики и диаграммы могут помочь в разговоре, но не заменят его.

Дайте командам самостоятельно отслеживать метрики и реагировать на них. Вовлеченный коллектив, обладающий автономией, профессиональным мастерством и целеустремленностью, будет сам заботиться о приносимой пользе и будет знать, какие показатели для этого лучше использовать.

Заходите к командам и регулярно общайтесь с ними, поддерживайте, если нужна помощь и вы увидите, как они начнут чувствовать себя более защищенными, и одновременно с этим вырастет вовлеченность. И никакие метрики не понадобятся.

Итак, мой окончательный ответ


Эта статья началась с моего разговора с другим коучем, который спросил, какие две метрики я бы отслеживал.

Теперь, тщательно всё обдумав, я бы дал более взвешенный ответ:

Пусть решают сами команды. Нужно почаще заходить к ним и общаться чтобы они ощущали участие и поддержку.


Методология Agile ориентирована на то, чтобы команда работала сообща и совершенствовалась. Главное здесь не цифры, диаграммы или графики.

Пришло время сосредоточиться на том, чтобы повысить вовлеченность команды: поощрять автономность, целеустремленность и развитие профессионального мастерства. В том числе команде нужно отдать работу с метриками. Тогда можно будет заняться тем, чтобы создать рабочую среду и дать поддержку, необходимые для работы.

Особая благодарность Мацею Ярошу и Маартену Далмийну за их вклад в эту статью.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее
Подробнее..

Как хороший разработчик становится плохим менеджером

29.04.2021 20:16:38 | Автор: admin

Вертикальный рост для разработчика не всегда дается легко. В этой статье я поделюсь своей историей и проблемами, с которыми я столкнулась, размышлениями о причинах этих проблем и о том, как их можно было бы избежать.

Жизнь разработчика

Всю самостоятельную жизнь я пишу код. Продумываю как высокоуровневую структуру, так и детали, благодаря чему чувствую полный контроль над процессом работы. Так сложилось, что надо мной никогда не стояло формальных менеджеров, только продакт овнеры, непосредственно транслировавшие видение проекта команде.

В ремесле разработчика меня привлекает с одной стороны четкая структура работы, а с другой - творческая составляющая, смешанные в идеальной на мой взгляд пропорции. У меня всегда есть план, и мне чертовски нравится вычеркивать из него пункт за пунктом, оставаясь к концу рабочего дня с пустым списком и приятным чувством легкости.

Удовольствие от работы складывается из разного рода составляющих, но самое приятное - это когда долго размышляешь над проблемой и вдруг наконец прозреваешь, мозаика складывается в картину - о, такие моменты определенно стоят всех вложенных сил!

Бывают кранчи, куда без них, но это как выложиться на стометровке - делаешь быстро и максимум, а потом радуешься результату.

В то же время мне нравится взаимодействие с людьми - собрать команду на хакатон, игру или вечеринку, организовать процесс и продумать план - это про меня. Я с удовольствием читаю книги по психологии и управлению, мне нравится побуждать людей к действиям, и люди, что самое замечательное, прислушиваются ко мне. И вот однажды я задумалась, что могу больше, нежели просто писать код.

Не без душевных терзаний я сменила работу на более перспективную в плане карьерного роста, и через 9 месяцев стала тимлидом команды разработки, размер которой достигал в пике 12-ти человек, по большей части разработчики - фронт и бэк, а также аналитики, проджекты и QA.

При наставничестве технического директора я влилась в новую роль. Что изменилось? Всё.

Далее будем драматически бить в набат каждый раз, когда что-либо в новой картине мира ломает картину старую.

Жизнь руководителя

Для начала, я практически перестала писать код (бум!). Максимум - скрипты в CI/CD или правка горящего бага за ушедшего в отпуск разработчика. Как будто почву из-под ног выбили - я не могла избавиться от чувства, что ничего не делаю, потому что артефактов новая работа практически не оставляет.

В команде - четыре клиент-серверных проекта, стек технологий не у всех идентичен, и я с фронтовым бэкграундом офигела от количества вещей, в которых нужно разобраться еще вчера. Я потеряла привычный контроль (бум!), не могла оценить, хороши ли те или иные решения, и все больше руководствовалась принципом это решение в любом случае лучше, чем ничего, ведь сроки никто не отменял.

Сроки - отдельная боль. Я привыкла отвечать за себя, но внезапно оказывается, что другие люди - это не я (бум!). Они не думают как я и не умеют читать мои мысли. То, что само собой разумеется для меня, может оказаться абсолютно не так для других, и нужно вкладывать много усилий и времени в налаживание и оптимизацию коммуникаций внутри команды.

Нужно периодически общаться со стороной заказчика, а это крупные компании, которые продавливают свои интересы (бум!), раздувая пул моих срочных задач до нечеловеческих размеров. И в целом мне не то, чтобы очень комфортно общаться с незнакомыми людьми, а когда ты девочка и объясняешь собранию бородатых мужей из IT-департамента, что им нужно сделать в своей внутренней сети, чтобы мы могли интегрироваться, - стресс возрастает в разы.

Размеренная и сосредоточенная работа - в прошлом (бум!). Контексты переключаются очень, очень много раз за день: созвониться с заказчиком, разобраться с проблемой деплоя ревью-площадок, оценить новую фичу, помочь исправить косяк в гите, проревьювить приемочные тесты, обсудить с разработчиком затык в задаче, дополнить документацию, собеседовать кандидата, выпустить релиз, нарисовать диаграмму, кроме того - планерки, митинги, обсуждения, тушение пожаров... но чувства на славу потрудилась сегодня так и не возникает, как и радости от очередной решенной проблемы, потому что впереди их еще вагон.

Результат через полгода - замученная команда и замученный руководитель, который исчерпал свой энтузиазм и просыпается каждое утро с мыслью главное пережить этот гребанный день. В светлое будущее корабль с таким капитаном точно не уйдет.

Итог

Я ушла в другую команду в разработку внутреннего продукта, углубившись в бэкенд. Так или иначе сейчас у меня по-прежнему возникают околоуправленческие задачи, но их я уже решаю более осознанно и охотно - они уже не съедают всё мое время и меня в придачу. Размышляя над этим опытом, я выделила несколько основных своих ошибок, и если ты, дорогой читатель, твердо решил расти в менеджера, начинаешь этот путь или чувствуешь первые признаки проблем, возможно, моя ретроспектива поможет тебе справиться с трудностями.

Не своди все процессы на себя, ты под ними быстрее утонешь, чем обретешь контроль. Ты просто не можешь контролировать всё до мелочей так же, как это было раньше. Расставь приоритеты и доверься другим людям.

Береги свой внутренний ресурс. Научись абстрагироваться от рабочих проблем, даже если задач выше крыши. Каким образом это делать - решай сам, но на одной силе воли далеко не уедешь - проверено на личном опыте. В крайнем случае - есть психологи и психоаналитики.

Регулярно уделяй время развитию технической грамотности, чтобы чувствовать себя уверенно.

Определи для себя метрики успеха. Например, прошлый релиз ты спешно и безуспешно пытался закрыть в последний день спринта, а этот - уже за два дня до окончания, и вылезла из него всего одна задача. Прогресс? Прогресс. В прошлый понедельник после митинга с заказчиком ты до конца дня разгребал результаты встречи, а в этот - половину раскидал на сторону заказчика еще во время митинга, часть делегировал команде и в итоге потратил только полдня на разгребание. Замечательно же.

И да, работа - это не вся твоя жизнь, а только ее часть, и чтобы добиться успеха где бы то ни было, нужно соблюдать осознанный баланс.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru