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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чому написання ідеального коду може призвести до вашого звільнення

Блогер та розробник Джозеф Круз розповів, чому не варто писати ідеальний код та чому це…

18.04.2025

ChatGPT, моторошна долина та трохи Фройда

Днями я завзято нила про щось ChatGPT (експериментую між сеансами з живим терапевтом). І от…

17.04.2025

Я прийшла за покупками, а не крутити колесо

«Крутіть колесо, щоб отримати знижку до 50%!» «Натисніть тут, щоб відкрити таємничу пропозицію!» «Зареєструйтесь зараз,…

16.04.2025

Майже навайбкодив десктопний монітор CI пайплайнів

Дуже хочеться робити якісь десктопні апки. Сумую за часами коли всі програми були offline-first, і…

15.04.2025

Як працюють транзакційні комісії в мережах Bitcoin і Ethereum

Надсилаючи криптовалюту, багато новачків ставлять запитання: як працюють комісії та чому вони відрізняються в різних…

14.04.2025

Обережно, тепер вас можуть обдурити на співбесіді з роботодавцем

Нова афера набирає обертів — ось детальний розбір того, як фальшиві потенційні роботодавці намагаються вкрасти…

11.04.2025