У цьому відео ми розкажемо як ви можете зрозуміти скільки коштуватиме розробка вашого застосунку, як отримати приблизну і точну оцінки, а також, як ви можете дуже-дуже орієнтовно оцінити ваш проєкт прямо зараз, використовуючи нашу статистику. Варто додати, що ця статистика справедлива для проєктів такого рівня, як розміщені у нас на сайті, і лише при використанні Flutter, який дозволяє розробляти застосунок одразу під різні платформи — Android, iOS, macOS, Windows і веб. Якщо ви оберете інші технології, можливо вам доведеться оцінювати і розробляти застосунок під кожну платформу окремо.
Ось більш детальна інформація про технології, з якими ми працюємо:
https://ubrainians.com/en/technologies-we-use
Статистика по вартості однієї години розробки:
https://dev.to/fireartd/offshore-software-development-rates-by-country-in-2022-5b6h
Дивіться, поки у вас немає технічної документації, отримати точну оцінку абсолютно неможливо (хіба що ваша задача стандартна і вам можуть запропонувати шаблонне рішення). Чому. Тому що щоб точно порахувати вартість проєкту і скласти його календарний план так, щоб потім це могло стати додатком до договору про розробку програмного забезпечення, потрібно розуміти повний перелік усіх найменших дрібниць, з яких він складається, і вимог до них, а для цього потрібно ретельно його продумати, що є найскладнішою і найважливішою частиною проєкту і по суті визначає його подальшу долю. У нашій компанії розробка проєктної документації є окремим самостійним проєктом з якого починається співпраця з клієнтом.
Ця документація може містити схематичний інтерактивний прототип застосунку, що допоможе вам побачити його очима майбутніх користувачів, походити по екранах, перевірити, чи все є логічним, чи нічого ви не забули. Також, варто описати, як обробляються помилки (наприклад, як застосунок поводить себе за відсутності інтернету, чи можна хоча б переглядати інформацію, яка вже була завантажена), скільки загалом контенту і користувачів планується, щоб коли ви, наприклад, завантажите всі свої товари або зробите розсилку повідомлень про акцію своїм клієнтам все не впало. Це важливо, адже впливає не тільки на вартість розробки, а і на щомісячні витрати (наприклад, на хостинг).
Тому до речі, тендери на визначення розробника за ціною без детальної документації не мають жодного сенсу, адже таким чином обирається не хто зробить дешевше, а хто зробить менше.
Я б радив обрати декілька компаній, які вам подобаються, зустрітися з ними, розказати їм про вашу задачу і попросити їх зробити приблизний розрахунок. Чому декілька? Тому що у різних компаній зазвичай різний досвід, також хтось може бачити ваш проєкт складніше, або простіше ніж ви самі його уявляєте, навіть настрій людини в конкретний день може впливати. Тому, скоріше за все, і оцінки ви отримаєте дуже різні, вони можуть відрізнятися навіть в рази. Це нормально. Але приблизний діапазон буде зрозумілим. Також, одночасно ви зможете побачити хто як працює, хто виконує обіцянки, хто ні, з ким комфортно спілкуватись. Зазвичай, таким чином оцінку можна отримати за декілька днів.
Ну і наприкінці, як і обіцяв, я розповім, як ви можете дуже-дуже орієнтовно оцінити ваш проєкт прямо зараз. Як це працює, дивіться. Ми взяли декілька наших проєктів, їх загальний час на реалізацію (який включає в себе все: розробку, тестування, публікацію тощо), і розділили його на кількість унікальних екранів у кожному з проєктів. Проєкти різного розміру, від менше ніж 20 екранів до близько 100. І результати такі: від 28 до 56 робочих годин на один екран.
Отже, щоб дізнатись приблизну вартість вашого проєкту, ви можете порахувати кількість унікальних екранів у ньому, помножити цю кількість на орієнтовний час розробки одного екрану, і потім помножити отриманий загальний час на вартість однієї години розробки.
Щоб зрозуміти, з яких саме екранів складається ваш застосунок, я б радив уявити його очима користувачів, прослідкувати з ними весь шлях від завантаження і першого запуску застосунку і до виконання всіх дій, які будуть у ньому можливі.
Візьмемо для прикладу застосунок для доставки їжі з ресторану. Який тут сценарій? Людина відкриває застосунок, переглядає меню, можливо, дивиться детальну інформацію про певні позиції, додає щось у кошик, оформлює замовлення, сплачує за нього. Можливо ще залишає відгук, переглядає історію замовлень, редагує свої дані. Тому, скоріше за все, буде екран завантаження, екран входу, екран реєстрації, головний екран зі переліком позицій меню за категоріями, екран конкретної позиції, кошик, оформлення замовлення, оплата, відгук, історія замовлень, профіль користувача.
Оскільки, скоріше за все, ви про щось забудете (наприклад ми не порахували екран відновлення паролю та екран з повідомленням про успішно або неуспішно оформлене замовлення), краще збільшити отриману кількість екранів на 25-50 відсотків.
Щодо вартості однієї години розробки. Я наведу в описі до цього відео декілька посилань на статті зі статистикою і по Україні, і по інших країнах, щоб ви могли подивитись і зорієнтуватись.
Тобто ще раз. Порахували екрани (припустимо, із запасом вийшло 15), помножили на 56 (отримали 840 годин), і помножили це на вартість однієї години розробки. Отримаєте орієнтир.
На цьому все. Сподіваюсь, це було корисно. Якщо у вас залишилися питання на цю тему, будь ласка, звертайтесь, ми будемо раді вам допомогти.