Як обрати партнера з розробки програмного забезпечення

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

Нижче — чотири речі, які реально відрізняють партнера, з яким варто працювати, від того, з ким варто попрощатися після першого дзвінка.

Discovery, а не ціна з нізвідки

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

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

Робочий продукт кожні кілька тижнів, а не “побачимо через пів року”

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

Ітеративна доставка — робочий, клікабельний продукт кожні два-три тижні — означає, що ви рецензуєте реальні екрани, а не слайди, і можете сказати “ні, роль менеджера має бачити інше” на другому тижні, а не на десятому. Питайте прямо: “Що я побачу через два тижні після старту?” Якщо відповідь розпливчаста, це сигнал.

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

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

Сильний сигнал — передача доступу до репозиторію і документації не в кінці проєкту одним архівом, а на кожному етапі, паралельно з роботою. Це не жест доброї волі — це перевірка того, що “кастомний” справді означає ваше, а не орендоване.

Скільки шарів між вами і людиною, яка пише код

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

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

Що перевірити за один дзвінок

Питання	Слабкий сигнал	Сильний сигнал
Як формується ціна	Фіксована сума без обсягу	Discovery, потім письмовий обсяг
Коли видно результат	Один реліз у кінці	Робочий продукт кожні 2-3 тижні
Хто власник коду	Лишається у підрядника	Передається поетапно, разом з документацією
Хто пише код	Невідомо, кілька шарів	Людина на дзвінку близька до розробки

Референси розкажуть менше, ніж здається

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

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

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

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

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

Коротка розмова про ваш проєкт — це форма контакту, і вона нічого не коштує.