Які проєкти краще не брати в роботу та які клієнти мають насторожувати

Мене звуть Христина Мартинюк і я CEO компанії Red Jumpers. Компанія займається наймом розробників у Східній Європі та Латинській Америці. Зауважу, що ми переважно співпрацюємо з партнерами, які тільки на старті та не мають значного досвіду та напрацьованих кейсів. Тому ми консультуємо щодо того, на що звернути увагу перш ніж почати з кимось співпрацю. Позитивні фідбеки наштовхнули на думку поділитися цією інформацією з ІТ-спільнотою DOU.

В статті розповідаю, як ми визначаємо проблемних клієнтів, що робимо в таких випадках та які замовлення не беремо в роботу. Наш досвід буде корисний всім, хто контактує з замовниками: СЕО аутстафінгових агенцій, рекрутерам та розробникам, які шукають проєкти напряму. Адже надійні проєкти = стабільні заробітки = більше допомоги економіці та донатів на ЗСУ.

Отже, ось які запити мають насторожувати.

1. Невідомий бюджет

Замовник не знає, який в нього є бюджет на проєкт або який рейт він готовий заплатити за розробника? Це може означати, що:

• бюджету немає взагалі;
• грошей недостатньо;
• замовник не орієнтується в реаліях ринку;
• замовник шукає, де дешевше — а значить, не орієнтований на якість (має відмінні від ваших пріоритети).

Коли клієнт не може назвати бюджет сам, на своїй стороні з самого початку озвучуємо приблизну суму та дивимося на реакцію: «В середньому виконання такої задачі коштує від $15 000 до 20 000, вас це влаштовує?».

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

Такий підхід допомагає зекономити час на оцінці та презентації оцінки — щоби витратити його на пошук інших запитів з вищою конверсією.

2. Розмиті критерії відбору кандидатів

Коли замовник каже: «Мені треба React Native розробника», але не деталізує стек, досвід, тип задач — це погана ознака. Щоби підібрати релевантного кандидата та запустили проєкт, потрібні максимально кваліфіковані та деталізовані запити.

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

• Аналізуємо причину. У випадку, коли ми не контактуємо безпосередньо з клієнтом, а отримуємо запит через партнерів, деталі можуть губитися. Одночасно, це може свідчити про те, що запит потрапив десяткам конкурентів, кандидатів буде дуже багато, і шанси навіть потрапити на співбесіду наближаються до нуля.
• Ініціюємо дзвінок з клієнтом та розпитуємо його особисто. Це допомагає не тільки отримати інформацію, але й побудувати лояльність: ми показуємо, що справді зацікавлені в якісному сервісі.
• Розпитуємо партнерів — якщо це запит від них. Розширення команди потрібно їм особисто чи їхньому клієнту? Він подавав запит ще комусь чи лише їм? Раніше вони вже мали з ним справу? На що клієнт звертає увагу при доборі кандидатів? Також, за можливості, просимо про дзвінок безпосередньо з клієнтом.

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

3. Нерелевантні умови співпраці

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

Тому на старті роботи над запитом ми просимо замовника сформулювати ключові умови співпраці:

• Оплата. Передплата чи NET 30 (оплата роботи за попередній місяць — протягом 30 днів наступного за ним місяця)? Скільки днів клієнт має на оплату роботи?
• Трекінг роботи. Чи треба використовувати трекінгові системи або запис екрану розробника? Чи буде звітування та в якій формі?
• Вихідні дні (якщо ви з замовником з різних країн). Чи може відпочивати розробник у дні, які в його країні є вихідними та святковими? Хто за них платить — ви чи замовник?
• Відпустка. Чи планує ваш девелопер відпустку протягом найближчих трьох місяців? Якщо так, краще повідомити про це клієнта. Інакше потім той може розізлитися, що розробник раптом зник на два тижні та зриває йому дедлайн.
• Штрафи. За що нараховуються штрафи? Який їхній розмір? Тут важливо прослідкувати за чіткістю формулювань, щоби не було розмитих формулювань при величезних штрафах.

4. Відсутність зворотного зв’язку

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

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

• не мають чітких критеріїв відбору (і тут ми повертаємося до пункту 2);
• мають невірно визначені критерії та не розуміють, хто їм насправді підходить;
• банально шукають когось подешевше.

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

5. Запити на рідкісну/ стару технологію

Якось ми взяли в роботу запит на дуже стару технологію Cobol. В результаті пошуків цього «динозавра» на ринку з’ясували, що у таких розробників рейти по $100, бо то вимираючий вид:)

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

У більшості випадків виявляється, що краще переробити проєкт на чомусь новому. По-перше, це дозволить швидко знайти девелопера з рейтом $30, а не $100. А по-друге — в перспективі такий проєкт буде легше підтримувати, оптимізувати та масштабувати.

6. Запити з малою тривалістю

Ми не беремо в роботу проєкти строком менше трьох місяців. Причин кілька:

• Нерентабельно. Чим довший проєкт — тим більше можливостей для апсейлу. З нашого досвіду, на тривалих проєктах строком від року дуже велика вірогідність того, що в процесі треба буде додати ще розробників. Натомість на коротких ці шанси наближаються до нуля.
• Безперспективно. Тривалість проєкту говорить про масштаб клієнта, серйозність його самого та задачі. Якщо йдеться про роботу на два місяці, скоріш за все, це якийсь support або перероблення чужого коду, що дуже важко. В будь-якому випадку перспективи сумнівні.
• Не на користь розробнику. Щоби розібратися в задачах, вивчити матеріали, інтегруватися в команду, потрібно не менше двох тижнів. Поки розробник набере темп, проєкт вже закінчиться — і треба буде вивчати новий. Такий підхід демотивує та виснажує.

7. Значні тестові задачі

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

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

• оплачувані тестові;
• безоплатні тестові, виконання яких не перевищує 4 годин;
• пропозиція замість тестового переглянути наявний зразок кода девелопера на GitHub (розробникам добре такий мати).

Три поради, як фільтрувати проєкти вже на старті

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

• При першому ж контакті звертайте увагу на «червоні» сигнали: багато невідомих (бюджет, критерії відбору, негативні відгуки про розробників без уточнення причин), підозріло великі тестові завдання, короткострокові проєкти, запити на рідкісні технології.
• Не соромтесь ставити питання. Хто безпосередній замовник? Чому він шукає саме цю технологію? Чи згоден він працювати за передплатою? Чим більше деталей ви з’ясуєте — тим швидше зрозумієте, чи потрібно далі мати справу з цим клієнтом.
• Чітко визначте для себе, з якими замовниками ви не будете працювати ніколи, а де можете піти на компроміс.