Feeds:
Berichten
Reacties

Archive for april, 2007

Wanneer je een software professional of een deskundige bent op het gebied van kwaliteitszorg in software of IT(beheer) of leiding geeft aan softwareprojecten of een ITC afdeling en open staat voor unieke, niet-alledaagse inzichten die je onmisbaar voor je opdrachtgever ofwerkgever maken, dan nodig ik je uit deze en de volgende blogs serieus te bestuderen.

Wanneer je dit doet staat je een bijzonder aangename verrassing te wachten. Met de informatie die in deze blogs langskomt zul je in staat zijn 100% beter te presteren met 50% minder inspanning.

Nee, dit is geen typfout. Je kunt je prestaties verdubbelen met de helft van de inspanning die je nu levert. En het is niet eens zo moeilijk, als je maar weet hoe!

Beter gezegd, als je maar weet:

  1. wat je ANDERS moet doen,

  2. wat je NIET meer moet doen,

  3. waar je MEER van moet doen

Dat is precies de informatie die ik de komende blogs me je ga delen.

Laat me eerst beginnen met op te merken dat veel van de dingen die we bij het ontwikkelen van software doen zo vanzelfsprekend lijken dat we ze voor zoete slikken en niet ter discussie stellen. Neem bijvoorbeeld het traditionele softwareproces.

Wanneer ik dit proces kritisch analyseer stel ik vast dat het op vele punten te kort schiet en betere prestaties zelfs belemmert. Ergo, voor mij is het een regelrecht wonder dat we ondanks dit proces tot goede prestaties in staat zijn.

Maar je kunt beter, vele, vele malen beter!

Laten we bij het begin beginnen en het onderliggende softwareproces model nader bekijken. Deze bestaat uit de volgende stappen:

  1. vraag de gebruiker wat ze wil

  2. maak wat de gebruiker gevraagd heeft

  3. test het

  4. implementeer het

  5. onderhoud het

Wat is er mis met dit proces? Veel, maar ik zal me hier beperken tot een kleine selectie. Voordat ik echter hier toe overga, eerst het volgende: als je bovengenoemde stappen van het software procesmodel bestudeert dan moet het je opvallen dat ze verdacht veel lijken op het model dat Henri Ford een kleine 100 jaar geleden toepaste om auto’s te fabriceren. Dit model is decennia lang toonaangevend geweest bij de fabricage van industriële producten. Het is daarom te begrijpen dat Dr. Royce sterk door dit model is beïnvloed, alleen zitten wij nu opgescheept met de ongewenste bijeffecten. In zekere zin kun je zeggen dat we door deze dwaling software ontwikkelen zoals Henri Ford dat een kleine 100 jaar geleden zou hebben gedaan. Alsof er sindsdien geen nieuwe, baanbrekende ontwikkelingen geweest zijn.

Terug naar het software proces model: dit model gaat uit van enkele vooronderstellingen die soms verre van juist zijn. De eerste is dat de gebruikers in staat zijn hun sitiuatie grondig te analyseren, precies weten wat ze willen en dit in staat zijn helder te verwoorden. Verder gaat het uit van de impliciete vooronderstelling dat de gebruiker alle mogelijkheden die de technologie biedt kent en optimaal weet te benutten.

Na 30 jaar en een kleine 100 softwareprojecten in meer dan 50 organisaties durf ik deze vooronderstelling te bestrijden. En iedereen die een softwareproject van nabij heeft meegemaakt zal dit kunnen beamen. Wensen en eisen van gebruikers blijken keer op keer, project na project, verre van correct c.q. compleet c.q. stabiel.

En het komt in elk project voor dat zelfs tijdens het testen nieuwe specificaties worden opgehoest c.q. eerder geformuleerde specificaties worden herzien. Wat zijn jouw ervaringen?

Een andere vooronderstelling is dat de analist in staat is de juiste vragen te stellen. Maar zelfs wanneer ze dat zou kunnen ben je er nog niet: het is namelijk niet voldoende de juiste vragen stellen, het is noodzakelijk ALLE vragen te stellen om de specificaties sluitend te krijgen.

Dit zijn slechts 2 van de problemen die nauw met het softwareproces model samenhangen en ik kan moeiteloos nog een hele rij noemen.

Nog een voorbeeld? Dit proces is een kleine 40 jaar geleden door Dr. Winston Royce geconcipieerd en het is best interressant je even af te vragen welk probleem hij met dit proces heeft willen oplossen.

Toen de eerste computers hun intrede in het bedrijfsleven deden waanden programmeurs zich kunstenaars die hun gang konden gaan. Van projecten was nooit zeker hoe lang ze zouden duren, wat ze gingen kosten en of ze aan de wensen voldeden. Dit tot groot ongenoegen van het management. De oplossing voor dit probleem is het proces van Dr. Royce.

Dit proces is dus primair bedoeld geweest om management inzicht te verschaffen in de voortgang van softwareprojecten c.q. in te grijpen c.q. het roer om te gooien. Maar er is meer.

De omstandigheden in 2007 zijn anders. De wereld is dynamischer, de technologie is met reuzenstappen vooruit gegaan, de eisen die we nu stellen zijn volstrekt anders en de concurrentie is veel heviger.

En wat is de implicatie hiervan?

Toen Dr. Royce met zijn proces ten tonele verscheen was automatisering primair bedoeld om handmatig werk door de computer te laten overnemen. Niets meer en niets minder. En wie wisten het beste hoe het werk uitgevoerd werd?

Pas veel later drong het inzicht door dat computers de mogelijkheid openden werk veel slimmer in te richten. Anno 2007 zijn alle handmatige processen inmiddels geautomatiseerd. Softwareprojecten richten zich niet langer op het automatiseren van handmatig werk, maar op het ondersteunen van nieuwe producten c.q. diensten. Deze processen zijn nieuw en moeten als het ware uitgevonden worden. Bovendien moet het nu veel sneller, beter en moet het nog minder kosten, ook.

Allemaal eisen die het antieke softwareproces niet aan kan, omdat het hier niet voor bedoeld is. Alle inspanningen en goede bedoelingen van de afgelopen decennia (nieuwe tools, nieuwe methoden, initiatieven om de kwaliteit van het softwareproces te verbeteren, enz.) ten spijt.

Waarom?

Omdat geen van deze maatregelen de kern van het probleem oplost. Wat ze doen is symptomen bestrijden.

Vandaag heb ik een deel van de kern van het probleem geraakt. De komende weken zal ik hier verder mee gaan, totdat je over voldoende inzicht beschikt om het probleem in haar volle omvang te overzien en te adresseren.

Ik hoop nu dat je uit je schulp kruipt en jouw mening laat horen. Reageer en laat merken wat je van mijn inzichten vindt. Reageer met eventuele vragen c.q. opmerkingen.

Groet,
Black Belt Kelly
Coherent Systems
kwg@coherentsystems.nl

p.s. dit is een excerpt van mijn eerste boek uit een serie van vier dat binnenkort uitkomt.

Read Full Post »