От разработчика до руководителя

Проект оказался очень успешным. Мы довольно быстро создали хорошую программу, причем все участники команды были довольны, потому что ясно понимали цели проекта и могли работать эффективно в составе многофункциональной группы. До этого проекта мы были сильно привязаны к схеме «мы против них». Главными были «мы» (инженеры, специалисты по продукту, аналитики, маркетологи), а вся остальная организация — «они». Новая схема была удачей в плане организационного здоровья команды. Поэтому мы решили, что во всей организации разработка нового продукта (в том числе и в смысле информационных технологий) должна строиться на основе таких кроссфункциональных групп. Их можно называть по-разному — «небольшая стая», «отряд» или «опорная колонна», — но многофункциональные образования становятся все более популярными по вполне определенным причинам. Объединяя работников, нужных для успешного осуществления проекта, мы тем самым помогаем им концентрироваться на проекте и делаем коммуникацию внутри группы гораздо более эффективной.

Закон Конвея24, часто упоминаемый в дискуссиях, гласит: «Организации, осуществляющие дизайн систем… часто обречены на то, что системы копируют структуру общения в самих организациях».

Создавая кроссфункциональные организации, мы тем самым признаём, что наиболее важным видом коммуникаций внутри них, нужным нам больше всего, становятся те, что ведут к разработке и выпуску продукта. Обратите внимание, что при этом не обязательно задействуются самые передовые технологии! Могут быть даже разработаны менее эффективные системы, чем в компаниях, где центральную роль играют команды инженеров-программистов. Поэтому, отважившись на формирование многофункциональных команд, вы должны решить: согласны ли вы признать некоторые слабости систем в пользу наиболее эффективного процесса разработки продукта?

Организация кроссфункциональных команд

Как же работают «гайки и болты» в «стайных» структурах? Один вопрос, часто вызывающий беспокойство: кто кем управляет? Перейдя к многофункциональной схеме, мы не меняли организационную структуру команд. Программистами управляли менеджеры по технологиям, подчинявшиеся мне. Менеджеры по продукту подчинялись руководителю соответствующего подразделения. Однако определение, кто над чем работает, в значительной мере происходило внутри группы. Работники находились под техническим управлением и контролем со стороны менеджеров, но повседневная работа организовывалась самой командой в соответствии с потребностями действующего плана разработки продукции.

Разумеется, каждое функциональное направление сосредоточивается на конкретных обязанностях. Кто-то из инженеров-программистов контролирует создание базовых систем, и вокруг него работает несколько специалистов, занимающихся базовым веб-приложением, мобильными приложениями и базами данных. У меня эти функции были сосредоточены в небольшой инфраструктурной группе, непосредственно разработкой продукта не занимавшейся. Даже в подобных группах инженеры, разрабатывавшие конкретный продукт, должны иметь некоторый резерв времени, чтобы заниматься такими вещами, как помощь пользователям по телефонным звонкам (дежурства on call), интервьюирование пользователей или поддержка программ. Я на основе личного опыта и опыта коллег рекомендую, чтобы 20% рабочего времени инженеров-программистов отводилось на эту работу.

Кроссфункциональные структуры не редкость в стартапах. Многие большие компании тоже часто организуют команды по такому принципу. Например, в банках команды инженеров-программистов порой придаются определенному направлению деятельности финансового учреждения. Структура менеджмента определяется инженерами, а планирование и повседневная работа — совместно бизнес-подразделением и приданной группой инженеров. В крупных компаниях иногда имеется центральная межфункциональная группа, которая разрабатывает базовые системы и платформы, используемые затем командами в организации. Даже во многих компаниях сугубо технического профиля применяются многофункциональные структуры. Бизнес-подразделения могут возглавлять бывшие инженеры-программисты, выступающие как менеджеры по продукту или бизнес-менеджеры вместо специалистов по бизнесу.