Як обрати R&D-методологію для defteсh-компанії в умовах швидкого росту

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

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

У цій статті розповім про методології, які я застосовував в R&D-проєктах у галузі def-teсh. Розгляну, як оптимізувати бізнес-процеси та вибирати методологію для R&D-проєктів.

У зв’язку з політикою конфіденційності компанії називати не можу.

Погнали! У перші тижні повномасштабного вторгнення я вирішив звільнитися з посади заступника Міністра із цифрового розвитку МОН та перейти до def-teсh компанії на посаду керівника проєктів. Я хотів застосувати набутий мною в ІТ досвід на користь Сил оборони, тому нижчий рівень посади мене не хвилював.

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

Водночас мене дуже здивувала і надихнула велика кількість геніальних ентузіастів, з якими я познайомився та продовжую знайомитися в def-teсh індустрії. Хоча з ними, як з усякими геніями, складно працювати з точки зору процесних підходів, до яких звикли ІТ-менеджери.

Трохи даних про динаміку цієї галузі: за три роки повномасштабного вторгнення багато def-teсh проєктів виросли у великі інноваційні компанії. Через високу швидкість розвитку управління проєктами зазвичай відставало. Запроваджуючи методологію, необхідно бути гнучким, готовим швидко приймати рішення та вносити корективи у бізнес-процеси.

Підходи та принципи, які я застосовую

Будь-яке впровадження методологій чи оптимізація процесів повинні починатися з аналізу поточних процесів. Головна задача, яку я собі ставлю, незалежно від компанії, в якій працюю, — це не нашкодити бізнесу. Моє особисте правило — не зламай те, що працювало до тебе; потрібно покращувати, а не шкодити. Кожен крок оптимізації бізнес-процесів, чи впровадження будь-яких методологій має бути ретельно проаналізовано та має бути впевненість, що саме ці кроки покращать роботу компанії та принесуть суттєві business value.

Я виділяю два підходи щодо оптимізації бізнес-процесів: еволюційний та революційний.

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

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

Важливо також активно комунікувати з колегами про позитивні аспекти змін та їхній вплив на результативність компанії. Я дуже радію, коли колеги самі пропонують оптимізаційні ідеї. Це є ознакою того, що ми рухаємось у вірному напрямку.

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

За три роки роботи у def-teсh компаніях я щоразу намагався підібрати методологію, яка буде найкраще, наскільки це можливо, підходити конкретній компанії в рамках її бізнес-процесів.

Мій road map підбору методології для R&D-проєктів:

1. Аналіз поточних бізнес-процесів «As is».
2. Пошук bottleneck та різноманітних витрат чи проблем.
3. Визначення цілей впровадження методології та що хочемо отримати в результаті.
4. Оцінка ризиків та ключових метрик після впровадження — business value.
5. Вибір методології.
6. Складання road map впровадження методології.

Аналіз поточних бізнес процесів «Аs is»

Як бізнес-аналітик з великим досвідом дуже люблю на практиці застосовувати різноманітні нотації для моделювання бізнес-процесів: UML, IDEF0, EPC, але найбільше — BPMN, бо вважаю її оптимальною.

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

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

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

Ролі в RACI:

• Responsible (R): ті, хто безпосередньо виконує завдання або створює кінцевий результат. Ними можуть бути розробники, дизайнери, інженери та інші виконавці.
• Accountable (A): особа, яка несе кінцеву відповідальність за завдання. Вона забезпечує, щоб робота була виконана вчасно і якісно. Зазвичай це керівник проєкту або менеджер (лише один на завдання).
• Consulted (C): експерти або спеціалісти, які надають поради та зворотний зв’язок. Це можуть бути аналітики, консультанти, клієнти або інші зацікавлені сторони.
• Informed (I): люди, яких необхідно тримати в курсі подій, але які не беруть активної участі в роботі над завданням. Це можуть бути члени інших команд, керівництво або клієнти.

Як створити матрицю RACI?

1. Визначити завдання: складіть список усіх завдань.
2. Скласти список команди: визначте всіх учасників вашого бізнес-процесу.
3. Розподілити ролі: призначте ролі RACI для кожного завдання.
4. Валідація: погодьте матрицю з усіма учасниками.

Шаблон-приклад:

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

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

Розглянемо «плюси» та «мінуси» застосування матриці RACI:

Плюси:

• Чіткий розподіл ролей.
• Прозорість бізнес-процесу компанії.
• Збільшення продуктивності.

Мінуси:

• Складність у великих організаціях.
• Ризик уникнення відповідальності.
• Недоцільність у простих проєктах.

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

Пошук bottleneck та різноманітних витрат чи проблем

Bottleneck (вузьке місце) — це точка в процесі, яка сповільнює або обмежує загальну продуктивність. У def-teсh компаніях вони можуть виникати через складність проєктів, регуляторні вимоги, залежність від постачальників, небажання брати на себе відповідальність, проблеми в комунікаціях між колегами тощо.

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

Декілька пунктів, які я використовую для визначення bottleneck:

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

Аналіз bottleneck допоможе сформувати ключове бачення, де насамперед необхідно вносити корективи у бізнес-процесі, спланувати оптимізаційні активності та підібрати найкращу методологію — to be.

Визначення цілей впровадження методології та очікуваних результатів

На початку 2023 року я був залучений до стратегічної сесії def-teсh компанії. В рамках сесії було виділено одним із ключових напрямів розвиток інноваційних рішень та розбудова R&D-напряму. Відбулась дуже інтенсивна та довга дискусія між топменеджерами. Вона звелася до того, що основні проблеми в компанії пов’язані з R&D-напрямом.

Фінансовий директор наполягав на плануванні та дотриманні бюджетів напряму. Директор з продажу казав, що в компанії велика бюрократія та за підготовкою купи документів вона почала відставати від конкурентів, втрачати позиції на ринку. Директор виробництва наполягав на бюрократії, бо «ті інженери в R&D щось навидумують, документації достатньої не має, а як будувати серійне виробництво — незрозуміло». Операційний директор всім доводив, що основна проблема в тому, що компанія працює за незрозумілою методологією, тому слід впровадити Agile або Lean, а R&D — це взагалі «чорний ящик».

Через годину заграло правило: хто гучніше кричить, той правий. Технічному директору було дуже непросто відбиватися від нападів колег. Найгучнішим був операційний директор, тож усі прийшли до необхідності впровадити Lean.

Після чого я долучився до дискусії.

Артур: Яку саме проблему ми хочемо вирішити?

Операційний директор: Ну як — впровадити методологію, за якою буде працювати вся компанія, не мені ж вам розповідати, для чого методологія в компанії, і що найкраща для виробничої компанії — це Lean!

Артур: Звісно, а що таке взагалі методологія? І яку саме проблему ви хочете вирішити методологією Lean? Які можливі наслідки впровадження методології можуть бути? Давайте розберемо основні ваші нарікання:

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

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

Всі погодились та перейшли до розгляду наступних напрямів та проєктів.

Ця історія показує великі проблеми та можливі наслідки. Перш за все, коли ви хочете обрати методологію, поставте два питання:

• Що ми хочемо досягти з впровадженням методології?
• Що отримає компанія (business value) в результаті?

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

Що ж робити?

1. Опишіть поточні проблеми.
2. Виконайте аналіз поточної ситуації.
3. Виконайте аналіз можливих шляхів оптимізації.
4. Проаналізуйте та опишіть вплив (негативний та позитивний) впровадження методології на компанію.
5. Проаналізуйте методології та їхні інструменти.
6. Перейдіть до підбору оптимальної методології чи набору інструментів саме для вашої компанії.

Вибір методології

Багато стартапів швидко виростають в інноваційні компанії. Є випадки, коли проєкт за рік виростає від команди з 10 працівників до компанії з понад 500 працівників. Компанії вимушені утримувати позиції на ринку та зростати з неймовірною швидкістю. Звісно, процеси не будуть встигати за ростом і постійно змінюватись, в поточній ситуації потрібно прийняти це.

Отже, давайте повернемось до ситуації на ринку def-teсh компаній. Поточна ситуація наразі наступна:

1. Ринок дуже стрімко розвивається.
2. На ринок виходить все більше та більше нових гравців.
3. Ринок щодня отримує нові та досконаліші продукти.
4. Дуже обмежені терміни виготовлення.
5. Велика гонитва за інноваціями.
6. Постійна зміна нормативно-правових актів.

Наведу приклад однієї компанії на початку моєї кар’єри в def-teсh. Підхід і набір інструментів, які в ній запровадив, почали використовувати з невеликими модифікаціями 9 із 12 компаній, з якими я співпрацював.

Однією зі стратегічних задач у цій компанії була оптимізація бізнес-процесів. Головний біль — саме R&D-напрям. До мого приходу колеги описали, яким має бути процес цього напряму. Робота досить непогано давала розуміння, яких оптимізацій прагне компанія. Це мене дуже надихнуло. Ми почали розробляти навіть шаблони для стандартизації в рамках компанії.

Процес стартував з опису гіпотези, технічних вимог у вигляді ТТХ (тактико-технічні характеристики) формування команди, створення проєктного плану, формування бюджету проєкту, підписання наказу по компанії. Все ніби гарно, логічно та реалістично.

Але вже на п’ятий день роботи в компанії я побачив, як насправді відбувається старт R&D-проєкту.

9:30 ранку, до кабінету залітає СЕО:

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

Ми почали слухати ідею. Технічний директор підтвердив, що ідею можливо реалізувати у визначений термін, але термін іншого проєкту потрібно перенести. СЕО погодив.

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

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

Артур: Гайз, що наразі сталося?

Операційний директор: В якому сенсі?

Артур: Я помиляюсь чи щойно відбувся запуск R&D-проєкту?

Операційний директор: Так, а що?

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

Операційний директор: Так. Треба все це зробити, зараз саме це і будемо робити.

Артур: Скільки на це піде часу? І ми ж уже порушуємо те, про що домовлялись! А це дійсно потрібно нашій компанії?

Операційний директор: Та зараз за годину все зробимо!

Технічний директор: Ага, за годину! Попередній проєкт за таким процесом йшов два тижні!

Операційний директор: Ні! Нам необхідно працювати в рамках якихось процесів, тому надалі будемо вдосконалюватися!

Артур: Стоп! Я маю ідею, але мені потрібен день для аналізу всього, що я побачив.

Вночі я не спав, думаючи, як бути в цьому випадку. У стандартизованих процесах працювати краще, але чи правильно витрачати час, коли його немає? У книзі «Дедлайн» Том Демарко пише: «День, який ми втрачаємо на початку проєкту, значить так само багато, як і день, втрачений наприкінці».

Я міркував, підбирав кейси зі свого досвіду та згадав про те, що часто всім кажу:

Більшість великих інноваційних компаній вийшли зі стартапів!

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

Після чого я згадав дві методології, які застосовував у стартап-проєктах: Lean Startup та Blitzscaling.

Lean Startup — це методологія розробки та запуску продуктів, що базується на швидкому тестуванні гіпотез, отриманні зворотного зв’язку від користувачів і постійному вдосконаленні продукту.

Основні принципи Lean Startup:

1. Build-Measure-Learn (створюй — вимірюй — навчайся) — циклічний процес, що мінімізує витрати часу та ресурсів:

• Build — швидке створення мінімального життєздатного продукту (MVP);
• Measure — тестування у реальних умовах, збір даних про ефективність;
• Learn — аналіз результатів, вдосконалення продукту.

1. Мінімально життєздатний продукт (MVP — Minimum Viable Product) — продукт із мінімально необхідним функціоналом для перевірки ключових гіпотез. Мета MVP: швидко отримати фідбек без значних витрат на розробку.
2. Pivot або Persevere (змінити напрям або рухатися далі?) — Lean Startup передбачає, що початкові припущення можуть бути помилковими. Важливо вчасно визначити, чи потрібно змінювати стратегію (Pivot) або вдосконалювати поточний продукт (Persevere).
3. Continuous Deployment (безперервне розгортання та тестування) — постійне оновлення продукту невеликими ітераціями та швидке виправлення помилок на основі реальних даних.

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

Основні принципи Blitzscaling:

1. Speed ​​priority (пріоритет швидкості над ефективністю) — спрощуємо рішення, щоб запустити MVP максимально швидко.
2. Risk tolerance (толерантність до ризиків) — мінімум бюрократії, максимум швидких тестів.
3. Focus key factors (фокус на ключових факторах росту) — концентруємось на тих речах, які дають найбільший вплив.
4. Quick decision (швидке прийняття рішень) — принцип «Маємо 70% впевненості — діємо!».
5. Scaling the start (масштабування з самого старту) — робимо MVP одразу з можливістю подальшого розширення.

Наступного ранку я представив колегам свої ідеї та наголосив, що методологія — це лише набір інструментів, рекомендованих для використання, тому ми самі можемо і повинні обирати свій шлях.

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

1. Quick decision (швидке прийняття рішень) — принцип «Маємо 70% впевненості — діємо!».
2. Risk tolerance (толерантність до ризиків) — мінімум бюрократії, максимум швидких тестів.
3. Build-Measure-Learn (створюй — вимірюй — навчайся) — циклічний процес, що мінімізує витрати часу та ресурсів.
4. Мінімально життєздатний продукт (MVP — Minimum Viable Product) — продукт із мінімально необхідним функціоналом для перевірки ключових гіпотез. Мета MVP: швидко отримати фідбек без значних витрат на розробку.
5. Scaling the start (масштабування з самого старту) — робимо MVP одразу з можливістю подальшого розширення.

Також ми запропонували перелік документів та інструментів:

1. Гіпотеза рішення — короткий опис проблеми, яку вирішуємо, особливості застосування, короткий опис гіпотези, мінімальні ТТХ та/або концептуальна модель застосування, очікувані результати (що в результаті маємо отримати — кількість тестових зразків, проведення спільних випробувань, ціновий сегмент тощо).
2. Дорожня карта (MVP Roadmap) — заведений проєкт R&D в Jira, розбитий на задачі.
3. Перелік закупівельних матеріалів та обладнання — що необхідно закупити для реалізації проєкту.
4. Бюджет проєкту — орієнтовний бюджет на реалізацію проєкту, який базується на переліку закупівельних матеріалів та обладнання, розрахунку вартості тестувань.
5. Методики випробувань — згідно зі стандартизацією за ДСТУ.
6. Протоколи випробувань — згідно зі стандартизацією за ДСТУ.
7. Фінансовий звіт — за результатами роботи проєкту.

Розробка road map впровадження методології — це тема для наступної статті, тому що маю для неї багато кейсів та історій. Стежте на DOU за розділом Defence tech, де є багато цікавої інформації, яка постійно поповнюється.

Висновки

• Кожна команда — унікальний організм, який потребує індивідуального підходу, тому адаптуйте описані методології до своєї ситуації.
• Виконуйте аналіз поточного процесу в рамках контексту ринку. Аналізуйте переваги та недоліки впровадження будь-якої методології в компанії.
• Методологія — лише інструмент. Головне — бачення, команда і готовність до змін!
• Вибір методології — це вибір шляху. Оберіть той, що приведе до результату.