Як українська студія працює з іноземним замовником

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

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

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

Причин зазвичай чотири, і вони не зводяться до ціни.

• Своя команда зайнята. Внутрішні розробники завантажені основним продуктом, а завдання треба закрити паралельно.
• Потрібна вузька компетенція. Робота з конкретною платформою, заради якої немає сенсу наймати людину в штат.
• Обсяг разовий. Проєкт на два-три місяці не виправдовує розширення команди.
• Різниця у вартості години. Вона реальна, але сама собою рідко буває вирішальною.

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

Тут же варто назвати те, чого замовники бояться найбільше. Сильніше за якість коду й строки їх лякає невизначеність: як зрозуміти, що робота йде, поки нічого не видно; що робити, якщо підрядник перестане відповідати; кому дзвонити, якщо сайт дасть збій через рік після здачі. Усі три страхи можна зняти домовленостями, зафіксованими до старту.

Як виглядає процес від першого листа до релізу

Оцінка й чому вона попередня

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

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

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

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

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

Етапи, демонстрації та зворотний зв’язок

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

• Кожен етап закінчується чимось видимим. Прототип, макет, робоча сторінка, а не «зроблено сорок відсотків».
• Демонстрація за розкладом. Раз на тиждень або раз на два, залежно від тривалості проєкту.
• Зауваження збираються списком. Одним документом, а не листами протягом тижня.
• Строк на зворотний зв’язок фіксований. Якщо замовник мовчить, проєкт стоїть, і це має бути обумовлено.
• Зміни поза домовленістю оцінюються окремо. Їх оцінюють і погоджують новий строк.

Часові пояси й ритм комунікації

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

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

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

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

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

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

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

• Договір із переліком робіт. Укажіть конкретні етапи з результатом кожного.
• Розбивка платежів за етапами. Передоплата за перший етап, далі за фактом здачі кожного наступного.
• Валюта й спосіб оплати. Обумовлюються до старту, разом із тим, хто платить комісії.
• Рахунок на кожну оплату. Виставляється під кожен платіж і підходить для вашої бухгалтерії.
• Що буде, якщо проєкт зупинять. Замовник має право зупинити роботу, оплативши виконане.
• Строки й що вважається їх порушенням. З урахуванням часу на зворотний зв’язок замовника.

Погодинна робота застосовується там, де обсяг заздалегідь невідомий: підтримка, дрібні доопрацювання, дослідницькі завдання. Ставка в межах кастомної розробки становить $25/год, а фіксована ціна працює для проєктів зі зрозумілими межами.

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

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

Кому належить код і доступи

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

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

• Репозиторій з кодом. У Git замовника, якщо він є, або в нашому Git з доступом для замовника за потреби.
• Домен і хостинг. Оформлені на компанію замовника.
• Облікові записи в сторонніх сервісах. Аналітика, платіжні системи, поштові сервіси.
• Документація. Опис архітектури й особливостей, а не тільки коментарі в коді.

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

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

Що саме перевіряти, коли отримуєте готовий проєкт, описано в матеріалі про чек-лист приймання сайту.

Конфіденційність і робота під NDA

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

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

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

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

Що показати замість кейсів, коли клієнта називати не можна

Замість назви компанії показують суть завдання. Це працює і у зворотний бік: коли підрядник розповідає про закритий проєкт без назв, видно, наскільки він розуміє предметну сферу.

• Опис завдання без назви. Галузь, масштаб, суть проблеми.
• Технічні рішення. Що використовували й чому саме це.
• Результат у цифрах. Без прив’язки до конкретного бренду.
• Роль команди. Що робили ви, а що замовник або інші підрядники.

Критерії вибору підрядника ми зібрали окремо.

Як перевірити підрядника до великого проєкту

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

• Чи ставлять питання. Або мовчки роблять те, що зрозуміли по-своєму.
• Як пишуть. Зрозуміло й по суті чи загальними словами.
• Чи попереджають про проблеми. Заздалегідь або постфактум.
• Чи вкладаються в названий строк. І що роблять, коли бачать, що не встигають.
• Що передають на виході. Готовий результат разом із доступами й поясненням чи тільки файли.

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

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

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

Ризики, про які варто спитати одразу

Чесна розмова про ризики на старті економить нерви пізніше. Питання, які має ставити замовник.

• Хто конкретно робитиме проєкт. Одна людина чи команда, і що буде, якщо вона захворіє.
• Як передаються справи. Якщо виконавець змінюється всередині студії.
• Що з підтримкою після здачі. Скільки триває гарантійний період і що в нього входить.
• Як реагують на терміновість. Чи можуть швидко підключитися поза графіком?
• Що вже йшло не так у минулих проєктах. Відповідь «у нас усе завжди гладко» гірша за чесну історію.

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

Що ви отримуєте після завершення

Наприкінці проєкту замовник має отримати не тільки робочий сайт.

• Усі доступи. Повний перелік, а не той, який згадали.
• Вихідний код. У репозиторії, до якого має доступ замовник.
• Інструкцію з обслуговування. Що оновлювати, як робити копії, куди дивитися в разі збою.
• Опис інтеграцій. З якими системами сайт обмінюється даними й за яким розкладом.
• Контакт для звернень. Із зрозумілим форматом і строком реакції.

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

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

Висновки

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

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

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