Annedien Hoen Geplaatst: 15 september 2003 Annedien Hoen 3,2k 287 Geplaatst: 15 september 2003 Link naar reactie
0 Jeroen Bakker Geplaatst: 15 september 2003 Jeroen Bakker 9,9k 462 Geplaatst: 15 september 2003 Geweldig! ;D Link naar reactie
0 H. Geplaatst: 15 september 2003 H. 61 0 Geplaatst: 15 september 2003 Die afbeelding heb ik ook eens voorgeschoteld gekregen tijdens een presentatie over projecten en methoden. De hele presentatie ging hierover. Er hoort namelijk bij iedere afbeelding wat uitleg over hoe het kon gebeuren en wat je eraan kan doen om (te proberen) het te voorkomen. Hier een poging tot uitleg van de afbeeldingen: Vooropgesteld, dat het per afbeelding werd gepresenteerd en dat het betrekking heeft op software development. Afbeelding 1 (How the customer explained it) ----- De klant weet niet altijd wat hij precies wil. De beschrijving die deze, vaak in eerste instantie, geeft komt niet overeen met wat hij werkelijk wil. Dit komt vaak door gebrek aan technische kennis of slecht vooronderzoek naar wat de eindgebruikers met een applicatie moeten kunnen in de praktijk. Afbeelding 2 (How the Project Leader understood it) ----- Hier zie je dat er een vertaalfout wordt gemaakt, tussen de klant (a-technisch) en de projectleider (semi-technisch). Dit kan komen, doordat de projectleider (meestal) gedeeltelijk verstand van zaken heeft. Hierdoor interpreteert hij bepaalde dingen van de klant (onbewust) anders dan dat de klant dit bedoelt. Wanneer de project- leider vervolgens vraagt (met half technische termen) "Is dit wat je wilt?", zegt de klant (te) snel "Ja", ook als deze het niet helemaal begrijpt. Dit doet de klant, omdat deze ervan uitgaat dat de projectleider verstand van zaken heeft. Afbeelding 3 (How the Analyst designed it) ----- De projectleider geeft de opdracht vervolgens aan een analyst (software ontwerper), die ermee aan de slag gaat en een technisch ontwerp maakt. Deze heeft wèl (theoretische) technische kennis en ziet aan de omschrijving van de projectleider, dat de klant waarschijnlijk niet kan doen wat hij wil (schommellen) en bedenkt daarvoor een oplossing, die zo dicht mogelijk in de buurt van de beschrijving van de projectleider komt. Afbeelding 4 (How the Programmer wrote it) ----- De programmeur moet vervolgens het technisch ontwerp omzetten naar een werkend (praktisch) programma. Hierbij kan hij tegenstrijdig- heden in het ontwerp tegen komen, die praktisch onmogelijk op te lossen zijn en op papier niet zo snel aan het licht komen (bijv. dat de stokken die de boom moeten dragen dit nooit kunnen houden). De programmeur begaat vervolgens dezelfde fout die de analyst heeft gemaakt, hij koppelt dit niet terug en bedenkt een eigen oplossing. Afbeelding 5 (How the Business Consultant described it) ----- In deze afbeelding is te zien hoe de consultant het beschreef. Deze stap weet ik niet helemaal meer, maar het kwam erop neer dat deze het te luxe beschreef. Dus wanneer een gebruiker bijv. een file wil kunnen verwijderen, bedenkt de BC erbij dat er ook een undelete bij moet en een mogelijkheid om de file te versnipperen, etc. Te veel van het goede in ieder geval. Afbeelding 6 (How the project was documented) ----- Spreekt voor zich lijkt me. Geen documentatie aanwezig of niet de kern gedocumenteerd. Geen technische handleiding (wat op zich nog niet zo'n ramp lijkt, maar al helemaal geen gebruikers- handleiding. Dit laatste is direct een ramp, omdat de klant dit nodig heeft. Zeker in het geval van ingewikkelde applicaties, maar ook vaak bij relatief eenvoudige, omdat wanneer er bijv. nieuwe medewerkers mee moeten gaan werken, hier wel een beschrijving voor moet zijn. Het probleem bij ontbreken van technische documentatie komt pas naar voren wanneer er fouten in het programma zitten, die pas na een poos tevoorschijn komen (y2k bugs bijv.) of wanneer de applicatie na lange tijd moet worden aangepast en/of uitgebreid. Afbeelding 7 (What operations installed) ----- Dit is de service aan de klant die faalt. De afdeling "operations" kreeg het product niet aan de praat op een werkstation van de klant, omdat deze bijvoorbeeld een ander OS gebruikt en installeert het zo goed als hij kan. Ook kan het zijn dan operations bij gebrek aan kennis van alle mogelijkheden van de applicatie, niet alles benut. Afbeelding 8 (How the customer was billed) ----- Hier zie je dat de klant een vèèl te grote rekening krijgt gepresenteerd, doordat als gevolg van de eerdere miscommunicaties het project teveel tijd heeft gekost en er uiteindelijk van alles is ontwikkeld, dat niet de bedoeling was. Afbeelding 9 (How it was supported) ----- After sales. Geen tot weinig communicatie met de klant of communicatie- problemen door de eerder genoemde oorzaken (vertaalslag tussen de projectleider en klant). Ook kan het zijn dat de support niet (goed) mogelijk is door gebrek aan (volledige) documentatie, waardoor fouten niet effectief kunnen worden hersteld, of dit extra (uitzoek) werk kost (lees: de klant extra geld gaat kosten). Afbeelding 10 (What de customer really needed) ----- Dit is zo'n beetje de conclusie van het verhaal, waar de eerste communicatie fout te zien is. Moraal: Communiceren, communiceren, communiceren en terugkoppellen. Dit is de grootste nachtmerrie van een bedrijf en vooral als het niet geconstateerd wordt of als het niet als dusdanig behandeld wordt, omdat het, naast veel geld, ook nog eens klanten kan kosten en een slechte reputatie kan opleveren. Niet alleen een hilarische afbeelding dus, maar een vrij realistische (worst case) situatie, waaruit een les kan moet worden getrokken. Link naar reactie
0 R.I.P. - Fred Wiersma Geplaatst: 17 september 2003 R.I.P. - Fred Wiersma 4,7k 244 Geplaatst: 17 september 2003 Inderdaad een prachtige visual. Ik ken hem ook van vroeger als iemand die een fiets wil, uiteindelijk via step, driewieler, tandem, motorfiets etc uiteindelijk een 1wieler (zoals in circus) geleverd krijgt. Helaas bij mij niet beschikbaar, als iemand die heeft 'm wil scannen en opsturen (of hier publiceren) graag! Bye, ToC r.i.p. Fred Wiersma | IN MEMORIAM Link naar reactie
0 OlafJ Geplaatst: 2 december 2003 OlafJ 272 3 Geplaatst: 2 december 2003 Er bestaat geen smiley om uit te drukken hoe ik heb gelachen. LOL! De plaatjes spreken op zich boekdelen. Niettemin ga ik je uitleg maar even lezen. Leuk initiatief trouwens, om een lollig plaatje als inzet te gebruiken voor een thread. Olaf Janssens www.anasign.com Link naar reactie
Annedien Hoen
Annedien Hoen
Link naar reactie
Aanbevolen berichten
4 antwoorden op deze vraag