Кроссфункциональные команды
С кем вы хотите работать? Кому подчиняетесь? С кем сотрудничаете? Ответы очевидны и в очень маленьких компаниях (со всеми и всем), и в очень больших (до вашего прихода все уже организационно структурировано). В качестве лидера растущей компании вам придется отвечать на эти вопросы как минимум единожды, а может быть, и много раз. Каковы же будут ответы?
Я хочу уделить немного времени рассказу об одном замечательном опыте, вынесенном из работы в Rent the Runway, онлайн-сервисе аренды одежды. В ней была создана команда, совмещавшая функции разработчика ПО и подразделения по продуктам. Когда я пришла в компанию, команда инженеров-программистов была разделена примерно на две части: фасадную, занятую разработкой клиентской части сайта, и складскую, занимавшуюся поддержкой программного обеспечения, которое управляет логистикой. Мы быстро сделали так, что фасадная часть команды стала заниматься и пользовательским интерфейсом, и программно-аппаратным обеспечением, потому что переписывала код с РНР-монолита на микросервисные архитектуры, построенные на языках Java и Ruby.
В конце первого года моего пребывания в компании мы осуществили эксперимент. Нам нужно было создать для потребителей новый продукт — программу, строившуюся на собственных фотографиях клиенток. Поскольку для них большой проблемой был поиск одежды, идеально подходившей по размеру конкретной женщине, мы хотели дать потребителям возможность просматривать изображения других клиенток в такой одежде, которые они загружали бы в программу. При этом изображения должны были сопровождаться дополнительной информацией от клиенток, включающей их размер, рост, вес и характер фигуры (атлетическая, грушевидная, пышная и т. д.). Для разработки программы мы и создали многофункциональную команду. В ней были инженеры, имевшие хороший опыт работы с интерфейсами, а также программисты, специалисты по программно-аппаратному обеспечению. В команду входили менеджер по продукту, дизайнеры, аналитик и даже представитель службы клиентского сервиса. Команда начала разработку программы для потребителей.
Проект оказался очень успешным. Мы довольно быстро создали хорошую программу, причем все участники команды были довольны, потому что ясно понимали цели проекта и могли работать эффективно в составе многофункциональной группы. До этого проекта мы были сильно привязаны к схеме «мы против них». Главными были «мы» (инженеры, специалисты по продукту, аналитики, маркетологи), а вся остальная организация — «они». Новая схема была удачей в плане организационного здоровья команды. Поэтому мы решили, что во всей организации разработка нового продукта (в том числе и в смысле информационных технологий) должна строиться на основе таких кроссфункциональных групп. Их можно называть по-разному — «небольшая стая», «отряд» или «опорная колонна», — но многофункциональные образования становятся все более популярными по вполне определенным причинам. Объединяя работников, нужных для успешного осуществления проекта, мы тем самым помогаем им концентрироваться на проекте и делаем коммуникацию внутри группы гораздо более эффективной.
Закон Конвея24, часто упоминаемый в дискуссиях, гласит: «Организации, осуществляющие дизайн систем… часто обречены на то, что системы копируют структуру общения в самих организациях».
Создавая кроссфункциональные организации, мы тем самым признаём, что наиболее важным видом коммуникаций внутри них, нужным нам больше всего, становятся те, что ведут к разработке и выпуску продукта. Обратите внимание, что при этом не обязательно задействуются самые передовые технологии! Могут быть даже разработаны менее эффективные системы, чем в компаниях, где центральную роль играют команды инженеров-программистов. Поэтому, отважившись на формирование многофункциональных команд, вы должны решить: согласны ли вы признать некоторые слабости систем в пользу наиболее эффективного процесса разработки продукта?
Организация кроссфункциональных команд
Как же работают «гайки и болты» в «стайных» структурах? Один вопрос, часто вызывающий беспокойство: кто кем управляет? Перейдя к многофункциональной схеме, мы не меняли организационную структуру команд. Программистами управляли менеджеры по технологиям, подчинявшиеся мне. Менеджеры по продукту подчинялись руководителю соответствующего подразделения. Однако определение, кто над чем работает, в значительной мере происходило внутри группы. Работники находились под техническим управлением и контролем со стороны менеджеров, но повседневная работа организовывалась самой командой в соответствии с потребностями действующего плана разработки продукции.
Разумеется, каждое функциональное направление сосредоточивается на конкретных обязанностях. Кто-то из инженеров-программистов контролирует создание базовых систем, и вокруг него работает несколько специалистов, занимающихся базовым веб-приложением, мобильными приложениями и базами данных. У меня эти функции были сосредоточены в небольшой инфраструктурной группе, непосредственно разработкой продукта не занимавшейся. Даже в подобных группах инженеры, разрабатывавшие конкретный продукт, должны иметь некоторый резерв времени, чтобы заниматься такими вещами, как помощь пользователям по телефонным звонкам (дежурства on call), интервьюирование пользователей или поддержка программ. Я на основе личного опыта и опыта коллег рекомендую, чтобы 20% рабочего времени инженеров-программистов отводилось на эту работу.
Кроссфункциональные структуры не редкость в стартапах. Многие большие компании тоже часто организуют команды по такому принципу. Например, в банках команды инженеров-программистов порой придаются определенному направлению деятельности финансового учреждения. Структура менеджмента определяется инженерами, а планирование и повседневная работа — совместно бизнес-подразделением и приданной группой инженеров. В крупных компаниях иногда имеется центральная межфункциональная группа, которая разрабатывает базовые системы и платформы, используемые затем командами в организации. Даже во многих компаниях сугубо технического профиля применяются многофункциональные структуры. Бизнес-подразделения могут возглавлять бывшие инженеры-программисты, выступающие как менеджеры по продукту или бизнес-менеджеры вместо специалистов по бизнесу.
Межфункциональная структура, несомненно, оказывает на команды определенное влияние. Скажем, в группах, занимающихся информационными технологиями, инженеры работают исключительно с коллегами (тем более с коллегами того же профиля — специалистами по мобильным приложениям, программно-аппаратному обеспечению или связующему ПО). В центре внимания работников находится завоевание статуса лучшего инженера по принятым параметрам. Здесь лидерами и примером для подражания становятся те, кто создает дизайн сложных систем или в совершенстве знает мельчайшие детали последних мобильных операционных систем. В структурах, ориентированных на продукт, требования меняются. Теперь лидерами становятся инженеры, обладающие лучшим чутьем на продукт, создающие новое ПО быстро и эффективно и лучше общающиеся с представителями других групп и функциональных направлений.
Я не стараюсь навязывать свое суждение, но призываю всегда понимать разницу между ориентацией на продукт или бизнес и ориентацией на технологии. Руководствуйтесь каждой там, где целесообразно. Что по-настоящему важно для успеха компании или организации? Если создание продукта, сочетающего разные стороны бизнеса, то вы, видимо, заинтересованы в лидерах, бизнес-интересы понимающих. Напротив, там, где прежде всего необходимы солидные инновационные информационные технологии, больше нужны инженеры и разработчики сложных систем. Зачастую вам не нужно полностью ориентироваться на один вариант. Но вам нужно сознавать, что одно из направлений должно быть ведущим. И особенно если вы один из высших руководителей компании: вы должны уметь сосредоточить внимание на направлении, наиболее ценном для компании, и сконцентрироваться на нем.
