Точна оцінка часу — це різниця між bounty як корисним досвідом і bounty як витраченим вихідним. Більшість завдань у екосистемі Solana мають фіксовану винагороду, тому ваша реальна погодинна ставка прямо залежить від того, наскільки правильно ви спланували роботу. Нижче — практичні методи, приховані пастки та критерії, які допоможуть оцінити час реалістично.
Методи оцінки для різних типів завдань
Підхід до оцінки відрізняється залежно від природи роботи. Універсальної формули не існує, але для кожного типу завдань є свої робочі методи.
Текстові та контентні завдання
Статті, переклади, документація, гайди. Оцінюйте за обсягом вихідного матеріалу та глибиною дослідження. Для перекладу технічного тексту рахуйте не лише кількість слів, а й час на розбір термінології — знайомий вам текст і текст, де кожне третє слово треба перевірити в контексті Solana, це різні завдання. Для оригінальних статей додайте окремий блок на вивчення проєкту та перевірку фактів.
Дизайн та візуальні матеріали
Ілюстрації, інфографіка, банери, UI-екрани. Оцінюйте від кінцевого результату назад: скільки варіантів концепції ви подасте, скільки правок очікуєте, чи потрібна адаптація під різні формати. Завжди закладайте час на узгодження стилістики з командою проєкту — у кожного свій розуміння «в стилі Solana».
Технічні завдання (код)
Баги, фічі, тести, інтеграції. Метод розбиття на підзавдання працює найкраще: налаштування середовища, розуміння архітектури, написання коду, тестування, виправлення помилок. Для завдань з Rust або Anchor додайте окремий час на розбір макросів, роботи з PDA (Program Derived Addresses — похідні адреси програм) та взаємодій через CPI (Cross-Program Invocation — міжпрограмні виклики). Якщо ви вперше працюєте з конкретним шаблоном проєкту, множте оцінку мінімум на 1,5.
Community-менеджмент та аналітика
Модерація, звіти, дослідження аудиторії, аналіз конкурентів. Оцінюйте за кількістю джерел інформації та обсягом даних, які треба обробити. Аналіз десяти Discord-серверів і аналіз трьох — це не пропорційна різниця у часі, бо кожен новий контекст вимагає адаптації.
Фактори, що збільшують час
Ці фактори майже завжди присутні, але їх легко проігнорувати на етапі оцінки.
- Онбординг у проєкт. Навіть просте завдання вимагає часу на розуміння структу репозиторію, стилів коду, домовленостей команди. У нових проєктах це може зайняти від 30% до 50% загального часу.
- Комунікація з мейнтейнерами. Час очікування відповіді на питання, уточнення вимог, отримання фідбеку. У децентралізованих проєктах відповідь може приходити за годину, а може — за два дні.
- Налаштування середовища. Встановлення залежностей, підключення до RPC-вузлів, налаштування Anchor, розгортання локального кластера. Те, що ви робили раніше, зазвичай згадується як «п'ять хвилин», але на практиці завжди знаходиться щось, що йде не так.
- Конкурсний формат bounty. Багато bounty-програм працюють як конкурси: кілька учасників виконують одне завдання, а винагороду отримує лише один. Це означає, що ви витрачаєте час без гарантії результату. Це не недолік формату, а його особливість — і її треба враховувати в оцінці ризику, а не лише часу.
- Цикли правок. Перша подія рідко приймається з першого разу. Закладайте мінімум один повний цикл правок у свою оцінку.
- Час на захист авторських прав. Фіксація авторства, збереження історії комітів, скріншоти проміжних результатів — це не формальність, а ваша страховка. Виділіть на це 15–20 хвилин, але виділіть свідомо.
Як не недооцінити складність
Недооцінка складності — найчастіша причина розчарування в bounty. Ось конкретні критерії, які допоможуть цього уникнути.
Перевірте, чи є завдання «зоопарком залежностей». Якщо для виправлення одного рядка треба розібратися в п'яти модулях, які ви раніше не бачили, — це не одногодинне завдання. Ознака: у описі багато посилань на інші issue або комітів, які «треба врахувати».
Оцініть чіткість вимог. Якщо опис завдання можна прочитати двома різними способами — це червоний прапорець. Неоформлені вимоги майже гарантовано призведуть до переробки. Якщо сумніваєтесь — поставте уточнююче питання до початку роботи. Якщо відповідь розмита, краще пропустити завдання.
Знайдіть попередні спроби. Перевірте, чи не брали це завдання раніше й чому воно досі відкрите. Іноді причина в тому, що завдання складніше, ніж виглядає, або що вимоги змінювалися кілька разів.
Застосуйте правило множника. Після того як ви оцінили час, застосуйте множник 1,3–1,5 для знайомого типу завдань і 1,8–2,0 для нового. Це не песимізм — це статистика. Якщо завдання займе менше часу, ви виграєте. Якщо більше — ви були готові.
Розбийте на перевірені етапи. Замість «написати функцію» — «зрозуміти інтерфейс», «написати логіку», «написати тести», «перевірити на локальному кластері». Кожен етап оцінюється окремо і точніше.
Баланс між часом та потенційною винагородою
Оцінка часу має сенс лише тоді, коли ви співставляєте її з винагородою. Але тут є кілька важливих нюансів.
Рахуйте реальну погодинну ставку з урахуванням ризику. Формула проста: винагорода поділити на оцінений час. Але оскільки bounty часто є конкурсом, реальна ставка — це винагорода, помножена на ймовірність перемоги, поділена на час. Якщо ви вперше працюєте з таким типом завдань і є досвідченіші учасники, чесна оцінка ймовірності може бути нижчою, ніж вам хотілося б.
Враховуйте неплатіжну цінність. Деякі завдання варто робити навіть при низькій погодинній ставці, бо вони дають щось інше: досвід із конкретним стеком, публічний внесок у відомий проєкт, розуміння архітектури, яке знадобиться пізніше. Це не виправдання для роботи за копійки, а чесний спосіб оцінити, чи варте завдання вашого часу загалом.
Встановіть свою мінімальну ставку й дотримуйтесь її. Визначте для себе суму, нижче якої ви не йдете, незалежно від привабливості проєкту. Це захистить від емоційних рішень і «просто зроблю, бо цікаво» — а потім шкодуєте витрачений час.
Знайте, коли зупинитися. Якщо ви витратили на завдання вдвічі більше часу, ніж планували, і кінця не видно — зупиніться. Це не поразка, це управління ресурсами. Зафіксуйте, що зробили, збережіть код або матеріали для себе. Навіть незавершений досвід є досвідом.
Не порівнюйте bounty з фріланс-замовленнями. Фріланс передбачає договір, гарантію оплати та чіткі межі. Bounty — це інша модель з іншими правилами. Оцінюйте її за її власними критеріями, а не за стандартами традиційного аутсорсу.
Точна оцінка часу приходить з практикою. Кожне виконане завдання — це дані для наступної оцінки. Фіксуйте, скільки часу ви планували і скільки витратили насправді. Через п'ять–сім завдань у вас з'явиться власна база оцінок, яка працюватиме краще за будь-які поради.