Чому системи, а не процеси

Коли щось йде не так у компанії, перший інстинкт — полагодити процес.

Додати крок. Прибрати крок. Створити шаблон. Запланувати зустріч. Написати політику. Логіка проста: якщо результат неправильний — підкрути процедуру, яка його виробляє.

Іноді це працює. Якщо проблема дійсно процедурна — пропущене погодження, нечітка передача інформації, забуте повідомлення — тоді процесний фікс це правильний інструмент.

Але більшість проблем, які я описав на попередній сторінці, не процедурні. Вони структурні. І це принципова різниця.

Процес описує послідовність: зроби це, потім це, потім це. Він виходить з того, що компоненти фіксовані, а шлях між ними потребує оптимізації.

Система описує набагато більше, ніж відносини. Вона бачить, які елементи є і чим вони якісно різні. Як вони з’єднані — їхню архітектуру. Через що вони взаємодіють — не просто обмін, а взаємне перетворення, де кожен елемент витрачає частину свого ресурсу і щось отримує від інших. І де проходять межі системи. З усього цього разом виникають властивості, яких жоден елемент окремо не має.

Лагодите процес — оптимізуєте шлях. Розумієте систему — бачите весь ландшафт.

Зниклий людський фактор

Є глибша проблема з процесним мисленням, і її рідко називають прямо.

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

Аналітик, архітектор, розробник, QA — в процесній діаграмі вони взаємозамінні. Замініть одного іншим — процес не зміниться. В цьому і суть: процеси спроектовані так, щоб не залежати від конкретної людини.

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

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

Якщо ви пишете код, то, може, помічали — іноді ніби все працює, абстракції гнучкі, але щось не дає спокою. Важко навіть сказати чому. Просто є відчуття, що так як є — недобре. Треба покопатись. І відчуття не обманює. Ось ця чуйка, ця гострота уваги — процес її не враховує і не виміряє. Але саме вона відрізняє команду, що створює, від команди, що виконує.

Процес, який ігнорує людський фактор, може бути ефективним. Але він не може бути винахідливим. Не може адаптуватись. Не може виробити нічого по-справжньому нового.

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

Виробничим лініям гомоцентризм не потрібен. Творча, крос-функціональна робота без нього не виживе.

Проблема багатоякісності

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

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

Коли ми ставимось до людей і відділів як до одноякісних сутностей — «вона бекенд-розробниця», «це фінансовий відділ» — ми втрачаємо більшу частину багатства, яке визначає, наскільки добре працює система. Ми будуємо команди, зіставляючи назви посад з вимогами, а не компонуючи доповнювальні спектри якостей у завершене ціле.

Для прикладу. Три геніальних бекенд-розробники з ідентичним досвідом і однаковим стилем мислення. Це не суперкоманда. Це крихка система. Їхні спектри повністю перекриваються. Коли загроза приходить з неочікуваного боку — UX-проблема, питання безпеки, комунікаційний збій з іншою командою — ніхто її не бачить. Через високу симетрію вони мислять однаково, дублюють функції один одного, і пропускають те, що міг би помітити хтось інший.

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

Цілісність — ось ключове слово. Не в моральному сенсі — у структурному. Система, що має всі якості, потрібні для функціонування, без критичних прогалин.

Побудувати цілісність — центральний виклик організаційного дизайну. І це неможливо зробити процесами. Тільки через розуміння системи — і людей всередині неї.

Берталанфі мав рацію

В 1968 році австрійський біолог Людвіг фон Берталанфі опублікував Загальну теорію систем. Його ключовий інсайт: будь-яка складна система — живий організм, компанія, програмний продукт — підпорядковується спільним принципам організації. Система — це не просто сума компонентів. Це спосіб їхньої взаємодії.

Ідея вплинула на десятки дисциплін. Але в більшості компаній залишилась академічною. Менеджери продовжували оптимізувати процеси, поки система — реальна структура відносин і взаємодій — еволюціонувала сама по собі, непоміченою і некерованою.

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

Її розробив у Львові в 1989 році радіофізик Олександр Малюта. І вона дає те, чого загальна теорія систем так і не досягла: формальний, придатний до реалізації фреймворк для розуміння багатоякісних систем — включно з командами людей.

Про це — далі.