Как выбрать веб-студию

НЕУДОБНЫЕ ВОПРОСЫ

Почему лучшим подрядчиком может оказаться тот, кто задаст вам самые неудобные вопросы

У каждой веб-студии есть красивое портфолио.

Каждая обещает высокое качество.

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

Почти у всех есть награды, известные клиенты и современный стек технологий, 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.

Во время нее мы вместе проверяем предположения, анализируем возможные сценарии, ищем скрытые риски и формируем основу для принятия технических решений.

Иногда результатом становится новый сайт.

Иногда новая архитектура.

Иногда оказывается, что существующую систему вообще не нужно переделывать.

Все три варианта одинаково ценны.

Потому что самые дорогие ошибки в цифровых проектах чаще всего происходят не во время разработки.

Они происходят значительно раньше.