Теневые этапы разработки сайта: о чём молчат студии, когда вы заказываете проект

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

Все эти этапы — классика. Они есть в любой книжке по управлению проектами. Но если вы хоть раз сталкивались с реальной разработкой веб-сайтов, то знаете, что между «мы всё подписали» и «вот ваш готовый сайт» лежит целая пропасть. И в этой пропасти часто теряются деньги, нервы и сроки. Почему? Потому что существует целый список этапов, о которых вам никто не скажет вслух. Это теневая сторона разработки. И сегодня мы разберем, какие этапы при разработке веб сайтов отсутствуют в официальных сметах и договорах, но на деле занимают 50% времени и ресурсов.

Этап первый: Синдром пустого листа и бесконечные правки «просто попробовать»

Вы думаете, что работа начинается с брифа? Как бы не так. Всё начинается с тишины. Заказчик получает первый прототип и… зависает. Потому что одно дело — фантазировать о классном сайте, и совсем другое — видеть его конкретные очертания.

Этот этап не прописывают в коммерческом предложении. Он называется «Согласование вкусовщины». И вот тут происходит самое интересное. Начинаются фразы: «А давайте попробуем сделать кнопку не здесь, а чуть левее?», «А что, если мы уберем этот блок? Хотя нет, верните, но сделайте его полупрозрачным». Это не этап разработки в классическом понимании. Это этап «нащупывания» реальности.

Почему о нем молчат? Потому что это этап, который нельзя точно оценить в часах. У одной команды он займет день, у другой — месяц. И чаще всего эти итерации входят в фиксированную стоимость как «расходы на коммуникацию», но никогда не выносятся в отдельную строку. Хотя по факту — это полноценный цикл разработки гипотез и их проверки на коте, то есть на заказчике.

Психологическая адаптация заказчика к новому интерфейсу

Знаете, какие этапы при разработке веб сайтов отсутствуют в любом учебнике? Этап привыкания. Когда вы смотрите на свежесделанный дизайн, ваш мозг паникует. Ему всё непривычно. Это не тот сайт, который вы представляли в голове, даже если дизайнер сделал круче. И начинается саботаж.

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

Этап «Археология»: копание в legacy-коде и чужих ошибках

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

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

Бесконечный сбор контента: как выбить текст из заказчика

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

Этот этап называется «Административный ад». Он не про разработку, он про менеджмент. Исполнитель превращается в няньку: пишет напоминалки, звонит, просит, убеждает. Формально сайт готов на 90%, но запустить его нельзя, потому что нет контента. В голове заказчика это время идет впустую, и он начинает нервничать, хотя проблема не в разработчиках, а в его собственной неорганизованности. Опытные команды закладывают буферное время на этот этап, но в списке услуг вы прочтете лишь сухое «наполнение контентом», подразумевая, что тексты у вас уже лежат готовые стопкой.

Тестирование на живых людях: момент истины

Вы думаете, что тестирование — это когда программист нажал пару кнопок и сказал «работает»? Нет. Настоящее тестирование, которое часто отсутствует в официальном списке работ, — это «юзабилити-тестирование на реальных пользователях».

Максимум, что предлагают студии — это кроссбраузерная проверка (чтобы работало в разных браузерах). Но никто не говорит об этапе, когда вы сажаете перед сайтом вашу тетю, вашего друга или случайного человека и просите купить товар. Вы с ужасом наблюдаете, как он тыкает пальцем не туда, не понимает, где корзина, и злится. Это бесценный этап, который выявляет косяки проектировщиков. Но он требует времени и денег, поэтому его «забывают» включить в смету. А зря. Потому что это единственный способ узнать правду о вашем сайте.