Портал №1 по управлению цифровыми
и информационными технологиями

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

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

Где продукты – там и команда. Необходимо сильно ограничить область ответственности, выделить и закрепить ресурс на 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 ноября.

«Kanban Flow Metrics: управление потоковым производством на основе данных»
Тренажёр про метрики на реальных примерах

Комментариев: 12

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

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

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

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

      • Сергей

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

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

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

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

  • Игорь Бессонов

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

  • Я даже календарь проверил. Вдруг, думаю, первое апреля. Ан нет…

  • Сергей

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

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

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

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


Добавить комментарий для СергейОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM