Як обрати вебстудію

НЕЗРУЧНІ ЗАПИТАННЯ

Чому найкращим підрядником може виявитися той, хто поставить вам найбільш незручні запитання

У кожної вебстудії гарне портфоліо.

Кожна обіцяє високу якість.

Кожна запевняє, що чудово розуміє ваш бізнес.

У більшості є нагороди, відомі клієнти та сучасний технологічний стек, Laravel, React, Shopify, AI, Headless Commerce, кастомна розробка.

З боку вони виглядають майже однаково.

Ми зібрали практичний чекліст, як відрізнити їх одне від одного, у статті How to Choose a Web Design Agency in Seattle. Тут ми детальніше розбираємо один конкретний шматок цього чекліста: рішення, які агентство ухвалює ще до того, як рекомендує технологію.

І саме тут починається головна проблема.

Тому що справжня різниця між агентствами майже ніколи не помітна в портфоліо.

Вона проявляється в тому…

як команда мислить.

А якщо точніше,

як вона ухвалює рішення ще до того, як рекомендує першу технологію.

За роки роботи ми дійшли несподіваного висновку.

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

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

Навіть якщо воно виявиться простішим.

Дешевшим.

І… менш вигідним для них самих.

Ми зрозуміли це не з книжок.

І не зі статей.

Ми зрозуміли це завдяки проєктам.

Деякі з них стали нашими найбільшими перемогами.

Інші, найболючішими уроками.

Саме вони змінили те, як ми працюємо сьогодні.

Саме про них ця стаття.

ПРОЄКТ, ВІД ЯКОГО ВІДМОВИЛИСЬ

Найбільший проєкт, від якого ми самі відмовилися

Кілька років тому ми брали участь у тендері однієї з найбільших компаній України.

Відбір складався з кількох етапів.

Технічне завдання.

Тестові завдання.

Зустрічі.

Обговорення.

Десятки агентств-конкурентів.

Зрештою ми отримали листа, який мріє побачити майже кожна студія.

«Ваша пропозиція виявилася найкращою. Залишилося лише одне питання. Якщо ви зможете трохи знизити вартість, проєкт ваш.»

Для невеликої команди це був проєкт мрії.

Великий клієнт.

Довгострокова співпраця.

Контракт, здатний змінити майбутнє компанії.

Напевно, багато хто знайшов би спосіб погодитися.

Ми, ні.

Не тому, що не хотіли працювати з цим клієнтом.

А тому, що розуміли те, чого тоді ще не бачив сам замовник.

Бюджет, який він очікував, просто не відповідав рівню якості, на який він розраховував.

Так, ми могли знизити ціну.

Але тоді ці гроші довелося б забрати звідкись в іншому місці.

Менше Discovery.

Менше роботи над архітектурою.

Менше тестування.

Менше часу досвідчених розробників.

На папері все виглядало б цілком нормально.

До того моменту, поки проєкт не перейшов би у розробку.

Рано чи пізно хтось однаково заплатив би цю різницю.

Клієнт.

Команда.

Або компанія, якій через кілька років довелося б усе переробляти.

Схожу закономірність ми розбирали у статті The Most Expensive Mistake Business Owners Make Before Hiring a Digital Agency: шкода рідко видна до того, як проєкт уже запущено.

Саме тоді ми засвоїли урок, який більше ніколи не забували.

Хороше агентство не каже «так» кожній можливості.

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

УРОК КП

Комерційна пропозиція, яка навчила нас не поспішати

Не всі важливі уроки приходять завдяки успішним проєктам.

Іноді їх приносять ті, які ти програв.

Один із таких випадків стався під час роботи з великою приватною стоматологічною мережею.

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

На той час більшість агентств працювали приблизно однаково.

Бриф.

Кілька дзвінків.

Попередня оцінка.

Комерційна пропозиція.

Ми вирішили зробити інакше.

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

Ми провели з командою клієнта кілька годин.

Вивчали не майбутній сайт.

Вивчали компанію.

Як побудовані процеси.

Як проходить шлях пацієнта.

Чому співробітники працюють саме так, а не інакше.

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

Кожне рішення мало свою причину.

Ми поверталися до офісу з повною впевненістю, що справді зрозуміли цей бізнес.

Ми помилялися.

Дорогою назад мені щиро здавалося, що ми зробили все правильно.

За кілька годин стало зрозуміло, що цього недостатньо.

У компанії, де я тоді працював, була власна система оцінювання проєктів, estimator.

Для свого часу це був справді хороший інструмент.

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

Але була одна проблема.

Він умів оцінювати розробку.

Він не вмів оцінювати розуміння бізнесу.

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

Її потрібно було переписати.

Не технічно.

По-людськи.

Пояснити, чому ми пропонуємо саме такі рішення.

Показати зв’язок між нашими рекомендаціями та реальними бізнес-процесами компанії.

Говорити мовою клієнта, а не мовою розробників.

І найголовніше…

Нам був потрібен час.

Час перевірити власні висновки.

Час поставити під сумнів власні припущення.

Час переконатися, що ми справді зрозуміли бізнес, перш ніж щось рекомендувати.

Цього часу не було.

Комерційну пропозицію потрібно було надіслати того ж дня.

Ми її надіслали.

За кілька днів мені зателефонував клієнт.

Я досі пам’ятаю його слова.

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

А потім прозвучала фраза, яка назавжди змінила моє ставлення до комерційних пропозицій.

«Але ваша пропозиція зрозуміла наш бізнес гірше, ніж пропозиції компаній, які взагалі до нас не приїжджали.»

Тоді це було боляче почути.

Сьогодні я розумію, що клієнт мав рацію.

Недостатньо приїхати.

Недостатньо поставити правильні запитання.

Недостатньо щиро намагатися розібратися.

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

Відтоді я перестав сприймати комерційну пропозицію як документ із ціною.

Для мене вона стала зовсім іншим.

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

Саме тому сьогодні я дуже обережно ставлюся до ситуацій, коли складний цифровий проєкт оцінюють після годинного Zoom-дзвінка…

…за брифом…

…або лише за технічним завданням.

Бо якщо навіть цілого дня, проведеного всередині бізнесу клієнта, виявилося недостатньо…

…то як можна чесно пообіцяти правильне рішення, просто прочитавши PDF-документ? 

ТЗ НЕДОСТАТНЬО

Чому технічного завдання недостатньо

Після тієї історії я почав інакше дивитися майже на кожен проєкт.

Бо одного разу поставив собі дуже просте запитання.

Якщо навіть цілого дня, проведеного всередині бізнесу клієнта, виявилося недостатньо, щоб зрозуміти його до кінця…

…то як взагалі можна об’єктивно оцінити складний цифровий проєкт за брифом?

Або після годинного дзвінка.

Або лише за технічним завданням.

І саме так сьогодні працює значна частина ринку.

Компанія готує документ.

Іноді на десять сторінок.

Іноді, на сто.

Його може написати внутрішня команда.

Зовнішній консультант.

А останнім часом дедалі частіше його пише штучний інтелект.

Потім цей документ надсилають кільком агентствам.

За тиждень приходять комерційні пропозиції.

Різні бюджети.

Різні терміни.

Різні технології.

З боку здається, ніби агентства просто не можуть між собою домовитися.

Насправді відбувається зовсім інше.

Вони оцінюють…

припущення.

Не бізнес.

Бо технічне завдання майже ніколи не описує, як працює компанія.

Воно описує лише чиєсь поточне уявлення про те, що потрібно побудувати.

А це зовсім різні речі.

У технічному завданні може бути детально описано:

• каталог товарів;

• особистий кабінет;

• інтеграцію з CRM;

• розширений пошук;

• нестандартне оформлення замовлення;

• програму лояльності.

Усе виглядає логічно.

Усе виглядає зрозуміло.

Здається, що цього цілком достатньо, аби назвати вартість проєкту.

Але найважливіше зазвичай залишається поза документом.

Про схожу сліпу зону ми писали у статті Most Companies Don't Own Their Website. They Own a Collection of Dependencies: те, що ніде не записано, зазвичай і коштує найдорожче.

Ніхто ще не поставив запитання:

• Чому компанія вирішила змінювати сайт саме зараз?

• Яку бізнес-проблему вона насправді намагається вирішити?

• Хто ухвалює остаточне рішення?

• Це B2B, B2C чи обидві моделі одночасно?

• Що станеться, якщо за рік кількість замовлень подвоїться?

• Які внутрішні процеси не можна порушити за жодних обставин?

І, мабуть, найважливіше запитання.

НЕ В САЙТІ СПРАВА

А що, якщо проблема взагалі не в сайті?

Саме тому сьогодні ми ставимося до будь-якого технічного завдання як до відправної точки.

Але ніколи як до остаточної відповіді.

Бо технічне завдання описує рішення.

Discovery допомагає зрозуміти проблему.

І якщо почати розробку раніше, ніж будуть перевірені припущення, на яких побудоване технічне завдання…

…ви не зменшуєте ризики.

Ви просто починаєте ухвалювати дорогі рішення з більшою впевненістю.

LARAVEL БЕЗ ПОТРЕБИ

Проєкт на Laravel, який ніколи не мав стати проєктом на Laravel

Через деякий час до нас звернувся ще один клієнт.

Цього разу все виглядало максимально просто.

Детальне технічне завдання.

Інтернет-магазин приблизно на вісім тисяч товарів.

Складні картки товарів.

Функціональний особистий кабінет.

Інтеграція з CRM.

І одна вимога, яка повторювалася майже на кожній сторінці документа.

Laravel.

З погляду клієнта технологію вже було обрано.

Залишалося відповісти лише на одне запитання.

Скільки це коштуватиме?

Більшість агентств на цьому етапі просто порахували б вартість того, що отримали.

Чесно кажучи…

Ми теж ледь не зробили так само.

Якби реалізовувати проєкт саме так, як він був описаний у технічному завданні, його вартість становила б приблизно 35-40 тисяч доларів.

Але в якийсь момент ми перестали дивитися на слово Laravel.

І почали дивитися на сам бізнес.

Що глибше ми аналізували вимоги, то частіше поверталися до одного й того самого запитання.

Чому саме Laravel?

Не тому, що Laravel поганий фреймворк.

Це зовсім не так.

Ми самі будуємо проєкти на Laravel.

Наша команда розробки на Laravel робить це регулярно, коли бізнесу це справді потрібно.

Питання було зовсім іншим.

Чи справді цьому бізнесу потрібен Laravel?

Чи, можливо, хтось уже обрав рішення…

…ще до того, як повністю зрозумів проблему?

Коли ми завершили аналіз, висновок виявився несподіваним навіть для нас.

Жодна з реальних бізнес-вимог не потребувала Laravel.

Клієнту був потрібен:

• надійний інтернет-магазин;

• зручне керування каталогом;

• функціональний особистий кабінет;

• інтеграція з CRM;

• можливість спокійно розвивати проєкт у майбутньому.

Усе це можна було реалізувати на WooCommerce.

Без втрати функціональності.

Без обмежень для подальшого масштабування.

І без зайвої складності.

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

Перша повністю відповідала технічному завданню.

Laravel.

Друга ставила під сумнів саме технічне завдання.

Коли клієнт побачив її вперше, він був щиро здивований.

Він очікував, що ми просто назвемо вартість.

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

Ми детально пояснили свою логіку.

Показали сильні й слабкі сторони обох підходів.

Порівняли не технології.

Порівняли вплив кожного рішення на бізнес.

Зрештою клієнт обрав WooCommerce.

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

Проєкт був реалізований.

Минуло вже кілька років.

Інтернет-магазин успішно працює й сьогодні.

Нічого важливого не було втрачено.

Бо метою ніколи не був Laravel.

Метою був бізнес, який працює.

AI ТА DISCOVERY

Штучний інтелект не дав неправильної відповіді

За останні кілька років ця історія набула ще одного несподіваного змісту.

Раніше клієнти говорили:

«Мені Laravel порадив знайомий розробник.»

Сьогодні вони кажуть інакше.

«ChatGPT рекомендує Laravel.»

Багато хто вважає, що проблема в штучному інтелекті.

Насправді…

…у більшості випадків AI чесно відповідає саме на те запитання, яке йому поставили.

Якщо людина запитує:

«Чи варто робити інтернет-магазин на Laravel?»

то найважливіше рішення вже було ухвалене.

Ніхто ще не з’ясував, чи потрібен цьому бізнесу Laravel взагалі.

Ніхто не розповів AI про бізнес-модель.

Про внутрішні процеси.

Про бюджет.

Про команду, яка підтримуватиме систему.

Про плани розвитку.

Про альтернативні варіанти.

AI не помилився.

Йому просто не дали можливості зрозуміти бізнес.

Це важлива відмінність, і ми говорили про те саме у статті Four AIs Agreed. We Still Hadn't Verified Anything: згода моделі не те саме, що розуміння.

І це значно важливіше, ніж здається.

Бо ту саму помилку ми бачимо не лише в розмовах зі штучним інтелектом.

Вона повторюється у технічних завданнях.

На зустрічах із агентствами.

На внутрішніх нарадах.

Люди починають захищати вже обране рішення…

…ще до того, як по-справжньому зрозуміли саму проблему.

А після цього будь-яка дискусія стає упередженою.

Колись люди делегували технічні рішення розробникам.

Сьогодні дедалі частіше вони делегують їх штучному інтелекту.

Не працює ні перше.

Ні друге.

Бо ні розробник.

Ні AI.

Не зрозуміють ваш бізнес…

…доки ви самі не допоможете їм його зрозуміти.

Штучний інтелект не замінює Discovery.

Він робить якісний Discovery ще ціннішим.

Власне, про це ж ми писали у статті The Cost of AI Isn't Generation. It's Verification.

ЗАПИТАННЯ АГЕНТСТВУ

Запитання, які справді має ставити хороша вебстудія

За роки роботи, виграних проєктів, програних тендерів, власних помилок і непростих рішень ми дійшли дуже простого висновку.

Якість агентства визначається не тим, наскільки швидко воно відповідає.

Вона визначається тим…

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

Якщо вже на першій зустрічі вам рекомендують конкретну технологію…

…варто насторожитися.

Якщо після одного технічного завдання вам упевнено називають вартість складного проєкту…

…варто насторожитися.

Якщо ніхто не намагається поставити під сумнів ваші припущення…

…варто насторожитися ще більше.

Бо хороші агентства починають не з Laravel.

Не з Shopify.

Не з WordPress.

І навіть не з бюджету.

Вони починають із розуміння бізнесу.

Саме тому кожна наша Strategic Session починається однаково.

Не з технологій.

Не з термінів.

Не з вартості.

І навіть не з функціоналу.

Зі запитань.

Бо за роки роботи ми переконалися в одній простій речі.

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

Намагатися обрати її раніше, означає просто вгадувати.

ВИСНОВОК

Висновок

Якщо всі ці історії чогось нас навчили, то, мабуть, ось цього.

Обираючи вебстудію…

…ви насправді обираєте не вебстудію.

Ви обираєте те,

як ухвалюватимуться рішення у вашому бізнесі протягом наступних років.

Кожна архітектура.

Кожна інтеграція.

Кожна технологія.

Кожне оновлення.

Кожний наступний етап розвитку.

Усе починається з одного моменту.

Хтось ухвалює рішення.

Питання лише в тому…

як саме.

Найкращі агентства відрізняються не найефектнішим портфоліо.

Не найбільшою командою.

І не найдовшим списком технологій.

Їх відрізняє готовність трохи пригальмувати, перш ніж проєкт почне рухатися вперед.

Поставити незручне запитання.

Засумніватися в очевидному.

Запропонувати простіше рішення там, де всі очікують почути складніше.

Навіть якщо це означає менший бюджет.

Бо за роки роботи ми помітили одну закономірність.

Ніхто не шкодує, що перед стартом проєкту поставив забагато запитань.

Зате дуже багато хто шкодує, що поставив замало.

ПОЧНІТЬ ІЗ РОЗУМІННЯ

Перш ніж починати розробку, почніть із розуміння

Якщо ви плануєте новий корпоративний сайт, інтернет-магазин, AI-продукт або складну цифрову систему, не починайте з вибору Laravel, Shopify, WordPress чи навіть підрядника.

Почніть із розуміння власного бізнесу.

Саме для цього ми проводимо Strategic Session.

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

Іноді результатом стає новий сайт.

Іноді нова архітектура.

А іноді виявляється, що чинну систему взагалі не потрібно змінювати.

Усі три результати однаково цінні.

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

Вони виникають значно раніше.

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