Как общаться с подрядчиком по сайту: правки и обратная связь

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

Формулируйте задачу, а не решение

Самая полезная привычка.

Не работает: «сделайте кнопку красной», «добавьте здесь блок», «уберите этот отступ».

Работает: «на этом экране непонятно, что делать дальше», «клиенты не находят цены», «на телефоне не видно телефон».

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

Это не значит, что нельзя предлагать решения. Просто говорите и то и другое: «мне кажется, кнопка теряется — может, сделать ярче?» Тогда обсуждается суть, а не форма.

Как оформлять замечания

От формулировки напрямую зависит скорость исправления.

Плохо: «у вас всё сломалось».

Хорошо: «на странице услуг с iPhone в Safari при отправке формы появляется ошибка, скриншот прилагаю».

Что указывать:

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

Ведите переписку в одном месте

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

Одно пространство — список задач или общий чат проекта, где всё сохраняется и видно статус.

Это же защищает вас: письменно зафиксированная правка не превращается в спор «я вам говорил — вы не говорили».

Доступ к списку задач — базовое требование к процессу при любой методологии, о чём в статье Agile или waterfall в веб-разработке.

Собирайте правки пачками

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

Причины:

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

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

Исключение: критичные поломки — форма не отправляется, сайт недоступен — сообщайте немедленно.

Один согласующий

Пункт, который решает больше, чем все остальные вместе.

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

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

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

Отвечайте вовремя

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

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

Различайте дефект и новую задачу

Источник большинства конфликтов.

Дефект: описано в задании, работает не так. Исправляется бесплатно в рамках гарантии — что в неё входит, в статье гарантия на сайт.

Новая задача: в задании не было или вы хотите иначе. Оценивается отдельно.

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

Здоровая практика: два-три круга правок на этапе дизайна входят в стоимость, изменения объёма оформляются отдельно.

Что делать при разногласиях

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

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

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

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

Чего лучше не делать

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

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

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

Требовать «просто быстро поправить». Любая правка — это время, и «просто» её не бывает.

Итог

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

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

Хорошая коммуникация не заменяет плохого подрядчика, но плохая способна испортить работу с хорошим.