Офіс простих рішень. Що спільного в штурмової бригади та IT-компанії?

Володимир Рожков

Прокляття програміста — всюди бачити неефективність та мати ідеї і «прості» рішення щодо виправлення цих прикрих помилок реальності.

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

Dan Luu чудово описав це в статті «Cocktail party ideas» — коли купка програмістів збирається, та починає придумувати як вирішити неефективність світу, хоча насправді вони не усвідомлюють масштаб та складність проблем.

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

Коли я працював у великому ентерпрайзі, то в нас був ІТ-відділ, який займався тим що видавав на проєкти сервери та інші ресурси. І от мені потрібні були ті самі сервери, але щоб отримати їх, треба було створювати заявки, які апрувились великим начальством.

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

Будь-хто, хто працював у великих організаціях стикався з проявами цього і спостерігав таку дисфункцію та виродження.

Тому умовний генерал не може просто так змінити всі процеси та підвищити ефективність. Це неможливо за збереження комплексу системи.

Один зі способів змін — створити маленьку структуру за своїми правилами, та будувати інтеграції, що абстрагуватимуть її учасників від великої материнської структури. Стартап, досвід якого потім можна буде масштабувати.

Здається що саме це зараз відбувається з 3 ОШБр. Невеликий підрозділ, який довів свою ефективність, отримав ресурси для масштабування та екстраполює свій досвід на інших.

Інновації та покращення рідко приходять зверху. Можна керувати всім в ручному режимі, але це буде зустрічати опір та італійські страйки з низів, зводячи все нанівець.

Тому в мене небагато очікувань від верхівки. Чи буде вона така, чи інша — без звитяжних людей, які здатні ефективно діяти, та мають волю до змін з низів, нічого не буде.

Якщо ви знайшли помилку, будь ласка, виділіть фрагмент тексту та натисніть Ctrl+Enter.

Останні статті

AI Engineer у сучасному технологічному стеку: трансформація процесів розробки програмного забезпечення

Штучний інтелект (ШІ) вже не просто модне слово, а рушійна сила, що змінює саму суть…

21.08.2025

Алгоритми консенсусу майбутнього: DAG, BFT, DPoS

Алгоритм консенсусу – це серце будь-якого блокчейна. Саме він визначає, хто і як записує нові…

12.08.2025

CSR у Next.js. Як працює і що у нього під капотом

Зайшов на сторінку, а там — спінери, skeleton і порожнеча? Це не баг, це —…

31.07.2025

Чому я пишу про факапи?

Таке запитання мені поставив мій знайомий, коли побачив мій профіль. Я настільки над цим задумалась,…

30.07.2025

Як налаштувати штучний інтелект з унікальною базою знань? (безкоштовно)

Нещодавно я вписався в один цікавий проєкт. Довелося розібратись з процесом звітності американських фармацевтичних компаній…

29.07.2025

Одного разу я сильно посварився з СЕО компанії або Коли треба вчасно зупинитися і вміти сказати «ні»

Одного разу я сильно посварився з СЕО компанії. Він кричав на мене, а я у…

28.07.2025