План Б: как устранить критичные моменты в проекте и не вылететь за рамки бюджета и сроков

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

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

Глазами студии

Предыстория стара как мир: разработчики проводят последние работы, контент-менеджер старается и готовит все тексты, потрачены часы, деньги. Но итоговый результат не соответствует ожиданиям заказчика. После получения отрицательных отзывов первое, что мы делаем, разбираем работу всей команды (дизайнеров, разработчиков). Вроде всё хорошо, заявленный функционал на месте, и вообще непонятно, почему заказчик недоволен. Смотрим дальше, открываем макеты, находим стандартные недоработки:

Эффективная и выгодная реклама с сервисом от МегаФона

Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585. ERID LjN8K1P7y.

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

На месте заказчика мы бы тоже задали эти вопросы: «Почему не предусмотрели?», «Почему не протестировали?», «Почему раньше не показали?». В ответ пришлось бы озвучить стандартное: «Всё выполнено по ТЗ, а вот эти пункты мы согласовали по почте».

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

Опять встреча

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

Выводы

Проблема текущего подхода, как вы правильно понимаете, комплексная и неутешительная.

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

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

Как это раньше происходило у нас:

1. Мы написали ТЗ.
2. Сделали дизайн.
3. Разработали по ТЗ.
4. Показали заказчику продукт:
   • Заказчик рассказал, что ему что-то не нравится и он хочет переделать.
   • Ссылаемся на ТЗ и говорим, что это дополнительные работы и т. Д.
   • Заказчик расстраивается.
   • Мы разруливаем ситуацию.

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

Гипотезы и выводы команды

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

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

2. Проводить тестирование по ключевым сценариям демонстрации.

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

3. Закладывать отдельный бюджет на работы по финализации.

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

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

Для себя мы определили готовность проекта на 70-80%, как время, когда необходимо проверять статус состояния.

5. Показывать результаты разработки заказчику максимально часто.

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

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

Схема работы дизайн-студии ZephyrLab

1. Мы написали ТЗ.
2. Провели аналитику, разделили функционал на ключевой и дополнительный.
3. Разработали дизайн-концепции, защитили и подготовили материалы для разработки.
4. Сделали работы по ТЗ:
   • На этапе готовности 70% проекта мы сделали срез состояния.
   • Провели аудит, собрали гипотезы по улучшению продукта. Сформировали общий стек задач и распределили приоритеты, причём мы находимся в тех же сроках и бюджете настолько, насколько это возможно.
   • Внесли самые приоритетные доработки.
   • Обсудили с заказчиком и остановились на согласованном варианте.
   • Сформировали релиз к публикации.
5. Демонстрируем продукт, формируем чек-лист к развитию.
6. Сопровождаем и развиваем продукт.

На практике мы столкнулись с некоторыми моментами:

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

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

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

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