Портал №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 ноября.

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

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

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

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

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

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

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

      • Сергей

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

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

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

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

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

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

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

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

  • Сергей

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

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

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

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

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

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

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


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

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

  • Рубрики

  •  
  • Авторы

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

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT