Как заказать дизайн цифрового продукта и не выкинуть его потом в мусорное ведро

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

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

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

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

Как правило, проект начинается в недрах компании и к моменту, когда клиент начинает искать исполнителя, у него уже готово «техническое задание». Но чаще всего это всё-таки не ТЗ, а БФТ — бизнес-функциональные требования. Или даже их гибрид. Если ТЗ отвечает на вопрос «КАК система должна работать», то БФТ — на вопрос «ЧТО система должна делать без учёта технической реализации».

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

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

Если слышите: «Без ТЗ результат — ХЗ», то бегите быстрее ветра от такого подрядчика

Если вы клиент, и слышите что-то вроде: «Без ТЗ результат — ХЗ», бегите быстрее ветра от такого подрядчика. Он будет постоянно требовать ответов, которых у вас нет и быть не может, и перекладывать ответственность за результат. Помочь клиенту сформулировать грамотные бизнес-функциональные требования к системе — одна из задач продакшена. Именно он является экспертом в возможностях и ограничениях системы и без этого понимания требования будут слишком общими и абстрактными.

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

Стоп, мы же вроде про дизайн начинали, причём тут бэкэнд?

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

Какие могут быть варианты развития событий.

1. Бэкэнд есть — это хорошо. Но нужно учитывать, что для мобильного приложения, бэк нужно дорабатывать. Важно на берегу договориться, кто и в какие сроки это будет делать. Напомню, мы говорим про сложные цифровые продукты, а это подразумевает, что большая часть данных и логики хранится на бэкэнде. Это накладывает много ограничений, без учёта которых сделать качественный дизайн невозможно.
2. Бэкэнда нет — тоже хорошо, если делает его та же команда. Если команда клиента или другого подрядчика, готовьтесь дорабатывать дизайн, когда бэк появится.
3. Интеграции со сторонними сервисами — если они есть, перед дизайном нужен технический ресерч: какую информацию мы можем получить из этих сервисов и в каком виде. Иногда оказывается, что никакую и нужно вставлять виджеты «как есть».

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

Очень правильный вопрос. На этот случай у нас есть штатный таролог и астролог! Ладно, насчёт таролога — шутка, а вот астролог действительно есть, но к оценкам проектов мы его не подключаем.

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

Фичерлист. Это список ожидаемой функциональности приложения. Иногда для этого достаточно внимательно изучить ТЗ и вытащить из него всё необходимое. Иногда — устроить брифинг с клиентом и за час добыть нужную информацию. Каждую функцию оценивают технические команды. Команда дизайна оценивает сценарии:

• процесс регистрации;
• выбор товаров из каталога;
• оформление заказа.

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

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

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

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

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

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

Условно можно выделить следующие зоны ответственности:

1. Продукт — создание продукта, который будет востребован целевой аудиторией.
2. Бизнес — разработка стратегии, как продукт удовлетворяет потребности бизнеса.
3. Техническая реализация — как именно он будет реализован с технической точки зрения.
4. Маркетинг — реклама и всё прочее.

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

Что делать? Убедиться, что все всё понимают. Бывает, что клиент просто не готов на уровне своих процессов к появлению нового бизнес-продукта. Или думает, что после того, как приложение попадает в стор, его сразу начинают неистово скачивать.

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

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

Что делать? Добиться синхронизации между бизнесом и производством в понимании целей продукта и стратегии развития.

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

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

Что делать? Обеспечить регулярную сверку часов — отчёты, статусы, риски. Радикальная прозрачность всего, что происходит на проекте. Только так можно добиться действительно эффективной командной работы.

Цифровой продукт — это живой организм. Он рождается из идеи или потребности и дальше развивается под влиянием людей, которые его делают. Идеальный сценарий, когда весь продукт делает одна постоянная команда: бизнес и производство.

У этого подхода есть несколько неоспоримых преимуществ.

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

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

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

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

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

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

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