Орг структура моей компании постоянно менялась и меняется, несмотря на то, что она предоставляет один и тот же набор сервисов по разработке, помощи в освоении и поддержке платформ электронной коммерции.
Изначально, когда в компании было до 50-70 человек, существовала жесткая линейная структура и одна функция - проектный офис. Проектный офис состоял из нескольких однотипных модулей / орг звеньев / проектных команд, каждая команда имела своего линейного менеджера (как правило проектного менеджера). Все люди в нужных позициях прикреплялись к проектным командам и каждая команда могла обслуживать нескольких клиентов/проектов. В это время по чуть чуть начали выделяться функциональные зоны, разработка, тестирование, бизнес анализ и прочее, в каждой их этих зон выделялся свой чемпион, которому позволялось тратить немного времени на работы с практиками и с людьми. Те функциональная структура на этом этапе развития компании была в самом зачатке и не была выделена отдельно в организационной структуре.
На этапе в 70 сотрудников, выделилось еще оргзвено - это отдел R&D. Выделился он главным образом потому, что поменялась модульность целевой системы и соответственно практики работ. В этот отдел вошли оргзвенья, которые занимались созданием модулей для переиспользования, которые могли быть использованы всеми другими оргзвеньями в процессе работы. Интересно то, что этот модуль/оргзвено был отделен от проектного офиса и работал независимо. Были определены полномочия, протокол взаимодействия и интерфейс взаимодействия. Это был ответ компании на значительный рост числа проектов и невозможность нанять инженеров/сотрудников в разумные сроки, и так же, возможность увеличить прибыль, так как можно было переиспользовать существующие наработки, вместо создания их с нуля.
Примерно в районе > 100 человек, стало понятно, что невозможно держать проектные команды / оргзвенья стабильными, и гораздо проще и выгоднее пересобирать их под конкретные проекты. Для этого ввели орг звено Resource Manager, ответственное за перераспределение людей между проектами. Как результат, функциональная структура стала более значимой, так как все больше внимания стало уделяться найму и подготовке сотрудников к работе, а также практикам работы. Однако, пережитки линейной системы оставались, и это выливалось в непонимание, кто ответственный за что. Например, является ли проектный менеджер (линейный руководитель из прошлой структуры) ответственным за повышение/увольнение инженера, или нет. Могут ли линейные менеджеры менять вид жизненного цикла проекта или нет.
Примерно в районе 180-200 человек выделилась новая структура CTO office. Эта структура сначала определила разработчков под разные платформы как основные функции и взяла их в подчинение, чуть позже добавила все остальные инженерные функции: solution architecture, business analysis, quality assurance и прочее.
Однако, оставалось не решенными несколько проблем. Первое, это проблема масштабирования. В отделе разработчиков под определенную платформу сидело 100 человек, их всех нужно было обучать, и как то работать с ними, те внутри каждой функции нужно быстро выстроить свою линейную структуру те создать более мелкие модули внутри более крупных модулей. Второе, это то, что сами проектные команды выделились в отдельную структуру ответственную за успех оказания сервиса. И нужно было определиться, как должны взаимодействовать функциональные структуры (CTO office) и структуры ответственные за оказание сервиса (условно: Проектный офис).
Для решения первой и второй проблемы была выбрана структура организации, которая называется Helix Beyond matrix organization, the helix organization | McKinsey. По сути это матричная структура с жестко разделенными полномочиями. Вся структура бьется на 2 ветви: Value Chain и Capability Chain. Value Chain - это функция ориентированная на предоставление сервиса и отвечающая за его качество. Capability Chain - это функция отвечающая за все производственные практики и за развитие орг звеньев. В рамках capability chain были введены линейные менеджеры, что позволило масштабировать эту структуру еще больше.
На текущий момент выбранная структура работает отлично для компании размером около 300 сотрудников. Хотя по прежнему существуют серые зоны, особенно на стыке инженерии и проектного управления, например кто ответственен за управление практиками (или подпрактиками) жизненного цикла. Существуют некоторые шероховатости в части интеграции модулей функциональной структуры в поддерживающие организацию орг звенья (CFO office, Marketing, Sales, Pre-sales). Те часть модулей/оргзвеньев, которые выполняют функции в рамках CTO office также выполняют функции в составе Sales Office в части pre-sales. Одно из возможных решений, это помещение функции pre-sales в CTO office, и таким образом проблемы с распределение времени на работы и ответственность за практики работы.