Правки при разработке сайта: как мы согласовываем изменения

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

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

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

Сначала разбираемся, почему появилась правка

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

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

Но пожелание заказчика не всегда сразу объясняет задачу, которую нужно решить.

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

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

Иногда достаточно нескольких вопросов, чтобы задача стала понятнее:

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

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

Как мы обсуждаем субъективные замечания

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

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

Но сам по себе факт, что кому-то не понравился цвет, ещё не объясняет, что нужно изменить. Сначала стоит разобраться, какое впечатление создаёт решение и насколько оно соответствует продукту, бренду и аудитории.

Такие же требования мы предъявляем к собственной аргументации. Формулировка «нам кажется, что так красивее» мало помогает обсуждению. Если мы выбрали определённую структуру, навигацию или визуальную иерархию, мы должны уметь объяснить выбор: особенностями аудитории, UX-принципами, доступной аналитикой, ограничениями интерфейса или опытом работы с похожими задачами.

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

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

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

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

Заказчик знает свой бизнес изнутри. Мы можем изучить рынок, конкурентов, отзывы и пользовательские сценарии, но это не заменяет знания человека, который годами работает с продуктом и клиентами. Со своей стороны мы отвечаем за проектирование интерфейсов, UX, визуальную коммуникацию и разработку.

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

Что мы считаем обычной правкой

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

Например:

скорректировать текст или формулировку;
уточнить уже согласованное содержание;
изменить отдельные элементы палитры;
поправить расположение элементов интерфейса;
скорректировать последовательность секций.

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

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

Где заканчивается правка и начинается новая задача

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

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

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

Отдельного обсуждения обычно требуют изменения, при которых:

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

Само изменение требований не является проблемой. За время разработки бизнес может внедрить новую систему, пересмотреть продукт или получить важную информацию о клиентах. Иногда первоначальное решение действительно стоит изменить.

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

Почему стоимость изменения зависит от этапа

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

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

Поэтому одна и та же идея на разных этапах требует разного объёма работы.

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

Полный порядок работы — от интервью до запуска — описан в статье «Этапы разработки сайта: как мы работаем от интервью до запуска».

Если новое замечание противоречит предыдущему

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

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

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

Здесь мы возвращаем обсуждение к конкретному вопросу: какую проблему должно решить изменение? Ответ помогает выбрать вариант и определить, по каким признакам его оценивать. Без этого можно долго перебирать решения, не приближаясь к завершению проекта.

Кто должен участвовать в согласовании

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

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

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

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

Зачем ограничения по правкам нужны в договоре

Ресурсы команды конечны. Дополнительные итерации требуют времени, которое уже могло быть запланировано на разработку, тестирование, следующие этапы или другие проекты.

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

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

Чем яснее зафиксированы требования и промежуточные договорённости, тем проще обсуждать такие ситуации предметно.

Последнее слово остаётся за заказчиком

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

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

Экспертность подрядчика не даёт ему права забирать у собственника контроль над его бизнесом. Но она обязывает объяснять риски, которые подрядчик видит в своей профессиональной области.

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

Как понять, что правки улучшают сайт

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

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

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

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

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

Правки при разработке сайта: как мы согласовываем изменения