«А де ваш продукт?» Як сервісні компанії виживають у світі продуктів і шаблонних рішень

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

От сидимо ми з черговим клієнтом на колі. Я відкриваю архітектурну схему (для тих, хто не в темі, вона виглядає майже як карта судинної системи людини) й готуюся пояснювати, чому саме такий стек ми обрали. Ну, щоб забезпечити стабільність при навантаженні в 100к RPS, гарантувати мінімальну затримку обробки викликів до сервера, уникнути каскадних відмов при пікових навантаженнях тощо (потрібне — підкреслити).

І ось клієнт дивиться на мене і... це наче я принесла йому живе теля замість стейку прожарки мідіум-рер. «А де, власне, сам продукт?» — лунає по той бік екрану. Я, як фахівець, розумію, що до тієї самої «панельки з кнопочками» ще як до місяця пішки, але як закрити це питання так, щоб людина, яка вже підписала з нами NDA, не перебувала місяцями в стані «мене, схоже, кинули на бабки»?

Чому це питання стало нормою

Питання «А де продукт?», насправді, не виникло нізвідки. За останнє десятиліття світ побачили тисячі SaaS-рішень, тож у свідомості топ-менеджменту вже надійно закарбувалася хибна теза: софт — це щось таке, що вже існує; його потрібно лише трішки налаштувати під вимоги конкретного клієнта та розгорнути, бажано — за добу-дві.

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

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

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

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

У чому сервіс програє на першому враженні

Давайте об’єктивно — навіть команда Гуглу не здатна викотити демо-версію складного продукту за кілька тижнів. Проєктні нутрощі (документація, інтеграції, беклог, архітектура) будуть зрозумілі лише тим, хто «вариться з розробниками в одному котлі», в той час як коробочний продукт одразу виглядає як завершене рішення, яке зможе презентувати стейкхолдерам навіть першокурсник технічного вишу.

Тож коли ти кажеш клієнтові щось на кшталт: «Ми не знаємо, як це виглядатиме на фініші, поки не проведемо діскавері-фазу», це звучить наче: «У нас є синя ізоляційна стрічка, палки та віра в краще, тож ви профінансуйте наш експеримент, а ми потім подивимося, що з цього вийде».

Чому складні задачі не завжди вирішуються продуктом

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

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

Ба більше, ідеальний продукт не повинен працювати автономно — він має забезпечувати безшовну передачу даних до десятків сторонніх систем, більшість з яких була розроблена, в кращому випадку, в ностальгічному 2007 та вже давно вважається «legacy». В сервісній моделі задля цього ми будуємо мости, а от у продуктовій всі сподівання переносяться на API, яких для цих самих легасі-рішень частіше за все просто не існує.

Зрештою, все те, що бачить клієнт, а саме інтерфейс, це лише 20 відсотків успіху. Решта, ті самі 80 відсотків — це аналітика, проєктування та виснажливі узгодження. Додамо до цього ще необхідність в зміні бізнес-процесів, навчанні персоналу та адаптації системи під співробітників, і стає очевидно, що продуктове рішення зі своїм лінком на документацію та сподіваннями «клієнт там сам вже якось розбереться» (а якщо ні — це його власні проблеми) абсолютно нежиттєздатне в сучасних бізнес-реаліях, де все повинно було бути автоматизовано вже вчора.

Внутрішній конфлікт сервісної компанії

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

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

Як сервіс адаптується до нової реальності

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

Наприклад, ми впроваджуємо стандартизацію всюди, де це взагалі можливо. Це стосується й однотипної структури Git-репозиторіїв, й єдиного формату документації в Confluence, й автоматизованих пайплайнів CI/CD, й уніфікованих конфігурацій Docker-контейнерів, і навіть загальноприйнятих підходів до логування та моніторингу помилок. Такий підхід мінімізує вплив так званого людського фактора. Завдяки цій ідентичності процесів від проєкту до проєкту кожен наш фахівець, заходячи на черговий sprint, не витрачає тиждень на пошуки логіки в чужих «геніальних, але одному Богу зрозумілих» рішень попередників. Так ми набуваємо тієї самої швидкості, яку обіцяють продуктові компанії, оминаючи їхні архітектурні обмеження.

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

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

Тож аби уникнути докорів на кшталт: «Та коли це вже закінчиться?», ми робимо ставку на прозорість. Вже під час діскавері-фази формуємо чіткий таймлайн та пропонуємо ціноутворення за моделлю Fixed Price для кожної ітерації, яка передбачувано завершується релізом. Так замовник отримує відчуття продукту, адже він бачить результат, який вже можна поклацати та перевірити. І, що найважливіше, у нього завжди залишається опція розгорнути цей проєктний корабель на 180 градусів у будь-який момент. Вочевидь така маневреність недоступна тим, хто обрав жорсткі обмеження готового продукту.

Що насправді стоїть за питанням: «Де ваш продукт?»

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

Проблема полягає в тому, що в корпоративному секторі ніхто не горить бажанням стати піддослідним кроликом, який погоджується на експеримент за власні кошти. Тож питання про продукт — це таке собі бажання почути: «Ми це робили вже сто разів, у нас є перевірений сотнями проєктів маршрут». Ось чому замість передбачуваної «коробки» ми демонструємо чіткий roadmap аналогічних рішень, відображаючи свій ДОСВІД і надаючи замовникові ту саму бажану впевненість в тому, що ось саме на його проєкті ми не будемо «набивати гулі».

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

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

Висновок

Питання: «Де ваш продукт?» — не вирок, а виклик. Сервіс — це рішення, головною перевагою якого є здатність вирішити будь-яку нетипову задачу. Зрештою, бізнес купує не ПЗ з купою позитивних відгуків, а вирішення саме своїх проблем. І якщо для цього потрібно збудувати кастомну систему — ми її побудуємо.