Как заткнуть фонтан желаний01.08.2016 11:33

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

Настала весна, и у ёжика выпали колючки. Вместо них выросли крылья, и он улетел в окно. Стоит мальчик, смотрит ему вслед и говорит:

— Да это не ёжик, это х%#@я какая-то…

Руководителем проектов я стала полтора года назад — до этого работала в Сибириксе аккаунт-менеджером. Продавала проекты, общалась с заказчиками, готовила документы по сделкам. Затем так получилось, что ко мне прилетела пара веселых проектов. Затем ещё и ещё. И всё завертелось.

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

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

Критериев, что зубы показаны вовремя, у меня четыре:

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

• Доработки — адекватны. Если неадекватны и без них никак — оплачиваются по справедливой цене.

• Проект сделан круто и полезен людям. Его не стыдно показать маме.

• Заказчик если не доволен по максимуму, то не топочет ногами.

Итак, как показать зубы, не попасть на бесконечные правки и не потерять заказчика после сдачи спринта? Основано на собственном опыте и болезненных набитых шишках.

История про встроить

Я поняла, что происходит какая-то фигня, когда на втором проекте заказчик серьезно на меня обиделся. Мы вносили очередные правки в макет главной страницы: взяли присланный нам логотип и вставили в шапку сайта, как и договаривались. После этого разразилась гроза: «Вы вставили логотип, а должны были ВСТРОИТЬ!»

Что значит «Встроить», я не понимала. Кажется, заказчик тоже этого не понимал. Но с его стороны ситуация была ясна: мы, студия — ужасные упыри, делаем мало и неправильно. Сверкали молнии, гремел гром.

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

«Мать моя женщина, шесть вариантов ЛОГОТИПА В РАМКАХ ГЛАВНОЙ СТРАНИЦЫ! Да ты с ума сошла», — кричу я себе прошлой.

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

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

Последствия

После этого случая ситуация повторилась на еще двух проектах — на разных этапах работы.

• Заказчик накидывает дополнительные пожелания после презентации.

• Ты хочешь, чтобы заказчик был счастлив, и принимаешь их в работу.

• Заказчик недоволен. Долго, не так, мало сделали.

• Полный космополитизм — теперь границ допустимого нет, бей подрядчика!

• Бесконечные итерации правок. Встройте, а не вставьте. Встройте с другой стороны. Переверните.

• Негатив по итогам проекта. Долго, не так, мало сделали.

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

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

Откуда берутся правки

С потолка бесконечные комментарии не падают. Пока я вижу вот такие причины:

1. Плохо работали с ожиданиями или не работали с ними вообще.

2. Не добили важные моменты на аналитике.

3. Заказчика несет по волнам безудержных фантазий / он сам не знает, чего хочет.

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

Так появляются просьбы переделать дизайн по принципу золотого сечения. Или добавить на текстовую страницу собаку — она олицетворяет домашнее тепло и семью. Не спрашивайте, откуда примеры :)

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

Третий вариант — самый сложный. Решается переговорами и бесконечными въедливыми вопросами со стороны менеджера. Иногда — не решается вообще, и вы расходитесь с заказчиком со вздохом облегчения.

Формирование ожиданий

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

1Подробно рассказывать про процессы и фиксировать рассказы письменно

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

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

2Дополнительные работы выполнять после сдачи основных

В процессах Сибирикса ТЗ — скорее формальность. Мы им прикроемся, если нас будут жестко бить палкой. К моменту старта среднего проекта ТЗ актуально процентов на 30–40. Поэтому у нас есть бэклог, в который записываются дополнительные комментарии.

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

Оцениваем — это важно.

Бесплатные непродуманные доработки — зло, из-за которого теряется ценность работы. Если сделали бесплатно вот эти пять штук, почему не можете сделать еще вот эти пять в подарок? Берите, пожалуйста, и делайте, заказчик всегда прав.

После сдачи спринта появилась доработка или пожелание, которое ранее нигде не обсуждалось? Это скрам, детка. Кто из менеджеров не желает гибко отреагировать на очередные изменения в проекте?

Вот и реагируйте. Фиксируйте. Оценивайте.

А делайте после того, как сдали MPV по договору. Дополнительным спринтом за отдельную адекватную оплату.

3Завышенные ожидания — опускать на приемлемый уровень

Относительно свежая история — делаем сайт по продаже недвижимости. Специфика проекта — 148 рекламных баннеров на главной странице. Чтобы это во всей красе появилось перед глазами: на главной странице есть два места, где нет рекламы. Это шапка и футер. Там некуда. Хвост к носу уже прикидывался, и не прикинулся.

С точки зрения бизнеса это логично — прибыль проект получает только за счет рекламных мест.

С точки зрения дизайна — задача нетривиальная (дальше зачеркнуто) это же ужас.

Заказчик в тренде. Он хочет, чтобы проект побеждал во всевозможных конкурсах сайтов. И креативный вау-супер-эффект на главной, состоящей из рекламы чуть менее, чем полностью. В общем, и вровень, и выпирать. От нас ждут железного обещания, что так и будет: креатив, 148 рекламных мест, победа в конкурсе.

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

Кто неправ, если проект проиграет в конкурсе? Бинго. Студия.

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

В разговоре с заказчиком вытаскиваем на поверхность следующее преимущество сервиса — новостройки снимаются с высоты дроном с камерой. Придумываем гениальную идею.

После письма договариваемся, что двигаемся четко по прототипу :) Макет главной сдается после двух комментариев.

4Не обещать лишнего, но давать чуть больше, чем обещали

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

Когда ожидания сформированы, самое время превзойти их. Внести контент, прикрутить красивый эффект или лоадер. Или круто оформить страницу «О компании». В крайнем случае — сделать игру на 404 странице. По обстоятельствам.

5Воспитывать заказчика

Проекты удаются, если:

1. студия не отступает от принципов;

2. заказчик уважает принципы студии;

3. заказчик участвует в процессе по максимуму.

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

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

Об участии. Правильно воспитанный заказчик трудится как маленькая пчела. Например:

• Готовит контент по списку.

• Снимает товары.

• Дорабатывает складскую систему.

• Стопятьсот видов активности, которые можно накинуть.

Список финальных доработок

А теперь — о формальной части вопроса.

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

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

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

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

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

По мелочам не спорим. Поменять заголовки, перекрасить кнопку, отпустить блок в свободное плавание — без проблем, фиксируем в списке и делаем (предварительно обсудив, точно ли оно надо). Дополнительных денег за это не берем.

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

После выполнения всего, что зафиксировано в списке, работы считаются принятыми, и подписывается акт на спринт.

Это сильно упрощает ситуацию с бесконечными исправлениями и негативом при сдаче. Конечно, без сопротивления не обходится — как же так, почему же финальные комментарии? А если я захочу еще? Но, если проект сделан так, как договаривались, оно легко преодолевается. Если при этом работали с ожиданиями — пройдет гладко, я проверила :)

Полный текст статьи читайте на CMS Magazine