Це не повинно потребувати пояснень
Ви маєте мати змогу зв'язатися зі своїм розробником і отримати відповідь того ж дня.
Ви маєте знати, над чим ведеться робота, не потребуючи нікого переслідувати.
Ви маєте отримувати свою роботу вчасно або чесне попередження, якщо щось затримується.
Це не надзвичайні очікування. Це базова професійна поведінка. Те, що так багато клієнтів постраждали від розробників, які не відповідають цим базовим стандартам, більше говорить про те, кого вони найняли, ніж про індустрію в цілому.
Ось як я насправді працюю.
До початку проєкту
Я ставлю запитання. Багато запитань.
Що саме зламано? Що має відбуватися замість цього? Яка платформа? Які плагіни? Що ви вже пробували? Чи є термін? Чи потрібно залучати когось ще?
Це не зволікання — це належна перевірка. Я бачив проєкти, де "зламана оплата" виявлялася неправильно налаштованим ключем API Liqpay, що виправляється за 10 хвилин. Я також бачив "дрібні виправлення", які виявляли пошкодження бази даних, що потребувало ретельної міграції.
Я не можу точно оцінити без розуміння проблеми. Якщо розробник оцінює вас без жодних запитань — він вгадує.
Я також встановлюю очікування перед початком: що я доставлю, до якого терміну, що не входить, який доступ мені потрібен, як ми спілкуватимемося.
Під час проєкту
Я відповідаю на повідомлення того ж дня. Зазвичай протягом кількох годин.
Я надсилаю оновлення без нагадувань. Не романи — короткі повідомлення на кшталт: "Перевірив базу даних, знайшов проблему, виправляю зараз, має бути готово сьогодні" або "Зіткнувся з ускладненням через версію Liqpay — потрібен ще один день, все інше за планом."
Я тестую на кількох пристроях і браузерах, перш ніж вважати щось завершеним. Я не публікую зміни на живому сайті без попереднього тестування на стейджинговому середовищі. Я не поспішаю з розгортанням у продакшені.
Якщо щось виявляється складнішим, ніж передбачалося, я повідомляю про це — з чесною оновленою оцінкою — до того, як мине термін, а не після.
Коли виникає проблема
Іноді все йде не за планом. Виправлення виявляє глибшу проблему. Сторонній API має недокументовану зміну. Хостинг клієнта має нестандартну конфігурацію.
Коли це трапляється, я негайно повідомляю клієнта, пояснюю, що знайшов, описую варіанти та даю переглянуті терміни. Я не зникаю, поки сам розбираюся. Зникнення — це саме те, як руйнується довіра.
Після доставки
Я не зникаю, щойно оплата надходить.
Я доступний для запитань протягом 2–4 тижнів після доставки без додаткової плати. Якщо щось, що я виправив, ламається з причини, пов'язаної з моєю роботою, я це виправляю. Якщо клієнт має запитання про те, як щось працює, я відповідаю.
Чого я не роблю: постійної безкоштовної підтримки для нових проблем, запитів на нові функції або проблем, спричинених зовнішніми оновленнями. Це окрема домовленість. Але я залишаю стосунки в такому стані, коли клієнт знає, як зі мною зв'язатися, якщо йому знадобиться додаткова робота.
Чому інші розробники зникають
Я не збираюся вдавати, що цієї проблеми не існує. Вона існує, і це поширене явище.
Більшість розробників, які зникають, належать до однієї з цих категорій:
- Молодші розробники, які переоцінили свої здібності й не знають, як це визнати
- Перевантажені фрилансери з більшою кількістю клієнтів, ніж вони можуть обслужити
- Люди, які недооцінили роботу й втратили мотивацію
- Справді ненадійні люди, які не повинні займатися клієнтською роботою
Схема майже завжди однакова: вони замовкають не тому, що злісні, а тому, що їм ніяково, вони застрягли або перевантажені — і їм бракує професіоналізму, щоб повідомити про це.
На що звертати увагу
Коли ви наймаєте розробника, найкращий провісник майбутньої поведінки — це минула поведінка.
Як швидко вони відповідають на ваші початкові повідомлення? Чи ставлять уточнювальні запитання, чи просто відразу називають ціну? Чи можуть пояснити свій план простою мовою? Чи мають реальні рекомендації або посилання на живі портфоліо?
Ці речі важливіші за їхнє портфоліо. Власне робота майже другорядна порівняно з надійністю, комунікацією та чесністю.
Розробник, який повільно відповідає до початку проєкту, дає розпливчасті відповіді про свій підхід і не має підтвердженої минулої роботи, показує вам саме те, як проходитиме проєкт.
Обирайте відповідно.