![\"Swing](\"\/app\/uploads\/2024\/05\/swing-software.jpg\")
<\/p>\n<\/p>\n
pildi allikas: perfectdigital.com<\/em><\/p>\n Ma arvan, et see n\u00e4itab v\u00e4ga h\u00e4sti, et suured lahknevused ja visioonipuudus v\u00f5ivad ilmneda tarkvaraarendus<\/a> projektid k\u00f5igi osalejate ja kaasatud inimeste vahel.<\/strong> Probleemid tekivad sageli juba alguses, kui klient tuleb (teoreetiliselt) l\u00f5pliku toode<\/a> n\u00e4gemus ja esitab selle meeskond<\/a>. Siis tulevad edasised arusaamatused, v\u00e4\u00e4rit\u00f5lgendused ja l\u00f5puks ka projekt<\/a> l\u00e4heb kiiresti valele arenguteele.<\/p>\n Anal\u00fc\u00fcsides \u00fclaltoodud graafikut, esitan ma samm-sammult k\u00f5ik v\u00f5imalikud ohud ja pakun v\u00e4lja, kuidas nendega v\u00f5idelda. L\u00e4heme kohe asja juurde!<\/p>\n Erinevusi esineb toote visioon<\/a> algusest peale. Miks? P\u00f5hjus on v\u00e4ga lihtne - iga\u00fcks t\u00f5lgendab tegelikkust omal moel, tal on mingi ettekujutus peas ja ta ei pruugi seda n\u00e4gemust teisele osapoolele t\u00e4pselt esitada. Kui te kirjeldate s\u00f5nadega toodet, mida te tahaksite ehitada, on suur t\u00f5en\u00e4osus, et arendusmeeskond<\/a> m\u00f5istab teie n\u00e4gemust teisiti, kui te kavatsesite.<\/p>\n Loomulikult on v\u00f5imalik seda v\u00e4ltida. Tuleks v\u00f5imalikult kiiresti alustada visualiseerimisega ja arutada toote funktsionaalsuse \u00fcksikuid elemente visandite p\u00f5hjal. Huvitaval kombel ei ole esimestel visanditel tavaliselt midagi \u00fchist l\u00f5pptootega. Selles etapis on aga k\u00f5ige t\u00e4htsam visiooni sidusaks muutmine.<\/p>\n Huvitav, miks esimene ja teine pilt nii erinevad? Projektijuht vaatab alati toote visiooni l\u00e4hemalt. Siiski, on oluline, et selline isik, kes vastutab sisuliselt kogu<\/strong> tarkvara arendusprotsess<\/a><\/strong>, m\u00f5istab t\u00e4ielikult probleemi ja tootega seotud vajadusi.<\/strong>. Projektijuhil peab olema selge \"suurem pilt\". Nagu n\u00e4ete, ei erine m\u00f5lemad pildid funktsionaalsuse poolest. Nad lihtsalt n\u00e4evad erinevad v\u00e4lja. Selle punkti paremaks m\u00f5istmiseks p\u00f6\u00f6rdume tagasi pildi number \u00fcks juurde. Projekti alguses puudusid visandid ja juba see viis arusaamatuseni. Toote funktsionaalsus on \u00f5ige, kuid disain on t\u00e4iesti erinev.<\/p>\n M\u00f5nikord ei tea anal\u00fc\u00fctikud ja arendajad kasutajate vajadusi ega p\u00fcstitatud \u00e4rilisi eesm\u00e4rke. Nad n\u00e4evad ainult v\u00e4ikest osa kogu projektist, mis haarab nende p\u00f5hit\u00e4helepanu. Nad ei ole v\u00f5imelised vaatama laiemalt ja see kehtib eriti suurte projektide puhul, kus t\u00f6\u00f6tab korraga palju arendajaid.<\/p>\n V\u00f5ime kasutada ka teist n\u00e4idet. V\u00f5ib juhtuda, et lahendatav probleem on n\u00e4iteks toote omaniku poolt valesti kirjeldatud. See t\u00e4hendab, et esitatakse ebat\u00e4ielik teave, mille p\u00f5hjal arendaja<\/a> v\u00f5i disainer loovad oma t\u00f5lgendusi ja toode kaldub \u00fcha enam k\u00f5rvale kavandatud arenguteest.<\/p>\n Kuidas seda muuta? Ma arvan, et hea lahendus on tagada, et inimesed, kes on projekti v\u00f5tmeisikud, teavad sellest \u00fcksikasjalikult - nn \"suuremast pildist\". Arusaamatuste korral on neil lihtsam tuua arusaamatusi tarkvara arendusprotsess<\/em> tagasi \u00f5igele teele. Seep\u00e4rast pidage meeles - kui iga\u00fcks n\u00e4eb ainult oma pisikest killukest v\u00e4ljat\u00f6\u00f6tatud funktsionaalsusest, siis muutuvad arusaamatused visioonis t\u00f5en\u00e4oliseks ohuks.<\/p>\n Siin on asi lihtne. Toode peab m\u00fc\u00fcma. Te peate kuidagi silma paistma, nii et n\u00e4iteks lihtne kiik oma aeda saavutab erakordsed elemendid. M\u00f5te on veenda potentsiaalset ostjat. Turundus- ja m\u00fc\u00fcgiosakond teeb kindlasti k\u00f5ik selleks, et n\u00e4idata, et toode on ainulaadne.<\/p>\n Puuduv dokumentatsioon on v\u00e4ga levinud probleem. M\u00f5nikord on dokumentatsiooni loomine ajal tootearendus<\/a> tundub asjatu ajaraiskamine. See on viga. Ma \u00fctlen v\u00e4ga sageli, et muudatused tehakse paberil kiiremini kui kood<\/a>, ja selles on midagi. Lisaks on lihtsam viidata dokumentatsioonile, et j\u00e4lgida muudatusi. Uskuge mind, dokumentatsioonita projektil on v\u00e4ga suur oht, et visioon j\u00e4\u00e4b saamata.<\/p>\n See etapp viitab keskkonna paigutamisele serverisse. Nagu punktis programmeerijate ja anal\u00fc\u00fctikute kohta, ilma t\u00e4ieliku andmed<\/a> ja kommunikatsioonil\u00fcnkadega v\u00f5ib selguda, et on loodud vaid osa vajalikust keskkonnast.<\/p>\n See on halva suhtlemise, v\u00e4hese UX<\/a> ja nii edasi. Vigade ilmnemine suurendab arendusaega. Ja aeg on ju raha? Minu soovitus on juhtida projekti vastavalt Agile'ile<\/a><\/strong>, s\u00e4ilitada k\u00f5rgeimad kommunikatsioonistandardid ja j\u00e4rgida selgeid eelarvelisi suuniseid. Ma ei kahtle, et nii tehes v\u00e4ldite selliseid probleeme.<\/p>\n Kliendid keskenduvad sageli ainult toote valmistamisele ja l\u00f5petavad selle. Kuid me elame paljude muutuste ja tehnoloogiliste uuenduste ajal, mist\u00f5ttu on vaja s\u00e4ilitada pidev tehniline tugi. Eesm\u00e4rk on v\u00e4ltida olukorda, kus midagi \u00e4kki enam ei t\u00f6\u00f6ta, kuna see vananeb ja toode kaotab oma v\u00e4\u00e4rtuse. Ka seda aspekti ei tohiks unustada.<\/p>\n Oleme j\u00f5udnud viimasesse punkti. Vaadake lahknevust esimese ja viimase graafiku vahel. L\u00f5ppude l\u00f5puks on m\u00f5lemad seotud kliendi vaatenurgaga. Miks see nii on? K\u00f5ik valetavad seda nii lihtsalt \ud83d\ude42 Uuringu tulemused erinevad alati teie vastajate tegelikest vajadustest. Uurijate k\u00fcsimusele vastates tahavad kasutajad n\u00e4idata oma parimat k\u00fclge. Seet\u00f5ttu, NAD EI VASTA SAGELI T\u00d5ESELT<\/strong>, vaid pigem nii, nagu nad arvavad, et nad peaksid vastama. P\u00f5him\u00f5tteliselt ei taha nad puutuda kokku teiste negatiivse hinnanguga. Siin on teile v\u00e4ike vihje - mainige juhendis, et ei ole olemas ei h\u00e4id ega halbu vastuseid.<\/p>\n Kus ilmnevad veel erinevused? Inimesed ei tea sageli, mida nad tegelikult tahavad. Sageli \u00fctlevad kasutajad algselt, et nad vajavad tootes 10 funktsiooni, kuid hiljem kasutavad nad tegelikult ainult n\u00e4iteks 3.<\/p>\n Kuidas siis seda probleemi lahendada? Lisaks sellele, et k\u00fcsite kasutajatelt, mida nad tahavad ja vajavad, lubage neil toodet testida, eelistatavalt autentsete esemetega, et s\u00e4ilitada usaldusv\u00e4\u00e4rsust. Mida rohkem teste toodete loomise ajal, seda suurem on t\u00f5en\u00e4osus, et tulemus on t\u00e4pne.<\/p>\n Kui te kunagi saate liikmeks tarkvaraarendus<\/a> projekti, pidage meeles minu n\u00e4iteid ja tehke j\u00e4reldusi, et mitte kopeerida \u00fclaltoodud vigu. Ja pidage meeles, et need m\u00f5isted on v\u00e4ga olulised toote (rakenduse) loomisel nullist:<\/p>\n - hea UX ja testid, et saaksite teada, mida teie kasutajad tegelikult vajavad,<\/p>\n - projektisisene suhtlus, nii et projekti v\u00f5tmeisikutel oleks v\u00f5imalik probleemi ja vajaduste p\u00f5hjalik m\u00f5istmine,<\/p>\n - arendada toodet vastavalt Agiilne<\/a>,<\/p>\n - \u00e4rge unustage tehnilist tuge.<\/p>\n Loe edasi:<\/strong><\/p>\n - Kuidas t\u00f5husalt juhtida kaugarendajaid? Juhend CTO-le<\/a><\/p>\n - Python vs. Ruby? Millist tehnoloogiat peaksite tootearenduses kasutama?<\/a><\/p>\nSa tead seda pilti, eks ole?<\/h2>\n
1. Kuidas selgitas klient oma ideed?<\/strong><\/h2>\n
2. Kuidas projektijuht sellest aru sai?<\/strong><\/h2>\n
3. Kuidas anal\u00fc\u00fctik seda kujundas? ja<\/em><\/strong> 4. Kuidas programmeerija selle kirjutas?<\/strong><\/h2>\n
5. Kuidas \u00e4rikonsultant seda kirjeldas?<\/strong><\/h2>\n
6. Kuidas projekt dokumenteeriti?<\/strong><\/h2>\n
7. Millised toimingud on paigaldatud?<\/strong><\/h2>\n
8. Kuidas kliendile arve esitati?<\/strong><\/h2>\n
9. Kuidas seda toetati?<\/strong><\/h2>\n
10. Mida klient tegelikult vajas?<\/strong><\/h2>\n
Kokkuv\u00f5te<\/strong><\/h2>\n