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

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

Річний реліз означає рік життя з незручностями

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

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

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

Не один продукт, а портфель продуктів

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

У Sales'Up у розробці одночасно перебуває кілька продуктових ліній: мультиканальна екосистема (Multichannel Chats, Multichannel Notifications, Multichannel Bulk Messaging, Multichannel Chatbots, Widget Chat Channel), а також Data Management, FMCG Management, Project Management, Questionnaire Management. У кожної лінії — свій релізний цикл і своя аудиторія, від маркетингових команд до польових торгових представників.

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

Що входить у кожен реліз

Здебільшого релізи свідомо поєднують два типи змін.

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

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

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

Швидкість закладена в архітектуру, а не в темп роботи команди

Високу частоту релізів неможливо забезпечити просто змусивши команду працювати інтенсивніше. Її можна досягти лише завдяки способу побудови самого продукту.

Продукти Sales'Up мають модульну структуру: конектори каналів відокремлені від бізнес-логіки, а логіка обробки — від інтерфейсу. Щоб додати новий месенджер у мультиканальну екосистему, достатньо написати конектор, а не переписувати ядро системи. No-code-інструменти Creatio і Freedom UI дозволяють аналітику, а не розробнику, виконувати більшість налаштувань під конкретного клієнта — без окремого релізу продукту.

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

Приклад: другий реліз готовий раніше за публікацію першого

Найяскравіший приклад — продукт Multichannel Chats. Наразі триває публікація першої версії на Creatio Marketplace, водночас другий реліз уже готовий, а план третього сформований.

Це не суперечність і не маркетинговий хід. Пілотні впровадження у клієнтів розпочалися ще до публікації: реальні команди вже використовували групові чати Telegram, WhatsApp, Viber, Slack і MS Teams безпосередньо в Creatio. Їхній зворотний зв'язок надійшов раніше, ніж продукт побачив широкий ринок, тож команда встигла його врахувати.

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

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

Владислав Литвинчук, R&D Leader, Sales'Up

Що це дає клієнту

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

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

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

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

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

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

У Sales'Up прагнуть будувати продукти в темпі клієнта, а не власного беклогу, і планують продовжувати цей курс.

Джерело: IT Ukraine Association