Всё, что менеджеру проектов нужно знать о правках

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

Правки могут занять существенное время. «Вторые 90 % проекта», в общем. Человека, который в диджитале недавно, это может сильно демотивировать. Поэтому, нужна некоторая подготовка и некоторые правила.

В целом, правки — это следствие в неполной мере проведённой работы с ожиданиями. Заказчик ожидал одного (зачастую, даже не имея возможности сформулировать это «одно»), а получил другое.

…и пройдёт время, и ты увидишь перед собой очень конкретного, очень определённого человека. И вот, когда ты его так близко и так конкретно увидела, ты подумаешь: Нееет :-( Это совсем не тот мужчина, который должен быть рядом, не потому, что он не соответствует каким-то представлением, а просто потому, что этот конкретный и определённый человек не имеет ничего общего с этим размытым, почти сказочным образом, который ты себе нарисовала в своём воображении и к которому привыкла.

Евгений Гришковец, спектакль «Планета».

Основные принципы работы с правками

Мы оказываем услугу

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

Наши услуги платные

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

У нас с заказчиком партнёрские отношения

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

Как максимизировать шанс быстрой приёмки

Количество правок можно уменьшить, применив ряд лайфхаков. Давайте их рассмотрим.

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

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

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

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

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

Работайте с референсами. Мы не работаем в вакууме и не создаём продукты реально с нуля. Всегда есть работы для вдохновения. Референсы обязательно нужно брать с заказчика, просить показать, какие примеры приложений им нравятся. Также совершенно нормально показать, чем вдохновлялись вы. Хорошая штука — мудборды, концепты, вайрфреймы, прототипы.

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

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

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

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

Воркфлоу

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

В целом, универсальный порядок такой:

• Фиксация. Заказчик должен в каком-то удобном виде зафиксировать правки. Лучше со скриншотами или, если проблема в интерактиве, то и скринкастами.
• Обсуждение. Неплохо было бы провести встречу с заказчиком, на котором он ответит на вопросы по замечаниям.
• Исправление. Уходим в работу, правим.
• Проверка. Отдаём правки заказчику, получаем официальный ответ, что правки приняты. Если какие-то не приняты, возвращаем их в работу, пока не сдадим.

Неприемлемые вещи в работе с замечаниями

• Ненормативная лексика, обесценивание работы, переход на личности. Нельзя давать заказчику себя оскорблять, писать, какие вы косорукие идиоты и прочее. Я бы даже не рекомендовал переходить на «ты», как бы ни хотелось.
• Теневые игроки. Очень больших проблем можно огрести, если у вас нет доступа ко всем лицам, принимающим решения и отгружающим правки. Тут надо проводить разъяснительную работу, что круг лиц, вносящих правки, должен быть максимально узок и все они должны в открытую участвовать в процессе.
• Затягивание согласования. Нужно прописывать в договоре время реакции заказчика на правки и строго следить за соблюдением этих сроков, чтобы не похерить внутреннее планирование и утилизацию ресурсов.

Как вносить правки в готовый продукт

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

• Действовать итерациями. Не вываливать все исправления продукт разом. В одном релизе поправить одну кнопку, в другом иконки, в третьем логику переходов. Постепенные изменения пользователи переносят лучше.
• Реализовывать неудачные на ваш взгляд правки не в интерфейсе, а средствами контента. Контент быстро меняется, можно будет аккуратно от него избавиться.

Юридические аспекты работы с правками

Никогда не работайте без договора. Также стоит помнить и про другие нюансы.

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

Грамотно составленный договор сильно упростит вам работу с правками.

Резюме

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

В целом, это всё, что менеджеру проектов нужно знать о работе с правками.