Што ја одредува цената на изработка на мобилна апликација
Нема еден чесен број пред да се знае обемот. Еве што навистина ја движи цената: платформата, екраните зад екраните и позадинскиот систем.
BILPP
Барањето “цена за изработка на мобилна апликација” речиси никогаш не добива корисен одговор, затоа што цената не е својство на апликацијата — таа е резултат на низа одлуки кои сè уште не се донесени кога се поставува прашањето. Два клиенти кои бараат “апликација за резервации” можат да опишуваат проекти чија цена се разликува повеќекратно, а обете описи звучат исто во првиот разговор.
Native или cross-platform е првата вистинска развилка
Одлуката дали апликацијата се гради native за секоја платформа или преку еден cross-platform пристап влијае на времетраењето, тимот и одржувањето подоцна. Cross-platform пристапот, кој го користиме за поголемиот дел од нашите мобилни апликации, обично значи еден код за iOS и Android наместо два одделни тима — но некои функции сепак бараат native компоненти, особено кога апликацијата зависи од хардвер или известувања во реално време.
Бројот на екрани не е исто со сложеноста
Апликација со десет едноставни екрани може да биде побрза за градење од апликација со три екрани кои содржат автентикација, офлајн синхронизација и плаќања. Она што навистина ја зголемува сложеноста не се екраните што ги гледа корисникот, туку она што се случува зад нив: чување состојба кога нема интернет, синхронизација кога врската се врати, безбедно ракување со податоци и известувања што пристигнуваат во вистински момент.
Позадинскиот систем чини повеќе од апликацијата сама
Апликацијата речиси никогаш не работи сама. Таа зборува со сервер, со систем за плаќања, а често и со постоечки систем во компанијата. Тука влегуваат интеграциите — и токму тука обично се крие поголемиот дел од работата што не се гледа на екранот, но се плаќа исто како и она што се гледа.
Фактори кои навистина ја одредуваат цената
| Фактор | Што менува |
|---|---|
| Native наспроти cross-platform | Големина на тим, брзина, одржување |
| Офлајн работа и синхронизација | Сложеност на логиката, тестирање |
| Плаќања или чувствителни податоци | Безбедносни барања, усогласеност |
| Поврзување со постоечки систем | Истражување, обработка на грешки |
| Известувања во реално време | Инфраструктура и надзор |
Одржувањето по објавувањето не е опционално
Апликацијата не е готова кога е објавена во продавниците. Оперативните системи излегуваат со нови верзии, продавниците менуваат правила за прегледување, а грешка што се појавува само на одреден уред бара внимание дури откако апликацијата веќе е во употреба. Буџет што не предвидува одржување по лансирање сметал само половина од вистинскиот трошок на апликацијата.
Кога навистина треба native компонента
Дури и во cross-platform проект, одредени делови — на пример пристап до камера на специфичен начин, длабока интеграција со известувања или врска со NFC хардвер — понекогаш бараат посебен native код за секоја платформа. Ова не е знак дека изборот на cross-platform бил погрешен; тоа е нормален дел од работата кога апликацијата навлегува подлабоко во она што уредот нуди. Проценка која однапред не го препознава ова обично подоцна се коригира преку дополнителна фаза, наместо да биде вклучена во првобитниот план.
Тестирањето на реални уреди не е чекор што се прескокнува
Симулатор на компјутер покажува дека апликацијата работи, но не покажува како се однесува на постар уред со послаб процесор, ниту како реагира кога мрежата е нестабилна. Тестирање на неколку реални уреди, вклучително и постари модели, открива проблеми кои никој не ги гледа на демонстрација, но кои реалните корисници ги забележуваат веднаш штом апликацијата излезе во продавниците.
Продавниците имаат сопствени правила и рокови
Apple App Store и Google Play имаат процес на преглед пред секое објавување, а секоја платформа со текот на времето менува свои технички барања. Апликација што не се одржува редовно ризикува да престане да работи исправно не поради сопствена грешка, туку затоа што платформата околу неа се променила. Ова одржување е дел од реалниот животен циклус на апликацијата, не дополнителна услуга.
Зошто “цена по час” не помага овде
Двајца програмери со иста цена по час можат да испорачаат многу различен резултат во исто време — еден гради код кој лесно се проширува, другиот брзо испорачува нешто што работи на демонстрација, но бара целосно преправање подоцна. Подобро прашање е колку често се гледа работна верзија на апликацијата, а не колку чини еден час работа.
Што всушност влегува во проценка
Пред каква било бројка, вистински разговор за откривање на обемот одговара на прашања кои изгледаат едноставно, но ја менуваат целата слика: колку кориснички улоги постојат, дали апликацијата заменува постоечки систем, каде се чуваат податоците и под кои ограничувања. Овие прашања не се егзотични — тие се обичните прашања на кои секој сериозен предлог мора да одговори пред бројката воопшто да значи нешто.
Цената на мобилна апликација не е својство на апликацијата. Таа е резултат на одлуки кои сè уште не се донесени кога се поставува прашањето.
Ако веќе го знаете обликот на вашиот проект, контактирајте нè за конкретен разговор наместо општа проценка. Ако одлучувате помеѓу готово решение и изработка по нарачка на позадинскиот систем, прочитајте го и текстот CRM: готово решение или изработка по нарачка.