Стратегія гнучкості: що дає поєднання Lean та Agile у DefTech

💡 Усі статті, обговорення, новини про оборонні технології — в одному місці. Приєднуйтесь до Defence tech спільноти!

Привіт, спільното! З вами знову Артур Селецький, co-founder/partner спільнот It Network, BUSINESS CRAFT CLUB, бізнес-консультант з аналізу та оптимізації бізнес-процесів, директор зі стратегічного розвитку в компанії KVERTUS. Маю понад 20 років досвіду в бізнес-аналізі, 15 років управління проєктами, більш як 10 років обіймав ключові посади в ІТ-компаніях та понад три роки — у defteсh-компаніях на позиціях СОО, СІО, СЕО, GM.

Написати цю статтю мене надихнув коментар під моїм дописом у LinkedIn — дякую його автору за поштовх до роздумів. Ось коментар і мої відповіді:

Ця стаття — не про методологію як набір інструментів. Якщо вам цікаво глибше зануритися саме в інструменти та процеси Agile чи Lean, то напишіть про це в коментарях, щоб я підготував окремий огляд.

Наразі ж поговоримо про філософію. Про те, як підходи Agile і Lean формують нове мислення в командах, трансформують культуру організацій і допомагають залишатися ефективними в умовах постійних змін.

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

Але в DefTech я також зрозумів, що, попри відмінності між індустріями, деякі принципи є універсальними. Особливо ті, що допомагають організаціям швидко адаптуватися, залишаючись ефективними.

Agile: коли в центрі — люди

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

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

Agile базується на таких цінностях:

1. Люди та взаємодія важливіші, ніж процеси та інструменти.
2. Робочий продукт важливіший, аніж вичерпна документація.
3. Співпраця із замовником важливіша за узгоджені умови контракту.
4. Готовність до змін важливіша, ніж дотримання початкового плану.

Lean: розумні процеси без втрат

Система Lean народилася у виробництві як відповідь на хаос, неефективність і втрати в операційній діяльності. Її мета — не просто структурувати процеси, а зробити їх розумними, прозорими та орієнтованими на цінність.

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

Філософські принципи Lean:

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

Філософія Lean спирається на такі ключові концепції:

1. Цінність: визначення того, що є цінним для клієнта, і концентрація зусиль на створенні цієї цінності.
2. Втрати: ідентифікація та усунення всіх видів утрат (Muda), які не додають цінності кінцевому продукту або послузі.
3. Безперервне вдосконалення (Kaizen): постійний процес пошуку можливостей для покращення всіх аспектів роботи.

Ще під час роботи в ІТ до моїх рук потрапила книга The Machine That Changed the World Джеймса Вомака, після якої я вже не міг дивитися на управління так, як раніше. Я почав шукати втрати в процесах своєї команди, досліджувати, що зупиняє наш розвиток. Я вийшов у гемба* — туди, де виникають справжні процеси, проблеми й інсайти — і почав будувати зміни з реального контексту.

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

Дві філософії — одна синергія

Підходи Agile і Lean можуть не просто співіснувати, а взаємно підсилювати один одного.

• Agile — про взаємодію, гнучкість і швидкість.
• Lean — про ефективність, цінність і усунення втрат.

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

Коли Lean і Agile поєднуються з розумінням і повагою до їхніх принципів, виникає сильна синергія. Один створює основу ефективності та постійного вдосконалення, інший — додає гнучкості та фокусу на людях і взаємодії. У середовищі DefTech, де важлива як швидкість, так і точність, я побачив, як ці дві філософії не лише уживаються, а й взаємно підсилюють одна одну.

Agilean: народження нової культури

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

З поєднання цих підходів народжується нове філософське бачення — Agilean. Це не методологія, а світогляд, заснований на чотирьох ключових цінностях:

1. Вільна комунікація. Відкрите середовище, де кожен може висловитись.
2. Психологічна безпека. Команди не бояться помилок і експериментів.
3. Безперервний розвиток. Навчання і вдосконалення — частина ДНК компанії.
4. Гнучкість. Здатність швидко адаптуватись і діяти в умовах змін.

Вільна комунікація

На другому році своєї кар’єри в DefTech я доєднався до неймовірної R&D-команди в ролі керівника проєктного офісу. Я був у захваті: на кожному квадратному метрі тут народжувались інноваційні рішення, які втілювали з неймовірною швидкістю. У команді часто цитували Айнштайна: «Тільки дурень потребує порядку — геній панує над хаосом».

Тож в атмосфері панував творчий хаос, але цей хаос почав створювати проблеми. У перші дні роботи в команді я проаналізував перелік звернень від клієнтів, величезна кількість яких стосувалася некоректної роботи програмного забезпечення. Звісно, я порушив це питання на першій же нараді з R&D-командою. Відповідь була, мабуть, аж занадто знайомою усім, хто читає цей текст: в інженерів зі встановлення програмного забезпечення руки криві, не можуть зробити згідно з інструкцією.

Я вирішив вийти в гемба (звучить як «вийти в космос») та подивитись, як усе відбувається. Так, в інженерів зі встановлення програмного забезпечення була покрокова інструкція. Мене дуже здивувало, що R&D передавали архів з набором близько 40 файлів. Інженери мусили розархівовувати файли, створювати безліч папок (директорії в операційній системі), зокрема в системних директоріях, та розкидати по них файли. Ну, ніби нічого складного... Але інженерів відволікали, вони щось забували, щось закидали не туди або помилялись у версійності файлів — і в підсумку програмне забезпечення працювало некоректно. Ці операції займали близько 30 хвилин. Множимо на 100 девайсів на місяць — й отримуємо 50 годин витраченого часу на встановлення софту.

Повернувшись із гемба, я поговорив з розробником програмного забезпечення:

Я: Друже, я подивився на процес — там дійсно нічого складного. Але ми отримуємо близько 15 звернень на місяць від клієнтів. Скільки часу в тебе забирає допомога технічній підтримці діагностувати суть проблеми?

Дмитро: У більшості випадків я просто перезаписую файли зверху.

Артур: А можемо зробити інсталяційний пакет?

Дмитро: Можемо, але навіщо я тоді інструкцію малював? І це все час!

Артур: Добре, скільки часу треба на розробку інсталяційного пакету?

Дмитро: 3–4 години.

Артур: Післязавтра в нас реліз нової версії, у Jira в тебе всі задачі виконані, зараз 13:00. Давай ти робиш інсталяційний пакет — і йдеш додому, гаразд?

Дмитро: Домовилися.

Дмитро зробив інсталяційний пакет за півтори години, відтестував його та через 2,5 години пішов додому.

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

У підсумку:

• встановлення програмного забезпечення на 100 девайсів займало 50 хвилин без участі інженерів — ми зберегли 49 годин;
• залученість програміста для вирішення інцидентів некоректної роботи програмного забезпечення звелася до нуля, а заощаджений час він використовував для написання коду, що гарантувало йому кращий настрій, ніж спілкування з «криворукими»;
• зменшилися репутаційні ризики від розчарування клієнтів.

Це — не кінець історії. Через три тижні Дмитро запропонував та зробив образ для розгортання операційної системи з усіма необхідними налаштуваннями, що також зменшило час як встановлення і налаштування софту, так і вирішення пов’язаних із ним інцидентів. І найважливіше: R&D-команда почала вільно спілкуватися як з технічною підтримкою, так і з виробництвом, дослухаючись до їхніх ідей.

Паралельно я навчав команду, що таке Lean, і вже за три місяці голос діда Айнштайна в офісі не звучав. Натомість в R&D-команді з’явилася інша фраза: «Думай як Kaizen. Взаємодій як Agile».

Психологічна безпека

На одному з підприємств, де я був Lean-консультантом і проводив тренінг, ми розглядали метод Poka-Yoke — «захист від помилок». Його головна ідея: не шукай винних, а знайди та усунь слабкі місця в системі, які дають помилці статися.

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

Щоб підійти до проблеми конструктивно, я запропонував провести мозковий штурм. Упродовж 30 хвилин команда згенерувала десятки рішень. До трійки найкращих ідей увійшли:

1. Використовувати дроти різного кольору, щоб візуально розрізняти їх.
2. Впровадити унікальні роз’єми для кожного проводу, щоб фізично неможливо було їх переплутати під час збирання.
3. Додати просту візуальну інструкцію з прикладом правильної пайки безпосередньо на робочому місці.

Проаналізувавши всі можливі ризики, фінансові витрати та технологічну складову, команда вирішила реалізувати другу ідею. На її користь свідчили такі аргументи:

1. Мінімізація людського фактора: конструктивна зміна унеможливлює фізичну помилку — дроти просто не вставляються неправильно.
2. Одноразове впровадження — постійний ефект: розробка та впровадження нових роз’ємів потребує певних зусиль, але в майбутньому повністю усуває потребу в постійному контролі.
3. Підвищення якості без демотивації: замість штрафів отримуємо інженерне рішення. Це покращує моральний клімат у команді та сприяє культурі вдосконалення.
4. Швидке тестування й масштабування: рішення легко протестувати на кількох одиницях продукції, а після підтвердження ефективності — масштабувати на все виробництво.
5. Фінансова доцільність: навіть за умови, що нові роз’єми трохи дорожчі, запровадити їх значно дешевше, ніж компенсувати втрати від згорілих плат (по ~$100 кожна) та витрати на адаптацію нових співробітників у разі звільнень.

Спочатку все виглядало логічно й багатонадійно. Але після практичного тестування гіпотези з’ясувалося, що навіть на новому роз’ємі дроти можуть бути неправильно припаяні, що знову повертає нас до проблеми.

Тож команда ухвалила фінальне рішення:

• Повністю відмовитися від дротів і замінити їх на плату, яка конструктивно унеможливлює некоректне з’єднання.

Через два місяці на одному з івентів у DefTech я зустрів керівника цеху і спитав, як у них справи. Той відповів: «Артуре, це щось неймовірне! Poka-Yoke — наше все! Співробітники за два місяці запропонували дуже багато покращень. І, що найважливіше, керівництво компанії наразі на всі процеси дивиться не через покарання, а крізь призму запобігання повторним помилкам».

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

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

Безперервний розвиток

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

Відділ продажів і техпідтримка отримували зворотний зв’язок від клієнтів, але ця інформація часто не доходила до команд, які могли її реалізувати. Вона губилася, затримувалася або зовсім залишалася без реакції. Команда R&D своєю чергою була перевантажена й не мала змоги глибоко аналізувати запити клієнтів (переважно військових) чи ділитися знаннями між собою.

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

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

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

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

Результат — за три місяці ми запустили шість нових R&D-проєктів, один із яких трансформувався в повноцінний продукт, що мав великий попит.

Коли навчання стає частиною культури, з’являється не просто прогрес, а прорив!

Гнучкість

У статті «Як обрати R&D-методологію для defteсh-компанії в умовах швидкого росту» я описав підхід BlitzsLean. У DeTech-середовищі швидкість та гнучкість — не перевага, а вимога. Саме тому ми в компанії застосовуємо підхід BlitzsLean, побудований на двох ключових принципах:

• Quick Decision — діяти, коли є хоча б 70 % упевненості. Краще швидко протестувати, ніж повільно розмірковувати.
• MVP (Minimum Viable Product) — створення мінімально життєздатного продукту для перевірки гіпотези без зайвих ресурсних витрат.

Одного ранку мені зателефонував друг з фронту.

Друг (голос стомлений, але чіткий): Артуре, у нас тут проблема. Дуже проста, але критично важлива. Якщо зможеш вирішити, буде великий плюс нашим хлопцям.

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

За годину я вже сидів у переговорній з керівником комерційного відділу.

Я: Є ідея. Проста, але реальна. Друзі з передової кажуть, це може врятувати життя. (Викладаю ідею.)

Керівник (після паузи): Це звучить потужно. Давай так — я сьогодні-завтра попитаю клієнтів. Буде інтерес — запускаємось негайно.

Два дні по тому він повернувся до мене з блиском в очах.

Керівник: Артуре, це воно! Усі, з ким говорив, питають: «Коли буде готово?» Люди готові тестувати хоч завтра!

Ми не стали чекати. За принципом BlitzsLean 70 % упевненості вистачає, решту доробимо в процесі. Команда зібралась одразу, техліди обговорили архітектуру, R&D за день зробив ескізи. Через тиждень ми вже тримали в руках перші прототипи. За два тижні — відправили перші дослідні зразки на передову.

І ось за день — дзвінок.

Друг (голос веселий): Артуре, це працює! Реально, хлопці кайфують, кажу — в точку!

Я: Клас! Передавайте вітання команді — наші вкладали душу!

Але вже за кілька годин — знову дзвінок. Голос зовсім інший.

Друг (нервово): Артуре, біда — миші згризли дроти. Прилад перестав працювати.

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

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

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

У кожній історії, яку ми прожили, — не просто кейси. У них пульсує те, що мотивує мене та рухає компанії: довіра, комунікація, розвиток, зміни.

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

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

Думай як Kaizen. Взаємодій як Agile. Рухайся як Agilean.

Стартувало літнє зарплатне опитування DOU. Збираємо відповіді 15 тисяч ІТ-фахівців в анкеті. Долучайтеся!