Bjauri tiesa apie programinės įrangos kūrimo procesą

paveikslėlio šaltinis: perfectdigital.com

Juk žinote šią nuotrauką, tiesa?

Manau, tai labai gerai parodo, kad dideli neatitikimai ir vizijos trūkumas gali atsirasti programinės įrangos kūrimas projektai tarp visų dalyvių ir susijusių asmenų. Problemų dažnai kyla nuo pat pradžių, kai klientas ateina su (teoriškai) galutiniu produktas viziją ir pateikia ją komanda. Tuomet kyla dar daugiau nesusipratimų, neteisingų interpretacijų ir galiausiai projektas greitai nueina klaidingu vystymosi keliu.

Analizuodamas pirmiau pateiktą diagramą, žingsnis po žingsnio pateiksiu visas galimas grėsmes ir pasiūlysiu, kaip su jomis kovoti. Pereikime prie to!

1. Kaip klientas paaiškino idėją?

Bus neatitikimų produkto vizija nuo pat pradžių. Kodėl? Priežastis labai paprasta - kiekvienas savaip interpretuoja tikrovę, mintyse turi kažkokią idėją ir gali netiksliai pateikti šią viziją kitai pusei. Jei žodžiais apibūdinate gaminį, kurį norėtumėte sukurti, didelė tikimybė, kad kūrimo komanda supras jūsų viziją kitaip, nei norėjote.

Žinoma, to galima išvengti. Turėtumėte kuo greičiau pradėti vizualizuoti ir aptarti atskirus gaminio funkcionalumo elementus remdamiesi eskizais. Įdomu tai, kad pirmieji eskizai paprastai neturi nieko bendro su galutiniu produktu. Tačiau šiame etape svarbiausia, kad vizija būtų nuosekli.

2. Kaip tai suprato projekto vadovas?

Įdomu, kodėl pirmoji ir antroji nuotrauka taip skiriasi? Projekto vadovas visada atidžiau pažvelgs į gaminio viziją. Tačiau, svarbu, kad toks asmuo, iš esmės atsakingas už visą programinė įranga kūrimo procesas, visiškai supranta su produktu susijusią problemą ir poreikius.. Projekto vadovas turi turėti aiškų “platesnį vaizdą”. Kaip matote, abu paveikslai nesiskiria funkcionalumu. Jie tiesiog atrodo skirtingai. Kad geriau suprastume šį punktą, grįžkime prie paveikslėlio Nr. 1. Projekto pradžioje nebuvo jokių eskizų, o tai jau sukėlė nesusipratimų. Gaminio funkcionalumas teisingas, tačiau dizainas visiškai kitoks.

3. Kaip analitikas jį sukūrė? ir 4. Kaip programuotojas jį parašė?

Kartais analitikai ir kūrėjai nežino naudotojų poreikių ar nustatytų verslo tikslų. Jie mato tik nedidelę viso projekto dalį, kuri užfiksuoja jų pagrindinį dėmesį. Jie nesugeba pažvelgti iš platesnės perspektyvos, o tai ypač būdinga dideliems projektams, kuriuose vienu metu dirba daug programuotojų.

Galime pasitelkti ir kitą pavyzdį. Gali atsitikti taip, kad sprendžiamą problemą neteisingai apibūdina, pavyzdžiui, produkto savininkas. Tai reiškia, kad pateikiama neišsami informacija, kuria remiantis kūrėjas arba dizaineris sukuria savo interpretacijas, o produktas vis labiau nukrypsta nuo numatyto kūrimo kelio.

Kaip tai pakeisti? Manau, kad geras sprendimas - užtikrinti, kad žmonės, kurie yra svarbiausi projekto vykdytojai, turėtų išsamių žinių apie projektą - vadinamąjį “platesnį vaizdą”. Kilus nesusipratimams, jiems bus lengviau pateikti programinės įrangos kūrimo procesas grįžti į teisingą kelią. Todėl nepamirškite - jei kiekvienas mato tik savo mažytį sukurto funkcionalumo fragmentą, nesusipratimai vizijoje tampa tikėtina grėsme.

5. Kaip jį apibūdino verslo konsultantas?

Čia viskas paprasta. Produktas turi būti parduodamas. Turite kažkuo išsiskirti, kad, pavyzdžiui, paprastos sūpynės jūsų sodui įgytų nepaprastų elementų. Esmė - įtikinti potencialų pirkėją. Rinkodaros ir pardavimo skyrius tikrai padarys viską, kad parodytų, jog gaminys yra unikalus.

6. Kaip projektas buvo dokumentuojamas?

Dokumentų trūkumas yra labai dažna problema. Kartais, kuriant dokumentaciją per produktų kūrimas atrodo nereikalingas laiko švaistymas. Tai klaida. Labai dažnai sakau, kad pakeitimai popieriuje atliekami greičiau nei kodas, ir tai yra kažkas tokio. Be to, lengviau atsiremti į dokumentaciją ir sekti bet kokius pakeitimus. Patikėkite manimi, projektui be dokumentacijos kyla labai didelė rizika prarasti viziją.

7. Kokios operacijos buvo įdiegtos?

Šiame etape aplinka patalpinama į serverį. Kaip ir punkte apie programuotojus ir analitikus, be visiško duomenys ir esant bendravimo spragoms, gali paaiškėti, kad sukurta tik dalis reikiamos aplinkos.

8. Kaip klientui buvo išrašyta sąskaita?

Tai blogo bendravimo, nepakankamo UX ir t. t. Klaidų atsiradimas pailgina kūrimo laiką. O laikas yra pinigai, tiesa? Mano užuomina - vykdyti projektą pagal "Agile, išlaikyti aukščiausius bendravimo standartus ir laikytis aiškių biudžeto gairių. Neabejoju, kad taip elgdamiesi išvengsite tokių problemų.

9. Kaip ji buvo remiama?

Klientai dažnai sutelkia dėmesį tik į produkto sukūrimą ir tuo baigia. Tačiau gyvename daugybės pokyčių ir technologinių naujovių laikais, todėl būtina nuolat teikti techninę pagalbą. Siekiama išvengti situacijos, kai kažkas staiga nustoja veikti, nes pasensta, o gaminys praranda savo vertę. Šio aspekto taip pat nereikėtų pamiršti.

10. Ko iš tikrųjų reikėjo klientui?

Pasiekėme paskutinį tašką. Pažvelkite į neatitikimą tarp pirmosios ir paskutiniosios diagramos. Juk abi jos susijusios su kliento požiūriu. Kodėl taip atsitiko? Visi meluoja, kad viskas taip paprasta 🙂 Apklausų rezultatai visada skiriasi nuo tikrųjų jūsų respondentų poreikių. Atsakydami į tyrėjo klausimą, naudotojai nori parodyti savo geriausią pusę. Todėl, JIE DAŽNAI NEATSAKO TEISINGAI., bet veikiau taip, kaip, jų manymu, jie turėtų atsakyti. Iš esmės jie nenori susidurti su neigiamu kitų vertinimu. Štai jums nedidelė užuomina - instrukcijose paminėkite, kad nėra nei gerų, nei blogų atsakymų.

Kur dar atsiranda skirtumų? Žmonės dažnai nežino, ko iš tikrųjų nori. Neretai vartotojai iš pradžių sako, kad jiems reikia 10 produkto funkcijų, o vėliau iš tikrųjų naudoja tik, tarkime, 3.

Kaip išspręsti šią problemą? Paklauskite naudotojų, ko jie nori ir ko jiems reikia, ir leiskite jiems išbandyti gaminį, pageidautina - autentiškus daiktus, kad išlaikytumėte patikimumą. Kuo daugiau bandymų atliekant produktų kūrimą, tuo didesnė tikimybė, kad rezultatas bus tikslus.

Santrauka

Jei kada nors tapsite programinės įrangos kūrimas projektą, prisiminkite mano pavyzdžius ir padarykite išvadas, kad nekopijuotumėte minėtų klaidų. Ir nepamirškite, kad šios sąvokos yra labai svarbios kuriant produktą (programą) nuo nulio:

- gerą UX ir testus, kad sužinotumėte, ko iš tikrųjų reikia jūsų naudotojams,

- bendravimą projekto viduje, kad pagrindiniai projekto dalyviai gerai suprastų problemą ir poreikius,

- kurti produktą pagal Agile,

- nepamirškite apie techninę pagalbą.

Skaityti daugiau:

- Kaip veiksmingai valdyti nuotolinius kūrėjus? CTO vadovas

- Python vs. Ruby? Kurią technologiją turėtumėte naudoti produktui kurti?

- Trumpas vadovas, kaip sukurti ir plėtoti savo rinką. Ką verta žinoti?