Ga naar inhoud
  • 0

Visual over projecten...

Aanbevolen berichten

4 antwoorden op deze vraag

  • 0
Senior     61 0

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
Retired Mod     4,7k 244

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
Legend     272 3

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
Gast
Dit topic is nu gesloten voor nieuwe reacties.
Verberg sidebar
  • Wie is er online?
    8 leden, 149 Gasten

  • Breng jouw businessplan naar een higher level!

    Op dit forum worden alle onderwerpen m.b.t. ondernemerschap besproken.

    • Stel jouw ondernemersvragen
    • Antwoorden/oplossingen van collega ondernemers
    • > 65.000 geregistreerde leden
    • > 100.000 bezoekers per maand
    • 24/7 bereikbaar / binnen < 6 uur antwoord
    •  Altijd gratis

  • Ook interessant:

×
×
  • Nieuwe aanmaken...

Cookies op HigherLevel.nl

We hebben cookies geplaatst op je toestel om deze website voor jou beter te kunnen maken. Je kunt de cookie instellingen aanpassen, anders gaan we er van uit dat het goed is om verder te gaan.