Roadmap впровадження R&D. Як зробити R&D рушієм сталого зростання, а не експериментом на удачу

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

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

Цю статтю хочу розпочати цитатою з книги «OKR. Міряй важливе» Джона Дора: «Ліпшого результату досягають, коли всі прагнуть рівня, що є поза межами звичайних можливостей».

Як зробити дослідження частиною сталого зростання, а не експериментом навмання? Це питання я щоранку п’ю разом із кавою. Кожна компанія — це ситуація, у якій стандартна методика живе своїм життям, але ж завжди хочеться знайти спільні патерни!

Створення roadmap впровадження методології R&D — це не просто розробка плану робіт, не просто запуск лабораторії чи відділу інновації. Це не про створення документації чи дослідного зразка.

Roadmap впровадження методології R&D — це стратегічний документ, який пов’язує:

• дослідницькі ініціативи;
• ресурси;
• часові горизонти;
• очікувані результати.

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

Ця стаття — практичний гайд для тих, хто хоче не просто «робити R&D», а вибудувати дорожню карту впровадження R&D як стратегії розвитку.

У попередній статті «Як обрати R&D-методологію для defteсh-компанії в умовах швидкого росту» я обіцяв поділитися своїм досвідом побудови roadmap впровадження методології в defteсh-компанії.

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

Моє впорядкування хаосу в компаніях складається з таких кроків:

1. Розробка roadmap для впровадження методології R&D.
2. Впровадження проєктного мислення.
3. Вибір робочої області та інструментів.
4. Опис процесу та розробка шаблонів.
5. Контроль впровадження методології R&D.

Розробка roadmap для впровадження методології R&D

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

Все відбувалося хаотично і на питання СЕО: «Коли ж буде реалізовано новий девайс?» лідер R&D відповідав стандартно: «Скоро».

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

Через тиждень мого аналізу бізнес-процесів компанії в мене відбулася розмова із СЕО:

Я: Я провів попередній аналіз. Ваші слова повністю підтвердилися: повних хаос.

СЕО: Що ж робити? За пів року ми не вивели жодного нового продукту на ринок, хоча за попередніх пів року вивели 2 продукти...

Я: Ок, за півтора року у вас вийшло 4 продукти на ринок, а скільки наразі в роботі?

СЕО: 3 нових продукти.

Я: Згідно з моїм попереднім дослідженням, я нарахував 12 нових продуктів.

СЕО: Звідки вони взялися?

Я: Я спілкувався з лідером R&D — у своєму блокноті він нарахував 7 нових продуктів, ще 3 він записав на клаптиках паперу та ще згадав 2, про які ви йому говорили.

СЕО: Хм... Та мене цікавлять саме ось ці 4 продукти (показує свій клаптик паперу).

Я: Більше того, наразі ваші 4 продукти стають франкенштейнами, вони кастомізуються — додаються нові функціональні можливості. Не дотестувавши одні покращення, до них додають нові. Вам нічого це не нагадує?

СЕО: Схоже на снігову кулю.

Я: ...яка найближчим часом може накрити всю компанію.

СЕО: Які пропозиції?

Я: Повернути вектор розвитку компанії в проєктне управління. Ось roadmap впровадження методології R&D, проєктного мислення та проєктного офісу на рівні R&D-команди.

Надалі ми почали спілкуватися про впровадження проєктного мислення та проєктного офісу на рівні R&D-команди. Зміст нашого обговорення — далі в цій статті.

Розробка roadmap — це ніщо інше, як планування проєкту, в якого, як і в будь-якого іншого, має бути ціль, команда, бюджет. Я бачив безліч ситуацій, коли впровадження нових процесів закінчувалось величезним провалом, який страшенно демотивував співробітників. Чому таке відбувається?

Важлива складова — це відповідні повноваження прийняття рішень за цим проєктом у керівника проєкту. Керівник проєктом по суті має бути або неформальним або формальним лідером. Без лідерства досить важко, та я б сказав майже неможливо впроваджувати зміни. Або у керівника проєктом має бути підтримка лідерів компанії.

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

Приклад KPI для оцінки успіху впровадження PMO в R&D:

• % проєктів, що закрилися вчасно (мета — 80%).
• Зменшення затримок по R&D-фазах.
• Прогнозованість витрат (+/- 10% до бюджету).
• Задоволеність стейкхолдерів (за результатами опитувань).

Які завдання можуть бути в roadmap (залежно від компанії та її конкретної ситуації, вони можуть бути змінені та доповнені):

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

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

Щоб відстежувати прогрес виконання проєкту, я дуже люблю використовувати інструмент MS Project. Ось який вигляд це може мати:

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

Далі розглянемо, як перетворити план на дієвий інструмент.

Впровадження проєктного мислення

Згадую час, коли мене було призначено заступником міністра освіти та науки України з питань цифрового розвитку. Якраз у цей час спалахнув COVID-19, тому моєю головною задачею стала організація дистанційного навчання в школах України. Це був цікавий кейс та водночас дуже складний виклик: часу обмаль — 1,5 місяці до початку навчального року, немає ні ресурсів, ні команди.

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

Першим кроком я склав перелік усіх державних підприємств, що підпорядковувалися міністерству й були дотичні до ІТ-ініціатив. Далі призначив короткі ознайомчі зустрічі (по 30 хвилин). Попередньо попросив представників підприємств підготувати інформацію щодо задач, які стосуються саме ІТ-продуктів. Протягом тижня я проводив зустрічі й поступово структурував отриману інформацію. У підсумку склав список із 12 державних підприємств та 56 пунктів ІТ-ініціатив. Так сформувався перелік майбутніх проєктів — і це стало першим кроком до створення портфеля проєктів міністерства. Більш докладно про цифровізацію освіти ми розповіли в подкасті «Як досягти змін у державному секторі».

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

Отож яку інформацію містила таблиця на цьому етапі:

1. Назва проєкту.
2. Назва державного підприємства.
3. Стан проєкту (ініціація, в роботі, на паузі, супровід).
4. ПІБ та контактна інформація відповідальної особи.
5. Планована дата завершення.
6. Короткий опис системи.

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

Другий крок — впровадження проєктного мислення серед державних підприємств.

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

Навіщо впроваджувати проєктне мислення

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

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

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

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

Що включає проєктне мислення?

• Цільове мислення — чітке формулювання кінцевої мети.
• Мислення в межах обмежень — врахування часу, бюджету та ресурсів.
• Фазовість — поділ процесу на етапи з конкретними результатами на кожному.
• Контроль і зворотний зв’язок — постійне відстеження прогресу.
• Рольове мислення — чіткий розподіл відповідальності між усіма учасниками.

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

Наступним етапом був вибір і впровадження інструменту для управління проєктами. Відповідаючи на запитання, яке, ймовірно, виникло у вас прямо зараз: так, у міністерстві було впроваджено Jira. Окрема подяка компанії Softgile, яка надала безкоштовні ліцензії для міністерства та власним коштом здійснила кастомізацію системи. Нижче — скріншот адаптованої Jira:

Вибір робочої області та інструментів

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

Якось одного чудового ранку ми з головним конструктором Олексієм вийшли на каву. На той момент я працював менеджером ІТ-продукту в deftech-компанії. Зав’язалася розмова:

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

Я: Друже, Excel — справді універсальний інструмент. Але давай виходити з задач і зручності використання. Молотком можна й саморіз забити, але викруткою чи шуруповертом це зробити значно простіше й ефективніше. Так само і тут: інструмент має відповідати задачі. Кажуть, що літаки без синьої ізоляційної стрічки не літають — може, й так (усміхнувся я), але ж ми прагнемо будувати системно, а не «на стрічці». 😉

Олексій: Працював у Jira — нічого не зрозуміло, усе складно.

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

Після цієї розмови ми почали впроваджувати Jira для всієї компанії.

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

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

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

Приклад постановки задачі на налаштування Asana:

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

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

Я дотримуюсь простого правила: мінімум часу на впровадження та навчання, мінімум витрат — максимум користі в роботі.

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

Розробка шаблонів та опис процесу

В одній з ІТ-компаній, де я працював операційним директором, СЕО поставив переді мною такі завдання:

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

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

Далі наведу кілька прикладів опису процесів на основі реального кейсу, адаптованих і знеособлених.

Ось кілька моїх правил щодо оформлення таких документів:

Правило 1. Документ не має бути надто об’ємним. У моїй практиці подібні документи зазвичай займали від 5 до 12 сторінок, з яких дві — титульна сторінка та зміст.

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

Правило 3. Опис процесу повинен будуватись на погодженій методиці, наприклад матриці RACI, про яку я розповів у попередній статті.

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

Правило 5. Необхідно описати правила роботи з інструментом, який ви обрали для управління проєктом.

Правило 6. Описати правила документообігу за проєктом.

Правило 7. Детально та компактно описати кожен етап проєкту. Не пишіть реферати на тему управління проєктами, а надайте мінімально необхідну інформацію для роботи:

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

Контроль впровадження методології R&D

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

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

Для ефективного контролю важливо запустити кілька ключових механізмів:

1. Регулярні статус-зустрічі (стендапи) по впровадженню.
   • На рівні R&D-команди — щотижня.
   • На рівні керівництва та стейкхолдерів — кожні 2-4 тижні. Це допомагає вчасно виявляти затримки та блокери і коригувати план.
2. Метрики впровадження. Що вимірюємо — те й контролюємо. Окрім KPI для R&D-проєктів, які я вже згадував, рекомендую також відстежувати:
   • % завершених етапів по Roadmap у планові терміни;
   • % команд, які перейшли на нові шаблони та процеси;
   • зменшення кількості «хаотичних» ініціатив без плану.
3. Інструментальний контроль. Всі проєкти та задачі мають бути не на листочках і в головах людей, а в інструменті (MS Project, Jira, Notion, Asana чи будь-який обраний вами трекер). Це — єдине джерело правди, де в режимі реального часу видно прогрес.
4. Пілот і корекція методології. Перше впровадження методології варто запускати як пілот на обмеженій кількості проєктів. І тільки після збору зворотного зв’язку — масштабувати на всю R&D-функцію. Зазвичай я закладаю 1-2 ітерації корекції перед фіналізацією методології.
5. Роль PMO як контролюючого центру. Створений на рівні R&D, РМО стає центром контролю: збирає звітність, фасилітує зустрічі, допомагає командам долати складнощі переходу на нові процеси.
6. Фокус на людях, а не лише на процесі. Контроль — це не лише про цифри. Дуже важливо моніторити стан команди: чи є перевантаження, чи зрозумілі нові правила гри, чи зберігається мотивація. Без цього ніяка методологія не запрацює.

Приклад контрольних точок впровадження R&D-методології:

• Проведено запуск проєктного офісу в R&D (дата).
• 100% R&D-проєктів заведені в систему трекінгу.
• Завершено навчання команд новим процесам.
• Проведено перше рев’ю методології та внесено зміни.

Мій головний меседж у цьому розділі: контроль — це не про «пресинг», а про ритмічність, прозорість і регулярні маленькі перемоги. Саме це перетворює методологію з теорії на реальний драйвер зростання компанії.

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

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

Успіху вам на ланах побудови R&D як рушія сталого зростання (без експериментів)!

До нових зустрічей на сторінках DOU!