Ця історія почалася з переписки про віддалену роботу над сайтами. У початковій публікації 2008 року я навів довгий діалог і різко оцінив співрозмовника. У цій редакції персональні дані та дослівне листування замінено знеособленим розбором: що ми намагалися погодити, де розійшлися очікування і чому до виконаного завдання справа не дійшла.
Запит на роботу й перший приклад
Людина звернулася з інтересом до віддаленої співпраці та показала сайт на Joomla. Я очікував резюме й опис виконаних проєктів, а отримав переважно посилання на одну роботу. На сайті, за моїм тодішнім спостереженням, залишалися ознаки незавершеного налаштування, зокрема шаблонний заголовок.
Це привід поставити питання про внесок виконавця, але не доказ його непорядності. Портфоліо потрібно розбирати предметно: що зроблено власноруч, які вимоги були на старті, як перевірено результат і чи завершена робота. Початкова оцінка про «95%» непридатних претендентів була емоційним узагальненням, а не результатом дослідження ринку.
Дві різні моделі співпраці
Я шукав людину для тривалої роботи з постійним завантаженням, навчанням і різними типами завдань. Співрозмовник цікавився стабільним заробітком, оформленням та передусім роботою в знайомій CMS. Ми не зафіксували на початку, чи йдеться про штат, окремі замовлення або договір із визначеним обсягом доступності.
У переписці спливала частка у 20% вартості замовлення. Без правил розрахунку така цифра мало що пояснює: потрібно визначити базу, етап виплати, відповідальність за дизайн, тестування, наповнення й виправлення. Моя вимога працювати лише на нашу команду також потребувала окремо погоджених умов, а не очікування, що співрозмовник сам їх прийме.
Налаштування CMS і програмування компонентів
Співрозмовник описував досвід Joomla та Mambo, знайомство з іншими CMS і власну збірку розширень. Я ж хотів перевірити здатність читати й змінювати код, адаптувати компонент до задачі та працювати не лише з одним набором готових модулів.
Це різні компетенції. Людина може добре встановлювати CMS, компонувати сторінки та налаштовувати розширення, але не братися за глибоку доробку чужого коду. Проблема виникає тоді, коли така відмінність не з’ясована до обговорення оплати й строку.
Тоді наша робота охоплювала Joomla, Bitrix і власний продукт «Корпорація». Це історичний опис стеку команди, а не нинішня рекомендація обирати конкретну CMS.
Що входить у портал і хто за це відповідає
Я говорив про портальні замовлення вартістю від кількох сотень доларів і орієнтир близько тижня на певний обсяг роботи. Співрозмовник одразу уточнив наповнення. Це було слушне питання: розробка функції, підготовка матеріалів і тестове наповнення — різні частини проєкту.
У нашій звичній моделі дизайнер відповідав за дизайн і нарізку, програміст — за функціональність. Над програмною частиною в один момент часто працювала одна людина. Для нового виконавця важливо було пояснити ці межі, критерії приймання та спосіб передачі роботи.
Робоче середовище та зв’язок
Ми кілька разів поверталися до питання, де виконувати завдання: локально чи на сервері. Я пояснював, що команда працює на сервері; співрозмовник згадував Linux-середовище й небажання налаштовувати локальний сервер. Частина відповідей загубилася в довгій переписці.
Так само не було узгоджено зручний канал розмови. Я пропонував корпоративний мобільний зв’язок, співрозмовник віддавав перевагу інтернет-засобам. Наступного дня контакт встановили із затримкою. Сам факт іншого каналу або пізньої відповіді ще не доводить наміру обманути; він показує, що потрібно домовитися про години зв’язку й очікуваний час реакції.
Нічний графік також не є самостійним критерієм професійності. Для командного проєкту важливі погоджене перекриття робочого часу, доступність на обговорення та виконання строків.
Дані про людину та довіра
У переписці я наполягав на повному представленні, а співрозмовник не хотів одразу розкривати всі дані. Це посилило взаємну недовіру. Але небажання передавати надмірні відомості до погодження формату роботи не встановлює шахрайства або паралельного збирання авансів.
Робочий підхід — пояснити, які дані й навіщо потрібні для конкретного етапу: попередньої розмови, договору, доступу до системи чи оплати. Особисті обставини, вік, місто проживання й припущення за голосом не доводять здатності виконати технічне завдання, тому в цьому розборі їх немає.
Пропозиція, яка не відповідала предмету розмови
У якийсь момент співрозмовник запропонував інший формат: розмістити наш банер на своєму сайті за регулярну оплату. Я розмовляв про розробку, тому рекламна пропозиція не розв’язувала поставленого питання. Її можна було відхилити, не переходячи до оцінки людини.
Цей епізод добре показує, навіщо повертати діалог до одного предмета: нам потрібен виконавець конкретного обсягу робіт чи рекламний майданчик? Якщо мета різна, продовжувати погодження на різних припущеннях немає сенсу.
Тестова доробка й суперечка про обсяг
Я підготував завдання на вже створеному сайті. За моєю оцінкою, портал був майже завершений — у переписці я називав 98% — і залишалися зміни функціональності окремих компонентів. Як тест пропонувалася оплачувана робота приблизно за 800 грн; моєю оцінкою строку були кілька днів.
Співрозмовник побачив більший обсяг і запропонував заміну чи переустановлення частини компонентів. З’явилися питання платного відеорозширення, перекладу, ключа ліцензії, підтримки форматів FLV/MPEG, чату й можливостей хостингу. Він вважав, що за запропоновану суму таке виконувати не варто, і віддавав перевагу створенню нового сайту.
Я відповідав, що очікую адаптації наявного коду, а не перероблення порталу. Водночас твердження замовника «тут лише 10–20 рядків» не замінює оцінки залежностей і перевірки коду. Так само пропозиція замінити компонент має пояснювати, яку саме вимогу неможливо або недоцільно виконати іншим шляхом.
Як зробити таку перевірку предметною
Потрібно виділити одну функцію: вхідні дані, очікуваний результат, наявна версія компонента, дозволений спосіб зміни та перевірка після виконання. Виконавець спочатку підтверджує, що розуміє обсяг, або описує конкретну невідповідність. Після цього погоджуються ціна й строк.
У цій історії виконаного результату не було. Це дозволяє сказати, що ми не домовилися й не перейшли до перевіреної доробки. Воно не доводить, що людина взагалі не здатна програмувати, свідомо планувала обман або так поводиться з усіма замовниками.
Авторські права та межі змін
Наприкінці діалогу виникло питання про допустимість зміни коду й видалення копірайтів. Я пояснював, що видаляти повідомлення про авторство не вимагав і очікував використання компонентів, які можна змінювати на належних умовах. Це варто перевіряти до тесту: доступний код не завжди означає необмежені права на його використання.
Головний результат історії
Для мене ця розмова стала прикладом того, як непогоджені очікування швидко переходять у взаємні оцінки. Я хотів довгострокового програміста для доробки, співрозмовник — іншого формату й іншої економіки роботи. Розмова завершилася без співпраці.
У ширшій практиці я стикався й із затримками проєктів, які доводилося терміново завершувати самому. Але з окремих невдалих випадків не випливає висновок про всіх фрилансерів. Корисний висновок для наступного проєкту — чіткий обсяг, погоджена доступність, проміжний результат і перевірка конкретної компетенції.
