Як найняти фрілансера-розробника

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

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

Вирішіть, що ви насправді створюєте

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

Перш ніж з кимось розмовляти, запишіть чотири речі:

• Завдання, яке потрібно виконатиЩо користувач повинен мати можливість зробити, чого він не може сьогодні. Одне речення на кожну можливість, мовою користувача, а не технічною.
• Обов'язкові вимогиКілька речей, без яких створення безглузде. Якщо ваш список містить більше шести пунктів, це список побажань, а не специфікація.
• Що вже існуєПоточний сайт, хостинг, домен, платіжний провайдер, CRM, електронні таблиці. Кожна інтеграція — це робота, а незадекларовані інтеграції — це те, де оцінки руйнуються.
• Хто підтримуєПрограмне забезпечення — це не покупка, це зобов'язання. Вирішіть зараз, чи будете ви утримувати розробника, наймати когось іншого, чи керувати ним самостійно.

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

Який розробник вам потрібен

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

• ФронтендТе, що користувач бачить і торкається: макет, взаємодія, чуйність, доступність. Найміть для редизайну, маркетингового сайту або нового інтерфейсу на існуючій системі. Дивіться фрілансери з фронтенд-розробки.
• БекендДані, логіка, API, автентифікація, платежі. Найміть, коли цінність полягає в тому, що відбувається після натискання кнопки. Дивіться фрілансери з бекенд-розробки.
• ФулстекОбидва, до робочого стандарту. Правильний вибір для більшості невеликих проектів, оскільки координація між двома фахівцями коштує більше, ніж економить у невеликих масштабах.
• CMS та платформаWordPress, Shopify, Webflow та подібні. Якщо ваші вимоги задовольняються існуючою платформою, найм індивідуального розробника для її переробки — це марна трата грошей. Дивіться розробка WordPress та розробка Shopify.
• МобільнийНативний iOS або Android, або кросплатформний. Справді інша дисципліна, ніж веб, зі своїми власними обмеженнями щодо перевірки магазину та випуску. Дивіться розробка мобільних додатків.
• Обслуговування та виправленняНалагодження, оновлення, продуктивність, безпека. Часто найцінніший найм з усіх, і той, який покупці відкладають найдовше. Дивіться обслуговування веб-сайтів.

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

Вибір технології перед людиною

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

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

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

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

Написання короткого технічного завдання, яке розробник може оцінити

Гарне технічне завдання є коротким і конкретним. Воно не вказує розробнику, як будувати; воно говорить йому, що має бути правдою, коли він закінчить.

• Проблема, в одному абзаці. Що відбувається зараз і чому це неприйнятно.
• Історії користувачів. Як клієнт, я можу… щоб…. Від п’яти до п’ятнадцяти таких історій — це справжня специфікація.
• Інтеграції. Назвіть кожну зовнішню систему за назвою, включаючи ті, які ви вважаєте незначними.
• Що ви надаєте. Текст, зображення, дизайни, логіни, тестові дані. Незадекларовані прогалини стають оплачуваними годинами.
• Обмеження. Дедлайн, діапазон бюджету, хостинг, на якому ви повинні залишатися, відповідність, яку ви повинні дотримуватися.
• Визначення готовності. Де розгорнуто, як протестовано, до якого рівня задокументовано, з чим передано.

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

Створення короткого списку

Прагніть до трьох-п'яти кандидатів. Менше — і у вас немає порівняння; більше — і ви не зможете належним чином оцінити жодного з них.

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

Почніть з людини, якщо робота потребує обговорення. Перегляньте розробників за дисципліною або за інструментом — React, WordPress, PHP, Python або Webflow — або опублікуйте технічне завдання і дозвольте пропозиціям прийти до вас. На Zinn Hub публікація проекту безкоштовна, і ви можете направити її на певну область, таку як розробка веб-сайтів, розробка бекенду або розробка мобільних додатків.

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

Як читати портфоліо розробника

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

• Відкрийте живі посилання. Знімок екрана нічого не доводить. Завантажте сайт на свій телефон, використовуйте його, зламайте його. Все, що зламано сьогодні, було підписано як зламане.
• Шукайте проблеми, схожі на ваші. Не та сама галузь — та сама форма. Потік бронювання — це потік бронювання, незалежно від того, чи продає він стрижки чи вертольоти.
• Перевірте, що вони зробили. У командних проектах запитайте, які частини були їхніми. Я працював над цим може означати багато або дуже мало.
• Перевірте основи самостійно. Чи швидко завантажується сторінка? Чи працює вона на телефоні? Чи можна використовувати форми за допомогою клавіатури? Це сигнали майстерності, які нетехнічний покупець може чудово прочитати.
• Читайте відгуки як сукупність доказів. Один захоплений відгук — це шум. Шаблон у багатьох, особливо щодо спілкування та термінів, — це сигнал. На Zinn Hub відгуки вимагають підтвердженої покупки.
• Запитайте, що пішло не так. Найсильніша відповідь на запитання розкажіть мені про проект, який пішов погано — це конкретна, невтішна, добре проаналізована історія. Не існує розробника, у якого були б лише безпроблемні проекти.

Для систематичної версії цього, перегляньте наш контрольний список перевірки фрілансерів з 12 кроків.

Питання, які слід поставити перед наймом

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

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

Тестуйте, перш ніж зобов'язатися

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

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

На Zinn Hub природний формат — це Micro Zinn — завдання з фіксованою ціною за $5, $10, $15 або $20. Перегляньте виправлення помилок та невеликі завдання з коду або виправлення помилок та налаштування веб-сайтів, або почніть з ціни з $20 Micro Zinns. Наш посібник з тестування фрілансера перед тим, як зобов'язатися, охоплює, як структурувати та оцінювати тест.

Скільки це коштує і як платити

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

• Невелике завдання

  Менше $200

  Виправлення помилки, конфлікт плагінів, форма, прискорення, невелика функція в існуючій збірці. Найкраще купувати як завдання з фіксованою ціною.

• Стандартна збірка

  $500–$2,000

  Сайт або магазин на платформі: конфігурація теми, кілька шаблонів сторінок, форми, базові інтеграції, запуск.

• Розширений

  $2,000–$8,000

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

• Застосунок

  $8,000+

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

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

На Zinn Hub кожен Zinn має ціну, встановлену його Zinner, покупці не сплачують комісію платформи, а всі ціни вказані в доларах США з приблизним еквівалентом у вашій валюті. Замовлення оплачується та захищається як єдина повна сума; немає поетапного або проміжного випуску, тому поетапна розробка оформлюється як окремі замовлення або узгоджується як окремі цінові етапи у вашому проектному завданні. Оберіть Zinner із захистом платформи, і ваш платіж буде утримуватися Zinn Hub до завершення замовлення; будь-яке відшкодування буде повністю зараховано на ваш Zinn Wallet у доларах США. Zinners, які підключають власний обліковий запис PayPal або Stripe, отримують оплату безпосередньо під час оформлення замовлення.

Право власності, доступ та передача

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

• Облікові записи на ваше ім'я. Домен, хостинг та будь-який сторонній сервіс повинні бути зареєстровані на вас, а розробник доданий як користувач. Ніколи не навпаки.
• Право власності на код після доставки. Чітко зазначте, що після остаточної оплати робота є вашою для використання, модифікації та перенесення в інше місце. Запитайте про будь-які сторонні компоненти з їхніми власними ліцензіями.
• Доступ до репозиторію. Навіть якщо ви ніколи його не відкриєте, ви повинні мати можливість передати його наступному розробнику.
• Усі облікові дані. Логіни адміністратора, ключі API, доступ до бази даних, доступ до розгортання — передані та підтверджені як робочі до остаточної оплати.
• Документація. Коротка письмова примітка про те, як розгорнути, де що знаходиться і що робити, якщо щось зламається. Однієї сторінки достатньо; нічого — ні.
• Вікно для виправлення помилок. Визначений період після запуску, протягом якого справжні дефекти виправляються без додаткової плати. Тридцять днів — поширений і розумний запит.

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

Помилки, які руйнують проекти розробки

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

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