Aplicație Web Personalizată Sau SaaS De Raft

Aproape nicio dezvoltare de aplicații web personalizate nu începe cu o specificație. Începe cu o foaie de calcul pe care cineva a făcut-o ca să urmărească un singur lucru, care a căpătat o a doua coloană, apoi o filă, apoi o formulă pe care o înțelege o singură persoană. Trei ani mai târziu fișierul acela ține programarea, prețurile și jumătate din evidența clienților, patru oameni îl editează în același timp și nimeni nu poate spune cu certitudine care copie este cea curentă.

Acesta este adevăratul punct de decizie și nu este cel pe care îl tratează majoritatea articolelor despre a construi sau a cumpăra. Nu alegeți între o pagină albă și un produs. Alegeți între trei ieșiri dintr-un proces care funcționează, dar este fragil: să cumpărați un produs, să asamblați ceva pe o platformă no-code sau să comandați software croit pe felul în care lucrați.

Să construiți o aplicație web personalizată sau să cumpărați SaaS? Cumpărați, cu excepția cazului în care se împlinesc cel puțin două dintre trei condiții: procesul este un factor de diferențiere și nu un cost de regie, niciun produs nu i se potrivește fără să vă deformeze felul de a lucra, iar munca de integrare este grosul lucrării. Dacă se împlinește una singură, un produs plus configurare este aproape întotdeauna mai ieftin. O construcție personalizată aduce în plus un prag permanent de cost de aproximativ 15 până la 20 la sută din prețul construcției în fiecare an, pentru totdeauna.

Foaia de calcul care a ajuns să susțină totul

Tiparul este destul de precis ca să merite un nume, iar de obicei o echipă se recunoaște tocmai atunci când îl numește.

Începe cu o persoană și un scop. Cineva trebuie să știe ce lucrări sunt programate săptămâna aceasta, deci deschide o foaie de calcul. O a doua persoană trebuie să o citească, deci ajunge pe un disc partajat. Apoi o a treia trebuie să o editeze, așa că acum mai mulți scriu în aceleași celule în același timp. Apoi o filă pentru fiecare lună. Apoi o căutare într-un al doilea fișier. Apoi o macrocomandă, scrisă de un colaborator care între timp a plecat.

Semnele sunt mereu aceleași. Fișierul are o dată și un sufix de versiune în nume. Există o copie principală și toată lumea știe cine o ține. Integrarea unui om nou înseamnă să i se arate fișierul în loc să i se explice procesul, fiindcă procesul nu este scris nicăieri altundeva.

În acest punct foaia de calcul nu mai este un document. Este o aplicație fără control al accesului, fără jurnal de audit, fără validare, fără o politică de copii de siguranță pe care ați apăra-o și cu un singur întreținător. Funcționează, exact de aceea nu a înlocuit-o nimeni, și tot de aceea înlocuirea ei costă acum scump.

Cât costă de fapt situația actuală

Nimeni nu pune o cifră pe foaia de calcul, așa că pare gratuită. Nu este, iar socoteala este ușor de refăcut pentru propria afacere.

Începeți cu retastarea. Dacă două persoane petrec fiecare 45 de minute pe zi mutând date între foaia de calcul, programul de contabilitate și o căsuță comună, sunt șapte ore și jumătate pe săptămână, adică vreo 340 de ore într-un an de lucru de 45 de săptămâni. La GBP 22 pe oră în cost integral cheltuiți în jur de GBP 7.500 pe an ca să copiați cifre de pe un ecran pe altul, iar asta nu cumpără nimic în afară de ocazia unei greșeli de tastare.

Adăugați apoi reconcilierea, când cineva verifică lunar foaia față de sursa de referință și pierde jumătate de zi hotărând care versiune are dreptate. Adăugați erorile prinse târziu: oferta trimisă la prețul de luna trecută, lucrarea programată de două ori, reînnoirea ratată. Fiecare este o sumă mică și un client nemulțumit, iar niciuna nu apare pe vreo linie de buget.

Adăugați în final riscul persoanei-cheie. Un singur om înțelege formulele, iar când omul acela este bolnav, în concediu sau plecat, procesul coboară la nivelul presupunerilor.

Datele personale dintr-o foaie de calcul rămân date reglementate

Dacă fișierul conține nume, date de contact, dosare de personal sau informații despre clienți, sunt date cu caracter personal, iar UK GDPR li se aplică exact cum s-ar aplica unei baze de date.

ICO este direct în privința a ceea ce cere asta. Ghidul său privind securitatea datelor arată că un principiu esențial al UK GDPR este să prelucrați datele personale în siguranță prin măsuri tehnice și organizatorice adecvate și că acele măsuri trebuie să asigure confidențialitatea, integritatea și disponibilitatea sistemelor voastre și a datelor personale din ele. O foaie de calcul pe un laptop nu are permisiuni pe rând, nu are regulă de păstrare și nu are nicio evidență a cine ce a citit, iar ea se copiază integral de fiecare dată când o trimite cineva pe e-mail.

Consecințele nu sunt teoretice. În octombrie 2024 ICO a amendat Police Service of Northern Ireland cu GBP 750.000 după ce date ascunse într-o foaie de calcul, publicată ca răspuns la o cerere de acces la informații, au expus numele de familie, inițialele, gradele și rolurile tuturor celor 9.483 de angajați și ofițeri ai PSNI. Decizia de sancționare citează articolele 5(1)(f), 32(1) și 32(2). Fără abordarea ICO față de sectorul public, amenda ar fi fost de GBP 5,6 milioane.

Orice organizație care ține un proces pe foi de calcul are undeva o filă exact ca aceea.

Cumpărați produsul: când SaaS este limpede alegerea corectă

Acesta este răspunsul în majoritatea cazurilor și merită susținut de la început, nu expediat într-un paragraf de încheiere.

Dacă procesul vostru este unul obișnuit, produsul există și costă mai puțin decât orice ați putea construi. Salarizare, deconturi, gestiunea tichetelor de suport, programarea întâlnirilor, semnătură electronică, contabilitate, urmărirea candidaților. Cineva a petrecut un deceniu și o echipă mare de ingineri pe cazurile limită pe care voi nu le-ați întâlnit încă: eroarea de an bisect, schimbarea cotei de TVA, restituirea care sosește după închiderea perioadei.

Cumpărați totodată muncă pe care altfel ați plăti-o. Furnizorul duce disponibilitatea, corecțiile de securitate, schimbările din browsere, munca de accesibilitate și dovezile de conformitate pe care le cer clienții voștri. Nimic din toate acestea nu apare ca funcționalitate și toate înseamnă bani adevărați.

Testul onest nu este dacă produsul face totul. Este dacă face acele 80 la sută importante fără să vă oblige să schimbați ceva la care țineți. Dacă singura nepotrivire este că echipa voastră spune lucrare, iar programul spune tichet, cumpărați programul și schimbați cuvântul.

Cele trei condiții care justifică dezvoltarea unei aplicații web personalizate

O construcție personalizată se justifică prin strategie, nu prin iritare. Există trei condiții care chiar o susțin, iar regula utilă este că vă trebuie cel puțin două dintre ele. O singură condiție se rezolvă aproape întotdeauna mai ieftin cu un produs plus configurare. Același test se aplică la scară de corporație, lucru pe care ghidul nostru despre a construi sau a cumpăra CRM și ERP îl tratează la un cu totul alt ordin de mărime.

Procesul este un factor de diferențiere, nu un cost de regie

Întrebați-vă ce ar observa un client dacă procesul ar deveni de două ori mai bun. Dacă răspunsul este nimic, atunci este regie și ar trebui să cumpărați, fiindcă o salarizare excelentă nu vă aduce clienți. În schimb, un instalator specializat a cărui logică de programare stoarce o lucrare în plus din ziua fiecărei dube, sau un creditor ale cărui reguli de analiză sunt chiar produsul lui, își trece avantajul competitiv prin acel software. Nu puteți cumpăra un avantaj pe care concurenții voștri îl pot cumpăra la același preț lunar.

Niciun produs nu se potrivește fără să deformeze procesul

Fiecare produs codifică ipoteze despre felul în care circulă munca, iar semnul că sunt greșite pentru voi este că adoptarea lui v-ar cere să încetați ceva profitabil. Dacă firma voastră ofertează pe o bază pe care produsul nu o poate exprima, iar tocmai acel fel de a oferta este motivul pentru care clienții vă aleg, produsul vă cere să deveniți mai obișnuiți în schimbul unei taxe de licență.

Suprafața de integrare este munca adevărată

Uneori partea interesantă nu stă deloc în ecrane. Stă în a lua stocul dintr-un sistem, prețurile din al doilea, disponibilitatea tehnicienilor din al treilea și a scrie rezultatul într-al patrulea. Când cea mai mare parte a efortului este integrare, interfața este un strat subțire peste propria voastră instalație, iar ecranele incluse într-un produs sunt partea de care aveți cea mai puțină nevoie. Este condiția cel mai des subestimată și tot acolo locuiește capcana de la mijloc.

Capcana de la mijloc: cumperi și apoi construiești oricum

Cel mai scump rezultat nu este niciuna dintre cele două căi parcursă curat. Este să cumpărați un produs fiindcă părea mai ieftin, apoi să cheltuiți pe îndoirea lui după procesul vostru mai mult decât ar fi costat o construcție personalizată și să plătiți în continuare licența.

Se întâmplă treptat și fiecare pas în parte este justificabil. Produsul nu se potrivește, așa că angajați un partener de implementare. Partenerul scrie configurare în stratul de scripting proprietar al furnizorului, care este cod, dar nu pare cod fiindcă trăiește în interiorul produsului. Apoi trebuie să vorbească cu alte două sisteme, deci cumpărați o platformă de integrare. Apoi furnizorul lansează o versiune majoră, iar personalizările voastre cer teste de regresie.

În acel punct aveți toate costurile unui software personalizat și niciun beneficiu al proprietății: o bază de cod pe care nu o puteți citi, găzduită undeva unde nu aveți control, scrisă într-un limbaj care există într-un singur produs, întreținută de un partener al cărui tarif zilnic este acum o linie în bugetul vostru. Ghidul nostru despre costul dezvoltării software personalizate arată cum se adună cifrele acelea.

Semne că sunteți în capcană

Capcana este mai ușor de detectat decât de părăsit, iar semnalele sunt fără echivoc de îndată ce le căutați.

• Onorariul partenerului de implementare este mai mare decât licența primului an.
• Cineva ocupă practic un post cu normă întreagă administrând un singur produs.
• Ați scris logică în limbajul de scripting proprietar al furnizorului, iar nimeni din afara firmei nu o poate citi.
• Fiecare actualizare a furnizorului declanșează un test de regresie pe personalizările voastre, așa că amânați actualizările.
• Plătiți o platformă de integrare care există doar ca să alimenteze cu date acel singur produs.
• Țineți o foaie de calcul paralelă lângă produs, fiindcă produsul nu poate exprima ceva de care aveți nevoie.

Ultimul este cel mai limpede. Dacă foaia de calcul a supraviețuit cumpărării programului, programul nu a rezolvat problema.

No-code și low-code ca a treia cale serioasă

Întrebarea no-code sau personalizat merită mai mult decât o notă de subsol, fiindcă pentru dezvoltarea de unelte interne platformele low-code sunt adesea răspunsul corect și nu sunt o jucărie.

Platforme precum Airtable, Retool și Microsoft Power Apps vă lasă să construiți o aplicație reală cu mai mulți utilizatori, cu bază de date, formulare, permisiuni și automatizări, în zile în loc de luni, fără să angajați pe nimeni. Ele duc găzduirea, copiile de siguranță, autentificarea și aranjarea pe telefon. Pentru sarcina precisă de a muta o foaie de calcul care susține totul într-un loc cu control al accesului și jurnal de audit, sunt adesea calea cea mai rapidă spre o reducere mare de risc.

Sunt totodată tarifate pe utilizator, iar acest fapt hotărăște dacă rămân răspunsul potrivit pe măsură ce creșteți.

Unde câștigă cu adevărat no-code

Câștigă atunci când forma problemei este dată de înregistrări, formulare, vizualizări și reguli simple: un registru de active, o coadă de aprobări, o listă de verificare pentru primirea unui client, o rezervare de săli. Câștigă cel mai clar atunci când persoana care înțelege procesul îl poate construi singură, fiindcă cerințele nu mai trebuie să supraviețuiască traducerii într-o specificație și înapoi.

Câștigă și la timpul până la valoare. O unealtă funcțională în două săptămâni și folosită zilnic bate una perfectă în șase luni, încă în faza de proiectare, iar versiunea construită vă învață care erau de fapt cerințele.

Unde no-code se lovește de un zid

Zidul este de obicei unul dintre cinci lucruri. Performanța la numărul real de rânduri, de îndată ce o vizualizare trebuie să filtreze sute de mii de înregistrări. Permisiunile cu o complexitate reală, de pildă reguli pe rând care depind de starea înregistrării și de echipa celui care se uită. Integritatea tranzacțională, unde două lucruri trebuie să se întâmple amândouă sau niciunul. Testarea și controlul versiunilor, fiindcă adesea nu există niciun fel de a revizui o modificare înainte să intre în producție. Și orice are un automat de stări adevărat, unde regulile stabilesc care tranziții sunt permise.

Nu ajungeți la zid treptat. Ajungeți la el atunci când o modificare care ar trebui să dureze o oră se dovedește imposibilă.

Ce face la scară mare tarifarea pe utilizator

Tarifarea pe utilizator este ieftină la zece utilizatori și poate deveni de neapărat la patru sute, iar tarifele publicate arată asta ușor.

Pagina de prețuri Retool listează planul Business pentru norul britanic la GBP 40 pe lună pentru fiecare constructor și GBP 12 pentru fiecare utilizator intern, cu planul Team la GBP 8 și GBP 4. Microsoft listează Power Apps Premium la GBP 16,90 pe utilizator pe lună cu plată anuală, fără TVA, coborând la GBP 10,80 la un minim de 2.000 de posturi. Airtable publică planul Team la USD 20 și Business la USD 45 pe utilizator pe lună, ambele facturate anual în dolari americani.

Proiectați cifrele. Patruzeci de utilizatori pe Retool Business, dintre care trei constructori, înseamnă în jur de GBP 6.800 pe an. Aceeași formă la patru sute de utilizatori ajunge la vreo GBP 59.600 pe an și urcă din nou în clipa în care mai adăugați oameni. Pe Power Apps Premium, patru sute de posturi costă în jur de GBP 81.000 pe an înainte de TVA.

Niciunul dintre aceste tarife nu este nerezonabil. Ideea este că factura urmărește numărul de angajați și nu valoarea livrată, iar numărul de angajați crește.

Problema ieșirii când logica trăiește într-o unealtă proprietară

Orice platformă vă va exporta datele. Niciuna nu vă va exporta aplicația.

Rândurile ies în CSV sau printr-o interfață de programare, iar aceea este partea pe care o verifică toată lumea înainte de semnare. Ce nu iese este lucrul pe care l-ați construit: automatizările, coloanele cu formule, regulile de permisiune, formularele condiționate, fluxul care transformă o cerere în trei notificări și o schimbare de stare. Logica aceea este activul, a costat luni de decizii ca să iasă bine, iar numai motorul unui singur furnizor o poate executa.

Consecința practică este că părăsirea unei platforme low-code nu este o migrare, este o reconstrucție. Vă primiți datele înapoi și scrieți aplicația din nou în altă parte, pornind de la o specificație care nu a fost niciodată scrisă fiindcă platforma era specificația.

Acesta nu este un argument împotriva folosirii uneia, ci doar în favoarea păstrării unei descrieri scrise a regulilor în afara uneltei.

Costul total pe cinci ani pentru cele trei căi

Comparația pe care o face lumea de obicei este necinstită într-un fel anume: pune versiunea complet costificată a unei căi împotriva prețului de raft al celeilalte. Luați patruzeci de utilizatori și o aplicație operațională care înlocuiește o foaie de calcul și două abonamente mici. Cifrele sunt valori ilustrative de planificare, nu oferte, iar prețul construcției este variabila care se mișcă cel mai mult.

Citit în cuvinte: la patruzeci de utilizatori câștigă platforma no-code, cu circa GBP 75.800 pe cinci ani. Construcția personalizată vine a doua, la vreo GBP 94.500, fiindcă o construcție de GBP 45.000 plus GBP 1.800 de găzduire și GBP 8.100 de mentenanță anuală bate tot licența, middleware-ul și administrarea stivuite ale căii SaaS. Cumpărarea produsului iese ultima, la vreo GBP 135.000, și iese așa din cauza capcanei de la mijloc, nu doar a licenței.

De ce se răstoarnă același tabel la patru sute de utilizatori

Schimbați o singură intrare, numărul de angajați, și ordinea se schimbă complet. Acesta este cel mai frecvent motiv pentru care o construcție devine rațională.

La patru sute de utilizatori, licența SaaS la GBP 30 pe utilizator pe lună înseamnă singură GBP 144.000 pe an, iar cu același middleware și o sarcină administrativă mai mare totalul pe cinci ani trece de GBP 800.000. Calea no-code ajunge aproape de GBP 375.000. Construcția personalizată abia se mișcă: mai mulți utilizatori înseamnă o factură de găzduire și un buget de mentenanță ceva mai mari, așa că nici măcar dublarea prețului construcției la GBP 70.000 nu duce totalul pe cinci ani mai departe de GBP 153.000.

Motivul este structural. Tarifarea pe utilizator este un cost variabil care crește odată cu organizația, în vreme ce un sistem personalizat este un cost fix plus o mică parte variabilă, iar acea parte este infrastructura, care este ieftină. Dacă răsturnarea contează pentru voi este o prognoză de afaceri, nu o judecată tehnică.

Pragul permanent de cost al unei construcții personalizate

Linia pe care lumea o lasă afară dintr-o estimare personalizată este cea care nu se oprește niciodată. O aplicație croită pe măsură are un prag de cost, iar acesta nu coboară la zero într-un an liniștit în care nimeni nu cere funcționalități.

Pragul este făcut din găzduire, monitorizare, copii de siguranță din care ați testat restaurarea, certificate TLS, corecții de securitate, actualizări de dependențe și cineva care răspunde la telefon când se strică luni la nouă dimineața. Planificați în jur de 15 până la 20 la sută din costul inițial al construcției pe an. Aceasta este o ipoteză de planificare desprinsă din felul în care se comportă asemenea proiecte și nu o statistică publicată, dar este cifra pe care ne facem bugetul, iar o ofertă fără ea nu este o ofertă completă. Articolul nostru despre costul de mentenanță software îl detaliază mai departe.

Fiecare total pe cinci ani al construcției personalizate de mai sus presupune că linia aceea este finanțată. Proiectele care o sar nu economisesc banii, îi amână și îi plătesc mai târziu ca rescriere, adică exact ceea ce descrie datoria tehnică.

Software-ul neîntreținut se degradează

O aplicație care a mers neatinsă doi ani nu este stabilă. Este nepetecită, iar diferența contează.

În codul vostru nu s-a schimbat nimic, dar în jurul lui s-a schimbat totul. Mediile de execuție ajung la sfârșitul vieții după un calendar publicat: Node.js susține în prezent versiunea 26 ca versiune curentă, cu versiunile 24 și 22 ca linii LTS active, ceea ce înseamnă că orice este clădit pe versiunea 20 sau mai veche este acum în afara suportului și nu mai primește corecții de securitate. Dependențele adună vulnerabilități publicate. Browserele schimbă felul în care tratează modulele cookie și stocarea. Procesatorii de plăți retrag versiuni de interfață și vă dau un termen.

Niciuna dintre acestea nu este vina voastră și toate sunt problema voastră, fiindcă într-un sistem croit pe măsură nu există un furnizor care să le absoarbă în locul vostru. Acesta este avantajul autentic și structural al cumpărării: echipa de ingineri a altcuiva petrece fiecare săptămână împiedicând podeaua să putrezească, iar taxa de licență este cât costă asta. Propriul vostru buget de mentenanță cumpără exact aceeași muncă, iar voi o plătiți fie deliberat, fie în regim de urgență.

Găsirea propriului prag de rentabilitate pe utilizator

Puteți calcula pragul în vreo zece minute, iar el convinge un director financiar mai mult decât orice discuție despre proprietate.

Luați costul lunar al căii cu produs, totul inclus: licență, middleware și fracțiunea de salariu cheltuită pe administrarea lui. Scădeți costul lunar de funcționare al unui sistem personalizat, adică găzduirea plus o doisprezecime din bugetul anual de mentenanță. Împărțiți prețul construcției la ce a rămas. Rezultatul este numărul de luni până când construcția s-a plătit singură.

Socotit la patruzeci de utilizatori: calea SaaS merge la vreo GBP 2.150 pe lună, iar sistemul personalizat la vreo GBP 825, deci economia lunară este de aproximativ GBP 1.325. O construcție de GBP 45.000 se împarte în ea cam de 34 de ori, așa că amortizarea cade aproape de doi ani și zece luni. La patru sute de utilizatori amortizarea scade sub un an.

Două rezerve. Prețul construcției este aici cifra cea mai nesigură, deci faceți socoteala cu oferta primită și încă o dată cu 50 la sută mai mult. Iar o amortizare mai lungă de vreo trei ani este un caz slab, fiindcă procesul vostru s-ar putea să nu supraviețuiască neschimbat atâta vreme.

Datele și dependența taie în ambele sensuri

Dependența de furnizor este argumentul clasic pentru a construi și este reală. Este însă doar jumătate din tablou, fiindcă un sistem personalizat pe care nu l-a documentat nimeni este și el o formă de dependență.

Pe partea de produs, verificați înainte de semnare ce iese cu adevărat. Înregistrările se exportă de obicei curat. Atașamentele, jurnalele istorice de audit, firele de comentarii, structurile de permisiuni și relațiile dintre înregistrări adesea nu. Măsura practică nu este dacă există un buton de export, ci dacă ați putea ridica un înlocuitor funcțional numai din acel export.

Pe partea personalizată, riscul egal și opus este un sistem construit de un singur colaborator, fără README, fără teste, fără manual de operare, cu credențiale într-un fișier de configurare pe un laptop și cu depozitul de cod în contul personal al cuiva. Este mai rău decât dependența de un furnizor SaaS, fiindcă furnizorul măcar încă funcționează.

Remediile sunt contractuale și ieftin de cerut la început. Dețineți voi depozitul de cod, cereți documentația și un manual de operare ca livrabile numite și cereți ca un al doilea inginer să îl poată instala numai din acea documentație. Verificați promisiunea înainte de plata finală. Ghidul nostru complet pentru cumpărători tratează clauzele contractuale mai pe larg.

Securitate și conformitate în fiecare model

Împărțirea responsabilității diferă de la o cale la alta, dar un lucru nu se mișcă deloc, iar greșeala aceasta este frecventă.

Sub UK GDPR voi sunteți operatorul. ICO definește operatorul ca entitatea care, singură sau împreună cu altele, stabilește scopurile și mijloacele prelucrării datelor cu caracter personal, iar persoana împuternicită ca aceea care prelucrează date personale în numele operatorului. Furnizorul vostru SaaS este aproape întotdeauna persoana împuternicită. Rămâneți voi răspunzători pentru demonstrarea conformității, iar ICO spune explicit că un operator răspunde pentru persoanele pe care le împuternicește și trebuie să aibă un contract obligatoriu care conține prevederile cerute de articolul 28(3).

Ceea ce duce cu adevărat furnizorul este stratul de infrastructură: securitatea fizică, corecțiile platformei, controalele de rețea și adesea certificările. Modelul răspunderii partajate al NCSC este limpede că, chiar și cu SaaS, vă rămân trei lucruri: să evaluați dacă serviciul vă acoperă nevoile de securitate, să îl configurați în siguranță și să hotărâți ce date puneți în el.

Într-o construcție personalizată moșteniți în plus tot stratul tehnic: corecții, control al accesului, criptare, jurnalizare, copii de siguranță și restaurare. Articolul nostru despre conformitatea tehnică GDPR arată cum arată asta în cod. Poziția juridică nu se schimbă de la o cale la alta.

Accesibilitatea se aplică și uneltelor interne

Uneltele interne sunt construite în mod obișnuit ca și cum nimeni dintre cei care le folosesc nu ar putea avea o dizabilitate, ceea ce este greșit și, pentru unele organizații, ilegal.

Conform secțiunii 20 din Equality Act 2010, un angajator are obligația de a face adaptări rezonabile, inclusiv de a lua măsurile care pot fi luate în mod rezonabil ca să evite un dezavantaj substanțial provocat de o dispoziție, un criteriu sau o practică, și de a asigura mijloace auxiliare. Un sistem de planificare a turelor care nu poate fi folosit de la tastatură pune un angajat cu dizabilități într-un dezavantaj substanțial, iar pentru software-ul pe care clienții voștri nu îl văd niciodată nu există nicio excepție.

Pentru organizațiile din sectorul public poziția este explicită. Ghidul GOV.UK despre cerințele de accesibilitate arată că siturile de intranet și extranet intră sub reglementările de accesibilitate, că trebuie să respecte WCAG 2.2 AA și că siturile interne mai vechi, publicate înainte de 23 septembrie 2019, trebuie făcute accesibile atunci când sunt actualizate.

Criteriile pe care uneltele interne le ratează cel mai des sunt cele banale: 2.1.1 Tastatură și 3.3.2 Etichete sau instrucțiuni la nivelul A, 1.4.3 Contrast (minim) la nivelul AA, iar dintre adăugirile WCAG 2.2 criteriile 2.4.11 Focalizare neacoperită (minim) și 2.5.8 Dimensiunea țintei (minim), ambele la nivelul AA.

În no-code accesibilitatea este un plafon pe care nu îl controlați

Acesta este punctul de accesibilitate care schimbă o decizie între a construi și a cumpăra, în loc doar să îi adauge muncă.

Pe o platformă no-code nu scrieți voi marcajul. Îl generează platforma, deci accesibilitatea aplicației voastre este plafonată de cea a bibliotecii ei de componente. Dacă selectorul ei de date nu poate fi folosit de la tastatură, sau dacă fereastra ei modală ține prost focalizarea, nu puteți repara. Puteți deschide un tichet de suport și aștepta.

Este în regulă atâta vreme cât plafonul este destul de sus, iar câteva platforme tratează problema serios. Nu este în regulă atunci când aveți o obligație anume, un angajat anume sau o îndatorire de sector public, fiindcă remediul stă în afara controlului vostru și în afara calendarului vostru.

Într-o construcție personalizată munca de accesibilitate vă revine, ceea ce costă mai mult la început și înlătură dependența. Cereți oricărui furnizor luat în calcul o declarație de conformitate privind accesibilitatea înainte să proiectați un proces în jurul componentelor lui și tratați absența ei ca pe un răspuns.

Reducerea riscului unei construcții personalizate printr-o primă felie subțire

Felul în care eșuează proiectele personalizate nu este de obicei tehnic. Este angajarea întregului buget pe o specificație scrisă înainte ca cineva să fi folosit ceva.

Alternativa este o felie subțire: un flux de lucru, cap-coadă, în producție, folosit de un om real care face muncă reală, în șase până la opt săptămâni. Nu un prototip și nu o demonstrație, ci cea mai îngustă cale prin sistem care produce un rezultat autentic, cu date reale, autentificare reală și o punere în producție reală. Dacă procesul este ofertarea, felia creează o ofertă, o calculează și o trimite.

Felia aceea face patru lucruri pe care o specificație nu le poate face. Dovedește integrările, adică exact locul unde stau surprizele. Măsoară ritmul real de livrare al echipei în loc să îl estimeze. Pune software funcțional în fața omului al cărui proces este, ceea ce schimbă de fiecare dată cerințele. Și vă dă o ieșire: ați cheltuit o sumă definită și dețineți ceva care funcționează.

Puneți apoi acolo un punct de decizie, în scris, înainte să se elibereze cheltuiala mai mare. Ghidul nostru despre cum se construiește o aplicație web tratează forma tehnică a unei prime felii, iar pagina noastră de servicii de dezvoltare software explică felul în care o delimităm.

Un cadru de decizie pe care îl parcurgeți într-o după-amiază

Nimic din toate acestea nu cere un contract de consultanță. Cere câteva ore și onestitate față de cifre.

Întâi, scrieți procesul așa cum se desfășoară cu adevărat, pe pași, inclusiv excepțiile pe care oamenii le rezolvă manual. Numai atât încheie adesea dezbaterea, fiindcă scoate la iveală că sunt trei procese și nu unul.

Al doilea, numărați posturile de azi și estimați-le pentru trei ani. Al treilea, alegeți pe listă exact trei produse și notați-le față de procesul vostru scris, nu față de listele lor de funcționalități, marcând fiecare loc în care adoptarea produsului v-ar schimba felul de a lucra și dacă acea schimbare vă costă ceva.

Al patrulea, puneți explicit un preț pe capcana de la mijloc: onorarii de implementare, middleware și fracțiunea de salariu care îl va administra. Al cincilea, aplicați testul celor două condiții din trei. Al șaselea, calculați pragul în luni pentru ambele numere de posturi. Al șaptelea, dacă răspunsul este personalizat, comandați o felie subțire în loc de un sistem.

Cine ar trebui să închidă această filă și să meargă să cumpere ceva

Unii cititori ar trebui să se oprească aici, iar a o spune pe șleau este mai util decât o concluzie echilibrată.

Dacă procesul vostru este unul obișnuit, pe care mii de firme îl duc cam la fel, cumpărați produsul. Dacă aveți sub vreo douăzeci de utilizatori și nicio prognoză care să schimbe asta, cumpărați produsul sau construiți-l pe o platformă no-code, fiindcă aritmetica pe utilizator nu se va întoarce în favoarea voastră în niciun orizont pe care îl puteți planifica. Dacă nimeni nu va prelua răspunderea software-ului după livrare, cumpărați produsul, fiindcă un sistem personalizat fără stăpân se degradează repede într-o povară.

Dacă nu vă puteți descrie procesul în scris, nu comandați încă nimic. Scrieți-l mai întâi. Multe proiecte eșuate au fost comandate pe baza unei descrieri pe care trei oameni din aceeași încăpere o înțelegeau diferit, iar asta nu se repară cu inginerie, oricâtă ar fi.

Dacă se împlinește o singură condiție din cele trei, cumpărați produsul și reveniți peste un an. Condițiile chiar se schimbă, de obicei fiindcă a crescut numărul de angajați. Iar dacă ce vă trebuie de fapt este un sit public și nu o unealtă internă, acela este alt proiect, acoperit de munca noastră de dezvoltare de site-uri web.

O a doua opinie înainte să vă angajați

Greșeala scumpă, în oricare direcție, se face înainte să existe vreo linie de cod, așa că cel mai ieftin lucru pe care îl puteți cumpăra acum este o evaluare onestă.

Mecanik construiește aplicații web operaționale pentru firme britanice, iar o mare parte din munca aceasta înseamnă să le spunem oamenilor că nu au nevoie de una. Aduceți foaia de calcul, numărul de posturi și cele trei produse pe care le-ați ales, iar echipa noastră de dezvoltare software personalizată fie va calcula o primă felie subțire, fie vă va spune ce produs să cumpărați în locul ei. Dacă aplicația se adresează clienților și nu echipei interne, porniți de la dezvoltarea de site-uri web și citiți comparația dezvoltare web personalizată față de platforme SaaS, care acoperă acea latură a întrebării.

Întrebări frecvente

Cât costă o aplicație web personalizată în Regatul Unit? O aplicație internă bine delimitată care înlocuiește o foaie de calcul și unul sau două abonamente costă de obicei între GBP 25.000 și GBP 60.000 de construit, din care o primă felie subțire ia între GBP 8.000 și GBP 15.000. Puneți în buget încă 15 până la 20 la sută din prețul construcției în fiecare an pentru găzduire, corecții și actualizări de dependențe, fiindcă pragul acela de cost nu ajunge niciodată la zero.

Este no-code o alternativă reală la dezvoltarea unei aplicații web personalizate? Da. Pentru înregistrări, formulare, vizualizări și reguli simple este adesea răspunsul corect și este mult mai rapid. Se lovește de un zid la numere mari de rânduri, la permisiuni complexe, la integritate tranzacțională, la controlul versiunilor și la automatele de stări adevărate. Este totodată tarifat pe utilizator: Retool listează planul Business la GBP 40 pentru fiecare constructor și GBP 12 pentru fiecare utilizator intern pe lună, ceea ce este ieftin la zece posturi și consistent la patru sute.

De la câți utilizatori devine construirea mai ieftină decât cumpărarea? Împărțiți prețul construcției la economia lunară, adică la costul total al produsului minus găzduirea plus o doisprezecime din bugetul anual de mentenanță. La patruzeci de utilizatori, o construcție de GBP 45.000 față de un cost lunar al produsului de GBP 2.150 se amortizează în vreo 34 de luni. La patru sute de utilizatori se amortizează în sub un an, fiindcă taxele pe utilizator cresc odată cu numărul de angajați, în timp ce costul de funcționare al unui sistem personalizat abia se mișcă.

Cine răspunde de protecția datelor dacă alegem SaaS în loc să construim? Voi. ICO definește operatorul ca entitatea care stabilește scopurile și mijloacele prelucrării, iar furnizorul vostru SaaS este aproape întotdeauna persoana împuternicită care acționează la instrucțiunile voastre. Rămâneți răspunzători pentru demonstrarea conformității, pentru conformitatea celor pe care îi împuterniciți și pentru un contract conform articolului 28(3). Cumpărarea de software mută munca de infrastructură, nu răspunderea juridică.

Se aplică regulile de accesibilitate uneltelor interne pe care nu le vede nimeni din afară? Da. Secțiunea 20 din Equality Act 2010 cere angajatorilor adaptări rezonabile, iar o unealtă care nu poate fi folosită de la tastatură pune un angajat cu dizabilități într-un dezavantaj substanțial. Intraneturile și extraneturile din sectorul public intră în plus sub reglementările de accesibilitate și trebuie să respecte WCAG 2.2 AA. Pe o platformă no-code, plafonul de accesibilitate este fixat de componentele furnizorului.