Milline on sinu prototüüp?

"Kui detailne ja millise tehnoloogiaga prototüüp luua," paistab olevat iga prototüüpimist sisaldava projekti kindel arutelupunkt.

Kui täna sattusin lugema sellesisulist postitust ühes e-maili listis, tekkis vastupandamatu soov seda teemat ka meie blogis kajastada...

Üldiselt olen selgeks saanud paar tõde, millest prototüübi detailsusastme ja tehnoloogia valiku osas tuleks lähtuda:

1. Kui hakkad tehnoloogiat või prototüüpimise vahendit valima, tee kindlaks, kui selge on algne ülesandepüstitus.

Kodeerimiskeeled on head prototüüpimise vahendid, kui ülesandepüstitus on väga selgelt mõistetav. Peamiselt seepärast, et ümbertegemist kipub üheselt mõistetaval ülesandepüstitusel vähem olema.

Samas on koodi-kirjutamisel olemas eeliseid tõepärasuse ja hilisema uuestikasutamise osas. Seeläbi on võimalik ka uue tehnoloogia piiranguid ja võimalusi kompida ning väheneb kindlasti arendusaeg, kuna osa koodi on juba olemas :). Selliste vähe muutuvate projektide puhul kaalub vahest kasu suurema prototüüpimise vaeva.

2. Kirjutades prototüüpi läbi koodi (HTML, CSS, PHP, Java vidinad), läheb ühe vormi kohta prototüübi loomine mitu korda kallimaks ka ilma suuremate parandusvajadusteta.

Sest:

• prototüüpija (tihti sina ise) peab valdama vastavat keelt, targemad inimesed on kallimad;
• prototüüp tehakse üledetailne, kuna kavatsed koodi kasutada valmistoote juures;
• korduvat kasutamist prototüübi koodi osas kunagi 100% ei juhtu, pigem jääb see umbes 10% piiresse.

3. Tehniliselt võimekat prototüüpimise mudelit eelistavad peamiselt tehnilised inimesed nagu arhitektid ja programmeerijad, kellele on täiesti vastuvõetamatu mõte midagi ära visata või uuesti teha.

Eelistus on emotsionaalne ja kujundatud vastavalt "usule". Emotsioonidega emotsioonide vastu ei saa. Kaine põhjendus on võimalus, kui suudad selgeks teha kaks nüanssi:

• miks prototüüpi loov arendaja ei saa end arendada uue ja huvitava tehnoloogiaga;
• miks keegi peab tegema uuesti selle töö, mis juba korra tehtud sai.

4. Kui kliendilt küsida, kas odavam ja äravisatav või kallim ja jääv töö, valib 90% klientidest kallima osa.

Ei ole eriti meeldiv mõte, et maksad surnud hobust, isegi kui see on väga odav. Pehme tulem nagu testitud idee ja lahendus ei ole paljude inimeste silmis mõõdetav. Kui suudad selgitada konkreetse kasu saamise mudelit, ei tundugi hobune enam nii surnud olevat.

5. Prototüübi elumõte on palju ja odavalt muutuda. Seda selleks, et kui hakkame tegema kallist tööd, oleks hea lahendus juba teada ja me ei pea selleks kallist tööaega kulutama.

Mustand-mustand-mustand. Muidu võiks ju kohe päris süsteemi luua, miks kulutada aega mingile prototüübile.

6. Inimesed ei suuda iial suuri süsteeme ühe tervikuna hallata. Seega ei saa kunagi valmis väga hea süsteemi prototüüp kohe esimese korraga. See punkt ei kehti siis, kui tegemist on lihtsa navigatsiooniga väikese kuni 25-lehelise süsteemiga ning peamiselt paari kasutatava funktsiooniga (artikli-vaade, otsimine).

Keerukad süsteemid tekivad järk-järgult täienedes ja muutudes läbi katsetamise. Mõtle näiteks evolutsiooni peale...

7. Juhtkonnale ei soovita kunagi näidata ilma disainielementideta prototüüpi ja tihti juhtkond ei oska seda ka hinnata. See on üks põhjus, miks tehakse kallim prototüüp tellija juures, kus IT-projektid on harvemad külalised.

See ei kehti kui juhtkond on üheks hindavaks osapooleks - sellisel juhul on ka neil võetud aega süveneda sisusse. Pilte on alati kergem hinnata ja tekib selline sisetunne, mille põhjal 75% inimestest otsustab...

Kui juhtkonnale näitamine ei anna sisulist sisendinfot, tuleb mõelda kuidas ka mitte nii ilusaid prototüüpe esitleda. Lihtne kasumlikkuse arvutus juba töö planeerimise ajal aitab palju kaasa.

Prototüüp on tihti see esimene visuaalne lahendus kaua oodatud, uuest, kõiki probleeme lahendavast süsteemist... pettumus on kerge tulema, ka kõrged ootused ei teki ülipika aja peale. Ideest on asi muutunud "käega katsutavaks", kindel siht ja plaan aitab kärsitust vaos hoida.

8. Kui teed prototüübi täielikult kujunduselementideta, võib tihemini juhtuda, et süsteemi arenduse käigus on vaja teha muudatusi väljamõeldud lahendusele. Peale prototüübi faasi tehtavad muudatused on mitu korda kallimad.

Seega täiesti kujunduselementideta ei saa, kujundus aitab tihti kaasa lahenduse testimisele ja probleemid tulevad paremini välja. Samas saab teha kõike mõistlikul tasemel.

9. Kui lood täieliku visuaalse disainiga prototüübi, hinnatakse väga suurel määral kujundust ning natukene mõne funktsiooni mugavust.

Kujundust on lihtsam hinnata, see on kõigile elulisem ja igal inimesel on oma arvamus selle kohta, isegi kui ta seda põhjendada ei oska. Funktsioonide mugavus, navigatsiooniskeem ja objektide järjestus ei tekita tavaliselt emotsioone.

Seega on mõistlikum mitte nii täiuslikult silutud kujundus luua ja võimalikult palju infot juba analüüsi faasis kaudsete küsimustega kindlaks teha.

10. Kui prototüübis on üle 50 lehe ja see sisaldab täielikult lihvitud kujundust, hinnatakse ainult kujundust.

Suurte süsteemide hindamisel tuleks seda teha väiksemate osade haaval ja soovitavalt funktsiooni kaupa, sest inimesel on võimatu kõiki seoseid mõista - nende õppimine võtab palju aega.

11. Müügipersonal läheb näost valgeks, kui räägid loodavast prototüübist, mis ei näe välja visuaalselt täpselt selline, nagu päris loodav süsteem. Järgneb tunnine tuline vestlus...

Tegemist on inimestega, kes päevast-päeva seletavad, miks meie teeme paremini kui kõik teised...Ja nüüd nii selgelt tajutav puudus... Selle probleemi vältimiseks aita müügipersonalil kohe algusest peale müüa sellist lahendust, mida konkreetse projekti puhul täpselt vaja on.

12. Prototüüpe luuakse erinevatel põhjustel. Mõne põhjuse puhul on vaja täpset koopiat loodavast süsteemist, mõnel juhul on vaja mustandit. Enamustel juhtudel on vaja kombinatsiooni mõlemast.

Osad prototüübid on lihtsalt piltide kujul, teised on liikuvad (dünaamilised). Tee selgeks, kas esitatakse nõudeid või mängitakse võimalikke lahendusvariante läbi, kui palju disain mõjutab kasutajal süsteemis oma eesmärgi saavutamist. Iga vajaduse jaoks on olemas oma lahendused (prototüüpimise tööriistad, tehniline realisatsioon).

Prototüüp võib olla nii dokumenteeritud detailne ülesandepüstitus, kui ka paberile joonistatud must-valge vorm. Testida ja hinnata saab neid kõiki. Vahe on töövõtetes, tulemustes ja hinnas.

13. Ja viimane ehk kõige tähtsam punkt - ära klammerdu oma "usu" külge.

Kõige vastuvõetamatum idee võib mõnel juhul olla suisa ainus lahendus. Kasutatavuse töövõtete valimine on tegelikult see oskus mille pärast spetsialist oled just sina ja mitte keegi sinu asemel.

Naudi väljakutseid ja elu on lill :)