Как успешно убить проект без аналитики и дизайна

Очевидно, что без грамотного технического задания подступать к разработке бессмысленно, аналитика и UX/UI дизайны важны, однако не все заказчики это понимают. Еще до создания студии YuSMP Group, мне приходилось управлять проектами, в которых проигнорировали ТЗ и предварительные дизайны. Проекты были разными, а вот результат всегда один — заказчики теряли время и деньги.

В статье — три кейса из моего опыта: что происходит с проектом, если пропустить бизнес-аналитику и UI/UX-дизайн перед разработкой, и как правильно выстроить эти этапы, чтобы не повторить чужие ошибки.

Что входит в аналитику и дизайн перед разработкой

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

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

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

Кейс 1. Времени нет, погнали разрабатывать

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

Смотрите также: бизнес-аналитика и discovery.

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

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

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

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

Итог: Потерянное время, деньги, а также желание когда-либо заниматься запуском перспективных приложений. 

Сейчас я бы предложил двигаться по Scrum, но обязательно с техническими требованиями, кликабельным прототипом, сделав в самом начале дизайн-концепт.

Кейс 2. Нам достаточно только экранов приложения

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

Когда предложил аналитику для описания алгоритмов поведения системы, ответили: “Нам достаточно экранов приложения». Тогда я не стал спорить с заказчиком и мы успешно согласовали все экраны.

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

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

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

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

Кейс 3. Начали за здравие, закончили за упокой

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

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

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

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

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

Во сколько раз дороже исправить ошибку на разных этапах

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

Этап, на котором нашли ошибку	Во сколько раз дороже исправить, чем на этапе аналитики
Аналитика и дизайн	1× (базовая стоимость)
Разработка	≈3–6×
Тестирование перед релизом	≈10×
После запуска в продакшн	≈15–100×

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

Как не повторить эти ошибки

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

• Не начинайте разработку без зафиксированных требований — даже если клиент торопится. Кейс 1 показал: устные договорённости расходятся с ожиданиями уже через один спринт.
• Не ограничивайтесь только экранами приложения. Кейс 2 — без описания алгоритмов и бизнес-логики тестирование выявляет пробелы, которые дороже закрыть постфактум.
• Актуализируйте аналитику и дизайн при каждой правке. Кейс 3 — правки без синхронизации документации рассинхронизируют команду и клиента.
• Зафиксируйте оба артефакта письменно — техническое задание и дизайн-макеты, даже в сжатом виде, экономят и время, и деньги на дальнейших этапах.

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

Частые вопросы (FAQ)

Сколько времени занимает аналитика и дизайн перед разработкой?

Зависит от сложности проекта: бриф и анализ ЦА/конкурентов — от нескольких дней до двух недель, кликабельный прототип — ещё 1–3 недели, техническое задание пишется параллельно. В сумме — от одной до четырёх недель для среднего проекта, что значительно дешевле переделки после запуска разработки.

Можно ли пропустить дизайн и сразу перейти к разработке MVP?

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

Что делать, если сроки проекта уже горят?

Сократить аналитику до минимума — бриф, ключевые экраны и краткое ТЗ на 1–2 страницы, — но не убирать её полностью. Даже сжатая аналитика снимает большую часть рисков из кейса 1, где решение стартовать «прямо сейчас» без единого документа привело к месяцу без результата.

Кто участвует в аналитике и дизайне — только дизайнер?

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

Сколько стоит пропустить аналитику — в деньгах?

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

Как понять, что аналитики и дизайна было достаточно?

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