Aplicația ta făcută cu AI merge în demo. Acum prezint-o utilizatorilor reali.
Descrii o idee unui instrument AI de dezvoltare. Acesta creează ecrane, formulare, navigație și o bază de date. Faci câteva ajustări, conectezi un serviciu și dintr-odată conceptul funcționează.
Poți deschide aplicația, îți poți crea un cont, poți finaliza acțiunea principală și poți arăta rezultatul altcuiva.
E o etapă importantă.
Un demo funcțional dovedește că ideea poate deveni concretă.
Te poate ajuta să explici conceptul, să atragi interes timpuriu, să testezi cererea sau să obții susținere internă.
Următoarea fază începe când aplicația nu mai e folosită doar de persoana care a creat-o.
Utilizatorii reali nu urmează scenariul din demo.
Uită parole. Introduc informații neașteptate. Dau clic de două ori. Rămân fără conexiune. Folosesc un telefon vechi. Refuză permisiuni. Pleacă la jumătate. Revin mai târziu. Cer banii înapoi. Împart un cont. Încearcă să acceseze ceva ce nu ar trebui să vadă.
Asta nu face aplicația construită cu AI un eșec.
Înseamnă că proiectul trece de la demonstrație la produs.
Testează mai mult decât scenariul ideal
Scenariul ideal, așa-numitul happy path, e traseul perfect printr-o aplicație.
De exemplu:
- Utilizatorul își creează un cont.
- Emailul de confirmare ajunge.
- Utilizatorul se autentifică.
- Introduce informații valide.
- Plata reușește.
- Rezultatul dorit apare.
Un demo urmează de obicei acest traseu.
Un produs real trebuie să facă față alternativelor.
Ce se întâmplă când:
- Adresa de email există deja?
- Emailul de confirmare nu ajunge?
- Utilizatorul uită parola?
- Linkul de resetare a parolei a expirat?
- Utilizatorul introduce un număr de telefon invalid?
- Un câmp obligatoriu e gol?
- Un fișier încărcat e prea mare?
- Plata e refuzată?
- Utilizatorul reîncarcă pagina la jumătate?
- Aceeași acțiune e trimisă de două ori?
- Un serviciu extern e indisponibil?
- Utilizatorul rămâne fără conexiune?
- Contul e șters?
- Utilizatorul își cere datele?
Acestea nu sunt cazuri rare. Sunt părți normale din operarea unui produs.
Revizuiește rolurile și permisiunile
Multe aplicații au mai multe tipuri de utilizatori.
Pot exista:
- Clienți
- Angajați
- Manageri
- Administratori
- Furnizori
- Parteneri
- Vizitatori
Fiecare rol ar trebui să vadă și să modifice doar ce e potrivit.
Verifică dacă:
- Utilizatorii pot accesa informațiile altui utilizator
- Utilizatorii obișnuiți pot ajunge la ecranele de administrare
- Linkurile expun înregistrări care ar trebui să rămână private
- Conturile șterse rămân accesibile
- Permisiunile angajaților sunt mai largi decât e necesar
- Rolurile sunt impuse în sistemul de bază, nu doar ascunse în interfață
Un buton invizibil nu e același lucru cu o acțiune restricționată în mod sigur.
Aceasta e una dintre zonele care nu pot fi evaluate corect printr-o scanare obișnuită a site-ului public.
E nevoie de acces la proiectul în sine.
Înțelege unde ajung datele
O aplicație făcută cu AI poate conecta rapid mai multe servicii.
De exemplu:
- Autentificare
- Bază de date
- Livrare de emailuri
- Stocare de fișiere
- Plăți
- Instrumente de analiză
- Suport pentru clienți
- Automatizare
- Modele AI
- API-uri externe
Fă-ți o imagine clară despre:
- Ce servicii sunt folosite
- Ce date primește fiecare serviciu
- Unde sunt stocate datele
- Cine deține fiecare cont
- Cu ce metodă de plată e achitat fiecare
- Ce se întâmplă când se termină un plan gratuit
- Dacă datele de producție și cele de test sunt separate
- Dacă există backupuri
- Cum pot fi exportate datele
- Cum poate fi retras accesul
Proiectele devin adesea greu de întreținut când servicii importante rămân legate de conturi personale, perioade de probă temporare sau chei generate în timpul experimentelor.
Finalizarea înseamnă să transformi acele conexiuni experimentale într-o configurație operațională ușor de înțeles.
Protejează cheile de acces și informațiile private
Cheile API, parolele, datele de acces la baza de date și tokenurile private nu ar trebui să apară în cod public sau în browser.
Verifică modul în care proiectul stochează și folosește:
- Datele de acces pentru plăți
- Cheile bazei de date
- Cheile serviciului de email
- Cheile serviciilor AI
- Datele de acces administrative
- Secretele integrărilor cu terți
Verifică și dacă logurile, mesajele de eroare sau instrumentele din browser dezvăluie informații sensibile.
Nu presupune că un proiect e nesigur pentru că a fost creat cu AI.
Dar nu presupune nici că e sigur pentru că ecranul principal funcționează.
Abordarea corectă e inspecția.
Pregătește-te pentru eșecuri
Orice serviciu extern răspunde la un moment dat lent, întoarce o eroare sau devine temporar indisponibil.
O aplicație de încredere nu ar trebui să se prăbușească într-un ecran gol când se întâmplă asta.
Gândește-te la:
- Ce vede utilizatorul când o acțiune eșuează
- Dacă poate încerca din nou în siguranță
- Dacă plățile sau înregistrările duplicate sunt prevenite
- Dacă sistemul înregistrează eroarea
- Dacă e cineva notificat
- Dacă acțiunile incomplete pot fi recuperate
- Dacă echipa de suport poate înțelege ce s-a întâmplat
Mesajele de eroare utile ar trebui să îl ajute pe utilizator să meargă mai departe fără să expună informații tehnice sau sensibile.
Echipa proiectului ar trebui să aibă și ea destule informații ca să diagnosticheze problema.
Separă mediile de test și de producție
În timpul dezvoltării e normal să experimentezi.
Poți crea utilizatori de probă, tranzacții de test, înregistrări temporare și funcții neterminate.
Înainte să inviți utilizatori reali, stabilește dacă proiectul are nevoie de medii separate pentru:
- Dezvoltare
- Testare
- Mediu de testare
- Producție
Cel puțin, datele reale ale clienților și plățile reale nu ar trebui amestecate la întâmplare cu experimentele în curs.
Publicarea modificărilor ar trebui să fie și ea repetabilă.
O schimbare mică nu ar trebui să depindă de memorarea unei secvențe fragile de pași manuali.
Decide cine o va întreține
Lansarea aplicației nu e sfârșitul dezvoltării.
După lansare, cineva va trebui să se ocupe de:
- Actualizări de software
- Schimbări ale serviciilor
- Integrări care eșuează
- Alerte de securitate
- Suport pentru utilizatori
- Corecturi de date
- Performanță
- Backupuri
- Probleme cu dispozitive sau browsere noi
- Creșteri de costuri
- Cereri de funcționalități noi
Proiectul nu ar trebui să depindă în întregime de istoricul unei conversații dintr-un singur instrument AI.
Asigură-te că firma are acces la:
- Cod
- Contul platformei de creare
- Găzduire
- Setările domeniului
- Baza de date
- Serviciile terților
- Documentație
- Datele de acces
- Conturile de facturare
Deținerea și mentenabilitatea fac parte din finalizare.
Începe cu o analiză structurată
Un SiteScan public poate fi în continuare util când aplicația are o interfață publică semnificativă.
Poate ajuta la evaluarea:
- Utilizabilității pe mobil
- Accesibilității
- Performanței
- Conținutului public
- Formularelor
- Încrederii
- Îndemnurilor la acțiune
Nu poate stabili dacă autentificarea, permisiunile, bazele de date, integrările, datele private sau publicarea sunt configurate corect.
Din acest motiv, o aplicație sau o platformă va avea de obicei nevoie de o Analiză de finalizare a proiectului AI.
Obiectivul nu e să cauți motive să reconstruiești totul.
Analiza ar trebui să stabilească:
- Ce poate rămâne
- Ce are nevoie de îmbunătățiri
- Ce trebuie corectat înainte să vină utilizatorii reali
- Ce poate aștepta în siguranță
- Ce ar trebui să includă următoarea fază de dezvoltare
Rezultatul ar trebui să fie un plan practic de finalizare.
Ai dovedit deja că ideea poate funcționa.
Acum proiectul trebuie să dovedească că poate continua să funcționeze când vin utilizatorii reali.