Бизнес — статьи о сайтах
Почему правки — это нормальная часть работы, а не признак провала
Есть распространённое заблуждение: если заказчик просит что-то переделать, значит исполнитель ошибся. И обратное: если исполнитель спорит с правкой, значит он упрямый и не слышит клиента. Обе позиции мешают делу.
Разработка сайта — это последовательное уточнение. На старте у заказчика в голове одно представление о результате, у дизайнера — другое, и полностью совместить их без промежуточных итераций невозможно. Даже подробное техническое задание описывает логику и требования, но не показывает, как именно будет выглядеть блок с преимуществами на экране ноутбука. Поэтому правки — это инструмент сближения ожиданий, а не жалоба на качество.
Проблема начинается в другой точке. Не в том, что правки есть, а в том, как они подаются, в каком объёме, на каком этапе и кто их согласовывает внутри компании заказчика. Именно это превращает нормальный рабочий процесс либо в предсказуемое движение к запуску, либо в бесконечный круг, где третий вариант главной страницы нравится меньше первого, а сроки уже сдвинулись на два месяца.
Хорошая обратная связь экономит деньги. Плохая — сжигает их незаметно: часы уходят не на то, чтобы сайт стал лучше, а на то, чтобы угадать, чего от него хотят.
Откуда берутся бесконечные круги согласований
Почти всегда причина не в дизайнере и не в капризном клиенте. Причина в организации процесса. Типичные сценарии повторяются из проекта в проект.
- Правки собираются не от одного человека. Макет смотрят директор, маркетолог, продажник и жена собственника. Каждый пишет своё видение, часто противоречащее остальным. Исполнитель получает набор взаимоисключающих требований и физически не может выполнить их все.
- Замечания приходят порциями. Сначала три, через день ещё пять, потом «а ещё вот это». Дизайнер правит по кругу одни и те же экраны, потому что каждая новая порция ломает предыдущее решение.
- Правки даются не на том этапе. Структуру начинают обсуждать, когда уже готова вёрстка. Или меняют смысл блока, когда написан и согласован текст. Возврат на предыдущую стадию всегда дороже, чем работа внутри текущей.
- Формулировки нечёткие. «Как-то не цепляет», «сделайте поживее», «мне кажется, чего-то не хватает». Исполнитель угадывает, показывает вариант, угадывание не совпало — цикл повторяется.
- Нет зафиксированной точки согласования. Если ни один этап формально не закрыт, к нему можно вернуться в любой момент. И возвращаются — обычно за день до запуска.
Отдельная история — когда правки подменяют собой отсутствующее решение. Компания не определилась, кому продаёт и в чём её отличие от конкурентов, и пытается найти ответ через перебор вариантов дизайна. Так не работает: макет не может исправить нерешённый вопрос о позиционировании, он только сделает его заметнее.
Как сформулировать правку, чтобы её поняли с первого раза
Универсальное правило: описывайте проблему, а не предлагайте готовое решение. Вы лучше всех знаете свой бизнес и своих клиентов, исполнитель лучше знает, какими средствами решить задачу.
Сравните две формулировки. «Сделайте заголовок красным и крупнее» — это указание, которое может испортить композицию. «Заголовок теряется, его не замечаешь на первом экране» — это задача, и решений у неё несколько: изменить размер, убрать соседний акцент, поменять фон, перестроить сетку.
Что делает правку понятной:
- Точное место. Страница, блок, экран. Лучше со скриншотом и пометкой прямо на нём.
- Что не устраивает. Не «плохо», а конкретно: не читается, не видно кнопки, непонятен смысл, не соответствует тому, как продукт устроен на самом деле.
- Почему это важно. Например: «наши клиенты — снабженцы, им нужны артикулы и наличие, а не вдохновляющие фотографии». Причина помогает исполнителю принять верное решение без десяти уточняющих вопросов.
- Приоритет. Критично для запуска или можно доделать потом. Без приоритетов всё становится одинаково срочным.
- Факты вместо вкуса. «Название компании написано с ошибкой» — факт. «Синий не мой цвет» — вкус. Первое исправляется без обсуждения, второе требует разговора о том, кому и что должен сообщать сайт.
Очень помогает, когда правки собраны в одном списке: таблица, документ, задачи в сервисе. Комментарии из мессенджера, почты и телефонного разговора неизбежно теряются, а потом всплывают как «я же говорил».
И ещё одно: фраза «мне не нравится» — это законная обратная связь, просто её недостаточно. Если не удаётся объяснить, почему не нравится, помогает пара примеров чужих сайтов с пояснением, что именно в них кажется правильным. Не для копирования — для калибровки.
Что относится к правкам, а что к изменению задачи
Это главный источник конфликтов и споров о деньгах. Разница простая.
Правка — это доработка внутри согласованной задачи. Переформулировать заголовок, поменять местами два блока, заменить иконки, поправить отступы, уточнить порядок полей в форме. Такие вещи предусмотрены в любом нормальном процессе и входят в оговорённое количество итераций.
Изменение задачи — это новая работа. Добавить раздел, которого не было в структуре. Подключить онлайн-оплату, если её не планировали. Сделать вторую языковую версию. Переделать каталог под другую логику фильтрации. Переверстать всё под ещё один тип устройства. Формально это тоже «правка» в глазах заказчика, но по трудозатратам — отдельный блок работ, влияющий и на срок, и на стоимость.
Честный разговор об этом лучше вести сразу, а не в конце. Исполнителю стоит прямо сказать: «это выходит за рамки, вот сколько времени и денег потребуется, решайте». Заказчику стоит спокойно это услышать: не как попытку выставить дополнительный счёт, а как информацию для решения. Иногда изменение действительно необходимо, и лучше внести его осознанно, чем впихнуть бесплатно и получить кривое решение, сделанное на ходу.
Полезная практика — держать отдельный список «после запуска». Туда уходит всё, что важно, но не критично для первой версии. Сайт выходит в срок, а накопленные идеи реализуются следующим этапом, уже с данными аналитики, а не на основе догадок.
Кто решает и как устроен регламент правок
Организационная часть важнее, чем кажется. Без неё даже идеально сформулированные замечания превращаются в хаос.
Минимальный набор договорённостей:
- Один человек со стороны заказчика собирает и утверждает правки. Внутренние споры решаются до передачи исполнителю. Если у директора и маркетолога разные мнения, исполнитель не должен выбирать между ними — это не его зона ответственности.
- Правки передаются пакетами, по этапам. Один круг замечаний по прототипу, один по дизайну, один по вёрстке. Не по одной мысли в день.
- У каждого этапа есть срок на обратную связь. Если макет ждёт согласования три недели, сроки проекта сдвигаются — не из вредности, а потому что команда уже переключилась на другой проект.
- Количество итераций оговаривается заранее. Обычно двух-трёх кругов достаточно, если правки осмысленные. Дальше — за дополнительную плату, и это справедливо для обеих сторон.
- Согласованный этап фиксируется письменно. Возврат к нему возможен, но уже как отдельное изменение задачи.
Такой регламент часто воспринимают как попытку исполнителя защититься от клиента. На самом деле он защищает обоих. Заказчик получает предсказуемый срок и понятную стоимость, а не проект, который «вот-вот закончится» полгода. Исполнитель получает возможность делать работу, а не обслуживать поток разнонаправленных мнений.
Что делать, когда правки уперлись в тупик
Бывает, что сайт объективно неплох, но заказчику он не нравится, а объяснить причину не получается. Перебор вариантов тут не поможет — каждый следующий будет вызывать такое же смутное недовольство.
В этой ситуации работает возврат на шаг назад. Не к макету, а к вопросам: кто целевой посетитель, какое действие он должен совершить, чем ваше предложение отличается от соседнего, какие возражения мешают ему принять решение. Как правило, тупик в правках — это симптом того, что на один из этих вопросов ответа нет, и все спорят о цвете кнопки вместо того, чтобы договориться о сути.
Второй рабочий приём — перевести спор из плоскости вкуса в плоскость проверки. Если нет согласия, какой заголовок сильнее, это не повод голосовать. Это повод запустить сайт и посмотреть на поведение посетителей. Данные после запуска решают такие споры за неделю, тогда как обсуждение может длиться месяц.
И последнее. Правки заканчиваются не тогда, когда сайт стал идеальным, а тогда, когда он готов выполнять свою задачу. Идеального состояния не существует: через полгода вы всё равно захотите что-то изменить, потому что появятся новые услуги, новая аналитика и новое понимание аудитории. Сайт — не памятник, а рабочий инструмент, который дорабатывается постоянно. Задача этапа разработки — не довести его до совершенства, а довести до состояния, в котором он начинает приносить пользу.
