Как консультанту объяснить заказчику ценность общего бэклога и превратить поток запросов в управляемую систему?

Как начиналась работа

Наш проект начинался достаточно стандартно — как и любой проект, выполняемый руками интегратора. На старте у нас было только верхнеуровневое ТЗ. С нашей стороны у заказчика работали две команды из разных бизнес-единиц, которые сразу столкнулись с постоянно уточняющимся пулом требований и идей. Часть из них мы проверяли через PoC, поэтому приоритеты, состав работ и их зависимости регулярно менялись. 

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

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

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

Контекст проекта

Речь идет о проекте по внедрению BI-системы для финансового планирования и бюджетирования в крупной ритейл-компании. В проекте у нас была сборная команда из двух департаментов: 

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

• Вторая команда занималась подготовкой данных заказчика для ввода в систему (DE-разработка). 

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

На момент нашего прихода Jira уже использовалась в компании заказчика. Но в рамках проекта задачи и договоренности через нее не вели. Мы предложили изменить это и начать использовать Jira как общее Kanban-пространство, а Confluence — для хранения инструкций и документации.

Ключевые боли на проекте

Всего их пять:

• Непрозрачность поступления запросов. Важные запросы из рабочих чатов по текущим проблемам терялись в общем потоке сообщений, где обсуждались и будущие этапы проекта. Разделение коммуникации на несколько чатов по частям проекта не помогало держать все в фокусе внимания;

• Бизнес-задача и техническая реализация существовали отдельно. Часто описание задачи ограничивалось только краткой формулировкой проблемы, идеями или предложениями о том, как ее можно решить. Отсутствовал зафиксированный на «бумаге» бизнес-контекст;

• PoC не был ограничен минимальным сценарием проверки основной механики. Его требования почти полностью совпадали с требованиями к целевому решению. В результате команда фактически разрабатывала полноценную функциональность без заранее определенных референсных точек, по которым можно было бы проверить гипотезу на раннем этапе;

• Не было приоритизации задач. Все хотелки бизнес-пользователей горели со статусом «нужно сделать вчера». Было сложно определить срок решения по каждой задаче из-за постоянного переключения между частями проекта. Вариант «залить ресурсом» даже не рассматривался, потому что целесообразность и рост стоимости проекта были неочевидны.

• Не было истории изменений и уточнений по задаче. Все причины и следствия изменений хранились только в памяти участников встреч, а блокеры (нехватка доступов, доработка в смежной системе заказчика, согласования и т. д.) часто терялись, поэтому их решение занимало больше времени.

Основная проблема

На мой взгляд, она заключалась не в отсутствии Agile и не в проектном подходе как таковых, а в несовпадении моделей ожиданий. Заказчик в проектном подходе ожидает законтрактованный объем работ, выполненный к указанному сроку. При этом в гибкой методологии ожидается наличие изменений, пересмотр приоритетов и изменение последовательности в задачах. Тут и рождается конфликт:

• Гибкость в глазах заказчика воспринимается как уход от обязательств по выполнению объемов в рамках дедлайнов;

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

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

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

Что получает заказчик, если согласится работать с консультантом через единый бэклог? 

• прозрачность текущего и будущего объема работ;

• единый источник правды для всех договоренностей;

• возможность влиять на порядок работ через смену приоритетов;

• понятное разделение на задачи «сделать сейчас» и «обсудить позже»;

• явное отображение зависимостей;

• история решений и изменений приоритетов;

• предсказуемое планирование сроков;

• меньше повторных обсуждений и потерянных запросов.

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

Обработка возражений

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

Возражение 1. «Мы маленькая команда, можем договориться в чате» 

Ответ: Мы не предлагаем полностью отказаться от чатов в пользу трекера. Чат остается местом для быстрого обсуждения, а трекер фиксирует итог: что решили, кто отвечает и что будет дальше.

Казалось бы, зачем нам отдельный процесс управления задачами? Можно написать в чате, созвониться и договориться. На практике через несколько недель у нас появились задачи из переписки, устные обещания, срочные просьбы заказчика и несколько вариантов того, что именно означает «готово». 

В рабочих чатах можно быстро обсудить короткие вопросы или договориться о срочной встрече, но в них сложно:

• получить полный список всех обязательств с привязкой к ответственным лицам;

• отслеживать задачи, одновременно выполняемые одним и тем же исполнителем (конкуренция за ресурс);

• проследить историю задачи и ее решения;

• определить первоначальные договоренности;

• показать текущее объективное состояние проекта.

Возражение 2. «Зачем нам заводить все задачи в вашу систему? Вы хотите нас контролировать?»

Ответ: Мы не предлагаем фиксировать каждое обращение от заказчика как обязательство. В трекер попадает только согласованный результат обсуждения: описание проблемы, ожидаемый эффект от ее решения, текущий приоритет и дальнейшие шаги.

Трекер не должен превращаться в инструмент контроля заказчика или формального поиска виноватых. Заказчик должен получить возможность влиять на порядок работ и видеть последствия своих решений.

Важное замечание: Трекер не превращает каждое пожелание заказчика в обещание подрядчика. Он помогает разделить пожелание, согласованную задачу и принятое обязательство.

Возражение 3. «У нас уже есть план проекта» 

Ответ: План проекта и бэклог решают разные задачи. 

План фиксирует проектные ожидания на низком уровне детализации: ключевые вехи, этапы, контрольные точки, ожидаемые результаты, сроки и ответственные, а также отвечает на вопрос: «Какими большими шагами мы придем к целевому результату?» 

Бэклог детализирует выполнение работ внутри этих этапов. Он отвечает на другой вопрос: «Какие конкретные задачи, зависимости, уточнения и решения нужны, чтобы пройти ближайшую веху?» 

Они не конкурируют, а дополняют друг друга.

• План проекта = крупные этапы и контрольные точки

• Бэклог = управляемый список изменений проекта и фиксация текущих результатов.

План проекта

  └── Этап

        └── Результат этапа/Веха

              └── Бэклог задач, PoC, зависимости и уточнения

В консалтинге план часто фиксируется на уровне крупных этапов:

• Инициация: подтверждение бизнес-целей, границ и участников проекта;

• Планирование и проектирование: подход к реализации, целевая архитектура, верхнеуровневый план;

• Реализация и проверка: выполнение работ командами, создание прототипов, проведение демо;

• Мониторинг и контроль: проверка результатов работы, подготовка инструкций, исправление критических замечаний;

• Закрытие и передача проекта: передача функционала и документации заказчику.

Схема соответствует логике PMBOK: инициация, планирование, исполнение, мониторинг и контроль, закрытие. При этом реализация и контроль в проекте идут параллельно, а не строго последовательно.

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

• проверка качества показателей по новой метрике;

• изменение логики расчета;

• проведение демонстрации;

• расширение этапа при появлении новых, характерных для него, вводных.

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

Возражение 4. «Давайте сейчас не будем тратить время на приоритеты. Просто делайте все, что просим, а потом разберемся, что было важнее.» 

Ответ: Если взяться за всё одновременно, команда начинает переключаться между сценариями, а подготовленные данные и прототипы могут оказаться невостребованными.

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

В консалтинге команда не реализует запрос буквально, а помогает заказчику решить его реальную задачу. Поэтому перед началом работы важно уточнить: «Какой результат сейчас принесет наибольшую пользу проекту и какую гипотезу необходимо проверить первой?»

Если использовать общий бэклог, можно:

1. зафиксировать все запросы: реалистичные и амбициозные;

2. выделить бизнес-ценность каждой доработки;

3. отделить подтвержденные обязательства от гипотез;

4. выбрать ближайший PoC;

5. ограничить его объем минимальным сценарием;

6. заранее определить критерий проверки;

7. после демонстрации решить, развивать гипотезу, изменить подход или остановить работу.

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

Возражение 5. «Бэклог быстро устареет» 

Ответ: Да, бэклог будет меняться. Но это не недостаток, а отражение изменений в проекте. При фиксации изменений в переписке теряется понимание того, как именно меняются приоритеты и как они влияют на весь проект.

Чтобы отразить изменения, необходимо зафиксировать ответы на следующие вопросы:

1. Что появилось или изменилось в проекте?

2. На какую задачу это изменение влияет и насколько сдвигает сроки по ней?

3. Почему новое решение важнее уже существующего?

Пожалуй, это все основные барьеры, которые могут возникать при внедрении такого подхода. Но согласиться с идеей — это лишь половина дела. Как именно мы организовали работу с этим бэклогом, какие статусы использовали и как превратили поток хаотичных запросов в управляемый процесс? Расскажу во второй части, где подробно разберу механику нашей Kanban-доски, жизненный цикл задачи и реальные примеры того, как этот инструмент помог передать проект заказчику в виде «живой» карты развития.