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

Риск 1. Изолировать дизайнеров от разработчиков

Многие клиенты привыкли следовать старым схемам: сначала полностью проектировать продукт, рисовать дизайн, а только потом отдать его разработчикам. Так устроены Waterfall, V-Model и другие линейные методики управления проектами.

Похожая ситуация, когда заказчик говорит: «У меня классные разработчики, но не дёргайте их. Просто отдайте им макеты, они всё поймут и сделают без вопросов». Такой подход — прямая дорога к разочарованию и перерасходу бюджета.

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

Макеты — это лишь визуальное представление идеи, а контекст, цели проекта и логика взаимодействия с пользователем часто остаются за кадром. Если дизайнеры рисуют интерфейсы в изоляции, а разработчики просто «натягивают» их на код, возникает куча проблем:

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

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

Пример из практики

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

Как лучше?

Команда должна работать как единое целое:

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

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

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

Наш опыт

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

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

Дизайнеры Brele всегда начинают с понимания задачи: разбираются в сути продукта, проверяют на себе внутренние процессы, чтобы узнать, как всё работает. Например, в проекте Freedom Football Manager дизайнер изучал компьютерные игры, чтобы создать удобный и интуитивно понятный интерфейс платформы для футбольных тренеров.

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

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

Риск 2. Бесконечная разработка и откладывание запуска

Распространенные риски в разработке — зациклиться на доработке IT-продукта и так и не выпустить его на рынок. Можно бесконечно улучшать детали, бояться, что продукт «недостаточно хорош», но в итоге просто потерять время и деньги.

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

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

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

Пример из практики

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

Как лучше?

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

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

Вернёмся к примеру с маркетплейсом и системой возвратов. Если бы до дедлайна запуска IT-продукта оставалось 2 месяца, то стало бы ясно, что без продаж возвраты вообще не нужны. Команда сосредоточилась бы на запуске, а возвратами занялась уже после первых сделок.

Наш опыт

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

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

Один из подходов, которые мы используем для быстрого запуска — это FFF: Fix Price, Fix Budget, Flex Scope. Суть в том, что у проекта есть фиксированные сроки и бюджет, которые не дают ему раздуваться бесконечно. При этом есть гибкость в функционале, она позволяет адаптироваться к изменениям, сохраняя контроль над ресурсами. Такой подход помогает держать фокус на главном и не распыляться на детали.

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

Риск 3. Ключевой ЛПР не вовлекается в проект

Один из частых рисков при запуске IT-продукта — в проект не вовлекаются ключевые лица, принимающие решения (ЛПР). Основатели, инвесторы или топ-менеджеры, которые придумали идею и выделили бюджет, должны быть в курсе происходящего. Иначе есть риск, что финальный результат окажется не таким, как они ожидали.

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

У ЛПР есть своё видение продукта. Однако в крупных проектах они часто отстраняются от операционной работы, делегируя принятие решений команде менеджеров. Те, в свою очередь, принимают продуктовые решения, а не бизнесовые. Это приводит к тому, что:

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

Пример из практики

Бывает, что при первом контакте с заказчиком мы слышим: «Я здесь принимаю решения». Но когда начинаем разбираться, выясняется, что есть ещё руководство, инвесторы или генеральный директор, чьё мнение тоже важно. Нам говорят: «Не волнуйтесь, я всё согласую», но это далеко не всегда работает.

Если ключевой ЛПР не вовлечен с самого начала, велика вероятность, что после полугода работы он скажет: «Это не то, переделывайте». В итоге — потерянное время, деньги, стресс для всех участников процесса и перенос срока запуска.

Как лучше

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

Конечно, ЛПР не должны участвовать в ежедневных обсуждениях, но их вовлечение в ключевые этапы — критически важно.

Наш опыт

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

Мы стремимся привлечь ЛПР на таких ключевых этапах:

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

Мы понимаем, что у ЛПР плотный график, поэтому используем видео, презентации и краткие сводки, чтобы минимизировать их вовлечение без потери контроля. Главное — не превращать финальный результат в неожиданность для тех, кто в итоге принимает решение.

Если у вас есть замысел проекта, но вы сомневаетесь в успехе, то мы в Brele поможем вам предусмотреть все риски. Чтобы обсудить проект, просто заполните форму в правом верхнем углу страницы.