Процессы как продукты
Процессы команды — по сути её внутренние продукты. А хорошие процессы обладают всеми признаками, присущими успешному продукту.
Признаки хорошего процесса
Решает конкретную проблему
Или закрывает понятную пользовательскую потребность.
Процессы могут как ускорять разработку фичей, так и повышать их качество за счет внедрения соответствующих практик.
Направлен на конкретную аудиторию
Процесс делается не только под конкретную компанию, но и под реальную обстановку в командах. Предельно важно знать своих пользователей и особенности их работы.
Пользователями процесса чаще всего является ваша команда и команды, окружающие вас. С вашими пользователями, как и в случае с продуктом, необходимо постоянно проводить кастедевы, чтобы понимать, как развивать и улучшать ваши процессы.
Может масштабироваться
Вы знаете как развивать процесс по мере роста запросов от ваших пользователей и развития компании.
Простой процесс по передаче макетов в разработку со временем, может обрасти: шаблонами для описания макетов, правилами ведения и актуализации версий, гайдлайнами по описанию всевозможных механик, анимаций, паттернов и прочего.
Есть понятное УТП
Построение процесса для каждой команды уникально, и ваше предложение процесса бизнесу ничем не отличается от питчинга бизнес идеи инвестору. УТП же, как правило, кроется в уникальных чертах процесса, который переработан под особенности компании и учитывает множество характерных для неё нюансов.
Любой процесс или его часть должен быть адаптирован под нужды компании, в таком виде он будет наиболее эффективен. Процесс, взятый по принципу «как у соседа», почти всегда будет попросту неработоспособен.
Имеет реалистичную модель внедрения
Вы понимаете, как реализовать процесс, какие риски вам нужно преодолеть по пути, а также осознаете образ идеального и не идеального результата.
Не стоит расчитывать на успех, без понимания того, как вы будете реализовывать процесс, и что предстоит сделать после его внедрения. Даже рамочный план на несколько итераций вперед, в разы повышает выживаемость процесса в будущем.
Микропроцессы
Большие процессы состоят из маленьких составных частей — принципов, практик, договоренностей — небольших винтиков большого механизма. Именно они, на первый взгляд незначительные части большой машинерии, делают успешные популярные процессы уникальными и по настоящему работоспособными для каждой конкретной компании. Их мы называем микропроцессами.
Одна из самых знаменитых адаптаций устоявшегося процесса — история команды Intercom. Компания взяла фреймворк JTBD, которым пользовались тысячи компаний до них, и внедрила в него свой микропроцесс — Job Stories, механику, которая уточняет ситуацию, при которой клиент принимает решение. Так, проводя интервью с клиентом, бизнес выясняет не только, на какую работу он нанимает фичу или продукт, но и понимает особенности, при которых это решение было принято — ситуацию, мотивацию и образ ожидаемого результата. Казалось бы небольшое изменение общепринятого паттерна под свои нужды, в свое время кореным образом повлияло не только на Intercom, но и на то как работают многие команды по всему миру.
Пример микропроцесса — пост дизайн ревью
Внутри дизайн команды Вокса много процессов и микропроцессов, что-то мы используем уже многие годы и постепенно развиваем, что-то отмирает в процессе или со временем обретает иную форму, которая соответствует времени и ситуации.
Мы выбрали микропроцесс «Пост дизайн ревью» в качестве примера, так как он довольно простой и может реально помочь на первых этапах многим командам, а также хорошо отражает общие принципы подхода.
Основные страхи и сложности при внедрении
Дизайн ревью — процесс, который, как правило, разрабатывается на первых этапах жизни продукта. Его внедрение часто сталкивается с одинаковым набором возражений.
Частые возражения
До этого все как-то работало без дизайн ревью
Дизайнеров мало и будет бутылочное горлышко ресурсов
Есть тестировщики, которые смотрят дизайн на правки
Правки от дизайна не критичны для бизнеса
Еще один процесс, который всем добавит работы
Частые возражения
В нашем случае главной пугалкой было — бутылочное ресурсное горлышко. Один дизайнер в отпуске, второй заболел, третий завален задачами. Мы не большая команда и не можем быстро заместить отсутствующие ресурсы.
Что будет с задачей, когда никто не может сделать вовремя ревью? Откладывание выпуска фичи может быть чувствительно для бизнеса.
Особенно этот вопрос актуален для B2B продуктов, когда фича может представлять из себя добавление одной опции в настройках, но при этом нести за собой весомый функционал под капотом. Дизайн ревью такой задачи делается за 2 минуты и содержит минимальные риски, но потенциально задерживает релиз на недели.
Компромисный микропроцесс
Для того чтобы с одной стороны развеять страхи команды перед новым процессом, а с другой быстро внедрить его и показать результаты, мы придумали систему сдержек и противовесов, которые в нынешней итерации используем как крайнюю меру, он называется «Пост дизайн ревью».
Суть «Пост дизайн ревью»
Наш деливери процесс не отличается от многих других. Задача попадает в спринт разработки из бэклога и проходит все внутренние процессы инженеров, после чего приходит в тестирование и уже потом к дизайнерам на ревью.
Крайне важно чтобы первичная проверка была у QA, чтобы с одной стороны сконцентрировать тестировщиков на их первостепенных задачах, а с другой не делать туже самую работу два раза дизайнеру.
Алгоритм процесса после попадания в статус “дизайн ревью”
Если дизайн ревью не произошло в течение 24 часов. Или у нас есть острая бизнес необходимость его пропустить.
Дизайн ревью пропускается, и автоматически создается задача в очереди разработки на «пост дизайн ревью» с дизайнером-исполнителем (финальный контроль качества осуществляется продукт менеджером и тестировщиком).
Дизайн ревью проводится или в текущем, или в следующем спринте как приоритетная задача.
В специальном дашборде собирается статистика по запуску процесса «пост дизайн ревью» и разбирается каждый отдельный случай, чтобы избежать инцидентов в будущем
Схема процесса
Практическая польза
Простота
внедрения
Процесс проще внедряется и минует страх перед «бутылочным горлышком» на первых этапах внедрения.
Особенно актуально, для молодых команд с малым количеством ресурсов и процессов.
Контроль рисков
Позволяет управлять процессом при форс мажорах.
Нет ресурсов на проверку сейчас, небольшая фича блокирует большой запуск — всё это можно контролировать под минимальный риск и гарантию проверки за минимальное время.
Гарантия ревью
Ревью будет проведено всегда, вне зависимости от обстоятельств его пропуска.
Шанс того, что ревью фичи не пройдет и потеряется, минимален или отсутствует в принципе.
Больше
качества
Повышается суммарное число проверок результата дизайнерами , создается стабильная практика.
Статистически, даже с учетом того, что ревью можно пропустить при крайних обстоятельствах, количество проверок в реальности увеличивается в несколько раз, так как постепенно создается устойчивая практика.
Рост уровня
процесса
Со временем практика, приводит к привыканию команды к дизайн ревью и использованию его только при условиях непреодолимой силы.
Когда, команда привыкнет к работе с ревью через предохранители, процесс станет взрослее, а предохранитель останется на крайние случаи. Ни кому в реальности не нужны плохие результаты и чужая ответственность за них.
Результаты и цифры
19/20 дизайн ревью проходят в первичный цикл разработки, без «пост дизайн ревью».
100% задач итогово проходят дизайн ревью.
X 1,5 меньше багов на продакшене.
<5 дней потребовалось, чтобы внедрить первую версию процесса.
1 к 5. 1 дизайнер работает для 5 фронтендов, и успевает делать ревью.
<2 дней в среднем скорость закрытия пост дизайн ревью.
Выводы
Простой микропроцесс позволил нам быстро описать и внедрить практику дизайн ревью, так как своей особой формой убрал главный страх — страх бутылочного горлышка.
В короткий срок мы показали результаты и открыли дорогу к прочим улучшениям процесса, которые со временем превратили «пост дизайн ревью» в своеобразный стоп-кран или страховку на крайний случай.
Процессы появившиеся после внедрения дизайн ревью
Планирование квоты у дизайнеров в спринте на дизайн ревью.
Работа с тестировщиками над фокусной проверкой всех макетов.
Принципы и правила описания макетов для разработки и тестировщиков.
Принципы организации макетов в Фигме.
Шаблоны для дизайн ревью.
Дашборд с инцидентами.
Кроме того подобная практика, в измененных итерациях проросла в другие отделы, например в отдел копирайтинга.
В процессе мы научились
Не бояться переделывать устоявшиеся процессы под себя, даже если это устоявшаяся всеобще признанная практика.
Уметь идти на здоровые компромиссы и думать о перспективе развития процессов, а не о их идеальной форме.
-
Смотреть на процессы как на продукты и быть их полноценным владельцами.
Уметь питчить идеи процессов и защищать их
Строить роудмапы процессов, смотреть на них стратегически
Общаться с их пользователями наших процессов и добатывать их под реальную ситуацию в продуктах
Пилите процессы под себя, не бойтесь делать не как все, относитесь к своими процессам как к продуктам.
Дизайн команда Вокса ?
? ТГ канал дизайнеров Вокса
Там еще больше полезных материалов
https://t.me/syncaboutteam/
Бонус. Шаблон для дизайн ревью
У нас есть собственный шаблон для дизайн ревью, которым успешно пользуется много команд, мы будем рады если вам он также пригодится.
Забрать его можно в нашем Figma Community
