Вартість розробки мобільних додатків в 2018 році

1. Скільки коштує мобільний додаток
2. Чому ціна так різниться?
3. оптимізація
4. По-друге, це технології.
5. Як зробити дешевше і швидше?
6. Тому перед початком робіт задайте підряднику подібні питання:
7. Запитайте про те, на яких технологіях буде розроблятися продукт.
8. Як зробити дорожче і довше?

Автор: Олександр Мурзанаев CEO AppCraft

Скільки коштує мобільний додаток

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

Це не може не дезорієнтувати. І не може не запустити ланцюжок роздумів: якщо ця студія готова працювати так дешево, може бути вони роблять неякісно або недооцінюють обсяг робіт? Якщо ця студія популярна, напевно істотна частина її пропозиції забезпечується брендом, а не роботами. Так навіщо мені платити за бренд? У цих ціна середня, але немає ніякої підтримки. Який бюджет буде вимагатися, щоб підтримувати проект у іншій студії? Не обійдеться це дорожче інших пропозицій?

Щоб правильно оцінювати комерційні пропозиції, потрібно розуміти чинники формування вартості.

Чому ціна так різниться?

В основному через різного підходу до організації робочого процесу. Уявіть ситуацію: студія розробляє ваш мобільний додаток, в функціонал якого входить оплата товарів картою. Розробники доходять до цього місця і (раптово) стає зрозуміло, що у них немає доступу до платіжної системи. Щоб він був, необхідно створити обліковий запис, який зробити можете тільки ви, так як там необхідно вказувати реквізити вашої компанії, дані рахунків і так далі. Студія у вас їх запрошувати і намагається переключитися на інший момент.

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

Програмісти, так як їм нічого робити, дошкуляють менеджера подальшими завданнями (з завзятість, прямо пропорційною їх мотивації). Він же, в свою чергу, зайнятий роз'ясненнями тонкощів заповнення даних про програму вам. А там є, що роз'яснювати. Коло замикається, з'являється дедлок.

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

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

оптимізація

По-перше, це організаційний процес всередині команди.

Саме правильна його архітектура дозволяє уникнути тих замкнутих кіл, які були описані вище. Правильно організований робочий процес завжди простий, швидкий і гнучкий. Хороші результати дає Scrum і його модифікації. Всі завдання повинні записуватися в беклог, який ви разом з менеджером повинні щотижня коригувати і пріоритезувати. Ви і менеджер повинні чітко розуміти, які завдання будуть закриті в поточному спринті. Зазвичай це 1-2 тижні. І в якому вигляді ви зможете побачити продукт до кінця спринту. Так, саме так: якщо ви не можете щось помацати і спробувати через 1-2 тиждень розробки, значить процес побудований невірно. Продуктивність кожного спринту повинна вимірюватися, повинні аналізуватися проблеми, які заважали зробити цей процес швидше.

Одна і та ж команда може зробити один і той же проект за 1 або за 6 місяців. Це не перебільшення, це гірка правда. Це одні й ті ж люди, з тим же рівнем професіоналізму, одні і ті ж завдання, одне і те ж розуміння кінцевого результату, один і той же продукт на виході. Але в одному випадку це 1 місяць і 1 млн рублів, в іншому - 6 місяців і 10 млн рублів. Причина в різниці підходів. У багатьох книгах по Scrum описуються десятки таких прикладів.

По-друге, це технології.

Програмістам потрібно постійно вдосконалюватися в своїй майстерності, з цим навряд чи хтось сперечатиметься. А тепер уявіть ситуацію. Програміст закінчив поточний проект, з'являється наступний (ваш), не дуже складний і не дуже терміновий. Ви не доплачуєте за надстрокову, робота йде в штатному режимі. Він думає: "ага, відмінна можливість спробувати ту нову парадигму розробки, Flow Coordinators, про яку я недавно прочитав!".

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

Чи погано це? Ну, знання, як то кажуть, світло (а за світло треба платити), що добре з академічної точки зору. Але продукт створюється вами щоб заробляти гроші. Гроші ви зможете заробити тільки якщо продукт затребуваний вашими клієнтами. Чи впливають на думку клієнта обрані технології? Ні звичайно, для них абсолютно байдуже, на чому написано мобільний додаток. Якщо вони отримують через нього знижку, або дізнаються додаткову інформацію, або розважаються, тобто вирішують свою проблему, їм не важливо, як саме це відбувається - головне, що це вигідно / добре / швидко / приємно / важливо.

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

Як зробити дешевше і швидше?

Запитайте у потенційного підрядника не тільки, що він буде робити (набір послуг), але і як він це зробить. "Бач чого, це їхня внутрішня кухня, мені не важливо" як ", мені важливо вчасно, це їхні проблеми." - якщо для вас не мають значення терміни і вартість (а в кривавому Ентерпрайз це нерідко зустрічається), то ви, безумовно , мають рацію. Але якщо вам потрібен продукт (а значить швидкість) і його вартість (вигода) для кінцевого споживача (яка складається в тому числі з ціни розробки проекту підрядником для вас), то найважливіше, про що тільки можна запитати підрядника, так це про його організаційної структурі. Одна і та ж команда може зробити один і той же проект за 1 або 6 місяців в залежності саме від організаційного процесу.

Тому перед початком робіт задайте підряднику подібні питання:

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

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

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

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

Питання як буде виконуватися робота і як буде будуватися співпраця - ключові в розумінні ціноутворення розробки програми.

Запитайте про те, на яких технологіях буде розроблятися продукт.

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

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

Як зробити дорожче і довше?

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

На нашому каналі ми щодня публікуємо огляди цікавих ідей в сфері створення мобільних сервісів і їх аналіз. Приєднуйтесь!

Цікаво. Корисно. Щодня.