Дата публікації:
Публікація:
У продуктовій розробці для CRM прийнято міряти зрілість рішення обсягом функціоналу: скільки модулів, скільки налаштувань, наскільки довгий список можливостей. Ми міряємо інакше — часом між моментом, коли користувач сказав, що йому незручно, і моментом, коли це виправлено в бойовій системі. Це інша оптика, і вона змінює те, як влаштована розробка.
За останні 12 місяців ми випустили 70 релізів по 30 продуктах. Частина з них — великі функціональні блоки, більшість — точкові зміни, які помічає тільки той, хто працює в системі щодня. І саме друга категорія найкраще пояснює, навіщо взагалі тримати високий темп.
Класична модель виглядає так: команда збирає беклог, пріоритезує, планує великий реліз і виходить із ним раз на рік. Логіка зрозуміла — менше релізних циклів, менше регресії, простіше комунікувати зміни ринку.
Проблема в тому, що між моментом фіксації вимоги і моментом її релізу проходить від дев’яти до вісімнадцяти місяців. За цей час частина вимог втрачає актуальність: змінюється процес у клієнта, змінюється платформа, змінюється сам ринок. Клієнт живе рік із незручністю, про яку розробник уже знає і яку вже вміє полагодити.
Є і суто інженерна ціна. Великий реліз концентрує ризик: чим більший обсяг змін в одному пакеті, тим ширша поверхня регресії, тим довший UAT і тим болючіший відкат, якщо щось пішло не так. Малі релізи розносять цей ризик у часі — і роблять кожен окремий крок оборотним.
Тримати темп на одному продукті — задача організаційна. Тримати його одночасно на кількох — задача архітектурна.
У нас у розробці паралельно кілька продуктових ліній: мультиканальна екосистема (Multichannel Chats, Multichannel Notifications, Multichannel Bulk Messaging, Multichannel Chatbots, Widget Chat Channel), Data Management, FMCG Management, Project Management, Questionnaire Management. Кожна лінія має власний цикл релізів і власну аудиторію — від маркетингових команд до польових торгових представників.
Паралельний темп неможливий без спільної інженерної бази. Тому у нас уніфікований релізний процес для всіх продуктів, спільний шар інтеграції з Creatio, наскрізне регресійне тестування і жорстка прив’язка версій продукту до версій платформи. Коли Creatio виходить із новою версією, ми не переписуємо кожен продукт окремо — ми оновлюємо спільний шар.
У більшості релізів ми свідомо змішуємо два типи змін.
Перший — функціонал, який закриває бізнес-задачу. Новий канал комунікації. Новий тип синхронізації даних. Розширена модель планування. Це те, що потрапляє в презентації і в описи на Marketplace.
Другий — користувацький досвід. Збережений стан фільтра. Менше кліків до дії, яку менеджер робить сорок разів на день. Зрозуміліше повідомлення про помилку. Це те, що ніколи не потрапляє в презентації, — і те, що визначає, чи буде користувач працювати в системі добровільно.
Ми навмисно не відкладаємо другу категорію «на потім», коли звільниться ресурс. Ресурс не звільняється ніколи. Тому дрібні UX-зміни їдуть у тому ж релізному потоці, що й функціональні блоки, — і часто виходять раніше, бо дешевші в реалізації і безпечніші в регресії.
Високу частоту релізів неможливо отримати за рахунок того, що команда працює більше. Її можна отримати тільки за рахунок того, як побудований продукт.
Наші рішення модульні: конектори каналів відокремлені від бізнес-логіки, логіка обробки — від інтерфейсу. Додати новий месенджер у мультиканальну екосистему означає написати конектор, а не переписувати ядро. No-code-можливості Creatio і Freedom UI тут працюють як інструмент: більшу частину налаштувань під конкретного клієнта робить аналітик, а не розробник, і це не потребує окремого релізу продукту.
Саме тому кастомізація під клієнта і розвиток продукту в нас не конкурують за один і той самий ресурс.
Найпоказовіший кейс — Multichannel Chats. Продукт зараз виходить на Creatio Marketplace, публікація першої версії ще триває. При цьому другий реліз у нас уже готовий, а план третього сформований.
Це не парадокс і не маркетингова фігура. Пілотні впровадження у клієнтів почалися раніше за публікацію: реальні команди вже працювали з груповими чатами Telegram, WhatsApp, Viber, Slack і MS Teams усередині Creatio. Зворотний зв’язок від них прийшов до того, як продукт побачив широкий ринок, — і ми встигли його обробити.
Ринок побачить першу версію. Наші пілотні клієнти вже працюють із тим, що буде в наступній.
Ми не плануємо реліз від дати, ми плануємо його від зворотного зв’язку. Якщо зміна дешева в реалізації і безпечна для регресії — вона іде в найближчий реліз, а не чекає наступного кварталу. Модульна архітектура дає нам таку можливість, і це свідоме інженерне рішення, а не властивість характеру команди,
— Владислав Литвинчук, R&D Leader, Sales’Up.
Три речі, які видно не одразу.
Передбачуваність. Клієнт знає, що його запит не потрапить у беклог на рік. Реалістичний горизонт — найближчий або наступний реліз, залежно від складності.
Відсутність міграцій-подій. Оновлення на кілька відсотків функціоналу — це рутина. Оновлення на тридцять відсотків функціоналу — це проєкт із бюджетом, тестуванням і ризиком. Часті релізи перетворюють друге на перше.
Вплив на roadmap. Коли цикл короткий, зворотний зв’язок від користувача має шанс дійти до продукту, поки він ще актуальний. У річному циклі більшість таких сигналів просто губиться.
Швидкість перестала бути характеристикою команди і стала характеристикою ринку. Процеси в дистрибуції, FMCG, фармі та фінансових сервісах змінюються швидше, ніж встигає закритися типовий річний релізний цикл. Рішення, яке оновлюється раз на рік, гарантовано відстає — не тому, що воно погане, а тому, що воно синхронізоване з іншим темпом.
Ми будуємо продукти так, щоб бути в темпі клієнта, а не в темпі власного беклогу. І далі йтимемо цим шляхом.
У вас є дані. У нас є інструменти, щоб працювати з ними ефективно. Готові розібрати ваші конкретні кейси і показати, як це виглядає на практиці.
