Блог

Побажання клієнтів — це і є ваш беклог? Підхід до розробки комплексної СRM

Українські користувачі CRM із кожним місяцем стають усе більш вибагливими. Конкуренція шалена — лише українських CRM-систем на сьогодні є понад 30, вже не кажучи про іноземні продукти, що активно інвестують в ринки Східної Європи. Щоб ритм витримувати, маємо дбати не лише про технічну інноваційність, але й про відповідність очікуванням. 

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

Клієнт IT-продукту постійно хоче нових функцій

І це ок — особливо, якщо продукт працює по SaaS-моделі та кожні 1–2 тижні випускає реліз. Це чудовий сигнал, що користувач прагне впливати на беклог CRM (підтверджується ринкова потреба), але в якийсь момент ви, як розробник, отримуєте нескінченний список бажань у резерві. 

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

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

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

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

Щодо направленості — кожен IT-продукт має обрати зрозумілий фокус. Для себе обрали 3 фокусних направлення: воронка продажів, групування повідомлень, робота з товарами (ecommerce-модуль) — якщо задача наразі не збігається з фокусом, вона також не потрапляє в беклог. 

Короткострокові побажання клієнтів суперечать довгостроковим цілям. Неможливо будувати розробку фрагментарно. Адже швидке реагування на побажання не враховує того, яким ви бачите продукт через 1–2–5 років. 

Кейс — ми розробляли модуль для об’єднання всіх месенджерів в єдиному інтерфейсі для продавця, щоб він міг позбутися хаосу та не втрачати заявки. Частина клієнтів, коли про це почули, почали схиляти до певної пріоритезації — взяти в роботу синхронізацію з Telegram, Facebook Messenger тощо — хоча ми були впевнені, що спочатку маємо зробити синхронізацію з Viber, бо їм користуються 73,6% користувачів. Це приклад того, як ви повинні модерувати фідбек. 

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

Вміти сказати «ні» — важлива якість менеджера продукту

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

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

Кілька років тому ми з командою визначали критерії пріоритезації фіч Серед основних:

  1. Кількість користувачів, яким ця фіча потрібна. Ми робимо функціонал, який потрібен хоча б 50% користувачів, в ідеалі — 80–90%. 
  2. Як часто запитують цей функціонал? Є функціонал, який наче потрібен більшості, однак його рідко запитують, а є такий, що потрібен 10% клієнтів, а запитують його вкрай часто. У таких задач взагалі різна пріоритезація.
  3. Зв’язок з іншими фічами. Як фіча буде впливати на інший функціонал? Якщо багато взаємозв’язків — пріоритет вище. 
  4. Скільки часу потрібно, щоб виконати задачу в CRM без цієї фічі? Якщо клієнт може виконати свою задачу в продукті без фічі, то пріоритет нижче. 
  5. Час на розробку та product value. Є невеликі фічі, що розробляються за пару годин, але глобально вони не впливають на product value. А є великі, що розробляються 1–3 місяці й цінності принесуть вище. 
  6. Внутрішня незадоволеність від того, що фічу ще не реалізували. Це особистий — наскільки команді некомфортно від того, щоб відтягується розробка певної фічі? 

Нові сутності CRM лише ускладнюють процеси

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

Якщо в тебе немає стратегічного розуміння продукту, то CRM з часом перетворюється на важкий неструктурований хаос, в якому новий користувач не має бажання розбиратися. Будь-яка CRM — це про те, як пов’язати багато сутностей докупи («Замовлення», «Ліди», «Угоди», «Контакти», «Платежі» тощо) й при цьому зробити інтерфейс зручним, цілісним. Чим більше сутностей, тим складніше по експоненті. Бажання відгукнутися на запит клієнта лише для того, щоб задовольнити його, часто руйнує структуру системи.

Скажу, до речі, по російському Бітрікс. І до війни клієнти переходили з російського софту до KeyCRM, й причиною була саме складність того продукту, а не патріотичність (як в останні 2 роки). Більшість клієнтів Бітріксу використовували лише 10% від його функціонала, з іншим функціоналом було важко; цей user experience також став в основі нашого підходу — налагодити процеси в CRM таким чином, щоб будь-хто зміг розібратися в системі за 1-2 дні. Нас тому й не дуже полюбляють IT-інтегратори, бо небагато роботи з налаштувань.

Беклог = аналітика та здоровий глузд 

На сьогодні в нас понад 1000 побажань від клієнтів — яку кнопку маємо зробити там, який розділ переробити тут, що взагалі треба прибрати й т. д. Ми кластеризуємо ці побажання, розділяємо за ознакою «потрібно/не потрібно абсолютній більшості», а також аналізуємо, чи потребують цієї фічі потенційні клієнти, бо наразі масштабуємося та зростаємо на 10% місяць до місяця. 

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

Не займайтеся надбудовою IT-продукту — займайтеся оптимізацією, застосовуючи здоровий глузд.