De lelijke waarheid over het softwareontwikkelingsproces

afbeeldingsbron: perfectdigital.com

Je kent deze foto toch?

Ik denk dat het heel goed laat zien dat grote discrepanties en een gebrek aan visie kunnen verschijnen in softwareontwikkelingsprojecten tussen alle deelnemers en betrokkenen. Problemen ontstaan vaak vanaf het allereerste begin, wanneer de klant met een (theoretisch) definitieve product visie en presenteert deze aan de team. Dan komen verdere misverstanden, verkeerde interpretaties en, uiteindelijk, de project snel het verkeerde pad van ontwikkeling inslaat.

Terwijl ik de bovenstaande grafiek analyseer, zal ik stap voor stap alle mogelijke bedreigingen presenteren en voorstellen hoe deze te bestrijden. Laten we meteen aan de slag gaan!

1. Hoe heeft de klant het idee uitgelegd?

Vanaf het allereerste begin zullen er discrepanties zijn in de productvisie. Waarom? De reden is heel eenvoudig - iedereen interpreteert de werkelijkheid op zijn eigen manier, heeft een idee van iets in zijn hoofd en presenteert deze visie mogelijk niet nauwkeurig aan de andere partij. Als je in woorden een product beschrijft dat je zou willen bouwen, is de kans groot dat het ontwikkelingsteam je visie op een andere manier zal begrijpen dan je bedoelde.

Natuurlijk is het mogelijk om dit te vermijden. Je moet zo snel mogelijk beginnen met visualiseren en individuele elementen van productfunctionaliteiten bespreken op basis van schetsen. Interessant is dat de eerste schetsen meestal niets gemeen hebben met het uiteindelijke product. In dit stadium is het echter het belangrijkste om de visie coherent te maken.

2. Hoe begreep de projectleider het?

Vraag je je af waarom het eerste en tweede plaatje zo verschillend zijn? De projectleider zal altijd de productvisie onder de loep nemen. Echter, is het belangrijk dat zo'n persoon, die in wezen verantwoordelijk is voor de hele softwareontwikkeling proces, het probleem en de behoeften met betrekking tot het product volledig begrijpt. De projectleider moet een duidelijk "groter geheel" hebben. Zoals je kunt zien, verschillen beide afbeeldingen niet qua functionaliteit. Ze zien er alleen anders uit. Om dit punt beter te begrijpen, gaan we terug naar afbeelding nummer één. Aan het begin van het project waren er geen schetsen en dat leidde al tot een misverstand. De functionaliteit van het product is correct, maar het ontwerp is compleet anders.

3. Hoe heeft de analist het ontworpen? en 4. Hoe heeft de programmeur het geschreven?

Soms kennen analisten en ontwikkelaars de behoeften van gebruikers of vastgestelde bedrijfsdoelen niet. Ze zien alleen het kleine stukje van het hele project, waarin hun belangrijkste focus ligt. Ze zijn niet in staat om vanuit een breder perspectief te kijken, en dit is vooral het geval bij grote projecten, waar veel ontwikkelaars tegelijkertijd werken.

We kunnen ook een ander voorbeeld gebruiken. Het kan gebeuren dat het op te lossen probleem onjuist is beschreven, bijvoorbeeld door de producteigenaar. Hierbij wordt onvolledige informatie verstrekt waarop de ontwikkelaar of ontwerper zijn eigen interpretaties maakt en het product steeds verder afwijkt van het beoogde ontwikkelpad.

Hoe dat te veranderen? Ik denk dat een goede oplossing is om ervoor te zorgen dat de mensen die een sleutelrol spelen in het project er gedetailleerde kennis over hebben - het zogenaamde "grotere geheel". In het geval van misverstanden is het dan makkelijker voor hen om het project in de juiste richting te sturen. softwareontwikkelingsproces terug op het juiste spoor. Onthoud daarom - als iedereen alleen zijn eigen kleine fragment van de ontwikkelde functionaliteit ziet, worden de misverstanden in de visie een waarschijnlijke bedreiging.

5. Hoe heeft de bedrijfsadviseur het beschreven?

Hier is de zaak eenvoudig. Het product moet verkopen. Je moet op de een of andere manier opvallen, zodat bijvoorbeeld een eenvoudige schommel voor je tuin buitengewone elementen krijgt. Het idee is om een potentiële koper te overtuigen. De marketing- en verkoopafdeling zal er zeker alles aan doen om te laten zien dat het product uniek is.

6. Hoe is het project gedocumenteerd?

Ontbrekende documentatie is een veel voorkomend probleem. Soms is het maken van documentatie tijdens productontwikkeling lijkt een onnodige verspilling van tijd. Dit is een vergissing. Ik zeg heel vaak dat veranderingen sneller worden doorgevoerd op papier dan in de codeen daar zit wat in. Bovendien is het gemakkelijker om naar de documentatie te verwijzen om wijzigingen bij te houden. Geloof me, een project zonder documentatie loopt een zeer groot risico om de visie te missen.

7. Welke bewerkingen zijn geïnstalleerd?

Deze fase verwijst naar het plaatsen van de omgeving op de server. Net als in het punt over programmeurs en analisten, kan het zonder volledige gegevens en met communicatiehiaten blijken dat slechts een deel van de benodigde omgeving is gemaakt.

8. Hoe werd de klant gefactureerd?

Het is het resultaat van slechte communicatie, gebrek aan UX enzovoort. Het optreden van fouten verlengt de ontwikkelingstijd. En tijd is geld, toch? Mijn hint is om het project te leiden in overeenstemming met AgileHoud de hoogste communicatienormen aan en hanteer duidelijke budgetrichtlijnen. Ik twijfel er niet aan dat je op die manier dergelijke problemen zult vermijden.

9. Hoe werd het ondersteund?

Klanten richten zich vaak alleen op het bouwen van een product en zijn daar klaar mee. We leven echter in een tijd van veel veranderingen en technologische innovaties en daarom is het noodzakelijk om constante technische ondersteuning te bieden. Het idee is om te voorkomen dat iets plotseling niet meer werkt omdat het verouderd is en het product zijn waarde verliest. Ook dit aspect mag niet worden vergeten.

10. Wat had de klant echt nodig?

We hebben het laatste punt bereikt. Kijk naar de discrepantie tussen de eerste en de laatste grafiek. Beide hebben immers betrekking op het perspectief van de klant. Waarom gebeurt dit? Iedereen liegt dat het zo simpel is 🙂 Enquêteresultaten wijken altijd af van de werkelijke behoeften van je respondenten. Tijdens het beantwoorden van de vraag van de onderzoeker willen gebruikers zich van hun beste kant laten zien. Daarom, ZE REAGEREN VAAK NIET NAAR WAARHEIDmaar eerder op een manier waarop ze denken dat ze zouden moeten antwoorden. Eigenlijk willen ze niet blootgesteld worden aan de negatieve beoordeling van anderen. Hier is een kleine hint voor je - vermeld in de instructies dat er geen goede of slechte antwoorden zijn.

Waar verschijnen de verschillen nog meer? Mensen weten vaak niet wat ze echt willen. Heel vaak zeggen gebruikers in eerste instantie dat ze 10 functionaliteiten in het product nodig hebben, en later gebruiken ze er eigenlijk maar, laten we zeggen, 3.

Dus hoe los je dit probleem op? Vraag de gebruikers niet alleen wat ze willen en nodig hebben, maar laat ze ook het product testen, bij voorkeur op authentieke items om geloofwaardig te blijven. Hoe meer tests tijdens de creatie van producten, hoe groter de kans dat het resultaat accuraat zal zijn.

Samenvatting

Als je ooit lid wordt van een softwareontwikkeling project, onthoud mijn voorbeelden en trek conclusies om de bovenstaande fouten niet te kopiëren. En onthoud dat deze concepten erg belangrijk zijn bij het bouwen van een product (applicatie) vanaf nul:

- goede UX en tests, zodat je kunt leren wat je gebruikers echt nodig hebben,

- communicatie binnen het project, zodat een diepgaand begrip van het probleem en de behoeften beschikbaar is voor de belangrijkste mensen in het project,

- het product ontwikkelen in overeenstemming met Agile,

- Vergeet de technische ondersteuning niet.

Lees meer:

– Hoe ontwikkelaars op afstand effectief beheren? De gids voor CTO's

– Python vs. Ruby? Welke technologie moet je gebruiken voor productontwikkeling?

– Een beknopte gids voor het bouwen en ontwikkelen van je eigen marktplaats. Wat is de moeite waard om te weten?