Модное течение последних лет заключается в отказе от управления проектами в пользу управления продуктами. Долгое время мы пытались получать ценность от информационных технологий (и, соответственно, от ИТ-специалистов и ИТ-руководителей) с помощью проектного подхода: назовём важное изменение проектом, запланируем, выделим ресурс, постараемся уложиться в ограничения. В некоторых случаях срабатывало хорошо, в последнее время – не очень. Теперь ставку делают на управление продуктами как интересную и перспективную альтернативу.
Где продукты – там и команда. Необходимо сильно ограничить область ответственности, выделить и закрепить ресурс на 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 ноября.
Мысль интересная. А как же тенденции последних лет, которые направлены на цифровизацию/измерению спорта/искусства?
Программные продукты измеряются методом функциональных точек: в первую неделю после выпуска релиза по кол-ву зарегистрированных инцидентов на 1 функциональную точку можно судить о качестве работы продуктовой команды. Не так ли?