Плюси та мінуси власного R&D: кейс NovaPay
Олексій Рубан, директор з інновацій NovaPay, підготував для Scroll.media колонку про переваги та виклики у створенні власного R&D. З однієї сторони, це про глибоке розуміння бізнесу, з іншої — значні витрати, особливо на старті. Детальніше — у матеріалі.
Я по праву вважаю R&D-центр серцем будь-якої продуктової компанії. NovaPay – лідерська платіжна система в Україні, і саме власний R&D допоміг нам за 8 місяців власноруч створити та презентувати перший небанківський мобільний застосунок в Україні. Це був прорив для ринку – коли небанківська установа змогла запустити повноцінний додаток для клієнтів з картками та широким функціоналом.
Наш досвід показав, що власний R&D – це не просто модна тенденція, а необхідність для компаній, які хочуть залишатися конкурентоспроможними та інноваційними.
Плюси власного R&D
- Швидкість та гнучкість. Коли команда розробки всередині компанії, ти можеш миттєво реагувати на зміни ринку, потреби клієнтів чи регуляторні вимоги. Немає тривалих узгоджень з зовнішніми підрядниками, немає черг і «це не входить в технічне завдання».
- Глибоке розуміння бізнесу. Внутрішня команда живе продуктом щодня, розуміє специфіку галузі, знає біль-поінти клієнтів не з брифів, а з особистого досвіду. Це дає можливість створювати рішення, які дійсно долають реальні проблеми.
- Контроль якості та безпеки. Особливо критично для фінтеху. Коли розробка всередині, ти контролюєш кожен етап, кожен рядок коду, кожен процес. Це дозволяє підтримувати високі стандарти безпеки та якості.
- Накопичення експертизи. Знання залишаються в компанії, команда росте разом з продуктом, формується унікальна експертиза, яку неможливо просто «купити» на ринку.
Мінуси власного R&D
- Високі витрати на старті. Створення команди розробки – це суттєві інвестиції в людей, інфраструктуру, процеси. Особливо болісно для стартапів з обмеженим бюджетом.
- Складність пошуку талантів. Ринок IT-спеціалістів дуже конкурентний, особливо в Україні. Знайти та утримати топових розробників, архітекторів, продакт-менеджерів – це постійний виклик.
- Ризики залежності від ключових людей. Коли критично важлива експертиза зосереджена в декількох особах, їх відхід може серйозно вплинути на проєкти.
- Необхідність постійного розвитку. Технології швидко змінюються, команду потрібно постійно навчати, оновлювати знання, інвестувати в професійний розвиток.
Як побудувати ефективне управління R&D
Принципи організації команди
Керуючись нашим досвідом, я виділяю кілька ключових принципів:
Люди – частина однієї команди, але з чітко розподіленими і зрозумілими ролями. Кожен знає свою зону відповідальності, але при цьому всі працюють на спільний результат. Немає зайвих вертикалей, структура – типова: краще проєктних офісів ще нічого не вигадали.
Чим менша відстань між замовником і виконавцем – тим краще. Ми мінімізуємо кількість проміжних ланок між бізнес-потребою та її технічною реалізацією. Це прискорює процеси та зменшує ризики неправильного трактування вимог.
Все має працювати як одна структура без зайвого тиску ззовні. Не потрібно керівників, які постійно контролюють кожен крок. Довіра та автономія – основа ефективної роботи.
Організаційна структура і ієрархія має допомагати, а не тиснути. Ієрархія потрібна для чіткості ролей та відповідальності, але не для бюрократії та зайвого контролю.
Методології роботи
Наше розуміння методологій еволюціонувало з часом:
Раніше ми думали, що не потрібні жодні методології. Потім були прибічниками Scrum. Тепер, залежно від проєкту і роду діяльності, ми використовуємо різні методології і можемо навіть поєднувати їх.
Десь це може бути Scrum, десь – Waterfall чи Kanban, десь мікс – Scrumban. Вважаю, що проджект-менеджер – це експерт, він бачить проєкт і сам приймає рішення, яку методологію використовувати. Він озвучує ці правила гри команді, і поїхали!
Ми за свободу вибору. Надмірна корпоративна стандартизація – це шкода. Гнучкість і відповідальність за результат – це завжди плюс.
MVP-підхід
Від Scrum ми запозичили концепцію сегментації задач на MVP. Це дозволяє робити терміни реалізації коротшими, а ефективність – вищою.
Першу ітерацію будь-якого проєкту ми отримуємо вже за місяць і за такий короткий час можемо визначити, чи на вірному шляху. Після цього бізнес аналізує, вирішує, яких нових функцій додати, а R&D команда перемикається на іншу задачу.
За таким принципом ми будували, приміром, функціонал застосунку для ФОПів: спочатку – мінімальні фічі (онбординг і рахунок), потім – всі додаткові (довіреності, кредити, контроль оплати). І тепер це один із найбільш розвинених функціоналів для підприємців в Україні.
Раніше можна було рік працювати для того, щоб закінчити повноцінну версію, а за цей рік вже могли змінитись потреби бізнесу і навіть регуляторні норми.
Визначення пріоритетів
Пріоритетні ключові задачі визначаємо на рівні борду. Наприклад, по застосунку – раз на тиждень, по півтори години, це так звані kick-off meeting із залученням C-level.
Нікому не шкода на це часу, бо це дозволяє бути всім on the same page і дійти до спільного бачення. Це дуже важливо, що в роботу R&D ідуть вже задачі, погоджені бордом.
Висновок
Власний R&D – це інвестиція в майбутнє компанії. Так, це дорого та складно, але для лідерів ринку це необхідність. Головне – правильно організувати процеси, зібрати команду та створити культуру, де інновації стають частиною DNA компанії.
Автор: Олексій Рубан, директор з інновацій NovaPay
Плюси та мінуси власного R&D: кейс NovaPay
Олексій Рубан, директор з інновацій NovaPay, підготував для Scroll.media колонку про переваги та виклики у створенні власного R&D. З однієї сторони, це про глибоке розуміння бізнесу, з іншої — значні витрати, особливо на старті. Детальніше — у матеріалі.
Я по праву вважаю R&D-центр серцем будь-якої продуктової компанії. NovaPay – лідерська платіжна система в Україні, і саме власний R&D допоміг нам за 8 місяців власноруч створити та презентувати перший небанківський мобільний застосунок в Україні. Це був прорив для ринку – коли небанківська установа змогла запустити повноцінний додаток для клієнтів з картками та широким функціоналом.
Наш досвід показав, що власний R&D – це не просто модна тенденція, а необхідність для компаній, які хочуть залишатися конкурентоспроможними та інноваційними.
Плюси власного R&D
- Швидкість та гнучкість. Коли команда розробки всередині компанії, ти можеш миттєво реагувати на зміни ринку, потреби клієнтів чи регуляторні вимоги. Немає тривалих узгоджень з зовнішніми підрядниками, немає черг і «це не входить в технічне завдання».
- Глибоке розуміння бізнесу. Внутрішня команда живе продуктом щодня, розуміє специфіку галузі, знає біль-поінти клієнтів не з брифів, а з особистого досвіду. Це дає можливість створювати рішення, які дійсно долають реальні проблеми.
- Контроль якості та безпеки. Особливо критично для фінтеху. Коли розробка всередині, ти контролюєш кожен етап, кожен рядок коду, кожен процес. Це дозволяє підтримувати високі стандарти безпеки та якості.
- Накопичення експертизи. Знання залишаються в компанії, команда росте разом з продуктом, формується унікальна експертиза, яку неможливо просто «купити» на ринку.
Мінуси власного R&D
- Високі витрати на старті. Створення команди розробки – це суттєві інвестиції в людей, інфраструктуру, процеси. Особливо болісно для стартапів з обмеженим бюджетом.
- Складність пошуку талантів. Ринок IT-спеціалістів дуже конкурентний, особливо в Україні. Знайти та утримати топових розробників, архітекторів, продакт-менеджерів – це постійний виклик.
- Ризики залежності від ключових людей. Коли критично важлива експертиза зосереджена в декількох особах, їх відхід може серйозно вплинути на проєкти.
- Необхідність постійного розвитку. Технології швидко змінюються, команду потрібно постійно навчати, оновлювати знання, інвестувати в професійний розвиток.
Як побудувати ефективне управління R&D
Принципи організації команди
Керуючись нашим досвідом, я виділяю кілька ключових принципів:
Люди – частина однієї команди, але з чітко розподіленими і зрозумілими ролями. Кожен знає свою зону відповідальності, але при цьому всі працюють на спільний результат. Немає зайвих вертикалей, структура – типова: краще проєктних офісів ще нічого не вигадали.
Чим менша відстань між замовником і виконавцем – тим краще. Ми мінімізуємо кількість проміжних ланок між бізнес-потребою та її технічною реалізацією. Це прискорює процеси та зменшує ризики неправильного трактування вимог.
Все має працювати як одна структура без зайвого тиску ззовні. Не потрібно керівників, які постійно контролюють кожен крок. Довіра та автономія – основа ефективної роботи.
Організаційна структура і ієрархія має допомагати, а не тиснути. Ієрархія потрібна для чіткості ролей та відповідальності, але не для бюрократії та зайвого контролю.
Методології роботи
Наше розуміння методологій еволюціонувало з часом:
Раніше ми думали, що не потрібні жодні методології. Потім були прибічниками Scrum. Тепер, залежно від проєкту і роду діяльності, ми використовуємо різні методології і можемо навіть поєднувати їх.
Десь це може бути Scrum, десь – Waterfall чи Kanban, десь мікс – Scrumban. Вважаю, що проджект-менеджер – це експерт, він бачить проєкт і сам приймає рішення, яку методологію використовувати. Він озвучує ці правила гри команді, і поїхали!
Ми за свободу вибору. Надмірна корпоративна стандартизація – це шкода. Гнучкість і відповідальність за результат – це завжди плюс.
MVP-підхід
Від Scrum ми запозичили концепцію сегментації задач на MVP. Це дозволяє робити терміни реалізації коротшими, а ефективність – вищою.
Першу ітерацію будь-якого проєкту ми отримуємо вже за місяць і за такий короткий час можемо визначити, чи на вірному шляху. Після цього бізнес аналізує, вирішує, яких нових функцій додати, а R&D команда перемикається на іншу задачу.
За таким принципом ми будували, приміром, функціонал застосунку для ФОПів: спочатку – мінімальні фічі (онбординг і рахунок), потім – всі додаткові (довіреності, кредити, контроль оплати). І тепер це один із найбільш розвинених функціоналів для підприємців в Україні.
Раніше можна було рік працювати для того, щоб закінчити повноцінну версію, а за цей рік вже могли змінитись потреби бізнесу і навіть регуляторні норми.
Визначення пріоритетів
Пріоритетні ключові задачі визначаємо на рівні борду. Наприклад, по застосунку – раз на тиждень, по півтори години, це так звані kick-off meeting із залученням C-level.
Нікому не шкода на це часу, бо це дозволяє бути всім on the same page і дійти до спільного бачення. Це дуже важливо, що в роботу R&D ідуть вже задачі, погоджені бордом.
Висновок
Власний R&D – це інвестиція в майбутнє компанії. Так, це дорого та складно, але для лідерів ринку це необхідність. Головне – правильно організувати процеси, зібрати команду та створити культуру, де інновації стають частиною DNA компанії.
Автор: Олексій Рубан, директор з інновацій NovaPay
