Но даже по тем задачам, которые явно требуют вовлечения дизайнеров, оценить потенциальную нагрузку бывает непросто. Подсчитать ее в человеко-днях – задача из области фантастики, особенно если речь идет о периоде дольше квартала. Когда по задачам нет финальных бизнес-требований (а у задач с дальними сроками их не будет), точная оценка невозможна. Однако если ваше руководство привыкло ориентироваться на краткосрочные задачи и очень любит цифры, такой способ нельзя списывать со счетов. Главное – заранее обозначить все необходимые оговорки, чтобы предварительную оценку впоследствии не представили как обязательство непременно выполнить задачи в указанный срок.
Но как понять степень нагрузки, если невозможно посчитать ее в днях? Я предлагаю, во-первых, мыслить более масштабными отрезками: спринтами, месяцами и кварталами, во-вторых, опираться на экспертное видение дизайн-лида и бизнес-лидеров, а в-третьих, ориентироваться на опыт коллег из других команд. Руководители, разбирающиеся в продукте, как правило, могут «на глаз» оценить необходимый ресурс, а пример других подразделений подскажет вам, как можно распоряжаться этим ресурсом в рамках процессов вашей компании. Посмотрите по сторонам: сколько дизайнеров используют другие команды, чтобы справляться с бэклогом, похожим на ваш?
Видение бизнес-заказчика – важный фактор, который нельзя игнорировать при формировании команды. Многие бизнес-лидеры имеют твердое мнение о том, сколько специалистов (в том числе дизайнеров) им нужно для достижения целей своего направления.
Это мнение справедливо и осознанно, когда руководитель от бизнеса глубоко погружен в работу своих команд. К тому же, зачастую в руках бизнес-заказчика сосредоточены финансовые рычаги и из его бюджета финансируются дизайнерские ставки, да и финальное решение при согласовании структуры команды может быть за ним.
Очевидно, что такая ответственность должна предполагать осведомленность в вопросе формирования штатных единиц, но в жизни так бывает не всегда. Порой бизнес-руководители имеют слабое представление о тех реалиях, в которых работают их подчиненные, и из-за этого могут сформулировать свои запросы некорректно. Да и сами продуктовые команды не всегда способны объективно оценить, какой ресурс дизайна им необходим.
Поэтому дизайн-лиду нужно относиться к пожеланиям бизнеса уважительно, но критично. Если очевидно, что коллеги ошибаются, придется приложить усилия, чтобы выработать единую позицию. Зато если это получится, вы обеспечите себе поддержку не просто сильных союзников, но и лиц, принимающих решения.
Менее очевидный способ определить размер новой дизайн-команды – ориентироваться на количество программистов в продуктовых командах, с которыми будут работать дизайнеры. Смотреть нужно на frontend- и «мобильных» разработчиков, то есть на тех, кто занимается визуальной составляющей интерфейсов. Причем связку «разработчик iOS + разработчик Android» можно считать за одну единицу, если они работают по одним и тем же дизайн-макетам. Backend-разработчиков пересчитывать не следует: эти ребята работают «на глубине», и их деятельность связана с дизайном в меньшей степени.
Метод работает так. Посмотрите, какое соотношение дизайнеров и разработчиков в других командах. Учитывайте только активные команды, которые регулярно выпускают новые фичи. Те, что находятся в стадии формирования или кризиса, в расчет брать не нужно. Предположим, вы выявили соотношение 1 к 6 – это и есть цифры, к которым можно апеллировать.
Связать число дизайнеров с количеством разработчиков кажется отличной идеей: если команда набрала много ребят, которые будут верстать интерфейсы, она сможет реализовать много пользовательских сценариев, спроектировать которые предстоит дизайнерам.
Это может быть правдой, но и к этому критерию нужно относиться с осторожностью. Далеко не во всех продуктовых командах оптимальный подход к набору разработчиков: где-то они загружены сверх меры, а где-то имеют столько свободного времени, что берут несколько параллельных проектов на фрилансе. Если дизайн-команда будет воспроизводить такую структуру, неравномерная нагрузка получится и у ее участников.