Колку чини изработка на веб-апликација?

Веб-страницата презентира информации; веб-апликацијата врши работа. Таа разлика е причината зошто буџетите за апликации се однесуваат поинаку од буџетите за веб-страници. Веќе не плаќате за страници, туку за однесување: што смее да прави секој вид корисник, што системот мора да памети, што се случува кога двајца дејствуваат истовремено и што треба да направи софтверот кога нешто ќе тргне наопаку.

Тоа прави прашањето „колку чини веб-апликација“ да нема еден одговор, но да има целосно јасни фактори. Кога ќе ги разберете, можете правилно да прочитате секоја понуда, да споредите цени што изгледаат неспоредливо и да ја контролирате цената преку обемот, наместо да барате најевтин изведувач.

Кориснички улоги: множителот што никој не го брои

Прашајте колку видови корисници има системот пред сè друго. Алатка каде што сите гледаат исти екрани е една апликација. Алатка со клиенти, вработени и сопственик е поблиску до три: секоја улога бара свои екрани, свои дозволи и свое тестирање, бидејќи грешка што дозволува една улога да ги види податоците на друга не е козметички дефект.

Улогите ги множат и состојбите што мора да се дизајнираат. Покани, деактивирани сметки, ресетирање лозинка, некој што го губи пристапот, некој што ја напушта фирмата – секое од нив е вистински тек, а прескокнувањето е причината зошто апликациите стануваат неупотребливи шест месеци по лансирањето.

• Секоја дополнителна улога додава екрани, дозволи и тестирање
• Животниот циклус на сметките – покана, ресет, деактивација, пренос – е вистинска работа
• Грешките во дозволите се грешки во безбедноста на податоците, па бараат посебно тестирање

Моделот на податоци одредува што е можно подоцна

Под секоја апликација стои модел на бизнисот: што е клиент, што е нарачка, како резервацијата се поврзува со маса и време. Точниот модел на почетокот е најевтината работа во целиот проект, а погрешниот е најскапата, бидејќи секоја функција изградена врз лош модел мора да се гради одново кога моделот ќе се смени.

Тука студиото ја заслужува својата цена пред да напише многу код. Прашањата што на почетокот изгледаат ситничави – може ли еден клиент да има две сметки, може ли резервација да постои без маса, што се случува со старите записи кога цената ќе се смени – се токму оние што одредуваат дали втората година ќе биде евтина или болна.

Интеграциите се инженерство, не чекирање поле

Поврзувањето со платежни провајдери, системи за резервации, сметководствени системи, доставни служби или постојна внатрешна база е вистинска работа секој пат. Интеграцијата не е завршена кога работи среќниот сценарио; завршена е кога се справува со одбиени плаќања, истек на време, дупли барања и другиот систем што е недостапен еден час.

Понуда што наведува „се интегрира со вашиот систем“ како ставка не е разработена. Прашајте кој конкретен систем, кои конкретни операции и што треба да се случи кога другата страна ќе откаже. Одговорот покажува дали проценката е реална.

Административниот дел е половина производ

Повеќето буџети за апликации се прават околу тоа што гледаат клиентите, а потоа се открива дека сопственикот треба некако да управува со сето тоа. Некој мора да додава производи, менува цени, враќа средства, поправа печатна грешка, деактивира корисник, да види што се случило вчера. Тоа е втора апликација и ја користат секој ден токму луѓето што го плаќаат проектот.

Кога администрацијата се третира како дополнување, се добива софтвер со кој бизнисот се бори. Кога се третира како рамноправен дел од производот – со истото внимание како и делот за клиентите – се добива апликација што тимот навистина ја прифаќа.

Што да се изгради прво

Најефикасната контрола на трошоците во софтверот не е преговарање за цена по час; тоа е дефинирање прво издание доволно мало за да се заврши и доволно вистинско за да се користи. Изберете го работниот тек што носи најмногу вредност, изградете го целосно за улогите на кои им треба и ставете го пред вистински корисници.

Сè што ќе научите од тоа издание – што луѓето навистина прават, што игнорираат, што бараат – вреди повеќе од која било листа функции напишана пред лансирањето. Второто издание планирајте го од докази, не од првичната желба.

• Изберете еден работен тек што носи вредност самостојно
• Изградете го целосно за улогите на кои им треба, вклучувајќи ја администрацијата
• Пуштете го кај вистински корисници пред да го одредите следното издание
• Оставете набљудуваното однесување, а не првичната листа, да одлучи што следува

Трошоци што продолжуваат по лансирањето

Апликацијата е жив систем. Зависностите бараат безбедносни ажурирања, хостингот и базите чинат месечно, грешките бараат мониторинг, а корисниците бараат поддршка. Ништо од ова не е опционално, а запоставеното одржување е начинот на кој функционален производ тивко станува товар.

Прашајте го секое студио што се случува по лансирањето: кој ги ажурира зависностите, кого го викате кога нешто ќе се расипе, какво време на одговор се очекува и колку чини тоа. Тим што одговара прецизно веќе го работел тоа.

Прашања пред да потпишете

Квалитетот на понудата го предвидува квалитетот на софтверот. Поставете ги овие прашања на секој што ви дава цена и оценете ја прецизноста на одговорите исто колку и бројката на дното.

• Колку кориснички улоги се во обемот и што смее да прави секоја од нив?
• Што содржи првото употребливо издание и кога е употребливо?
• Кои интеграции се во обемот и што се случува кога ќе откажат?
• Дали административниот интерфејс е вклучен и за кого е дизајниран?
• Кој ги поседува кодот, податоците и сметките за хостинг?
• Што покрива одржувањето по лансирањето и колку чини?