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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чи маєте відчуття цінності в компанії, де працюєте?

Поговорімо на важливу тему — відчуття власної цінності в компанії. Чи завжди ви відчуваєте, що…

22.07.2025

Як я провела експеримент та отримала карʼєрну консультацію від ChatGPT

Одразу проговорю, що версія ChatGPT безкоштовна. Отже, попросила свого Альта уявити, що він — карʼєрний…

21.07.2025

Сервер MCP: навіщо він потрібен і для чого він підходить

Давайте відкинемо протокольний жаргон і скажемо прямо: якщо ви коли-небудь намагалися підключити свій ШІ до…

18.07.2025

AI-співбесіда або як я спілкувалась із Ші замість рекрутера

Нещодавно пройшла AI-співбесіду. Ух, оце був досвід! По-перше, мені здається, що вакансії взагалі не існувало…

17.07.2025

Як зробити біг регулярною звичкою, а не тимчасовим поривом?

Ще жодного разу я не прокидався з бажанням вийти на пробіжку. Завжди знаходяться переконливі причини…

16.07.2025

10 помилок, які роблять розробники при написанні API (і як їх виправити)

Блогер та розробник Марк Анрі розповів про головне помилки, які допускають розробники при створенні API.…

15.07.2025