Наскільки зрілим є 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. Зворотний зв'язок від них отримали ще до виходу продукту на широкий ринок — і встигли врахувати його.

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

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

Микита Калініченко, Marketplace Leader, Sales'Up

Що це означає для клієнта

Тут варто виділити три речі, які не одразу впадають в очі.

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

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

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

Замість висновку

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

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

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

Джерело: IT Ukraine Association