В первой части мы познакомились с метриками: время цикла (Cycle time) и время выполнения (Lead time); пропускная способность (Throughput); баги и заблокированные рабочие элементы.

Крайний срок выполнения (Due-date performance)

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

Сбор данных

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

Визуализация метрики

Для такой метрики круговая диаграмма является наиболее подходящей. Она даёт быстрый обзор того, сколько рабочих элементов было выполнено в срок и просрочено.

Крайний срок выполнения (Due-date performance)

Анализ метрики

Метрику “крайний срок выполнения” вы можете использовать для общения с другими командами и заинтересованными сторонами. Она также помогает расставить приоритеты и мотивировать вашу команду. Если какой-то рабочий элемент отстаёт, в соответствии с прогнозируемой датой исполнения, вы можете изменить приоритеты. Например, сказав: «Мы же не хотим испортить нашу великолепную статистику?»

Располагая данной метрикой, вы можете выстроить доверительные отношения с командами вокруг и с вашими заинтересованными сторонами. Но она также может привести к обсуждению вопросов по улучшению процесса.

Качество (Quality)

Измерение качества работы и определение ценности функций, которые поставляются заинтересованным сторонам и клиентам, определенно важная метрика.

Метрика “качество” отлично подходит для использования в качестве балансирующего показателя для других улучшений, например, времени выполнения (Cycle time). По ней так же можно увидеть, окупаются ли ваши усилия по затратам времени в улучшение качества (автоматическое тестирование, погашение технического долга и т. д.).

Качество – сложное понятие. Его можно интерпретировать по-разному. Мы примем определение Джеральда Вайнберга: «Качество – это ценность для кого-то».

Сбор метрики

Существует множество показателей качества, которые вы можете легко отследить:

  • Количество дефектов/ багов на сборку или на релиз продукта. Лучше всего определить, как тенденцию, показывающую, как число меняется с течением времени.
  • Количество возвращенных рабочих элементов на исправление на канбан-доске за единицу времени. Оно показывает, сколько ваших ресурсов тратится на исправление багов.

Если метрики легко отслеживать, это не значит, что их стоит отслеживать.

Важно отслеживать не количество дефектов, а конечную ценность для потребителя.

Как узнать, создали ли вы ценность для клиента? Ответить на него можно, только спросив тех, для кого вы хотите создать ценность. Существует много разных способов сделать это: опросы и интервью, количество лайков в Facebook и т.д.

Google Analytics, Optimizely и Google Tag Manager являются общими инструментами для веб-сайтов, которые отслеживают трафик, действия пользователей. Они могут дать вам много информации о качестве продукта и функциях, которые вы создаёте.

Визуализация метрики

Метрики качества могут принимать различные формы, поэтому я не могу дать вам хороший совет по одному из способов визуализации вашего. Я могу сказать это: сделайте это большим, сделайте это визуальным, и поместите это в стену. Панель инструментов Google Analytics на экране рядом с командой привлечёт много внимания и вызовет похвалы, вопросы и дискуссии – именно то, что вы хотите, чтобы улучшить ещё больше.

Анализ метрики

Если вам удастся найти метрику для измерения ценности, у вас окажется информация для аналитики. Затем вы можете внести небольшие изменения в свой продукт (эксперименты) и посмотреть, как изменяемые вами показатели меняются в зависимости от них. Это может даже пригодиться для A/B-тестированию, то есть к выпуску двух версий одной и той же функциональности, и просмотру, какая из них работает лучше.

Запрос на ценность и запрос на исправление

Запрос на исправление – это понятие, изобретённая профессором Джоном Седдоном. Он может быть понят как «запрос клиента, вызванный неспособностью что-либо сделать или сделать что-то не так, как хотел клиент». Противоположностью запросу на исправление является запрос на ценность. Запрос на ценность означает то, что вы хотите получить в продукте. Само собой разумеется, что вы хотите минимизировать запросы на исправления.

К сожалению, примеров запросов на исправление предостаточно. Они могут варьироваться от необходимости повторного выполнения работы из-за плохих спецификаций, непонимания друг друга, ошибок и дефектов. Запрос на исправление включает в себя все, что отвлекает вас от поставки новой функций, которые оказывают влияние на бизнес.

Измерить запрос на исправление в сравнении с запросом на ценность может быть сложно.

Сбор метрики

Из-за того, что иногда трудно классифицировать рабочие элементы, также может быть сложно собрать данные по метрике. Я предлагаю найти простой способ классификации рабочего элемента. Например, голосование в конце поставки рабочего элемента. Этот элемент был запросом на исправление или запросом на ценность? Некоторые рабочие элементы (например, дефекты) естественно попадают в категорию запрос на исправление.

Визуализация метрики

Если у вас есть способ классифицировать запрос на исправление по сравнению с запросом на исправление, вы можете визуализировать тренды в виде двух графиков. Или вы можете написать процент на доске: «На прошлой неделе у нас было 25% запросов на исправление, что на 10% меньше, чем неделей ранее».

Анализ метрики

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

Оставленные и выброшенные идеи

Эта метрика, которую легко упустить из виду, потому что мы, используя гибкие методы, поощряем изменения. Даже в слове agile – возможность быстро меняться. Но сколько команд вы видели, считая идеи или рабочие элементы, снятые с доски? Часто их выбрасывают и не думают, пока они не всплывают.

Сбор метрики

Простой способ отследить элементы, которые вы снимаете с доски, – это иметь корзину, куда вы перемещаете рабочие предметы, которые вы выбрасываете. Затем вы можете записать эти элементы и, возможно, даже подсчитать количество отвергнутых идей за единицу времени (например, за неделю или месяц). Эти данные могут стать контекстом для плодотворного обсуждения позже.

Анализ метрики

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

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

Визуализация метрик является важной частью создания метрики известной и важной для всех в команде и людей в команде. Хотя простые диаграммы в этом разделе – отличное начало, следующий раздел углубляется в две хорошо известные и мощные диаграммы: диаграммы управления процессом и кумулятивные схемы.