Привет, меня зовут Костя, и я руковожу цифровым дизайном в OTP Банке.
Дисклеймер
То, что я опишу дальше – это лично мой опыт в конкретной ситуации. Я им поделюсь, но, пожалуйста, при возникновении у вас чего‑то подобного отнеситесь критически к вашей конкретной ситуации.
Срочные задачи, размытые требования, меняющиеся вводные и большое количество людей, принимающих решения – это нормальное состояние для IT, продуктовой разработки и любых сложных систем. Поэтому в этой статье не будет рассуждений в духе «надо было всё предусмотреть заранее».
Наш кейс с видео в этой истории – лишь пример. В более широком смысле статья про организацию процесса в условиях, когда времени мало, ясности нет, а сделать нужно хорошо. Ниже – то, как к этому подошли мы.
Поехали…
Дано
В конце прошлого года к нам прилетела интересная задача – подготовить серию видеороликов для презентации партнерам. Мы могли отказаться, но решили вписаться.
Мы – команда интерфейсных дизайнеров. Мы не motion‑студия, не продакшн и не делаем видео на потоке. У нас не было инструмента, готового процесса и опыта именно в таком формате.
При этом:
планировалось 18 видео;
у каждого ролика был свой стейкхолдер и у него целая команда;
весь контент – на английском;
сроки были сжаты.
Эта задача была важна для бизнеса, потому что через эти ролики нужно было синхронизировать большое количество команд и донести единое понимание происходящих изменений до зарубежных коллег.
Как мы выстраивали процесс
1. Зафиксировать рамку задачи, даже если она неточная
Первое, с чего мы начали – просто стали задавать вопросы и собирать всё, что есть, в любом виде.
На старте мы не понимали:
в каком формате к нам должна приходить информация;
насколько она будет финальной;
договорились ли команды между собой внутри.
В какой‑то момент стало понятно, что ждать «идеальных» вводных бессмысленно. Нам нужен б��л хотя бы основной текстовый контент и примерное понимание, что вообще хотят показать. Самый быстрый и понятный формат для этого – слайды в какой‑нибудь презентации. Так появился первый пример с английской текстовкой, который и стал для нас отправной точкой.
И тут важно учитывать количество людей. Формат мы задали, но людей было много, все разные, поэтому информация всё равно приходила в разном виде и состоянии – и это, если честно, было ожидаемо. Часть времени ушла просто на то, чтобы собрать общий смысл воедино. И это дало несколько кругов правок с доточками по некоторым роликам.
2. Сразу признать неопределённость и заложить риски
В итоге мы исходили из того, что:
часть вводных изменится;
часть материалов придёт не в финальном виде;
правок будет больше, чем кажется.
Поэтому мы закладывали риски примерно в 50% времени. У вас цифра в зависимости от контекста может быть вообще другой, главное – на неё взглянуть честно. Это не попытка перестраховаться, а трезвая оценка контекста: первый раз, много людей, высокая срочность. И это одна из вещей, которая нас спасла относительно приближающегося дедлайна.
3. Выбрать инструмент, который команда уже понимает
Для себя на старте мы решили, что классический видеопродакшн – не наш путь.
Да, в команде есть люди, которые работали с After Effects или DaVinci, но большая часть дизайнеров никогда не занималась видео. И наша задача была найти не «лучший» инструмент, а эффективный в наших реалиях.
Так как все у нас работали с интерфейсной и Lottie‑анимацией и хорошо понимали её логику, самым подходящим инструментом оказался Jitter. Он был простым, с интеграцией с Figma и возможностью одновременной работы нескольких человек над одним видео.
Схема была простой:
подготовка слайдов в Figma;
передача через плагин;
анимация уже внутри Jitter.
Это позволило не тратить время на обучение и сразу уйти в продакшн.
4. Вынести коммуникацию в публичное поле
Снятие статусов и регалий ускоряет решения и снижает напряжение, особенно в преддверии дедлайна. Отдельным процессом стала коммуникация. Мой руководитель в прошлом был администратором форума, и одной из его задач была настройка коммуникации между людьми. Этот опыт он принёс в наше поле.
Поэтому одной из первых вещей была собрана большая супергруппа в мессенджере, куда были добавлены все стейкхолдеры и ответственные члены их команд, вне зависимости от статусов и должностей. Здесь важно учесть, что нужно не просто добавить людей в группу, а разграничить информационные потоки по темам или тредам по каждому направлению. Это снизит общий шум и не даст чату скатиться в помойку.
Это дало несколько эффектов:
вопросы перестали теряться;
решения принимались быстрее (представляю, сколько времени можно было бы потерять при той же коммуникации в почте);
снизилось количество личных чатов и пересылок;
работа стала видна со стороны.
Коммуникация стала частью процесса, а не его побочкой.
5. Чётко определить, что считается «финалом»
Здесь мы ошиблись.
Мы показали этот пример как референс, но не зафиксировали жёстко, что на продакшн должны попадать только полностью согласованные и финальные тексты. В итоге по некоторым роликам мы заходили на второй, а иногда и на третий круг правок. В результате правки начали множиться.
Фактически:
мы сделали 18 роликов;
а выполнили эквивалент 29.
Вывод: ещё до старта продакшна важно договориться, что именно считается финальной версией входящих материалов и в каком виде они принимаются.
Это важный вывод, который мы точно учтём в следующий раз. Но сейчас, глядя сверху на весь п��оцесс, понятно, почему мы не придали значения этому нюансу вовремя: на кону стояло много других вопросов: поиск людей, синхронизация, коммуникация – и этот момент просто выпал из фокуса.
Это не уберёт все правки – надо понимать, что они всё равно будут, потому что человек часто осознаёт свою ошибку только увидев результат, и это в порядке вещей. Но их можно будет существенно сократить.
6. Разделить роли внутри команды
Внутри команды мы сразу развели зоны ответственности:
один лид отвечал за продакшн и работу с дизайнерами;
я взял на себя правки, работу со стейкхолдерами и таймлайн;
второй лид прикрывал продуктовые задачи.
Это позволило не уронить основную работу и избежать хаоса внутри команды. Отставание в продуктах, конечно, произошло, но не критичное, и мы его достаточно быстро нагоним.
7. Делать процесс прозрачным каждый день
Ежедневно я писал общий статус со скрином из роадмапа, где был спланирован буквально каждый ролик. Кто делает, к кому идти за информацией, на каком этапе, какой статус, ссылка на материалы, дедлайны сценариев и пр. И если мы уходили на переделку какого‑либо ролика, мы открыто об этом говорили и отмечали, как это повлияло на сроки, в том числе и других роликов.
И здесь важный тейк: нет смысла в такие моменты уходить в разбирательства, почему так получилось. Почему мы что‑то переделываем и т. п. Это порождает только негатив и длительные, бессмысленные коммуникации.
Сначала результат, потом ретро.
Поэтому каждый день:
обновлялся таймлайн;
фиксировались статусы по роликам;
в общий чат уходил апдейт со скрином и комментариями.
Это снимало большую часть напряжения и убирало игру в оправдания. Процесс был прозрачен.
Чек-лист
Если сильно упростить всю историю, то для подобной ситуации на будущее мы собрали для себя чек‑лист:
Зафиксировать рамку задачи как можно раньше, даже если она неточная.
Признать неопределённость и заранее заложить на это риски.
Выбрать эффективный инструмент под конкретную задачу, который в идеальном сценарии команда уже понимает и может использовать сразу.
Сделать коммуникацию прозрачной и публичной, с единым каналом и регулярными апдейтами.
Чётко определить требования к входящим материалам и зафиксировать, что считается «финалом».
Разделить роли и ответственность внутри команды до старта активной работы.
Отдельно запланировать время на сдачу, согласования и правки, а не только на реализацию.
Этот список не гарантирует идеального результата. Но он сильно снижает вероятность того, что проект развалится по дороге.
Выводы
Главный вывод из всей этой истории – важен не идеальный процесс, а способность его быстро собрать и адаптировать в моменте.
Ошибки неизбежны. Контекст всегда уникален. Риски нужно закладывать сразу. Мы закладывали в этой задаче около 50% времени на риски и примерно в это и попали.
Мы часто так фиксируемся на реализации что забываем один из – самый ресурсоёмких этапов проекта – это его сдача. А, чем больше стейкхолдеров, тем больше времени и внимания она требует.
В следующий раз мы, возможно, где‑то споткнёмся. Но уже не в тех же местах (но это не точно).
