Как украинская студия работает с иностранным заказчиком

Компания в Германии, Нидерландах или США, которая ищет команду разработки, рано или поздно натыкается на предложения из Восточной Европы. Ставка заметно ниже домашней, портфолио выглядит прилично, и первым делом все спрашивают, в чем подвох.

В самой ставке подвоха нет. Значение имеет то, устроен ли процесс так, чтобы команда за несколько часовых поясов действительно доводила работу до результата. Ниже мы показываем этот процесс на практике, со стороны подрядчика и без обычного продающего глянца.

Почему подрядчика ищут за границей

Причина почти никогда не сводится к ставке. Одной дешевизны не хватило бы, чтобы согласиться на неудобство расстояния.

• Занятость местных. В европейских городах небольшие студии нередко расписаны на месяцы вперед.
• Размер команды. Задачу на трех человек на полтора месяца неудобно закрывать наймом.
• Узкая экспертиза. Что-то редкое нужно один раз, а не постоянно.
• Поддержка после запуска. По местным ставкам абонемент выглядит дорого.
• Второе мнение. Внешняя команда смотрит на проект без привычки.

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

Как выглядит процесс от первого письма до релиза

Оценка и почему она предварительная

Первый ответ на запрос никогда не бывает окончательной цифрой, и подрядчик, который называет ее сразу, угадывает.

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

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

Этапы, демонстрации и обратная связь

Работа делится на этапы, и каждый заканчивается тем, что можно посмотреть, а не отчетом о статусе.

Обычная последовательность такая: структура, дизайн, разработка, контент, тестирование, релиз. На маленьком проекте часть этапов сливается, на большом каждый делится на несколько. Работа, которая не укладывается в шаблон, вроде интеграции с собственной системой клиента или инструмента под одну компанию, идет теми же этапами, но с более длинным исследованием в начале, и именно такую форму обычно принимает кастомная разработка.

Между этапами идут демонстрации. Нужна работающая тестовая копия по ссылке, которую можно открыть со своего телефона. Это важнее, чем кажется. Письменные описания интерфейса две стороны понимают по-разному, а ссылка снимает разногласие за минуту.

Замечания собираются в одном месте, письменно, пронумерованными пунктами. Комментарии, разбросанные по трем чатам и одному звонку, это главная причина споров «мы договаривались о другом» при сдаче.

С языком тоже стоит определиться на этом этапе. Английский это рабочий язык переписки, документов и подписей интерфейса, тут вопросов обычно нет. Договориться нужно про язык самого сайта, когда он не английский, потому что тексты кто-то должен вычитать, и этот кто-то обычно на стороне клиента. Проект, три недели ждущий носителя языка для проверки немецкого текста, это частая и полностью предотвратимая задержка. Что именно дорожает, когда языков больше одного, разобрано отдельно: многоязычный сайт и что в нем дорожает.

Часовые пояса и ритм общения

Киев на час впереди Центральной Европы, на два впереди Лондона и примерно на семь впереди Нью-Йорка. График работы с понедельника по пятницу, с девяти утра до шести вечера по киевскому времени.

Для европейского клиента это почти полное пересечение, и договариваться не о чем. Для американского пересечение короткое, потому что утро на восточном побережье совпадает с концом нашего рабочего дня. Отсюда и четкий ритм работы:

• Один созвон в неделю. Для проекта, идущего по плану, достаточно.
• Письменные статусы. Отправляются так, чтобы попасть в начало вашего дня.
• Вопросы пакетами. Чтобы ответ не требовался в течение часа.
• Понятное окно ответа. Когда ответа ждут, а когда нет.
• Отдельный канал для срочного. Не тот же, что для повседневного.
• Письменная фиксация решений. Чтобы устная договоренность не испарилась.

Неполное пересечение на длинном проекте даже преимущество. Работа идет, пока вы спите, и утром результат уже готов. Преимуществом оно быть перестает, только если решение требуется каждые два часа, и процесс как раз выстроен так, чтобы этого не случалось.

Что происходит между этапами

В плане работ этого не видно, а времени оно занимает много.

Между сдачей этапа и началом следующего идет согласование, и его длительность зависит только от клиента. Подрядчик может сделать дизайн за две недели, но если замечания по нему приходят три недели, этап растягивается с двух недель до пяти.

Поэтому в плане обычно указывают два срока: сколько занимает работа и сколько заложено на согласование. Второе число часто оказывается больше первого, и лучше видеть его заранее, чем удивляться в конце.

Назначьте на каждый этап конкретный день, когда вы даете обратную связь, и держите его так же, как держит сроки подрядчик. Это единственный рычаг ускорения, который полностью в ваших руках.

Документы и оплаты

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

Электронная подпись это норма. Бумажными оригиналами обмениваются только тогда, когда этого требует бухгалтерия клиента.

Оплата по этапам защищает обе стороны. Вы не платите за несделанное, подрядчик не берет на себя месяцы работы без покрытия. Стопроцентный аванс такой же тревожный сигнал, как и требование полной оплаты только после релиза.

Кому принадлежит код и доступы

Короткий ответ: договор прямо перечисляет, что переходит клиенту после полной оплаты. Сам факт оплаты права не передает, это делает условие договора. Обычно в этот перечень входит следующее.

• Исходный код. Весь, а не только собранный результат.
• Файлы дизайна. В редактируемом формате, а не картинками.
• Доступы к домену и хостингу. Оформленные на клиента.
• Учетные записи сторонних сервисов. Аналитика, почта, платежи.
• Документация. Как разворачивается и как обновляется.

Отдельный пункт про сторонние компоненты. Почти любой сайт использует готовые библиотеки и расширения, и они остаются под своими лицензиями. Это нормально и вас не ограничивает, но если платное расширение куплено под проект, лицензия должна быть оформлена на вас, а не на подрядчика. Иначе оно перестанет обновляться в день окончания сотрудничества.

Полный перечень того, что проверяют при передаче, собран в статье про чек-лист приемки сайта.

Конфиденциальность и работа под NDA

На крупных проектах соглашение о неразглашении подписывается до обсуждения деталей.

Поэтому имя клиента и особенности проекта не появляются ни в портфолио, ни в кейсах, ни в докладах, ни в разговорах с другими клиентами. С технической стороны это значит, что доступ есть только у тех, кто работает над проектом, и он закрывается по окончании работ.

NDA работает и в обратную сторону. Все, что клиент узнает о внутренних процессах подрядчика, остается внутри проекта. Эта часть используется редко, но делает документ взаимным.

Что показать вместо кейсов, если клиента называть нельзя

Это неудобная сторона работы под NDA. Самые содержательные проекты как раз и есть те, которые нельзя показать.

• Описание без опознавательных деталей. Задача, подход, результат, без имен.
• Технические решения. Что построено и почему именно так.
• Цифры, которые клиент разрешил. Иногда метрику можно назвать без источника.
• Открытые проекты схожей сложности. Другая отрасль, сопоставимый масштаб.
• Рекомендация по телефону. Часть клиентов соглашается даже под NDA.

Если подрядчик не показывает вообще ничего и объясняет это исключительно конфиденциальностью, это повод задать вопросы. Полное отсутствие того, что можно показать, обычно означает не изобилие NDA, а что-то другое.

Как проверить подрядчика до большого проекта

Самый надежный способ это не начинать с большого проекта.

Небольшая платная задача показывает больше, чем любое собеседование. Она не обязана быть частью будущего проекта. Это может быть отдельная работа со своим бюджетом и сроком. На ней подрядчика можно проверить несравнимо дешевле, чем на третьем месяце крупной разработки.

Что такая задача показывает, вполне конкретно. Уложились ли в срок и предупредили ли заранее, если не укладывались. Задавали ли вопросы до начала или додумали сами. Как выглядит код при передаче. Как обрабатывались замечания и приходилось ли повторять одно и то же дважды.

Спросите также, кто именно будет делать ваш проект. В Amidcode над каждым проектом работают наши дизайнеры и разработчики, а персональный менеджер на связи с вами от брифа до запуска.

Критерии выбора команды и сигналы, на которые стоит реагировать заранее, собраны в статье о том, как выбрать веб-студию.

Риски, о которых стоит спросить сразу

Спросить прямо лучше, чем обнаружить потом. Если подрядчик отвечает на эти вопросы спокойно, это хороший признак, а если видит в них недоверие, это тревожный знак.

• Что будет, если срок сдвинется. Сдвиги бывают, поэтому спрашивайте, что делается, когда это происходит.
• Кто продолжит, если разработчик уйдет. Знает ли проект кто-то еще.
• Где хранится код. В вашем Git-репозитории, если он есть, или в нашем, доступ к нему откроем по запросу.
• Что происходит после релиза. Правятся ли ошибки и как долго.
• Как заканчивается проект. Порядок передачи всего.

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

Что вы получаете по завершении

Релиз это не конец отношений, но это момент, когда баланс должен быть ровным.

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

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

Стоимость и как она считается

Работа вне проекта с фиксированным объемом считается по часам, $25/час. Проект с определенным объемом оценивается фиксированной суммой по этапам.

Почасовая модель подходит работам, где объем нельзя зафиксировать заранее: исследование, интеграции с чужой системой, доработки существующего проекта. Фиксированная цена подходит разработке с понятным результатом. Смешивание двух моделей в одном договоре и есть источник большинства споров, поэтому их обычно разделяют с самого начала. Работа такого рода у нас идет как кастомная разработка.

Выводы

Главную сложность в работе с подрядчиком за границей создает неопределенность. Команда на другом конце континента, которая работает этапами, показывает результат по ссылке и фиксирует изменения письменно, предсказуемее местной, которая отчитывается устно.

Все описанное выше это процесс, а не обещание, и процесс можно проверить до того, как под него выделен большой бюджет.

Если вы рассматриваете подрядчика из Украины и хотите понять, как это выглядело бы в вашем случае, напишите нам описание задачи и ограничения по сроку и бюджету. Мы вернемся с предварительным диапазоном, списком вопросов, которые его сузят, и предложением небольшой первой задачи, если вам удобнее начать с проверки процесса, а не с подписания договора на весь проект.