Аналоговый блог [отца] Григория

Компании бывают большие, средние и маленькие. Но независимо от размера и специализации, во всех компаниях решается как минимум два вопроса: вопрос управления персоналом и управления проектами.

Для маленьких компаний все просто: директор, бухгалтер и несколько рабочих, подчиняющихся директору. В таких компаниях редко, когда несколько крупных проектов выполняются параллельно (они физически не могут себе этого позволить), поэтому схема управления достаточно прозрачная.

Компании среднего масштаба, обычно, делятся на отделы (подразделения), отделом  управляет начальник отдела (менеджер среднего звена), подчиняющийся менеджеру высшего звена (или директору). Зона ответственности начальника отдела включает как управление персоналом, так и управление проектами внутри отдела.

А что, если компания состоит из 1000 человек. Как в такой компании построить эффективную структуру управления людьми и проектами? Особенно, если возникает много краткосрочных разноплановых проектов.

Работая в одной крупной компании, занимающейся разработкой программного обеспечения для мобильных устройств, я познакомился с матричной структурой управления, представляющей собой комбинацию двух видов разделения: линейную (управление персоналом) и функциональную (управление проектами). Хочу поделиться своими наблюдениями и мыслями относительно такой структуры управления.

Основное достоинство матричной структуры - возможность динамичной перестройки структуры коллектива при постановке и решении новых задач (гибкость и адаптивность). А главными недостатками являются дороговизна такой структуры (поскольку появляется два вида руководителей), необходимость регулярной перестройки команд и переквалификации персонала при возникновении новых задач (проектов).

Сотрудниками, кстати, нововведение матричной структуры воспринимается обычно “в штыки”, так как теперь им приходится подчиняться двум боссам. Но сотрудников, обычно, никто не спрашивает :-) Так что поднимать бучу бесполезно.

Самое время перейти к практической части.

Рассмотрим вариант построения матричной структуры управления в IT компании занимающейся производством и выпуском программных платформ для мобильных устройств (например, смартфон на базе Android).

Для начала небольшой терминологический экскурс.

В матричной структуре управления существуют два вида руководителей: линейные и проектные. Линейный менеджер (LM) руководит людьми, менеджер проекта (PM) руководит процессом разработки. К видам проектных элементов относим компоненту, платформу и продукт:

• компоненты – это программы, сервисы, драйвера
• платформа – это базовая версия устройства, в которую вклчается операционная система + драйвера + сервисы, необходимые для того, чтобы устройство заработало
• продукт – это платформа + кастомизация (настройка) под пользователя

Для каждого из трех элементов существуют свои PM. Низшим управляющим звеном проекта являются лидеры подразделений – это опытные разработчики, возглавляющие процесс разработки какой-то небольшой компоненты.

На диаграмме отражена только линейная иерархия (управление персоналом) и не отражены функциональные связи и взаимодействия между отдельными участниками. Функциональные связи между участниками структуры определяют поток данных,  жизненно важный для текущих проектов, и могут периодически меняться, перестраиваться, адаптируя документооборот и поток данных под новые задачи.

Обозначения на диаграмме:

LM = Line Manager - человек, который руководит персоналом и решает рабочие задачи, а также предоставляет ресурсы (людей) для PM

PM = Project Manager - человек, который руководит проектом. Его мало беспокоят рабочие вопросы типа планирования отпусков, сломанных стульев и трудовой дисциплины, потому что всем этим заведуют соответствующие Line Manager. Зато его волнуют вопросы этапов и сроков сдачи проекта, ресурсы, выделенные на проект и результат работы.

• Senior LM - линейный руководитель подразделения, главный Line Manager
• BSP Team PM – менеджер проекта по разработке BSP (Board Support Package). Начальник команды, занимающейся портированием операционной системы на конкретную аппаратную платформу устройства (в частности телефона, смартфона, карманного ПК)
• Test LM – линейный руководитель всех тестеров. Под его началом находится обычно несколько команд, которые тестирую продукт, платформу, отдельные компоненты и фичи
• Senior Platform PM – главный менеджер проекта, который руководит разработкой платформы. Платформа – это еще не продукт, это то, что является основной для продукта. Платформа включает в себя операционную систему, прослойку BSP (драйвера и сервисы), а также базовый набор компонент – все то, что необходимо для работы устройства.
• Senior Product PM – главный менеджер проекта, который руководит разработкой продукта. Продукт продается конечному пользователю и представляет собой программную платформу + кучу софта + настройку устройства под конкретную страну (рынок, язык, пользователя) + скиннинг.
• Product Team LM – линейный руководитель продуктовой команды.
• System Engineering LM – линейный руководитель команды, которая решает архитектурные вопросы платформы, продукта и отдельных компонент, а также проверяет требования на разработку системы в целом и отдельных ее частей.
• Platform Team LM – линейный руководитель команды разработчиков платформы.
• Feature Lead – опытный разработчик, отвечающий за успешное решение поставленной задачи (разработку компоненты)
• RM Team Lead – лидер группы Release Management, выпускающей новые релизы
• CM Team Lead – лидер группы интеграторов, которые интегрируют изменения разработчиков в текущий проект и строят билды
• Tools Team Lead – лидер группы разработчиков вспомогательных инструментов
• MIB Team Lead – лидер команды Man In Black, решающей суперсрочные проблемы, которые не могут решить обычные разработчики за сегодня-завтра. Команда MIB состоит из суперопытных и быстродумающих разработчиков (“нелюдей” :-).
• Customization Team Lead – лидер группы настройщиков, выполняющих настройку базовой версии продукта для конкретного заказчика (покупателя). Например, они занимаются составлением списка компонентов, которые войдут в различные языковые версии билда или для разных заказчиков, а также укомплектовывают платформу мобильного устройства полезными тулзами, .
• Requirement Team Lead – лидер группы требований, которые составляют, меняют и проверяют требования на разработку отдельных компонентов и системы в целом
• Architect Team Lead – лидер группы системных архитекторов, которые планируют структуру системы и взаимосвязь компонентов; создают прототипы, ищут решения возникающих задач.
• Feature PM – менеджер проекта отдельной, достаточно крупной компоненты

Матричная схема управления показывает свою эффективность в том случае, когда часто возникают разноплановые проекты и имеется штат квалифицированный специалистов широкого профиля (или быстрообучаемых сотрудников). На мой взгляд, матричная структура управления хорошо подходит IT компаниям, выполняющим роль подрядчика на разработку программных продуктов западных заказчиков (типичные ”оффшоринш девелопер центры”).