Організаційні структури управління

Усі структури на одному екрані

Спершу все порівняння. Кожен рядок — одна структура: як вона групує людей, скільки керівників має одна людина, кому належать люди й бюджет і скільки повноважень у ній має проєктний менеджер. Назви в українському підручнику з менеджменту й у західній літературі з управління проєктами різняться, і ця різниця збиває з пантелику, тож наведено обидві.

Лінійна, ієрархічна, матрична — які з них справжні типи

Багато хто приходить до цієї теми з трьома словами — лінійна, ієрархічна, матрична, — і два з них позначають типи, а третє — ні. Лінійна — справжня структура: кожна людина має рівно одного керівника, і накази йдуть униз одним ланцюгом. Матрична — справжня структура: людина навмисно має двох керівників, одного за спеціальністю й одного за проєктом. Ієрархічна — не третій тип поряд із ними. Це властивість — наявність рівнів, кожен з яких підпорядковується вищому, — і вона є майже в кожній структурі з таблиці. Лінійна організація — найчистіша ієрархія; матриця — дві ієрархії, накладені одна на одну. Справжня протилежність ієрархічної — пласка чи самоврядна структура, де повноваження записано в ролі, а не в рівні.

Підручники іноді вживають «ієрархічні» як назву сімейства — у традиції Тома Бернса та Джорджа Сталкера, які в 1961 році протиставили механістичні організації органічним. У такому прочитанні лінійна, функціональна, лінійно-функціональна й дивізіональна структури — ієрархічні, або бюрократичні, а матрична, проєктна й бригадна — адаптивні. Це корисніше прочитання. Але список із трьох слів однаково пропускає найважливіше на практиці: лінійно-функціональну, дивізіональну, проєктну структури й продуктові команди — а саме в них живе більшість IT-компаній.

Два словники для тих самих форм

П’ять питань, що покажуть, у якій структурі ви працюєте

Оргсхема у вікі — це не доказ. Ось ці п’ять питань — доказ, і новий проєктний менеджер має знати відповіді на них уже першого тижня.

1. 1.Хто насправді вирішує

   1. 1.1Хто погоджує відпустки членів вашої команди?
   2. 1.2Хто визначає їхню зарплату й пише їм performance review?
   3. 1.3Коли два проєкти хочуть того самого інженера на наступний тиждень, хто вирішує?
   4. 1.4Хто може перерозподілити гроші всередині бюджету проєкту, ні в кого не питаючи?
   5. 1.5Коли проєкт закінчується, куди йдуть люди?

Якщо відповідь на 1.1 і 1.2 — керівник відділу, а на 1.3 — «домовляємося», ви у слабкій чи збалансованій матриці, хай би що казала схема. Якщо на 1.3 і 1.4 відповідаєте ви самі — це сильна матриця або проєктна структура. Якщо відповідь на 1.5 — «назад на бенч», компанія — матриця, де людьми володіють центри компетенцій. А якщо на 1.3 не може відповісти ніхто, ви знайшли найбільший ризик свого проєкту.

Два питання за кожною структурою

Кожна структура — це відповідь на два питання. Перше — як згрупована робота: за спеціальністю, щоб усі тестувальники були разом; за результатом, щоб разом були всі, хто будує мобільний застосунок; за клієнтом чи регіоном; або за проєктом. Друге — де лежать повноваження: скільки керівників має одна людина, скільки рівнів між тим, хто робить роботу, і тим, хто може вирішувати, і скільки можна вирішити, не піднімаючись цими рівнями.

Жодне групування не прибирає координації. Воно лише обирає, яку межу доведеться перетинати роботі. Групуйте за функцією — і кожна фіча перетинає відділи; групуйте за продуктом — і кожен спільний стандарт перетинає продукти. Питання проєктування завжди одне: за яке перетинання ви радше готові платити, — і чесна відповідь залежить від того, яку межу ваша робота перетинає найчастіше.

Що насправді вимірює «ієрархічність»

Друге питання — саме те, куди належить слово «ієрархічна», і це питання міри. Її здебільшого задає норма керованості (span of control) — скільки людей підпорядковано одному керівнику. Шістдесятьом чотирьом інженерам під керівниками з чотирма підлеглими в кожного потрібні три рівні управління й двадцять один менеджер. Якщо підлеглих по вісім — два рівні й дев’ять менеджерів.

Кожен рівень — це крок, на який має піднятися рішення, і крок, яким має спуститися відповідь. Вища структура дає кожному менеджерові менше людей і більше часу на кожну, але сповільнює кожне рішення, що перетинає межі команд. Пласкіша — швидша, але лишає кожному менеджерові менше уваги на людину. Жодна не є правильною. Це різні компроміси, і корисне питання — скільки кроків проходять ваші найчастіші рішення.

П’ять способів координувати роботу

Генрі Мінцберг у книжці The Structuring of Organizations (1979) назвав п’ять способів, якими люди координують роботу, і кожна структура спирається на одні з них більше, ніж на інші. Взаємне пристосування — люди просто говорять між собою. Пряме керівництво — керівник каже людям, що робити. Стандартизація робочих процесів — процедура, яка каже, як. Стандартизація результатів — специфікація того, що має вийти. Стандартизація навичок — наймати людей, навчених знати, що робити, без підказок.

Стартап із п’яти людей майже повністю тримається на взаємному пристосуванні. IT-департамент банку — на процесах і прямому керівництві. Продуктова компанія з крос-функціональними командами — на стандартизації результатів між командами (Definition of DoneDefinition of Doneщо тут означає «готово»Перелік умов, які робота мусить пройти, перш ніж її дозволено назвати завершеною: протестовано, перевірено, задокументовано, розгорнуто — як домовилась команда. Цінність у тому, що «готово» перестає бути предметом думки на статус-зустрічі.Докладніше в статті →Усі терміни, контракт APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни) і на взаємному пристосуванні всередині кожної. Багато що з того, що йде не так під час реорганізації, — це зміна структури, яка мовчки прибирає механізм координації, на який спиралася робота, і нічого не ставить на його місце.

Лінійна, функціональна, дивізіональна: класичні ієрархії

Лінійна

Лінійна структура — найпростіша з можливих: один ланцюг підпорядкування, один керівник на людину, накази вниз, звіти вгору. Анрі Файоль у 1916 році явно сформулював її головне правило як єдиноначальність: кожен працівник отримує накази лише від одного керівника. В IT це природна форма стартапу: засновник, можливо CTO, і інженери, які всі знають, хто вирішує. Вона швидка, дешева й однозначна. Ламається вона згори. Керівник мусить розуміти все, що вирішується, і щойно в компанії з’являється більше спеціальностей, ніж здатна оцінити одна людина, рішення вишиковуються в чергу до одного столу.

Функціональна й лінійно-функціональна

Фредерік Тейлор у праці Shop Management (1903) запропонував протилежність єдиноначальності — функціональних майстрів: працівник отримує вказівки від кількох майстрів-фахівців — одного щодо темпу роботи, іншого щодо контролю якості, третього щодо ремонту, четвертого щодо порядку робіт і так далі, усього вісьмох. Саме це українські підручники називають функціональною структурою. У чистому вигляді її майже немає, бо людина з вісьмома керівниками фактично не має жодного.

Існує ж усюди компроміс — лінійно-функціональна структура. Людей групують у відділи за спеціальністю — розробка, QA, DevOps, аналітика, дизайн, — у кожного один лінійний керівник, а штабні підрозділи на кшталт HR, фінансів, юристів, архітектурного офісу чи PMOPMOProject Management Office — офіс, що задає стандарти проєктівПідрозділ, що задає стандарти управління проєктами в організації, збирає звітність із проєктів і часом наймає проєктних менеджерів. Його цінність залежить від того, що саме з цього він робить: PMO, який лише збирає статус-звіти, додає рівень, не додаючи жодного рішення.Усі терміни радять лінії, не командуючи нею. Ідея штабу походить із військових генеральних штабів дев’ятнадцятого століття, а PMBOK називає результат просто functional organisation. Вона вирощує глибоку експертизу й зрозумілі кар’єри. Її провал — проєкт, якому потрібні всі відділи одночасно: робота стоїть у черзі під дверима кожного відділу, кожен керівник оптимізує завантаження своєї команди, і нижче за директора результатом не володіє ніхто.

Дивізіональна

Дивізіональна структура ділить компанію на напівнезалежні підрозділи за продуктом, регіоном чи клієнтом, і в кожного всередині свої функції. DuPont і General Motors збудували перші такі на початку 1920-х, а книжка Альфреда Чандлера Strategy and Structure (1962) перетворила їхню історію на правило: структура йде за стратегією. Дивізіон швидкий і відповідає за власні результати. Водночас він дублює кожного фахівця, а дивізіони поступово починають конкурувати між собою — за бюджет, за клієнтів і за платформу, яку мали б ділити.

Матриця: два керівники навмисно

Матриця накладає проєктну вісь на функціональну. Функціональному керівникові належить людина: найм, зарплата, навички, кар’єра. Проєктному — робота: що робити, у якому порядку, до коли. Інженер на перетині має двох керівників за задумом. Ця форма виросла серед американських аерокосмічних та оборонних підрядників у 1960-х, де сотні фахівців мали обслуговувати кілька великих програм одночасно, і сьогодні це типова форма IT-сервісних компаній: центри компетенцій або delivery-підрозділи на одній осі, клієнтські проєкти — на іншій.

Скільки влади на кожній осі — це й усе питання, і PMBOK називає п’ять точок на лінії між ними. Діаграма показує, як повноваження переходять від одного керівника до іншого; таблиця дає власні формулювання PMBOK для кожної точки.

У слабкій матриці проєктний менеджер насправді є експедитором або координатором: він нагадує, звітує й переконує, а кожне справжнє рішення щодо людей повертається до керівника відділу. Це легітимна й важка робота. Типова помилка — взяти на себе її відповідальність за дату без відповідних повноважень. У сильній матриці пріоритети вирішує проєктний менеджер, а функціональний дає людей і стандарти; тоді й performance review інженера має враховувати думку проєктного менеджера, інакше другий керівник тихо стає єдиним.

Дев’ять способів, якими ламається матриця

Стенлі Девіс і Пол Лоренс дослідили матричні компанії для Harvard Business Review у 1978 році й назвали дев’ять патологій, до яких ця форма особливо схильна. Частина з них трапляється в будь-якій організації; матриця просто вразливіша. Список постарів напрочуд добре.

Матрицю тримає в робочому стані не краща схема, а записані права на рішення. Хто вирішує пріоритет між проєктами — одна названа людина, а не комітет. Хто вирішує, як робити роботу, — команда, у межах стандартів відділу. Скільки часу кожної людини належить якому проєкту — домовлено на квартал, а не виборюється щотижня. Чия думка йде в performance review — обох. Решту каже назва статті Крістофера Бартлетта й Суманти Гошала в HBR 1990 року: матричне управління — це не структура, а спосіб мислення.

Проєктні структури й продуктові команди

На крайній точці шкали PMBOK — проєктна організація. Команда належить проєкту; проєктний менеджер наймає, спрямовує й відпускає людей; бюджет — його. Це найчистіша структура для одного великого дедлайну: державна система, програма міграції, запуск. Її слабкість настає в останній день. Коли проєкт закривається, людям нікуди йти, знання розпорошуються, а той, хто супроводжуватиме систему далі, не бачив жодного з тих, хто її будував.

Продуктові компанії пішли іншим шляхом. Замість збирати команду довкола кожного шматка роботи й розпускати її потім, вони тримають сталі, довгоживучі крос-функціональні команди — усі навички, потрібні продукту, в одній команді — і приносять роботу до команди. Сталою є команда; проєкти стають наступними елементами її беклогу. Більшість agile-методів припускають саме таку форму, і відповідальності в Scrum описують її.

Модель Spotify — це матриця

Найвідоміша версія — Spotify, описана Генріком Кнібергом і Андерсом Іварссоном у 2012 році. Squads — невеликі крос-функціональні команди, у кожної свій product owner. Squads, що працюють над суміжними напрямами, утворюють tribe. Люди з однаковою спеціальністю в різних squads утворюють chapter. Guilds — добровільні спільноти за інтересами, до яких може долучитися будь-хто. Стаття прямо називає цю форму матрицею, де squad — вісь поставки — основний вимір, бо саме там люди сидять і проводять свій час. Chapter lead — лінійний керівник, відповідальний за зарплату й розвиток, і водночас працює в одному зі squads.

Дві речі варто знати, перш ніж це копіювати. Стаття була знімком однієї компанії у 2012 році, і люди, що там працювали, пізніше писали, що багато що з неї ніколи не працювало саме так, як намальовано, — найвідоміший текст про це написав Джеремая Лі у 2020 році. І перейменування відділів на chapters, а команд на squads нічого не змінює, якщо разом із назвами не переходять права на рішення.

Team Topologies: чотири типи команд

Team Topologies Меттью Скелтона й Мануела Паїша (2019) — найпоширеніший сучасний словник для проєктування таких команд. Він називає чотири типи команд і три способи їхньої взаємодії: співпрацю — тісна спільна робота на обмежений час; X-as-a-Service — одна команда споживає те, що надає інша, з мінімальним контактом; і фасилітацію — одна команда допомагає іншій чогось навчитися.

• Stream-aligned команда

  Володіє одним потоком роботи — продуктом, шляхом клієнта — від ідеї до продакшену. Більшість команд мають бути саме такими; решта три існують, щоб полегшувати їм роботу.

• Платформна команда

  Надає внутрішні сервіси, якими stream-aligned команди користуються самостійно, — деплой, спостережуваність, дані, — щоб жодна команда не будувала інфраструктуру собі сама.

• Enabling-команда

  Фахівці, що допомагають іншій команді опанувати вміння — автоматизацію тестування, безпеку, новий фреймворк, — а потім відходять, а не роблять роботу замість неї.

• Команда складної підсистеми

  Володіє частиною, що потребує рідкісної експертизи, — відеокодеком, рушієм ціноутворення, рекомендаційною моделлю, — щоб усім stream-aligned командам не довелося її вивчати.

Закон Конвея: структура опиняється в коді

У квітні 1968 року Мелвін Конвей опублікував у Datamation коротку статтю — Harvard Business Review перед тим відхилив її, бо тезу не доведено, — із реченням, яке тепер називають законом Конвея: організації, що проєктують системи, змушені створювати проєкти, які копіюють їхні комунікаційні структури. Три команди створюють систему з трьох частин, а інтерфейси з’являються саме там, де командам доводиться говорити між собою.

Діаграма — практичний наслідок. Згрупуйте інженерів за шарами — фронтенд-команда, бекенд-команда, команда бази даних, — і система росте шарами, тож кожна фіча, якої просить користувач, перетинає три команди, три беклоги й дві передачі. Згрупуйте їх за продуктовими потоками — і архітектура піде за потоками, тож більшість фіч лишатиметься в межах однієї команди. Свідоме розташування команд заради потрібної архітектури називають зворотним маневром Конвея. Це ж пояснює, чому перехід на мікросервіси без змін в оргсхемі зазвичай відбудовує моноліт — по одному мережевому виклику за раз; сторінка про перехід від моноліту до мікросервісів описує міграційний бік цієї історії.

Докази з Windows Vista

Сорок років закон Конвея був спостереженням. У 2008 році Нахіаппан Нагаппан, Брендан Мерфі й Віктор Базілі перевірили його на Windows Vista: 3404 бінарні модулі й понад 50 мільйонів рядків коду. Вони будували моделі, що передбачали, які модулі зламаються після релізу, і вимірювали організацію довкола кожного модуля — скільки інженерів його торкалися, скільки з них пішло, наскільки далеко один від одного в оргсхемі сиділи його автори, скільки окремих підрозділів у нього робили внесок. Організаційні міри передбачали збої краще за будь-які міри коду.

Точність — яка частка модулів, позначених моделлю, справді зламалася; повнота — яку частку зламаних модулів модель знайшла. Висновок не в тому, що код не має значення. Він у тому, що хто працює над кодом і наскільки ці люди далекі одне від одного, передбачає якість щонайменше так само добре, як сам код. Брукс казав це ще в 1975 році; це було одне з перших великих вимірювань, що з ним погодилося.

Без менеджерів: пласкі й самоврядні структури

Кожне покоління компаній пробує прибрати ієрархію зовсім, і ці спроби задокументовано напрочуд добре. Дві варто знати детально, бо обидві вели люди, які справді цього хотіли.

Джо Фрімен пояснила цей патерн ще в 1972 році — пишучи про активістські групи, а не компанії, — у статті «Тиранія безструктурності». Група без формальної структури не стає безструктурною. У ній виникає неформальна структура, якою керує той, у кого найбільше часу, упевненості й друзів, — і ця ієрархія гірша за формальну, бо її не видно, її не можна оскаржити чи прибрати. Пласкі організації, що живуть довго, замінюють ланцюг підпорядкування явними, записаними правилами про те, хто що вирішує. Ті, що провалюються, прибирають ланцюг і нічого не пишуть на його місці.

Де реструктуризація перетворюється на театр

Реорганізація — найпомітніше, що може зробити керівник, і одне з найпростішого, що можна зробити, нічого не змінивши. Ось форми, яких набуває цей театр.

• Реорганізацію оголошують замість рішення: справжньою проблемою був пріоритет, якого ніхто не хотів визначати, а нова схема переносить ту саму суперечку на нові назви.
• Squads, tribes і chapters намальовано поверх відділів, які й далі вирішують усе.
• «Сильна матриця» на папері, у якій проєктний менеджер не може перемістити жодного інженера й жодної гривні.
• Відповідальність за дату покладено на того, хто не контролює ні людей, ні бюджету.
• «У нас пласка структура» — у компанії, де всі знають, чия думка насправді все вирішує.
• Двоє керівників, кожен з яких вважає, що performance review робить інший.
• Структуру скопійовано з блогу відомої компанії — без продукту, масштабу й людей, завдяки яким вона там працювала.

Чесна межа: структури без ціни не буває, є лише вибір, яку ціну платити. Кожна структура — це рішення про те, яку межу робота перетинатиме найчастіше, а закон Конвея гарантує, що ця межа проступить у продукті. Структура також не може дати того, на чому сама тримається, — довіри між двома осями матриці, керівників, здатних сказати «ні», прав на рішення, які хтось не полінувався записати. Якщо цього немає, нова схема переносить відсутнє в нову форму. Якщо є — більшість структур із першої таблиці цієї сторінки працюють краще за свою репутацію.

Коли це застосовувати

Пов’язані сторінки

• МенеджментPMBOKPMBOK Guide — це довідник PMI з управління проєктами; його восьме видання (листопад 2025) задає шість принципів, сім доменів і сорок процесів. Це вже третій різний документ під цією назвою менш ніж за десять років: 6-те видання приписувало 49 процесів, 7-ме замінило їх дванадцятьма принципами, а 8-ме повернуло процеси. Сторінка починається з усіх елементів чинного видання на одному екрані; далі — яке видання хтось має на увазі, шість принципів, як поєднуються домени й процеси, налаштування на одному проєкті, PMBOK поруч із PRINCE2 і Scrum, система виплат Phoenix і де все це вироджується.
• РозробкаМоноліт → мікросервісиМіграція з моноліту на мікросервіси — це перенесення можливостей наявної системи в окремі сервіси по одній, без зупинки системи. Міграція, яка працює, — не переписування з датою переходу, а послідовність невеликих виділень за фасадом, кожне з яких обґрунтоване виміряним обмеженням і має шлях назад; найскладніше тут — дані. Сторінка починається з одного виділення як шістнадцяти кроків; далі — що виділяти першим, шість способів переносити код без зупинки, поділ даних, модель і команди, як вести міграцію й коли зупинитися, п’ять задокументованих кейсів і де все це вироджується.
• МенеджментЧекліст PM на новому проєктіПерші дев’яносто днів проєктного менеджера на проєкті, який почав не він, — це діагноз і далі невелика кількість свідомих змін, а не реорганізація. Перший місяць — з’ясувати, як робота тече насправді; другий — домовитися, що саме ви зміните і з ким; третій — приземлити перші зміни й уміти показати, що вони зрушили. Ця сторінка і є тим чеклістом, разом із ситуативним судженням, яке вирішує, які його частини стосуються саме вас.