Den fula sanningen om mjukvaruutvecklingsprocessen

Bildkälla: perfectdigital.com

Du känner till den här bilden, eller hur?

Jag tycker att det visar mycket väl att stora avvikelser och brist på visioner kan förekomma i projekt för utveckling av programvara mellan alla deltagare och inblandade personer. Problem uppstår ofta redan i början, när kunden kommer med en (teoretiskt sett) slutgiltig Produkt vision och presenterar den för Team. Sedan kommer ytterligare missförstånd, feltolkningar och till slut projekt snabbt går in på fel utvecklingsväg.

När jag analyserar grafen ovan kommer jag steg för steg att presentera alla möjliga hot och föreslå hur man kan bekämpa dem. Låt oss gå rakt på sak!

1. Hur förklarade kunden sin idé?

Det kommer att finnas avvikelser i produktvisionen redan från början. Varför är det så? Anledningen är mycket enkel - alla tolkar verkligheten på sitt eget sätt, har en idé om något i huvudet och kanske inte presenterar denna vision på ett korrekt sätt för den andra parten. Om du med ord beskriver en produkt som du skulle vilja bygga är det mycket troligt att utvecklingsteamet kommer att förstå din vision på ett annat sätt än du tänkt dig.

Naturligtvis är det möjligt att undvika detta. Du bör börja visualisera så snart som möjligt och diskutera enskilda delar av produktfunktionaliteten utifrån skisser. Intressant nog har de första skisserna vanligtvis inget gemensamt med slutprodukten. I det här skedet är det viktigaste dock att göra visionen sammanhängande.

2. Hur uppfattade projektledaren det?

Undrar du varför den första och den andra bilden är så olika? Projektledaren kommer alltid att ta en närmare titt på produktvisionen. Men hur som helst, är det viktigt att en sådan person, som i huvudsak ansvarar för hela Utveckling av programvara process, förstår till fullo problemet och de behov som är relaterade till produkten. Projektledaren måste ha en tydlig "större bild". Som du kan se skiljer sig inte de båda bilderna åt när det gäller funktionalitet. De ser bara olika ut. För att bättre förstå denna punkt, låt oss återvända till bild nummer ett. I början av projektet fanns det inga skisser och det ledde redan till ett missförstånd. Produktens funktionalitet är korrekt, men designen är helt annorlunda.

3. Hur har analytikern utformat den? och 4. Hur skrev programmeraren det?

Ibland känner analytiker och utvecklare inte till användarnas behov eller fastställda affärsmål. De ser bara en liten del av hela projektet, som fångar deras huvudfokus. De kan inte se det ur ett bredare perspektiv, och detta är särskilt fallet för stora projekt där många utvecklare arbetar samtidigt.

Vi kan också använda ett annat exempel. Det kan hända att problemet som ska lösas är felaktigt beskrivet, till exempel av produktägaren. Det innebär att man ger ofullständig information som utvecklaren eller designern gör egna tolkningar av och produkten avviker mer och mer från den tänkta utvecklingsvägen.

Hur kan man ändra på det? Jag tror att en bra lösning är att se till att de personer som är nyckelpersoner i projektet har detaljerad kunskap om det - den så kallade "större bilden". Om det uppstår missförstånd blir det lättare för dem att ta med Process för utveckling av programvara tillbaka på rätt spår. Kom därför ihåg - om alla bara ser sitt lilla fragment av den utvecklade funktionaliteten blir missförstånden i visionen ett sannolikt hot.

5. Hur beskrev affärskonsulten det?

Här är frågan enkel. Produkten måste sälja. Du måste sticka ut på något sätt, så att till exempel en enkel gunga för din trädgård får extraordinära element. Tanken är att övertyga en potentiell köpare. Marknadsförings- och försäljningsavdelningen kommer säkert att göra allt för att visa att produkten är unik.

6. Hur har projektet dokumenterats?

Avsaknad av dokumentation är ett mycket vanligt problem. Ibland kan det vara svårt att skapa dokumentation under produktutveckling verkar som ett onödigt slöseri med tid. Detta är ett misstag. Jag säger ofta att förändringar görs snabbare på papper än i verkligheten. kodoch det ligger något i det. Dessutom är det lättare att hänvisa till dokumentationen för att spåra eventuella förändringar. Tro mig, ett projekt utan dokumentation löper en mycket stor risk att missa visionen.

7. Vilka operationer installerades?

Detta steg avser att placera miljön på servern. Precis som i punkten om programmerare och analytiker, utan fullständiga data och med kommunikationsluckor, kan det visa sig att endast en del av den nödvändiga miljön har skapats.

8. Hur fakturerades kunden?

Det är resultatet av dålig kommunikation, brist på UX och så vidare. När det uppstår fel ökar utvecklingstiden. Och tid är pengar, eller hur? Mitt tips är att driva projektet i enlighet med Agile, upprätthålla högsta kommunikationsstandard och ha tydliga budgetriktlinjer. Jag tvivlar inte på att ni genom att göra detta kommer att undvika sådana problem.

9. Hur stöddes det?

Kunder fokuserar ofta bara på att bygga en produkt och avsluta med det. Vi lever dock i en tid med många förändringar och tekniska innovationer, vilket är anledningen till att det är nödvändigt att upprätthålla konstant teknisk support. Tanken är att undvika en situation där något plötsligt slutar fungera eftersom det blir föråldrat och produkten förlorar sitt värde. Denna aspekt bör inte heller glömmas bort.

10. Vad behövde kunden egentligen?

Vi har nått den sista punkten. Titta på skillnaden mellan den första och den sista grafen. När allt kommer omkring relaterar båda till kundens perspektiv. Varför är det så här? Alla ljuger om att det är så enkelt 🙂 Undersökningsresultat skiljer sig alltid från dina respondenters faktiska behov. När de svarar på forskarens fråga vill användarna visa upp sin bästa sida. Därför är det så, DE SVARAR OFTA INTE SANNINGSENLIGTutan snarare på ett sätt som de tycker att de borde svara. I grund och botten vill de inte utsättas för andras negativa bedömning. Här är ett litet tips till dig - nämn i instruktionerna att det varken finns bra eller dåliga svar.

Var annars uppstår skillnaderna? Människor vet ofta inte vad de verkligen vill ha. Ofta säger användarna först att de behöver 10 funktioner i produkten, men senare använder de i själva verket bara, säg, 3.

Så hur löser man det här problemet? Förutom att fråga användarna vad de vill ha och behöver, låt dem testa produkten, helst på autentiska föremål för att bibehålla trovärdigheten. Ju fler tester under skapandet av produkter, desto större är chansen att resultatet blir korrekt.

Sammanfattning

Om du någonsin blir medlem i en Utveckling av programvara projekt, kom ihåg mina exempel och dra slutsatser så att du inte kopierar ovanstående fel. Och kom ihåg att dessa begrepp är mycket viktiga för att bygga en produkt (applikation) från grunden:

- bra UX och tester, så att du kan lära dig vad dina användare verkligen behöver,

- kommunikation inom projektet, så att en djup förståelse för problemet och behoven finns tillgänglig för nyckelpersoner i projektet,

- utveckla produkten i enlighet med Agil,

- glöm inte teknisk support.

Läs mer om detta:

– Hur hanterar man utvecklare på distans på ett effektivt sätt? En guide för CTO:er

– Python vs. Ruby? Vilken teknik ska du använda för produktutveckling?

– En snabbguide till hur du bygger och utvecklar din egen marknadsplats. Vad är värt att veta?