Кейс восстановлен по материалам выступления на FlowDays 23. Смотреть запись.
Проблема была не в Jira
Новую продуктовую команду собрали из специалистов, которые продолжали работать в нескольких технических системах и Jira-проектах. Каждый проект хорошо показывал локальные задачи, но руководителю продукта приходилось открывать 10–15 экранов, чтобы понять состояние одной клиентской функции.
На уровне компании это создавало три риска:
- статус продукта зависел от ручной интерпретации отдельных людей;
- техническая занятость выглядела как прогресс клиентского результата;
- зависимости становились видны слишком поздно, когда срок уже находился под угрозой.
Мы пытались решить проблему агрегирующей доской. Она загружалась 15–20 секунд, содержала слишком много карточек и оставалась непригодной для управленческого разговора. Улучшение интерфейса не решало вопрос: организация управляла не той сущностью.
Ошибка первой модели
Работа была организована вокруг задач разработчиков. Tech Lead видел специализации и мог распределять следующую карточку. Для локального контроля это удобно, но клиентский результат приходилось собирать из десятков технических фрагментов.
Попытка сгруппировать задачи по Epic с помощью swimlane тоже не сработала. Количество деталей осталось прежним, а связь с клиентским эффектом по-прежнему требовала устного перевода.
Для C-level это типичная ловушка инструментальной прозрачности: данных становится больше, а способность принять решение не растёт.
Решение: Customer Recognizable Item
Мы ввели единицу управления, которую способен узнать клиент: функцию или изменение поведения продукта. Она стала верхним уровнем работы, а технические задачи остались внутри неё.
Это разделило два необходимых контура:
- руководители и Product Owner отслеживали движение клиентского результата;
- специалисты управляли техническими шагами и зависимостями внутри результата.
Новая доска показывала одну продуктовую историю вместо суммы занятости по компонентам. Старые технические доски не запретили: они постепенно потеряли роль главного источника статуса, потому что новая модель лучше отвечала на вопросы команды и бизнеса.
Почему переход занял три месяца
В начале Tech Lead хотел видеть работу каждого разработчика и назначать следующую задачу. Прямое убеждение не сработало. Команде понадобилось около трёх месяцев, чтобы столкнуться с пределом task-centric модели и сформулировать потребность в другом объекте управления.
Для руководителя здесь важна организационная сторона. Изменение информационной модели затрагивает полномочия: кто распределяет работу, кто определяет прогресс и кто отвечает за общий результат. Настройки поля или доски для такого перехода недостаточно.
Что изменилось
Вместо 10–15 разрозненных экранов появился один продуктовый обзор. Бизнес и разработка получили общий объект разговора. Общие проблемы — зависимости, задержки и неясный клиентский результат — стали видны раньше технических симптомов.
Кейс не содержит надёжных данных о росте выручки или сокращении Lead Time, поэтому мы не выдаём улучшение прозрачности за финансовый результат. Подтверждённый эффект — снижение когнитивной нагрузки и переход от контроля занятости к управлению завершённой клиентской функцией.
Когда модель полезна
Такой переход оправдан, если:
- одна клиентская функция проходит через несколько систем или команд;
- руководителю приходится вручную собирать статус из технических отчётов;
- бизнес и разработка используют разные единицы планирования;
- команда уже умеет доводить технические задачи до конца, но теряет общий результат.
Если организация не может назвать клиентский результат и владельца его метрики, новый тип карточки станет ещё одним контейнером.
Что осталось нерешённым
Мы не считали себестоимость каждой функции и не вводили ограничение параллельной работы на уровне CRI. Модель также не заменяет портфельную приоритизацию и управление мощностью. Это следующий управленческий слой, а не свойство доски.
Вывод для C-level и фаундера
Единица управления определяет поведение организации. Верхний уровень с задачами специалистов направляет внимание руководителей на загрузку. Верхний уровень с клиентским результатом — на срок, зависимости, ставку и ценность.
Перед созданием новой управленческой панели стоит проверить: какую сущность она делает видимой и какое решение по ней должен принять руководитель?