Продуктовым командам метрики не нужны

Модное течение последних лет заключается в отказе от управления проектами в пользу управления продуктами. Долгое время мы пытались получать ценность от информационных технологий (и, соответственно, от ИТ-специалистов и ИТ-руководителей) с помощью проектного подхода: назовём важное изменение проектом, запланируем, выделим ресурс, постараемся уложиться в ограничения. В некоторых случаях срабатывало хорошо, в последнее время — не очень. Теперь ставку делают на управление продуктами как интересную и перспективную альтернативу.

Где продукты — там и команда. Необходимо сильно ограничить область ответственности, выделить и закрепить ресурс на 100% времени, посадить всех рядом, объявить единую цель, начать работать по новым принципам организации труда. Без этого всего управление продуктом будет номинальным, а тогда и пользы случится не больше, чем от проектного подхода.

Так мы приходим к продуктовой команде.

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

Начнём с рассмотрения утверждения, приведённого на один абзац выше, в классике формулируемого так: нельзя управлять тем, что не измеряешь. Авторство приписывают Питеру Друкеру, авторитет которого, разумеется, под сомнение никто ставить не собирается. Но есть три нюанса: во-первых, оригинальная цитата звучит так: «If you can’t measure it, you can’t improve it». Согласимся, что между manage и improve всё же есть разница, отсюда вывод — вполне можно управлять (manage), не измеряя.

Во-вторых, П.Друкер такого никогда не утверждал. Напротив, он утверждал ровно обратное: «It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth».

В-третьих, примеры управления, в том числе успешного, не опирающегося на измерения, видны повсюду. Далеко ходить не нужно, эксперимент будет коротким. Посчитайте, какая доля из сотен решений, которые вы, ваши подчинённые и ваши руководители приняли на прошлой неделе, основана на объективных данных? Согласимся, что в лучшем случае 10-15%, отсюда снова вывод — вполне можно принимать решения, то есть управлять, не опираясь на данные, то есть ничего не измеряя.

Рассмотрим второй аргумент. Не следует забывать, что измерение продуктовой команды — это противоестественно, ведь команда есть группа людей. У людей, в отличие от машин, бизнес-процессов и CMDB, есть мнения, устремления, мотивация и прошлый опыт. Всё это подсказывает той самой группе, что как только начнут измерять — жди беды в виде KPI, SLA, уменьшенной квартальной премии и прочих неприятностей. Никто в таких условиях продуктивно работать не станет, мотивация снизится, отсюда вывод — не нужно расстраивать специалистов творческих профессий какими-то там метриками. Станет только хуже.

Наконец, третий аргумент, наиболее сильный. Что именно, собственно говоря, измерять в продуктовой команде? Процесс? Не интересно, да и некому, ведь настоящая продуктовая команда работает без начальника, а значит метрики процесса некому анализировать, некому делать выводы. Измерять результат? Так это невозможно. Мартин Фаулер, уважаемый эксперт, ещё в 2003 году доказал, что в ИТ в целом и в разработке ПО в частности невозможно измерить продуктивность. Хуже того, М.Фаулер утверждает: «The reason we can't measure productivity is because we can't measure output». То есть, буквально — невозможно измерить результаты. Это знает каждый, кто пытался оценить в рублях или иных разумных единицах измерения результаты работы продуктовой команды. Поток мелких доработок в продуктах, ориентированных на внешних клиентов (сайты, мобильные приложения и прочее модно-технологичное), невозможно объективно сопоставить с изменением бизнес-показателей. А доработки внутренних систем (ERP, MRP, Supply Chain, АБС и прочее устаревшее) тем более никак нельзя соотнести с экономической эффективностью компании.

Итак, двигаясь в сторону продуктового подхода, про метрики можно забыть. Продуктовой команде они не требуются. Сойдёт и так.

Чуть более подробно на данную тему я буду рассуждать вслух на конференции «Корпоративный DevOps», которая пройдёт в Москве в ближайший вторник, 26 ноября.

DevOps Основы DevOps

Популярный трёхдневный учебный курс
 

Проект Феникс — DevOps на практике

Полезная деловая игра для вашей команды
 

Узнайте больше!

Комментарии и мнения

  1. Владимир Невский

    Мысль интересная. А как же тенденции последних лет, которые направлены на цифровизацию/измерению спорта/искусства?

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

    1. Олег Скрынник Автор

      Количество инцидентов считать как метрику нет смысла. Легенда пионеров (которые уже ушли далеко вперёд) гласит: каждый инцидент — событие, требующее всей команде быстро бросить работу и устранить (swarming), а потом раскопать причины; так что инцидентов у продуктовой команды много быть не может. А раз их немного, то и считать их за период не требуется.

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

      2
      2
      1. Сергей

        Смотря на какой стадии продукт. Если это MVP или еще хуже — RAT и их цель проверить востребованность продукта, то инцидентов может быть масса.

        Да и если в разработке продукта важен тайм ту маркет, это тоже меняет подход к инцидентам.

        1. Олег Скрынник Автор

          Одно из пониманий MVP — быстренько сделать часть работы и выдать в прод, чтобы хоть что-то было, так как полностью решение будем делать долго.

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

          Насколько я знаю, ни первое, ни второе не имеет отношения к изначальной идее, которую сформулировал Эрик Райс. И даже к тому, куда эта идея развилась в последнее время.

  2. Игорь Бессонов

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

  3. Сергей

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

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

  4. Олег Скрынник Автор

    Друзья и коллеги!

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

    Поэтому я решил повторить выступление и сделать его в формате вебинара. Готов подробно поделиться своими соображениями в январе следующего года (это не так далеко, как кажется).

    Регистрация уже открыта: cleverics.ru/subject-field/webinars

    Буду рад всех видеть.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
16
Учебный курс:
ITIL® 4 Managing Professional Transition 
ДЕК
23
Учебный курс:
ITIL® 4 Foundation (очно)