Проекты сайтов и приложений, которые шли не по плану: четыре случая и что мы изменили

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

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

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

Один честный пример у нас опубликован, и он не про срыв сроков, а про расхождение ожиданий. Концепт-стор SHI TRENDY больше одиннадцати лет продавал через соцсети, где аудитория перевалила за 300 тысяч подписчиков, и в 2020 году вложился в собственный магазин и приложение. В кейсе прямо написано: мгновенного роста продаж запуск не дал. Дал другое — автоматизацию, снятую нагрузку с менеджеров, собственный продукт и независимость от чужих алгоритмов. По первой строке проект выглядит неудачей, по остальным трём — решает ровно ту задачу, ради которой затевался. Расхождение не в работе, а в том, какой результат назвали вслух на старте.

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

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

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

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

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

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

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

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

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

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

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

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

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