Как управлять ИT-проектом, когда требований нет и всё меняется каждую неделю

Автор: Пётр Третьяк, руководитель проектов компании Faktura

Знакомая реальность

За пять лет в управлении проектами я выучил одну вещь: самая опасная фраза на старте — «мы точно знаем, что нам нужно». Самая же частая и честная — «давайте начнём, а по ходу разберёмся».

Примерно два года назад ко мне пришла компания — средняя розничная сеть. Задача звучала бодро: мобильное приложение с программой лояльности, кэшбэком и акциями. Срок — пять месяцев, к началу высокого сезона. На руках у заказчика не было ни ТЗ, ни макетов, ни внятного описания механик. Было понимание, что «надо догонять конкурентов» и что «мы сами пока не знаем, как лучше».

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

Самые сложные проекты — не те, где много задач, а те, где никто точно не знает, какие задачи вообще нужны.

Руководитель проектов компании Faktura Пётр Третьяк
Источник фото: Faktura

Почему так происходит

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

Такая картина — не редкость. Причины типовые:

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

Важно сразу снять иллюзию, что идеальное ТЗ обязательно появляется до старта. Часто это не так, и это не провал, а просто исходная среда.

Главная ошибка менеджера в такой ситуации

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

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

Так я понял: в условиях неопределённости PM, который пытается создать ложное ощущение порядка — фиксировать всё слишком рано, обещать точные сроки, составлять бэклог на полгода, «замораживать» изменения, давить на команду ради плана, — делает только хуже. План устаревает, команда выгорает, клиент разочарован.

Скриншот из десктоп-версии программы Slack
Источник фото: Faktura

Что работает на практике: подход вместо жёсткого плана

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

Ниже — пять принципов, которые я применил тогда и повторял потом на других проектах, где среда похожа на туман.

Принцип №1. Дробите проект на короткие циклы

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

Что это дало:

• Быстрый результат. Уже через пару недель заказчик видел работающий прототип экрана с парой сценариев, а не слушал рассказы про стадию «проработки архитектуры».
• Раннюю обратную связь. Когда мы показывали готовый кусок маркетингу, те быстро понимали, что на словах выглядело красиво, а на экране неудобно. Правки вносились раз в две недели, а не раз в полгода.
• Меньше дорогих ошибок. Мы не уходили вглубь разработки сложных механик, пока не убеждались, что направление верное.
• Понятный фокус команды. Разработчики точно знали, над чем работают прямо сейчас, и не распылялись.

Принцип №2. Фиксируйте не требования, а гипотезы

Вместо фразы «нужно сделать систему кэшбэка» мы стали записывать: «Мы предполагаем, что автоматическое начисление баллов за покупки увеличит средний чек на 7 %. Чтобы проверить это, сделаем упрощённый механики на две недели и покажем на тестовой группе пользователей».

Каждая «хотелка» обрабатывалась так:

• предполагаем эффект для пользователя или бизнеса;
• делаем минимально достаточную версию для проверки;
• собираем фактические данные или качественную обратную связь;
• решаем — развивать, менять или отказываться.

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

Скриншот из таск-менеджера Trello
Источник фото: Faktura

Принцип №3. Управляйте ожиданиями заказчика

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

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

Я сказал: «Это нормальная практика для проектов, где продукт ищет свою форму. Мы будем прозрачно показывать прогресс, а вы будете принимать решения на основе реальных данных, а не догадок». Такой подход снял напряжение: заказчик увидел, что мы не пытаемся угадать, а системно ищем рабочие решения.

Принцип №4. Держите прозрачный приоритет задач

Когда идей много, делать всё сразу нельзя. Мы ввели простую систему приоритетов:

Каждые две недели на планировании мы вместе с бизнесом пересматривали список и договаривались, что берём в следующий спринт. Если кто-то из стейкхолдеров прорывался с новой срочной идеей, я показывал таблицу и спрашивал: «Это важнее того, что уже запланировано? Если да, то что мы отодвигаем?». Такая наглядность быстро научила всех здоровому прагматизму.

Скриншот из веб-версии таск-менеджера Jiro
Источник фото: Faktura

Принцип №5. Защищайте команду от хаоса

Команда не должна быть громоотводом для всех входящих пожеланий. Я определил для себя две роли:

Фильтр. Все новые идеи и правки попадали сначала ко мне или аналитику. Мы задавали уточняющие вопросы, проверяли, не противоречит ли это текущим гипотезам, и только потом приносили задачу в работу. Если просьба была явно сиюминутной и не критичной, она записывалась в список «На будущее» и не дёргала разработчиков.

Пакетная обработка. Мелкие правки мы накапливали в специальной странице в Notion — «Парковка изменений». Раз в два дня я просматривал её вместе с техлидом, и мы решали, что можно включить в текущий спринт без ущерба, а что пойдёт в следующий. Команда получала изменения порционно, а не непрерывным потоком.

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

Скриншот из десктоп-версии программы Notion
Источник фото: Faktura

Мини-кейс из практики

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

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

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

Главный вывод

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

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