Web aplikacijos, SaaS ir MVP
Web aplikacijų kūrimas
Web aplikacija skiriasi nuo svetainės tuo, kad žmonės ne skaito turinį, o atlieka darbą: kuria įrašus, tvirtina, mato skirtingus duomenis pagal savo rolę. Todėl svarbiausi sprendimai priimami ne dėl dizaino, o dėl to, kas ką gali matyti ir keisti, kaip skaičiuojamas naudojimas ir kas atsitinka, kai duomenų kiekis išauga. Pradedame nuo mažiausios prasmingos versijos, kurią jau galima naudoti realiai, ir tik tada plečiame.
Aptarti produkto idėjąTrumpai: ko reikia pirmajai versijai
Pirmajai naudojamai versijai reikia trijų dalykų: vieno konkretaus scenarijaus, kurį produktas atlieka nuo pradžios iki galo, rolių sąrašo su aiškiomis ribomis, ir sprendimo, kokie duomenys yra šaltinis. Viskas kita — pranešimai, ataskaitos, papildomos integracijos — gali atsirasti vėliau nesulaužant pagrindo. Dažniausia klaida yra vienu metu kurti daug funkcijų, kurių niekas dar nenaudoja, todėl neaišku, kuri iš jų tikrai reikalinga.
Kada web aplikacija yra tinkamas pasirinkimas
- Tą patį darbą atlieka keli žmonės ir jiems reikia matyti skirtingus duomenis pagal atsakomybę, o ne bendrą lentelę.
- Procesas turi būklę: užklausa keliauja per etapus, kažkas ją tvirtina, reikia istorijos, kas ir kada pakeitė.
- Duomenys turi būti prieinami iš skirtingų vietų ir įrenginių be failų siuntinėjimo ir versijų painiavos.
- Produktą planuojate teikti klientams kaip paslaugą, todėl reikia atskirtų paskyrų, prieigos ribų ir naudojimo apskaitos.
Kada pakanka paprastesnio sprendimo
- Vienas žmogus tvarko nedidelį duomenų kiekį – skaičiuoklė su tvarkinga struktūra dažnai yra greitesnis ir pigesnis sprendimas.
- Reikia tik registracijos ar užklausos formos be tolesnio darbo su duomenimis – tam pakanka svetainės su forma.
- Egzistuoja standartinė sistema, atitinkanti procesą be didelių išimčių – tada pigiau ją sukonfigūruoti nei kurti savo.
Rolės, duomenys ir ribos
Rolės yra pirmasis techninis sprendimas, nes nuo jų priklauso duomenų struktūra ir saugumas. Žemiau pateiktas pavyzdys rodo, kaip skiriasi matomi duomenys ir leidžiami veiksmai skirtingiems produkto naudotojams. Tai iliustracinė struktūra, padedanti pasiruošti pokalbiui, o ne konkretaus kliento produkto aprašymas.
| Rolė | Ką mato | Ką gali daryti ir ribos |
|---|---|---|
| Paskyros savininkas | Visus savo organizacijos duomenis, naudojimo apskaitą ir sąskaitas. | Kviečia naudotojus, keičia planą, mato apmokestinimą. Negali matyti kitų organizacijų duomenų. |
| Komandos narys | Tik tuos įrašus ir projektus, prie kurių priskirtas. | Kuria ir redaguoja savo darbo įrašus. Negali keisti plano, sąskaitų ar prieigos teisių. |
| Kliento naudotojas | Savo užklausų būklę, istoriją ir dokumentus, susijusius tik su juo. | Pateikia užklausas ir komentuoja. Nemato vidinių pastabų ir kitų klientų duomenų. |
| Išorinis partneris | Tik pakviestus projektus ir informaciją, reikalingą jo darbui. | Atlieka priskirtas užduotis su terminuota prieiga. Nemato sąskaitų ir kitų projektų. |
| Administratorius | Sistemos veikimo įrašus, prieigos pakeitimų istoriją ir klaidas. | Valdo roles ir atkuria duomenis. Veiksmai lieka audito įrašuose ir nėra anonimiški. |
Kaip vyksta darbas
- 01
Scenarijaus patikslinimas
Išsirenkame vieną scenarijų, kuris duoda naudą jau pirmąją naudojimo dieną, ir aprašome jį žingsniais su rolėmis. Tai leidžia atmesti funkcijas, kurios skamba naudingai, bet neturi realaus naudotojo.
- 02
Duomenų struktūra ir prieigos
Suplanuojame duomenų modelį, rolių ribas ir tai, kaip atskiriamos skirtingų klientų paskyros. Šis etapas nustato, ką vėliau bus lengva pakeisti ir ką pakeisti bus brangu.
- 03
Pirmoji naudojama versija
Sukuriame veikiančią versiją su realiais duomenimis ir keliais naudotojais. Tikslas — ne demonstracija, o galimybė atlikti tikrą darbą ir pamatyti, kur procesas stringa.
- 04
Plėtimas ir perdavimas
Pagal naudojimą pridedame integracijas, ataskaitas ir apmokestinimą. Perduodame kodą, aplinkas ir dokumentaciją taip, kad produktą galėtų tęsti ir kita komanda.
Kas lemia kainą ir trukmę
- Rolių skaičius ir kiek skiriasi jų matomi duomenys bei leidžiami veiksmai.
- Ar reikia atskirtų klientų paskyrų ir naudojimo apskaitos, ar pakanka vienos organizacijos.
- Integracijos su išorinėmis sistemomis: jų dokumentacijos kokybė ir klaidų apdorojimas.
- Apmokestinimo logika: planai, limitai, keitimas viduryje periodo ir grąžinimai.
- Duomenų perkėlimas iš esamų failų ar sistemų ir jų kokybės patikra.
Ką verta apsvarstyti prieš pokalbį
- 01Kokį vieną darbą produktas turi atlikti nuo pradžios iki galo pirmojoje versijoje?
- 02Kas bus naudotojai ir kokie duomenys vienam iš jų turi būti nematomi?
- 03Kur šiandien laikomi duomenys ir ar juos reikės perkelti?
- 04Su kokiomis sistemomis produktas turės apsikeisti duomenimis?
- 05Ar produktą naudos tik jūsų komanda, ar ir klientai kaip atskiros paskyros?
Aptarkime pirmąją versiją
Pakanka aprašyti vieną procesą, dalyvius ir pagrindinę problemą. Nesiųskite prisijungimų ar tikrų klientų duomenų — anonimizuotas pavyzdys yra tinkamas pradinis taškas.