Что важно учитывать в работе с иностранными заказчиками, если вы делаете IT-проекты

В феврале 2022 года многие зарубежные заказчики поставили на паузу проекты с разработчиками из России. Это коснулось и нас: платежи были заморожены, но разработка не прекращалась — мы продолжали пилить продукт. Спустя время всё выровнялось, мы сохранили все зарубежные проекты, несмотря на ситуацию в мире. Об особенностях работы с иностранными заказчиками расскажем на примере одного из таких кейсов. Наблюдения, которые мы сделали, актуальны и для других проектов, проверено.

Меня зовут Вадим Кузенков, уже два с половиной года я директор проектного офиса KODE. Вообще я должен был стать директором в 2018 и даже приступил к обязанностям, но внезапно к нам офис приехал новый заказчик — представитель европейского банка.

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

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

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

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

От заказчиков в России мы часто слышим: «Да, бэкенд на нашей стороне, у нас своя команда». По факту оказывается, что в команде полтора землекопа, из которых один в отпуске. Тут всё тоже самое, никаких отличий.

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

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

Следствие доверительных отношений — иначе выстроенная иерархия. На мой взгляд, руководители европейских компаний гораздо ближе и более достижимы для исполнителя, чем мы привыкли, работая на российском рынке, где между собой взаимодействуют только менеджеры с обеих сторон. Лицо, которое на самом деле принимает решения, чаще всего это CEO компании, появляется в проекте раза три: в начале, в середине, например при согласовании дизайна, и в финале — при приёмке работ.

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

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

Скорее всего, к вашему появлению в проекте на стороне заказчика уже будут отлажены все процессы. У нас даже требования к бэкенду были уже описаны в Конфлюэнсе (спойлер: не все).

Если вы привнесёте в процессы что-то своё, иностранные заказчики будут внимательно к этому присматриваться. Держатели ĸрупного бизнеса ответственны за результат, поэтому готовьтесь: коммуникаций будет много по всем вопросам.

Типичная ситуация для России — сдавать проект ЛППР (лицу, принимающему промежуточные решения), а уже он защищает проект перед настоящим ЛПР. Редко получается выбиться напрямую и протолкнуть что-то менеджеру со стороны заказчика. В этом проекте у нас был прямой доступ к ЛПР на всех уровнях. Менеджер со стороны заказчика был в курсе всех деталей, болей и нюансов проекта. На совете директоров мы защищали проект за менеджера со стороны банка. Это редкий для России и крутой опыт, а ещё он сплачивает команды — вы всегда друг друга прикроете и поможете.

Нам, привыкшим к сбербанк-онлайнам и прочим тиньковым, было странно узнать, что «вот где карту выпускали, туда и обращайтесь» всё ещё является реальностью. Уровень цифрового развития в Европе, мягко скажем, удивил. Но для нас как разработчиков приложений и веб-сервисов это скорее плюс.

Заказчик поставил задачу — развивать диджитал-инфраструктуру, чтобы клиент мог совершить любую операцию, не посещая отделение банка. За первый год банк хотел перевести 30% всех клиентов на онлайн-обслуживание.

Когда мы начали изучать рынок и портрет типичного пользователя, то получили интересные инсайты. В ходе исследования мы обнаружили, что пользователь должен страдать — так возникает нужный эмоциональный ответ и запечатление с приложением. Понимаете наше UX-недоумение?

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

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

Чтобы упорядочить хаос, в любом крупном или сложном проекте с большим количеством сторонних вендоров, стоит закладываться на то, что придётся заниматься портфельным управлением. Даже если у вас контракт только на мобильную разработку или веб-сервис, чтобы сделать работу на должном уровне качества и влюбить заказчика в себя, придётся разобраться, что происходит у вендоров.

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

1. Начали актуализировать и писать требования для команды банка.
2. Включили команду заказчика в некоторые наши проектные ритуалы, например scrum of scrums. Это выручало, когда нам нужно было синхронизировать все потоки воедино.
3. Предложили тестировать их работу. Со временем заказчик нанял своих QA-инженеров и этот процесс вернулся обратно в банк.
4. Проводили постоянные консультации на всех уровнях: как готовить требования, как тестировать, как правильно организовать работу на проекте после того, как он выйдет в продакшен (разделять на разные стримы или нет).

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

У менеджера продукта есть четĸое представление, ĸаĸие данные ему нужны. Прежде чем что-то разработать, они изучают рыноĸ и ĸонĸурентов, перед релизом новой фичи на всех пользователей тестируют разные варианты интерфейса.

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

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

На старте проекта в документации была прописана разработка шаблонов платежей. Мы планировали её делать в два этапа:

1. Клиент делает платёж, приложение предлагает ему сохранить шаблон этого платежа.
2. Клиент может с нуля создать шаблон платежа.

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

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

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

Будьте готовы столкнуться с законодательством, которое заметно отличается от российского. Для нас таким примером стал Общий регламент защиты персональных данных (GDPR). Уровень жёсткости такой, что если слить данные или ещё как-то нарушить требования, то штраф в размере 20 млн евро или 4% годового оборота компании в зависимости от того, что больше. Другой «сюрприз» — PSD2, вторая директива Евросоюза о платёжных услугах. В ней появилась строгая аутентификация клиентов, которая сделала платежи безопаснее, а нашу жизнь сложнее.

Внедрение GDPR как раз выпало на первый год нашей работы с банком. Мы прошли этот путь вместе. Из-за этого релиз серьёзно сдвинулся — банковская структура не успела вовремя к нему подготовиться.

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

Мобильное приложение для европейского банка не единственный зарубежный проект KODE, но один из самых масштабных: ему четыре года, он пережил потрясения февраля 2022, оброс большим количеством дополнительных стримов и заработал награды в конкурсах и рейтингах.

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

Коротко повторю наши рекомендации по работе с зарубежными заказчиками:

• На этапе пресейла делать всё, чтобы наладить личный контакт. Готовиться, что коммуникаций по проекту будет очень много.
• Изучать менталитет и историю другой страны полезно, но лишь незначительно укрепит вашу позицию в переговорах. В большинстве случае команда, с которой придется работать, будет международной. Культурно-национальные рамки размыты максимально.
• Учитывать другой уровень цифрового развития за рубежом. Когда мы полностью перевели процессы банка из оффлайна в онлайн, это было прорывом для местного рынка, хотя в России этим уже никого не удивишь.
• На первом этапе проекта возможно жуткое недоверие. Чтобы его преодолеть, мы изучаем всю кухню, всю экосистему заказчика как терра инкогнита. Благодаря этому мы не обещаем невозможного.
• Готовьтесь разбираться, что происходит у вендоров, чтобы сделать работу на должном уровне качестве. Вендоров может быть непривычно много.
• Изучайте правовое поле другого государства сами. Даже если на стороне заказчика уже разобрались с законодательством без вас, не пренебрегайте этим, чтобы не попасть в ловушку чужого профессионализма.

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

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