Nepatīkamā patiesība par programmatūras izstrādes procesu

attēla avots: perfectdigital.com

Jūs taču zināt šo attēlu, vai ne?

Manuprāt, tas ļoti labi parāda, ka lielas neatbilstības un redzējuma trūkums var parādīties programmatūras izstrāde projekti starp visiem dalībniekiem un iesaistītajām personām. Problēmas bieži vien rodas jau pašā sākumā, kad klients nāk ar (teorētiski) galīgo piedāvājumu. produkts vīziju un iepazīstina ar to komanda. Pēc tam seko turpmāki pārpratumi, nepareizas interpretācijas un, visbeidzot... projekts strauji iet pa nepareizu attīstības ceļu.

Analizējot iepriekš minēto diagrammu, es soli pa solim iepazīstināšu ar visiem iespējamajiem draudiem un ieteiktu, kā ar tiem cīnīties. Pārejam uzreiz pie tā!

1. Kā klients izskaidroja ideju?

Būs neatbilstības produkta vīzija jau no paša sākuma. Kāpēc? Iemesls ir ļoti vienkāršs - katrs interpretē realitāti pēc sava prāta, prātā ir izveidojies priekšstats par kaut ko, un šis priekšstats var nebūt precīzs otrai pusei. Ja jūs vārdos aprakstāt produktu, ko vēlaties izveidot, pastāv liela varbūtība, ka otra puse ne izstrādes komanda sapratīs jūsu vīziju citādi, nekā jūs to iecerējāt.

Protams, no tā ir iespējams izvairīties. Jums vajadzētu sākt vizualizēt pēc iespējas ātrāk un apspriest atsevišķus produkta funkcionalitātes elementus, pamatojoties uz skicēm. Interesanti, ka pirmajām skicēm parasti nav nekā kopīga ar galaproduktu. Tomēr šajā posmā vissvarīgākais ir panākt, lai vīzija būtu saskaņota.

2. Kā projekta vadītājs to saprata?

Vai vēlaties uzzināt, kāpēc pirmais un otrais attēls ir tik atšķirīgi? Projekta vadītājs vienmēr tuvāk aplūkos produkta vīziju. Tomēr, ir svarīgi, lai šāda persona, kas būtībā ir atbildīga par visu programmatūra izstrādes process, pilnībā izprot ar produktu saistīto problēmu un vajadzības.. Projekta vadītājam ir jābūt skaidram “plašākam redzējumam”. Kā redzat, abi attēli neatšķiras funkcionalitātes ziņā. Tie tikai izskatās atšķirīgi. Lai labāk izprastu šo punktu, atgriezīsimies pie attēla Nr. 1. Projekta sākumā nebija skiču, un tas jau noveda pie pārpratuma. Produkta funkcionalitāte ir pareiza, bet dizains ir pilnīgi atšķirīgs.

3. Kā analītiķis to izstrādāja? un 4. Kā programmētājs to uzrakstīja?

Dažkārt analītiķi un izstrādātāji nezina lietotāju vajadzības vai noteiktos biznesa mērķus. Viņi redz tikai nelielu daļu no visa projekta, kas ietver viņu galveno uzmanību. Viņi nespēj paraudzīties no plašākas perspektīvas, un tas īpaši attiecas uz lieliem projektiem, kuros vienlaikus strādā daudz izstrādātāju.

Varam izmantot arī citu piemēru. Var gadīties, ka risināmo problēmu nepareizi aprakstījis, piemēram, produkta īpašnieks. Tas nozīmē, ka tiek sniegta nepilnīga informācija, uz kuras pamata tiek izstrādātājs vai dizainers rada savas interpretācijas, un produkts arvien vairāk novirzās no iecerētā attīstības ceļa.

Kā to mainīt? Es domāju, ka labs risinājums ir nodrošināt, lai cilvēkiem, kuriem ir galvenā nozīme projektā, būtu detalizētas zināšanas par projektu - tā sauktā “plašākā aina”. Nesaprašanās gadījumā viņiem būs vieglāk panākt, ka programmatūras izstrādes process atpakaļ uz pareizā ceļa. Tāpēc atcerieties - ja katrs redz tikai savu mazo fragmentu no izstrādātās funkcionalitātes, pārpratumi vīzijā kļūst par iespējamu apdraudējumu.

5. Kā to aprakstīja uzņēmējdarbības konsultants?

Šeit viss ir vienkārši. Produkts ir jāpārdod. Jums kaut kā jāizceļas, lai, piemēram, vienkāršas dārza šūpoles iegūtu neparastus elementus. Ideja ir pārliecināt potenciālo pircēju. Mārketinga un pārdošanas nodaļa noteikti darīs visu, lai parādītu, ka produkts ir unikāls.

6. Kā projekts tika dokumentēts?

Dokumentācijas trūkums ir ļoti izplatīta problēma. Dažreiz dokumentācijas izveide produktu izstrāde šķiet nevajadzīga laika tērēšana. Tā ir kļūda. Es ļoti bieži saku, ka izmaiņas uz papīra tiek veiktas ātrāk nekā uz papīra. kods, un tajā ir kaut kas sakāms. Turklāt ir vieglāk atsaukties uz dokumentāciju, lai izsekotu jebkurām izmaiņām. Ticiet man, projektam bez dokumentācijas ir ļoti augsts risks, ka tā vīzija netiks īstenota.

7. Kādas operācijas tika instalētas?

Šis posms attiecas uz vides ievietošanu serverī. Tāpat kā punktā par programmētājiem un analītiķiem, bez pilnīga dati un ar komunikācijas nepilnībām var izrādīties, ka ir radīta tikai daļa no nepieciešamās vides.

8. Kā klientam tika izrakstīts rēķins?

Tas ir sliktas komunikācijas, nepietiekamas izpratnes un izpratnes par UX un tā tālāk. Kļūdu parādīšanās palielina izstrādes laiku. Un laiks ir nauda, vai ne? Mans ieteikums ir vadīt projektu saskaņā ar Agile., uzturēt visaugstākos saziņas standartus un ievērot skaidras budžeta vadlīnijas. Es nešaubos, ka, šādi rīkojoties, jūs izvairīsieties no šādām problēmām.

9. Kā tas tika atbalstīts?

Klienti bieži vien koncentrējas tikai uz produkta izveidi un to pabeidz. Tomēr mēs dzīvojam daudzu pārmaiņu un tehnoloģisko inovāciju laikā, tāpēc ir nepieciešams uzturēt pastāvīgu tehnisko atbalstu. Mērķis ir izvairīties no situācijas, kad kaut kas pēkšņi pārstāj darboties, jo tas noveco un produkts zaudē savu vērtību. Nedrīkst aizmirst arī šo aspektu.

10. Kas klientam patiešām bija nepieciešams?

Mēs esam sasnieguši pēdējo punktu. Aplūkojiet neatbilstību starp pirmo un pēdējo grafiku. Galu galā abas attiecas uz klienta perspektīvu. Kāpēc tā notiek? Visi melo, ka tas ir tik vienkārši 🙂 Aptaujas rezultāti vienmēr atšķiras no jūsu respondentu faktiskajām vajadzībām. Atbildot uz pētnieka jautājumu, lietotāji vēlas parādīt sevi no labākās puses. Tāpēc, VIŅI BIEŽI VIEN NEATBILD PATIESI., bet gan tā, kā, viņuprāt, viņiem būtu jāatbild. Būtībā viņi nevēlas tikt pakļauti citu negatīvam vērtējumam. Lūk, neliels ieteikums jums - norādījumos miniet, ka nav ne labu, ne sliktu atbilžu.

Kur vēl parādās atšķirības? Cilvēki bieži vien nezina, ko viņi patiešām vēlas. Nereti lietotāji sākotnēji apgalvo, ka produktā ir nepieciešamas 10 funkcijas, bet vēlāk viņi patiesībā izmanto, piemēram, tikai 3.

Kā atrisināt šo problēmu? Papildus tam, ka jautājiet lietotājiem, ko viņi vēlas un ko viņiem vajag, ļaujiet viņiem izmēģināt produktu, vēlams, uz autentiskiem priekšmetiem, lai saglabātu uzticamību. Jo vairāk testu produktu izveides laikā, jo lielāka iespēja, ka rezultāts būs precīzs.

Kopsavilkums

Ja jūs kādreiz kļūsiet par programmatūras izstrāde projektu, atcerieties manus piemērus un izdariet secinājumus, lai nekopētu iepriekš minētās kļūdas. Un atcerieties, ka šie jēdzieni ir ļoti svarīgi, veidojot produktu (lietojumprogrammu) no nulles:

- labu UX un testus, lai uzzinātu, kas lietotājiem patiešām ir nepieciešams,

- saziņa projekta ietvaros, lai galvenie projekta dalībnieki varētu padziļināti izprast problēmu un vajadzības,

- izstrādāt produktu saskaņā ar Agile,

- neaizmirstiet par tehnisko atbalstu.

Lasīt vairāk:

- Kā efektīvi vadīt attālinātos izstrādātājus? CTO rokasgrāmata

- Python vs Ruby? Kura tehnoloģija būtu jāizmanto produktu izstrādei?

- Īss ceļvedis, kā izveidot un attīstīt savu tirdzniecības vietu. Ko ir vērts zināt?