Работа команды изначально строится вокруг определенных правил и паттернов. Но при увеличении пула задач, их сложности и количества задействованных в проектах команд все нередко начинает скатываться к хаосу, при котором специалисты на местах перестают понимать, что и зачем делают, как выполнять требования и где брать на это время.
Меня зовут Алексей Иванов. Я дизайн-директор в ОК. В этой статье я расскажу о нашем пути от хаоса к структуре в процессах, а также дам практические рекомендации на основе нашего опыта, которые помогут улучшить взаимодействие между командами, сделать работу каждого специалиста комфортнее и эффективнее.
Признаки появления проблем
Рано или поздно любая компания может столкнуться с ситуацией, при которой специалисты начинают выгорать, команды — сходить с намеченных маршрутов и терять ориентацию в ценностях. Особенно остро могут проявляться эти проблемы, когда компания стремительно развивается или вынуждена «тянуть» сотни одновременных процессов, которые невозможно централизованно проконтролировать.
Причин подобных негативных тенденций может быть много. Например:
процессы не формализованы, или люди не знают о принятых стандартах;
люди не понимают целей компании и/или вектора развития продукта;
есть проблемы на уровне структуры или состава команд;
от специалистов или команд требуют больше, чем они могут;
специалисты загружены нерационально — «просиживают» или вынуждены работать сверх нормы.
Вместе с тем, независимо от предпосылок, последствия таких проблем всегда схожи: эффективность работы падает, ошибок становится больше, качество работы ухудшается. В итоге это отражается на продуктовых метриках и бизнесе.
Как было у нас?
Проблемы в процессах — довольно типовая и распространенная ситуация. Не обошла она стороной и нас.
Еще год назад у нас можно было встретить ситуации, когда:
есть команды, состоящие из продактов, одного или нескольких дизайнеров, разработчиков и тестировщиков;
есть продакт, который отвечает за сервис или даже несколько сервисов, но у него нет своей команды — для решения любых задач ему приходилось обращаться к коллегам с просьбой выделить специалистов;
есть сервисы, у которых нет продакта, в связи с чем они были вне фокуса команды и не развивались.
При этом, у структуры первого типа (когда есть и продакт, и команда) были определенные преимущества:
каждая команда могла работать в своем графике и практически не зависела от «соседей», в том числе, на уровне процессов;
отсутствие строгих правил и практик взаимодействия давало возможность решать вопросы без лишней бюрократии;
изолированность каждой команды позволяла не только использовать свои практики и инструменты, но и не делиться доступными ресурсами;
была атмосфера стартапа, при которой каждый мог влиять на разработку и внутренние процессы.
Звучит круто, но в реальных условиях каждое из этих преимуществ становилось первопричиной целого ряда трудностей. Так:
специалисты, не входящие в большие команды, попадали в зависимость от них — иначе нельзя было решать большие задачи и получать нужные ресурсы;
каждая команда продвигала свое видение решения задач, словно «лебедь, рак и щука»;
разбираться в коде и реализациях других команд было подчас сложнее, чем написать свое решение с нуля, что плодило дубликаты;
на фоне индивидуальных приоритетов каждой команды общие цели компании часто уходили на второй план, что влияло на скорость их достижения и качество конечного результата;
в условиях отсутствия четкой структуры команд, специалистам часто приходилось выполнять непрофильные задачи, что перегружало людей и влияло на качество продукта;
команды не могли делиться экспертизой и наработанными решениями, поскольку все внутренние процессы изначально отличались и интегрировать новинки «извне» было сложно или невозможно вовсе.
Более того, отягощало ситуацию и то, что состав и структура наших команд часто отличались от желаемого. Например, обычно в «идеальной картине мира» дизайнеры и продакты подчиняются директору по продуктам (Chief product officer, CPO), а разработчики и тестировщики — техническому директору (Chief Technology Officer, CTO). При этом состав команды и количество специалистов на разных позициях обязательно учитывают характер и сложность задач.
Мы были далеки от этого. Например, в моей команде дизайна на 180 разработчиков было всего:
5 продуктовых дизайнеров;
2 исследователя;
2 коммуникационных дизайнера;
2 графических дизайнера;
2 дизайнера дизайн-системы.
Таким образом, соотношение дизайнеров к разработчикам достигало 1 к 32. При том, что согласно исследованию Ли Булей, в ИТ-компаниях оно не должно превышать соотношение 1 к 12. Мы нарушали оптимальный баланс почти в три раза.
С таким бэкграундом мы решили менять ситуацию и пытаться выстраивать процессы внутри ОК таким образом, чтобы все команды работали в едином симбиозе и могли выдавать качественный результат.
Поиски идеального процесса для ОК
При поиске паттернов выстраивания работающих и эффективных процессов внутри команд разработки мы оправданно исходили из того, что подобная история не уникальна и уже есть компании, которые прошли этот путь раньше нас. Понимая это, мы начали изучать опыт всех бизнес-юнитов VK и других ИТ-компаний, представленных на рынке.
Проведя такой анализ, мы выработали понимание современного продуктового цикла. Как правило, он состоит из шести этапов, на каждом из которых решаются определенные задачи.
Формирование целей. На этом этапе определяются и формализуются цели, определяется, зачем именно нужно делать ту или иную задачу. Соответственно, появляется ключевая метрика, которая помогает оценить результативность выполнения задачи. Что важно, здесь же сразу определяется, что может помочь и помешать выполнению задачи, прорабатываются варианты реализации и их нюансы. В идеале результатом этапа должна стать стратегия решения задачи.
Продуктовая проработка. Здесь задача декомпозируется и приоритизируется. Одновременно уточняются параметры, которые могут повлиять на достижение цели — для этого определяются субметрики и выбираются параметры успеха или провала. Одновременно с этим начинается первичная проработка структуры для проектирования реализации, а также проработка реализации внутри этой структуры. Основными итогами этапа являются формирование гипотез, их группировка, планирование экспериментов, предварительные тесты и формирование задания на разработку и дизайн.
Проработка дизайна. Здесь выполняется основной массив работы дизайнера: подготовка концептов, защита перед продуктовым менеджером, разработка прототипов, UX Writer-review, запись видео-демо, сross-review, design system-review и не только. Фактически тут, на этапе проработки, продукт должен получить предварительный вид или приблизиться к нему.
Исследования UX. Проверка пользовательского опыта важна для понимания, какой именно продукт нужен. Этап UX-исследований подразумевает целый пул задач: уточнение аудитории, запуск рекрута, подготовка методологии, полевые исследования, анализ данных и не только. По итогам подобных проверок формируются отчеты, которые становятся артефактом для последующей разработки.
Разработка. Ключевой этап производства начинается с установочной встречи, согласования всех решений, паттернов и нюансов, после чего следует непосредственно разработка продукта. Также к этому этапу относят код-ревью, тестирование и дизайн-ревью.
Запуск. Этап релиза, как правило, сводится к финальной глубокой проверке продукта и выкатке его в прод. Для этого обычно проводят A/B-тестирование, качественные исследования, ретро со всеми вовлеченными в разработку командами и специалистами. Основной артефакт этого этапа — продукт в проде.
Как заставить этот поезд ехать?
Понимать оптимальную этапность процессов, пул предстоящих работ и ценность каждого этапа — круто. Но этого мало. Надо внедрить и выстроить эти процессы внутри компании, а также обеспечить четкое следование им на протяжении всего цикла разработки продуктов.
На своем опыте мы выработали ряд практик, которые помогают выстроить идеальные процессы. Сейчас я расскажу о них подробнее и подскажу, что вы можете сделать уже сейчас, чтобы начать изменения в своей компании.
Ретро
В первую очередь мы пришли к внедрению практики регулярного проведения ретро. В рамках этих встреч или опросов можно обсуждать любые актуальные вопросы, искать решения со всеми вовлеченными специалистами, находить консенсусы, определять подробности реализации и не только.
При этом темы подобных опросов не ограничены и не регламентированы — таким способом можно собирать обратную связь по поводу процессов, устройств макетов, разработки, организационных вопросов и других аспектов.
Главное преимущество подхода в том, что такие мероприятия, в том числе в формате опросов, может организовать любой специалист, независимо от его роли в команде — достаточно создать доску в Miro или Figma Jam и попросить людей ответить на несколько вопросов. Например:
Что нам помогает в работе?
Что нам мешает в работе?
Что нужно изменить, чтобы работа делалась лучше?
Что нужно, чтобы результат был лучше?
Все полученные результаты мы категоризируем и выносим на общую доску в Figma в виде развернутых описаний. Это позволяет нам получать объективную картину текущей ситуации: что нужно менять, как менять, что работает хорошо и так далее.
При этом мы также пришли к пониманию, что ретро надо проводить на постоянной основе. В идеале до тех пор, пока жалоб со стороны сотрудников станет меньше или не останется вообще.
Внедрение ретро в нашем случае дало как прямой, так и косвенный эффект:
были выявлены и оперативно решены острые проблемы;
наладилась коммуникация между командами;
специалисты на местах получили возможность продвигать свои идеи, предлагать варианты решения проблем — появилась возможность шарить экспертизу по бизнес-вертикали;
повысилась вовлеченность специалистов во внутренние процессы компании, увеличилась мотивация за счет их причастности к общему делу и понимания вектора развития;
появилось первичное распределение зон ответственности, поскольку претензии могли поступать к каждому из специалистов.
С чего вы можете начать?
Проведите ретро внутри команды, в которой вы сейчас работаете, чтобы потренироваться.
Организуйте межкомандное ретро самостоятельно или с помощью фасилитатора.
Коммуникация с рынком
Полезной практикой стало непрерывное исследование рынка и опыта других команд или даже компаний. Причина в том, что многие компании проходят схожий, если не одинаковый путь, и нередко сталкиваются с типовыми проблемами. Изучение их опыта — возможность «не изобретать велосипед» и без больших затрат ресурсов и времени находить эффективное, уже проверенное решение.
Следуя этому подходу, мы наладили коммуникацию и взаимный обмен опытом с другими бизнес-юнитами VK, что дает не только краткосрочный, но и долгосрочный эффект — поможет в перспективе проходить многие этапы, не набивая собственные шишки.
С чего вы можете начать?
Определите команды и компании схожего профиля, с которыми можно наладить взаимный обмен опытом.
Изучите профильные сообщества, где специалисты делятся своими кейсами и способами их реализации.
Наладьте обмен опытом внутри команд в рамках одного бизнес-юнита.
Карты зон ответственности
Важно, чтобы каждый занимался своим делом и был на своем месте. Поэтому важной практикой является разработка карты зон ответственности для каждой из команд, которая будет графически отображать структуру входящих задач и обязанностей.
Фактически ее можно представить в виде схемы, на которой графически изображено, какие задачи и куда попадают, а также, кто за них отвечает.
Такое визуальное представление процессов и ответственных упрощает понимание взаимосвязанности всех этапов решения задач, помогает находить «серые зоны», для которых нет исполнителей (банально не хватает кадров) и/или ответственных. Аналогично можно понять, что штат излишне «раздут» — если в команде есть специалисты, которых стабильно нечем загружать.
Карта зон ответственности должна быть и продуктовых менеджеров, с поправкой на то, что вместо задач на нее выносятся направления, за которые они отвечают.
В нашем случае разработка подобных карт помогла привести структуру процессов к единому стандарту, найти задачи без ответственных и перераспределить их на специалистов, исключив перегрузку одних и простой других.
Сейчас структура всех наших команд выглядит примерно следующим образом:
На первый взгляд запутанно и сложно, но в действительности даже такая несколько громоздкая структура дает нам полное понимание всего происходящего и позволяет выстраивать вертикаль контроля за всеми процессами.
С чего вы можете начать?
Перенесите путь задачи от ее появления до реализации «на бумагу» и пропишите, кто является исполнителем и ответственным на каждом этапе.
Определите наличие «серых зон» и закрепите их за ответственным, который больше всего подходит по направлению или профилю.
Запросите у коллег информацию по поводу того, что они делали в течение последнего года и что хотели бы убрать из зоны своей ответственности.
Используя карты зон ответственности, оцените загруженность специалистов — возможно, нагрузка распределена неравномерно, что приводит к «перегоранию» одних и простою других.
Состав команды
Сбалансированность команды и ее соответствие не только текущим, но и перспективным задачам — залог комфортной работы всех вовлеченных специалистов. Поэтому выстраивание «идеальных» процессов должно затрагивать и изменение состава команд — найм недостающих специалистов, переквалификацию людей в штате или его сокращение.
При этом для себя мы выработали несколько правил, которые позволяют сделать такую «перезагрузку» команд максимально эффективной.
Желательно нанимать T-sharped специалистов, которые являются экспертами как минимум в одной области, но при этом имеют экспертизу сразу в нескольких направлениях, достаточную для понимания специфики работы специалистов из смежных областей. Такой подход помогает снизить риски bus factor, из-за того, что экспертиза сосредоточена в одних руках и человек становится незаменимым. T-sharped специалистов, как минимум, могут «прикрывать» простаивающие процессы, что даст больше свободы в распределении нагрузки.
Вместе с тем, надо понимать, что даже T-sharped специалист — не «человек-швейцарский нож» и требовать от него всего и сразу не стоит.
Полезно регулярно привносить в команду «свежую кровь», в том числе «чистых» специалистов без значительного опыта в крупных проектах. Как правило, это дает возможность посмотреть на текущие задачи под другим ракурсом и искать варианты решений вне рамок привычных подходов.
Но тут тоже есть несколько «подводных камней». Во-первых, привлечение новых специалистов связано с большими инвестициями времени и денег. Во-вторых, чтобы новый сотрудник стал полноценной частью команды, нужна определенная механика онбординга. В-третьих, найм — это всегда риск столкнуться с мемом «ожидание/реальность» в жизни и получить специалиста, который во время собеседования несколько «приукрасил» свои возможности.
Оптимально, когда команда формирует экспертную группу: например, когда дизайнеры с дизайнерами, а разработчики с разработчиками. Это позволит развивать внутреннюю экспертизу. Исключение — когда достаточно ресурсов для формирования Core-команды, которая решает фундаментальные вопросы и имеет влияние на другие команды.
Единственное, тут надо понимать, что лид у такой команды в идеале должен быть именно T-sharped специалистом — иметь широкую экспертизу во всех областях (от дизайна до разработки и тестирования), чтобы эффективно управлять процессами и ресурсами команды.
Не стоит искать «клонов». Слишком жесткие рамки при поиске новых сотрудников могут привести к тому, что команда «закостенеет» на одном уровне и не будет иметь импульса для дальнейшего развития. В идеале даже в рамках одинаковой позиции искать людей с разными супер-скилами — например, чтобы два дизайнера не дублировали, а дополняли друг друга.
Отдельно стоит отметить, что есть команды, в которых один человек закрывает и отрабатывает все позиции. Зачастую такое встречается в начале пути команды или в компаниях с ограниченными ресурсами. Очевидно, что работа в таком формате имеет как преимущества, так и недостатки: с одной стороны, не нужно ни с кем ничего согласовывать и есть полная свобода принятия решений, с другой — все неизбежно упирается в выгорание, а также заставляет выстраивать все процессы в рамках доступной экспертизы.
С другой стороны, есть большие команды с десятками специалистов разных направлений — от UX-писателей до графических дизайнеров. Естественно, в таком случае отпадает проблема с ограниченностью экспертизы, но возникает необходимость четко обозначать зоны ответственности каждого специалиста — надо понимать и помнить, что у каждой позиции свои задачи, но цели у всех общие.
С чего вы можете начать?
Выявите серые зоны в процессах и командах, донесите эту информацию руководству (бизнесу).
Инициируйте открытие ставок на позиции, куда нет возможности поставить квалифицированных сотрудников из штата.
Стимулируйте штатных сотрудников с низкой загруженностью получать новые компетенции или квалификации — иногда это проще и рациональнее, чем искать людей на позиции «на стороне».
Митинги: оптимизация рабочего времени
Важным условием отладки внутренних процессов и решения возникающих задач коллективными усилиями является проведение митингов. Проблема лишь в том, что иногда такие собрания превращаются в поток встреч, который отнимает львиную долю рабочего времени и не всегда несет практическую пользу.
Чтобы избежать подобных проблем и не превращать митапы в «пытку» для сотрудников, мы решили несколько пересмотреть подход к их организации и проведению. Так, изначально мы постарались перенести все основные встречи на начало недели и дообеденное время — так мы получили возможность координировать работу специалистов и команд в самом начале пути работы с задачей. К тому же утром в понедельник люди существенно лучше воспринимают информацию, чем после тяжелой и насыщенной рабочей недели вечером в пятницу.
Также мы постарались сократить календари коллег и оптимизировать чаты — участие в любых встречах и обсуждениях теперь напрямую зависит от пользы как для специалиста, так и для проекта. Ситуации, при которых человек слушает встречу фоном или ради «галочки» сведены к минимуму.
Дополнительно мы внедрили новые форматы мероприятий, вроде дизайн-критики — встречи, на которой дизайнер презентует идею коллегам для получения любой обратной связи (от критики и предложений новых решений до выработки альтернативных идей). Подобные встречи в формате коллективного мозгового штурма помогают уменьшить «застои» при подготовке проектов и повысить качество конечного продукта.
С чего вы можете начать?
Перенесите все регулярные встречи на начало недели и дообеденное время.
Соберите у коллег фидбек о пользе регулярных встреч, отмените ненужные.
Попросите коллег в теме каждой встречи указывать цели, которых нужно достичь.
Внедрите практику посещения только тех встреч, которые полезны.
Спринты
Для повышения контроля и прогнозируемости выполнения задач мы также используем спринты, то есть делим большую задачу на маленькие подзадачи и назначаем для их решения фиксированный период времени. Обычно спринт ограничивают двумя-четырьмя неделями, в которые «набивают» задачи определенного объема.
Преимуществ у подхода много. Так, появляются возможности:
регулярно отслеживать выполнение больших проектов и своевременно вносить коррективы, а не ждать выкатки готовой итерации;
держать задачу в фокусе, а не вспоминать о ней за неделю до дедлайнов;
контролировать нагрузку на специалистов — не допускать их простой с нагрузкой в 50%, но и не перегружать;
нативно привить в компании культуру планирования, при которой каждый понимает, что ему делать в ближайшей перспективе, и может регулярно «сверять часы» с другими исполнителями на проекте.
С чего вы можете начать?
Обсудите, какого размера спринт комфортен для большинства коллег.
Выясние, какой процент времени отдается на задачи и технический долг.
Организуйте инструменты (например, Jira) под спринты и назначьте ответственных за их проведение.
Попробуйте внедрить практику спринтов хотя бы ограниченно и в тестовом режиме.
Внедрение единых инструментов для организации работы
Любые нововведения, практики, договоренности и даже изменения на уровне состава команд могут быть нивелированы банальным человеческим фактором — люди могут забыть, неправильно понять друг друга, «потеряться» в этапах выполнения задачи. Поэтому ключевое значение имеют не только меры по оптимизации процессов, но и методы контроля. Один из способов получить такой контроль — использование инструментов для организации командной работы (например, Trello, Weeek или любой другой таск-менеджер).
Организация работы «вокруг таск-менеджера» полезна по ряду причин:
консолидирует все задачи и процессы в одной рабочей среде;
позволяет отслеживать ход и этапность выполнения;
помогает находить этапы, которые блокируют выполнение (например, если где-то собирается очередь из задач);
позволяет фиксировать все договоренности, устанавливать и отслеживать дедлайны, обмениваться документами и наработками без риска потери и не только.
Сейчас в ОК все процессы построены именно через таск-менеджеры. Например, команда дизайнеров раньше работала в Trello.
С чего вы можете начать?
Договоритесь об общем инструменте организации работы, подключите к нему всех членов команды.
Проведите ревью процесса, разделите его на этапы, которые будут формировать полный пайплайн выполнения проекта.
Обучите команду работать с инструментом и сделайте это обязательной практикой хотя бы временно (для оценки эффективности).
Внедрение методологии OKR
OKR (Objectives and Key Results, «цели и ключевые результаты») — методология, которая предполагает установление 3-5 амбициозных и сложно достижимых целей на определенный промежуток времени (месяц, квартал, год), а также определение измеримых ключевых результатов для каждой из поставленных целей. При этом способ достижения цели не важен — первичен именно результат.
Сама цель должна быть понятна, амбициозна, измеряема и реалистична с точки зрения доступных ресурсов.
Например:
Objective: Опубликовать хорошую статью о выстраивании процессов для дизайнеров, продактов и разработчиков.
Key Results:
Статья должна выйти не позднее мая 2024.
Количество просмотров — 3 тыс.
Рейтинг — +5.
Objective: Увеличить постоянную аудиторию ОК.
Key Results:
Увеличить MAU с 36 млн пользователей до 40 млн.
Увеличить количество новых регистраций до хххх в месяц.
Методология OKR позволяет синхронизировать командные и индивидуальные цели и обеспечить эффективный контроль над реализацией поставленных задач.
Мы оставили на KPI основные метрики и команды, которые работают с заработком денег, а для продуктовых команд сформировали OKR, которые связаны с метриками. Они подробнее описывают варианты достижения и лучше формируют образ результата, который понятен каждому сотруднику на его уровне. Так сотрудники понимают, какой вклад именно они могут внести, чтобы достичь результата, даже если они не влияют напрямую на KPI. Люди перестали предлагать и делать задачи ради задач, которые не ведут к высокоуровневым целям.
С чего вы можете начать?
Попросите руководство зафиксировать высокоуровневые цели в формате «Мы хотим прийти к тому-то» или «Мы хотим стать такими-то».
Донесите цели до всех сотрудников и команд (можно распечатать плакаты).
Сформируйте для каждой команды свои ключевые метрики (Key Results) в рамках общих целей (Objective).
Что в итоге?
Выстраивание идеальных процессов, учитывающих специфику и запросы каждой команды внутри компании, — сложный и подчас длительный процесс, который, кроме прочего, может «саботироваться на местах» людьми, которые не хотят ничего менять.
Вместе с тем, надо понимать, что результат от таких нововведений зачастую полностью оправдывает вложенные ресурсы и время: делает рабочий процесс более прозрачным, исключает «слепые зоны», за выполнение и контроль которых никто не отвечает, помогает корректнее распределять нагрузку на специалистов и уменьшить влияние любых факторов, отвлекающих от работы (вроде долгих согласований и встреч).
Однако улучшение процессов не требует спешки. Поэтому любые изменения вполне можно сначала тестировать в рамках отдельной команды, дорабатывать и только после распространять практики на всю компанию. В таком случае изменения будут «мягче», а специалисты на местах — более подготовленными к ним.