(Перед вами перевод бесплатного курса «Design Engineering» от компании InVision. Если вы здесь впервые, то лучше начните сначала)
Процессы тюнинга, фиксов и развития идут постоянно. Поэтому понимание того, как функция может адаптироваться к любым изменениям, сохраняя при этом свою культуру, является ключом к устойчивости.
Нет «правильного» ответа на вопрос организационной структуры. Скорее, как сказал Джон Маэда в рамках интервью для Design Leadership, вам нужно задать два основных вопроса:
- У нас сейчас правильная организационная структура для текущего этапа роста (growth) в текущих рыночных условий?
- Если мы знаем, где мы хотим быть в будущем, сможем ли мы собрать необходимую оргструктуру к тому моменту?
«Все, что мы создаем, имеет свои ограничения, и если мы не знаем, что они из себя представляют, мы не сможем развивать дизайн-решение».
Джон Маэда, Chief Technology Officer of Everbridge. Автор «Законы простоты
Дизайн. Технологии. Бизнес. Жизнь»
У меня есть опыт управления командами и опыт управления изменениями. А еще я многому научился у коллег в Indeed. Там мне посчастливилось учиться у Эдди Лу (директор по дизайн-инжинирингу) и Анны Ву (UX-менеджер, ранее — менеджер по дизайн-инжинирингу). И я считаю важным, чтобы вы тоже узнали то, что раздобыл по следующим вопросам:
- Централизованная модель: каковы плюсы и минусы того, что каждый участник команды подотчётен одному руководителю?
- Децентрализованная модель: каковы плюсы и минусы того, что участники команды распределены по организации и отчитываются перед различными подразделениями и несколькими руководителями?
- Гибридная модель: как выглядит смешанный (blended) подход между централизованными и децентрализованными структурами?
- Отчетность: каковы преимущества и недостатки отчетности перед различными функциональными руководителями?
В этой главе мы уделим особое внимание обеспечению ресурсами, вниканию в тонкости продукта, компетенциям, карьерному росту и лидерству.
Вы уже знаете, что продакты, руководители дизайн-команд и разработки часто обращают внимание на различные долги под капотом системы как на ключевую движущую силу для повышения скорости и стратегических возможностей. Однако предприниматель Стив Бланк утверждает, что организационные недоработки похожи на технические, но еще хуже.
«Стив Бланк ввел термин "структурный долг" в 2015 году и определил его так: все компромиссы между людьми/культурами, которые были приняты для того, чтобы "просто сделать это" на ранних этапах стартапа».
Ким Уильямс (Kim Williams), Head of product design at Minted
Это мышление можно легко применить на ранних этапах новой дисциплины и/или рефакторинга существующей дисциплины. Бланк предполагает, что ничто не убивает компанию быстрее, чем организационный долг.
Компанию с конкурентным преимуществом создает прочная культура, которую направляет стратегия и поддерживает команда с верой в главную цель. Именно такая компания и получает инвестиции в свой рост.
Централизованная модель
Если ваша команда дизайн-инжиниринга еще только зарождается или вы только стартовали, вы, вероятно, начали с централизованной модели.
Централизованная модель объединяет всех дизайн-инженеров в одной команде в общем пространстве (физическом или виртуальном), при этом все находятся под управлением одного руководителя. Некоторые называют такой подход «центром передового опыта», поскольку есть центральный лидер, который внедряет стандарты, а другие команды приходят в централизованную группу за их услугами – почти так же, как клиент обращается к агентству.
Как и любая организационная структура, централизованная модель имеет свои плюсы и минусы. Мы оценим их далее.
Ресурсы
Одно из преимуществ централизованной структуры состоит в том, что ресурсы команды более подвижны и адаптируются к изменениям. Как только возникает насущная бизнес-задача, команда мобилизуется для решения этой задачи. Благодаря нисходящей структуре руководители знают сильные стороны и навыки каждого из членов своей команды. Поэтому могут быстро понять как и какие силы лучше всего вложить для решения задачи. Наличие одной большой команды под централизованным руководством также дает некоторую экономию при масштабировании.
С другой стороны, такая модель может создать определенную напряженность между командой ядра и командой с централизованной моделью — ее могу считать «посторонней». Такой расклад может привести к политическому конфликту и потребует сильных лидеров, которые начнут активно строить отношения с другими отделами организации, чтобы противодействовать этому.
Знание продукта
Команда с централизованной модель внутри организации, скорее всего, будет работать с множеством кругов задач, поэтому у нее будет преимущество в виде обширной базы знаний о различных продуктах в компании и возможность работать в областях, которые ранее могли быть закрытыми.
С другой стороны, при такой схеме мало возможностей для развития глубоких знаний о продукте и отраслевой экспертизы. Внедрение модели не является всесторонним, так как взаимодействие с продуктом может варьироваться.
Основные компетенции
Сильная сторона такой схемы — погружение в новое направление с помощью вопросов. Централизованные команды непрерывно подключаются к разработке новых продуктов к другим командам и оперативно находят решения, а также оценивают развития событий, по которым может пойти продукт или стратегическая инициатива.
Ребятам в таких командах свойственно любопытство и они также способны перемещаться по ландшафту сценариев. Такие команды также могут легко менять направление после извлечения уроков из прототипов и пользовательских тестов.
Но централизованные команды не всегда остаются надолго в какой-либо одной области продукта. По этой причине они не разовьют столь же полное понимание внутренней работы продуктовой команды, включая технические и операционные ограничения. Кроме того, централизованные команды могут восприниматься как «посторонние», для получения разрешения на реализацию стратегических инициатив им требуется гораздо больше усилий.
Пути развития карьеры
Поскольку централизованные команды подотчётны одному руководителю, существует четкий владелец (owner) и лицо, принимающее решения для карьерного роста (career growth). Каждый в команде может развивать комплект навыков на основе матрицы навыков, которые могут со временем развиваться (по мере расширения команды). Естественная иерархия централизованной команды также открывает возможности для различных типов карьерного роста как для руководителей, так и для отдельных участников.
Однако сила, которую дает один лидер, также потенциально может быть слабостью. Так как у него может быть сосредоточено слишком много власти, при этом внимание одного всегда ограничено — это влияет на качество погружения в суть дел и стратегию развития каждого в команде.
Лидерство и управление
Как обсуждалось выше, наличие единого лидера может дать централизованной команде значительные выгоды. Руководители в такой модели могут управлять развитием навыков, развивать стандарты и единую стратегию, которая соответствует потребностям бизнеса.
Руководители в таких командах обладают предпринимательским духом, поскольку они постоянно развивают культуру команды и показывают результаты в ROI. Ценности в такой команде будут развиваться по мере роста компании, а руководители могут следить за результативностью, и подключать необходимые ресурсы по мере необходимости (инструменты, обучение, сотрудники).
Одна из проблем этой модели заключается в том, что руководители команд могут продвигать разные точки зрения на стандарты, особенно касательно роста и развития команд разработчиков.
Например, одна команда разработчиков может привлечь дизайн-инженеров к работе по внутренней разработке программного обеспечения, и эта работа может не соответствовать ключевой компетенции дизайн-инженеров. Конечно, головная команда всегда готова помочь, но главная задача лидера в центральной модели — обеспечивать развитие стандартов карьерного развития.
Децентрализованная модель: кросс-функциональные команды
Децентрализованные команды подключают дизайн-инженеров по кросс-функциональной схеме. Такие группы, как правило, обладают большей автономией в принятии ключевых решений, а общение между разработкой, продактами и дизайнерами осуществляется оперативнее. Такой тип модели характерен для компаний с General manager (GM).
Автономность децентрализованной модели привлекает, поэтому вы можете сразу захотеть начать с нее. Но децентрализованная модель как первая не сработает в большинстве случаев, если не проработать правильный фундамент. Давайте подробнее рассмотрим эти основы, а также другие плюсы и минусы этой модели.
Ресурсы
Дизайн-инженеры здесь часть кросс-функциональной команды и, соответственно, ощущают большую связь с назначенной командой (по сравнению с централизованной моделью). При такой схеме их с меньшей вероятностью начнут воспринимать как «посторонних». Но такой подход может нанести и ущерб гибкости. После того как дизайн-инженеры распределяются по назначенным командам, организации становится сложнее перераспределить ресурсы, при смене бизнес-приоритетов.
Знание продукта
После распределения по командам, дизайн-инженер в децентрализованной модели начинает накапливать глубокие знания только в определенной области продукта. У него появляется доступ к подробной документации с продуктовому контексту и требованиями по определенной функциональности, а еще он может даже сам заняться разработкой гайдлайнов.
Обучение и адаптация в такой команде происходит один раз при приеме на работу.
Недостатком этой модели является то, что участники команды могут стать разрозобщенным, так как они станут экспертами в определенных области (областях) продукта.
Основные компетенции
Децентрализованные команды склонны придерживаться более системного подхода к разработке продукта. А благодаря глубокому знанию продуктов и близости к своим коллегам по разработке и продуктовой работе им не нужно делать столько предположений о технических и эксплуатационных ограничениях.
Сложность этого подхода состоит в том, что команда может столкнуться с трудностями из-за неоднозначностей в стратегических инициативах, особенно если они еще и привязаны к гибкому рабочему процессу, который не оставляет места для анализа, исследований и экспериментов.
Кроме того, ребята в такой схеме могут какое-то время действовать без четкого видения, которое еще прорабатывает руководитель.
Пути развития карьеры
Благодаря кросс-функциональному сотрудничеству в децентрализованной модели у дизайн-инженеров есть шанс, что их вклад оценят коллеги (разработчики, продуктовые дизайнеры). Это в свою очередь может побудить их узнать больше об этих дисциплинах и внести свой вклад в единство команды разработчиков.
Пути карьерного роста являются наиболее важным и основополагающим фактором, поэтому они должны быть определены до перехода команды к децентрализованной модели. Дизайн-инженеры при таком сценарии отчитываются перед участником команды с другими функциональными задачами, иными приоритетами и стандартами. Такие сотрудники могут как иметь, так и не иметь влияния на карьерный путь дизайн-инженера. Если не заложить четкий путь карьерного роста, каждая команда может попытаться решать одну и ту же проблему и разрабатывать планы развития карьеры, несовместимые между командами.
Лидерство и управление
Лидеры в децентрализованных командах больше всего выигрывают от автономии в принятии ключевых решений. ROI в такой модели рассчитывается с учетом кросс-функциональности.
Руководители в такой схеме теснее ведут диалог со своими коллегами и могут добывать дополнительные ресурсы. Однако без центрального лидера на вершине организации, руководители в этих командах могут страдать от отсутствия единого видения своих целей и задач. Из-за этого может произойти фрагментация – ситуация, в которой руководители уровнем выше не видят необходимости в согласовании действий.
Гибридная модель
Гибридная модель становится все более распространенной, так как сочетает в себе несколько организационных моделей и параллельно задействует комбинации моделей. Давайте посмотрим на гибридную модель, чтобы рассмотреть пересечение централизованной и децентрализованной моделей:
Пример гибридной модели
Одна гибридная структура включает централизованную команду со специализированными участниками в рамках кросс-функциональной продуктовой команды. Централизованный руководитель — это руководитель функционального звена, прокачивающий определенную область организации.
Команда дизайн-инженеров при такой модели получает ежедневные приоритеты от UX-руководителей в продуктовой команде.
Гибридная модель обладает всеми преимуществами централизованной и децентрализованной моделей, а также всеми недостатками централизованной модели.
Причина, по которой эта модель нравится многим организациям от малых до крупных, заключается в том, что она более гибкая, практичная и легко масштабируется для различных бизнес-целей.
Вот одно из проявлений гибридной модели, которую мы ранее исследовали в Indeed. Питер Мерхольц и Кристин Скиннер изучали организационные подходы на протяжении многих лет работы и изложили их в книге «Org Design for Design Orgs». В книге представлена гибридная модель «Централизованное сотрудничество» и дополнительные соображения, объясняющие, почему смешанный подход наиболее эффективен. Давайте рассмотрим структуру отчетности более подробно.
Структура отчетности
Важно понимать плюсы и минусы вашей организационной структуры, а также важно знать преимущества и недостатки вашей структуры подотчётности. По сути, существует три способа, которыми проектная организация будет отчитываться перед руководством, с некоторыми вариациями в том, как команда (группы) дизайн-инженеров отчитывается в организации, возглавляемой руководителем продукта:
Мне удалось пообщаться с Эдди Лу (Eddie Lou, Senior Director, Design Engineering at Indeed), чтобы узнать его мнение о влиянии различных структур подотчётности на команду разработки, при этом уделил особое внимание проектным организациям, которые возглавляют директор по конфиденциальности (CPO) или директором по данным (CDO).
Когда дизайн-инженеры подотчётны разработчикам в продуктовой компании, обычно наблюдается предвзятость в сторону full-stack разработчиков, поэтому frontend-разработчик, которому нравится заниматься дизайн-инжинирингом, может остаться невостребованным.
Зачастую у разработчиков, которые не умеют работать с базами данных или усиливать безопасность системы, нет возможностей для продвижения и карьерного роста. Т.е в случае, когда руководитель отдела разработки не может построить работу вокруг дизайн-инженеров, они не будут чувствовать никакой поддержки. В таком случае бизнес не сможет получить максимум отдачи из такого ценного таланта.
Ситуация может сложиться лучше, если в продуктовой компании дизайн-инжиниринг будет работать под началом отдела дизайна.
Часто при таком сценарии дизайнеры ждут, что дизайн-инженеры помогут ускорить реализацию их идей путем устранения барьеров между ними и разработчиками. Естественное сотрудничество между этими двумя областями и тот факт, что руководители дизайна с большей вероятностью вложат средства в карьерный рост дизайн-инженеров, повышают вероятность удержания таланта.
А еще существует сценарий, по которому вся проектная организация, включая дизайн-инжиниринг, подотчётна главному директору по дизайну. Во многих отношениях такая структура идеальна, потому что она дает разработчикам, продуктовой команде и дизайнерам равное право голоса на исполнительном уровне и может привести к более сбалансированным приоритетам в всей команде. Такие организации, как Airbnb, используют эту структуру, чтобы, по словам Алекса Шлейфера (Airbnb), убедиться, что «каждая функция может расти параллельно и как требуется, по мере увеличения масштабов организации».
Посмотрите плюсы и минусы различных подходов к организации в таблице →
Вывод и рекомендации
Джон Маэда уже поднимал вопрос о том, что организационная структура вашей команды дизайн-инжиниринга зависит от стадии роста (growth) и условий рынка (Market Mapping). Возможно, уже через год придется изменять вашу структуру, поэтому необходимо продумывать развитие своих команд как можно раньше, чтобы было больше гибкости при крупных организационных изменениях. Если вы быстро растете, это особенно актуально.
Как сказала Линси Торнтон, вице-президент по пользовательскому опыту в Shopify, в подкасте Design Better Podcast: «Мы замечали, что каждая построенная нами организационная структура быстро устаревает, так как и мы быстро развивались. Поэтому нам приходилось планировать на 18 месяцев вперед, чтобы представлять, где мы будем и что нам понадобится».
Кроме того, на уровне всей компании с быстрым ростом часто происходит переход к гибридной модели, которая может принимать децентрализованные организационные модели.Следует вложить время в планирование изменений и рассмотреть потенциальные преимущества и недостатки каждой модели: так станете гибче к изменяющимся условиям, а команды станут смелее в реализации инициатив.
В следующей главе мы рассмотрим нюансы масштабирования практики дизайн-инжиниринга. Эти основы помогут вам переходить от одной организационной модели к другой.
← Назад | Продолжение (Глава 5) →