TAGASI
Arusaamatused ja arusaamatus tarkvaraarendusprojekti raames loodavast tootest on väga levinud probleemid kliendi ja protsessi eest vastutava meeskonna koostöös. Need ohud mõjutavad otseselt saavutatud tulemusi ja on sageli seotud tähtaegadest mahajäämise ja eelarvekadudega. Vaadake, kus need ohud võivad ilmneda ja kuidas nendega võidelda.
pildi allikas: perfectdigital.com
Ma arvan, et see näitab väga hästi, et suured lahknevused ja visioonipuudus võivad ilmneda tarkvaraarendusprojektid kõigi osalejate ja kaasatud inimeste vahel. Probleemid tekivad sageli juba alguses, kui klient tuleb (teoreetiliselt) lõpliku toode nägemus ja esitab selle meeskond. Siis tulevad edasised arusaamatused, vääritõlgendused ja lõpuks ka projekt läheb kiiresti valele arenguteele.
Analüüsides ülaltoodud graafikut, esitan ma samm-sammult kõik võimalikud ohud ja pakun välja, kuidas nendega võidelda. Läheme kohe asja juurde!
Toote visioonis on algusest peale lahknevusi. Miks? Põhjus on väga lihtne - igaüks tõlgendab tegelikkust omal moel, tal on mingi ettekujutus peas ja ta ei pruugi seda nägemust teisele osapoolele täpselt esitada. Kui te kirjeldate sõnadega toodet, mida soovite ehitada, on suur tõenäosus, et arendusmeeskond mõistab teie visiooni teisiti, kui te seda silmas pidasite.
Loomulikult on võimalik seda vältida. Tuleks võimalikult kiiresti alustada visualiseerimisega ja arutada toote funktsionaalsuse üksikuid elemente visandite põhjal. Huvitaval kombel ei ole esimestel visanditel tavaliselt midagi ühist lõpptootega. Selles etapis on aga kõige tähtsam visiooni sidusaks muutmine.
Huvitav, miks esimene ja teine pilt nii erinevad? Projektijuht vaatab alati toote visiooni lähemalt. Siiski, on oluline, et selline isik, kes vastutab sisuliselt kogu tarkvaraarendus protsess, mõistab täielikult probleemi ja tootega seotud vajadusi.. Projektijuhil peab olema selge "suurem pilt". Nagu näete, ei erine mõlemad pildid funktsionaalsuse poolest. Nad lihtsalt näevad erinevad välja. Selle punkti paremaks mõistmiseks pöördume tagasi pildi number üks juurde. Projekti alguses puudusid visandid ja juba see viis arusaamatuseni. Toote funktsionaalsus on õige, kuid disain on täiesti erinev.
Mõnikord ei tea analüütikud ja arendajad kasutajate vajadusi ega püstitatud ärilisi eesmärke. Nad näevad ainult väikest osa kogu projektist, mis haarab nende põhitähelepanu. Nad ei ole võimelised vaatama laiemalt ja see kehtib eriti suurte projektide puhul, kus töötab korraga palju arendajaid.
Võime kasutada ka teist näidet. Võib juhtuda, et lahendatav probleem on näiteks tooteomaniku poolt valesti kirjeldatud. See tähendab, et esitatakse ebatäielik teave, mille põhjal arendaja või disainer loob oma tõlgendusi ja toode kaldub üha enam kõrvale kavandatud arenguteest.
Kuidas seda muuta? Ma arvan, et hea lahendus on tagada, et inimesed, kes on projekti võtmeisikud, teavad sellest üksikasjalikult - nn "suuremast pildist". Arusaamatuste korral on neil lihtsam tuua arusaamatusi tarkvara arendusprotsess tagasi õigele teele. Seepärast pidage meeles - kui igaüks näeb ainult oma pisikest killukest väljatöötatud funktsionaalsusest, siis muutuvad arusaamatused visioonis tõenäoliseks ohuks.
Siin on asi lihtne. Toode peab müüma. Te peate kuidagi silma paistma, nii et näiteks lihtne kiik oma aeda saavutab erakordsed elemendid. Mõte on veenda potentsiaalset ostjat. Turundus- ja müügiosakond teeb kindlasti kõik selleks, et näidata, et toode on ainulaadne.
Puuduv dokumentatsioon on väga levinud probleem. Mõnikord on dokumentatsiooni loomine ajal tootearendus tundub asjatu ajaraiskamine. See on viga. Ma ütlen väga sageli, et muudatused tehakse paberil kiiremini kui kood, ja selles on midagi. Lisaks on lihtsam viidata dokumentatsioonile, et jälgida muudatusi. Uskuge mind, dokumentatsioonita projektil on väga suur oht, et visioon jääb saamata.
See etapp viitab keskkonna paigutamisele serverisse. Nagu programmeerijate ja analüütikute puhul, võib ilma täielike andmeteta ja kommunikatsioonilünkadega selguda, et vajalikust keskkonnast on loodud vaid osa.
See on tingitud kehvast kommunikatsioonist, UX-i puudumisest ja nii edasi. Vigade ilmnemine suurendab arendusaega. Ja aeg on ju raha? Minu soovitus on juhtida projekti vastavalt Agile'ile, säilitada kõrgeimad kommunikatsioonistandardid ja järgida selgeid eelarvelisi suuniseid. Ma ei kahtle, et nii tehes väldite selliseid probleeme.
Kliendid keskenduvad sageli ainult toote valmistamisele ja lõpetavad selle. Kuid me elame paljude muutuste ja tehnoloogiliste uuenduste ajal, mistõttu on vaja säilitada pidev tehniline tugi. Eesmärk on vältida olukorda, kus midagi äkki enam ei tööta, kuna see vananeb ja toode kaotab oma väärtuse. Ka seda aspekti ei tohiks unustada.
Oleme jõudnud viimasesse punkti. Vaadake lahknevust esimese ja viimase graafiku vahel. Lõppude lõpuks on mõlemad seotud kliendi vaatenurgaga. Miks see nii on? Kõik valetavad seda nii lihtsalt 🙂 Uuringu tulemused erinevad alati teie vastajate tegelikest vajadustest. Uurijate küsimusele vastates tahavad kasutajad näidata oma parimat külge. Seetõttu, NAD EI VASTA SAGELI TÕESELT, vaid pigem nii, nagu nad arvavad, et nad peaksid vastama. Põhimõtteliselt ei taha nad puutuda kokku teiste negatiivse hinnanguga. Siin on teile väike vihje - mainige juhendis, et ei ole olemas ei häid ega halbu vastuseid.
Kus ilmnevad veel erinevused? Inimesed ei tea sageli, mida nad tegelikult tahavad. Sageli ütlevad kasutajad algselt, et nad vajavad tootes 10 funktsiooni, kuid hiljem kasutavad nad tegelikult ainult näiteks 3.
Kuidas siis seda probleemi lahendada? Lisaks sellele, et küsite kasutajatelt, mida nad tahavad ja vajavad, lubage neil toodet testida, eelistatavalt autentsete esemetega, et säilitada usaldusväärsust. Mida rohkem teste toodete loomise ajal, seda suurem on tõenäosus, et tulemus on täpne.
Kui te kunagi saate liikmeks tarkvaraarendus projekti, pidage meeles minu näiteid ja tehke järeldusi, et mitte kopeerida ülaltoodud vigu. Ja pidage meeles, et need mõisted on väga olulised toote (rakenduse) loomisel nullist:
- hea UX ja testid, et saaksite teada, mida teie kasutajad tegelikult vajavad,
- projektisisene suhtlus, nii et projekti võtmeisikutel oleks võimalik probleemi ja vajaduste põhjalik mõistmine,
- arendada toodet vastavalt Agiilne,
- ärge unustage tehnilist tuge.
Loe edasi:
– Kuidas tõhusalt juhtida kaugarendajaid? Juhend CTO-le
– Python vs. Ruby? Millist tehnoloogiat peaksite tootearenduses kasutama?
– Kiire juhend oma turu loomiseks ja arendamiseks. Mida tasub teada?
Estonian 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch 
Greek