Портал №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-метод: практика построения быстрого потока»
Учебный курс, основанный на опыте консалтинга

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

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

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

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

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

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

      • Сергей

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

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

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

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

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

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

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

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

  • Сергей

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

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

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

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

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

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

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


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

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

  • Рубрики

  •  
  • Самое свежее

    • Определяем полюс потребителя
      При анализе и построении «путешествия заказчика» (customer journey) одной из важнейших задач является получение ответов на ряд вопросов, а именно: кто конкретно …
    • Семь распространённых мифов о DevOps
      В сообществе разработчиков бытует множество мифов о DevOps. И это и неудивительно, учитывая, сколько новшеств привнесла эта концепция за последние годы. DevOps — это …
    • Разрешение конфликтов в Agile-командах
      Большинство людей предпочло бы избегать конфликтов. Как специалисты по проектам, мы знаем, что это неизбежно, и мы также знаем, что несогласие может быть конструктивным. Но при …
    • Очередность прохождения курсов ITIL 4
      Имеет ли значение, в каком порядке проходить курсы по ITIL? Рассказывает аккредитованный тренер по ITIL 4 Игорь Фадеев. Cleverics — первая в России и одна из первых в …
    • 1 октября конференция «Роботизация бизнес-процессов 2020»
      1 октября 2020 издательство «Открытые системы» проведет ежегодную конференцию «Роботизация бизнес-процессов 2020» https://www.osp.ru/iz/rpa2020, где на одной площадке будут …
    • ITIL® 4 DITS — огонь, вода и медные трубы
      Мы уже писали о скором релизе последнего экзамена в сертификационной линейке ITIL 4 Digital and IT Strategy (DITS). Сейчас стоит добавить следующее (из информации, которую можно …
    • Как бизнес-аналитику встроиться в гибкую среду?
      Есть ли роль бизнес-аналитика в гибкой среде? Я уже довольно давно работаю бизнес-аналитиком, и этот вопрос возникает постоянно. Бизнес-аналитики  зачастую считают, что они должны …
    • Деловая игра Grab@Pizza: вкусный кейс
      Деловые игры – один из наиболее эффективных видов тренинга, позволяющий на основе близкого к реальному кейса попрактиковаться в выстраивании любой работы. Участники деловой игры …
    • ITAM & SAMday пройдёт в Москве 2 октября
      ITAM & SAMday  – всероссийская независимая конференция, посвященная вопросам управления ИТ-активами и программными активами — пройдёт в Москве 2 октября в режиме …
    • Бэклог! — Как много в этом слове ...
      Команды, работающие над развитием различных продуктов, имеют одну общую цель: обеспечить максимальную скорость изменения своего продукта для реализации возникающих потребностей …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT