Creativiteit in Software Ontwikkeling

Januari 2010 - Met een hamer werken omdat we deze nu eenmaal in onze handen hebben.

Je komt het overal tegen: oplossingen die bedacht zijn omdat we de situatie, omgeving of het systeem nu eenmaal goed kennen. We lopen daardoor soms vast in onze eigen kennis. Door een hele rits aan aannames worden oplossingen neergezet die niet altijd even effectief zijn, of zelfs geen oplossing zijn.

De druk op ICT wordt almaar groter: klanten vragen meer oplossingen, in kortere tijd, met minder middelen. Vaak is een frisse blik nuttig, zo niet noodzakelijk. Nieuwe gedachtegangen die ervoor zorgen dat we daadwerkelijk de oplossing aankaarten en niet verzanden in door onze eigen kennis aangedragen of opgelegde oplossingen.

In dit Whitebook ga ik in op hoe je deze frisse blik kunt creëren. Creatief denken hoort bij software ontwikkeling. De frisse blik op bestaande situaties en omgevingen kan bevrijdend werken en zorgt voor een snelle indicatie van de werkelijk gewenste oplossing.

Waar komen we vandaan?

Om goed te begrijpen waarom we verkeerde, of niet helemaal slimme, oplossingen bedenken, moeten we eerst weten waar we vandaan komen. We komen namelijk uit een situatie waarin onze kennis essentieel is om software te creëren.

Onze kennis van de huidige systemen, omgeving of bedrijfsprocessen vertroebelt regelmatig ons beeld van de beste oplossing. Dat komt omdat we vaak al een probleem denken te herkennen en hierdoor direct in een bepaalde oplossingsrichting denken. Uiteraard is dit niet vreemd, maar kan vaak beter anders aangepakt worden. Omdat we onze beelden over de bedachte oplossing baseren op aannames, dienen we deze eerst te toetsen.

Implicaties

Omdat we erg snel in oplossingen denken, en nauwelijks stil staan bij de impliciete aannames die wij doen, worden er met regelmaat oplossingen bedacht voor niet-lastige problemen die onnodig complex zijn .

De doelstelling van het IT project wordt hierdoor niet behaald en problemen worden niet of slechts gedeeltelijk opgelost. Dit resulteert in ontevredenheid over de automatiseringsafdeling, of extra kosten voor systemen die lastig te beheren zijn.

Zes basisvragen

Een behoorlijk simpele (misschien zelfs voor de hand liggende) manier om snel met een frisse blik te kunnen kijken naar ons project is het stellen van zes simpele vragen. Door deze vragen dwing je jezelf, en andere betrokkenen, om buiten het project te stappen en niet direct te kijken naar een oplossing.

Door deze zes vragen aan de verschillende betrokkenen te vragen is het mogelijk om een gemeenschappelijk doel te genereren. Met dit doel kan iedereen aan de slag. De vragen zijn als volgt opgebouwd, maar hoeven niet per definitie in deze volgorde gesteld te worden.

Wie? en Wat?

Welke mensen zijn onderdeel van het project, waar liggen de systeemgrenzen waar het probleem zich afspeelt? Het antwoord waar wij naar zoeken zijn de elementen binnen ons project. Welke belangen spelen een rol? Wie is de probleemhouder en welke andere belanghebbenden zijn er?

Hoeveel?

Wees niet bang om dit te vragen. Deze vraag houdt in dat er een budget is, een prijs gekoppeld aan de gewenste oplossing(en) die we gaan ontwikkelen. Dit heeft veel, meer dan de overige vragen, met perceptie te maken. Wat is de verwachte hoeveelheid tijd, geld, resources, enzovoorts wat er in het project wordt gestopt? Hoeveel is het ons waard?

Wanneer?

Deze vraag gaat in op de dimensie tijd en is multidimensionaal in te zetten. Wanneer heeft de organisatie de oplossing nodig? Wanneer verwachten de verschillende betrokkenen dat een eventuele oplossing geld op gaat leveren? Wanneer gaan we beginnen en wanneer zijn we in productie?

Waar?

Ergens in de organisatie treedt het probleem op en is een oplossing gewenst. Maar waar precies? Waar verwacht de organisatie dat de oplossing gerealiseerd zal worden? Waar liggen verantwoordelijkheden en waar zijn de oplossingen voorhanden?

Hoe?

Deze vraag is op twee manieren in te steken: Hoe is het probleem ontstaan? Maar ook: hoe denken we het probleem op te lossen?

Waarom?

Misschien wel de belangrijkste vraag tussen deze zes. We beginnen hier eindelijk over problemen te praten, maar nog belangrijker: de implicaties van deze problemen. Waarom is een oplossing voor het probleem noodzakelijk of gewenst? Denk hierbij dus overduidelijk niet aan de oplossing, maar aan consequenties van het probleem. Vindt u dit lastig? Probeer het dan eens in termen als uitdagingen. Wat gebeurt er als we deze uitdaging niet pakken?

Doelen stellen

Na het stellen van deze vragen komen we bij het stellen van een enkel gemeenschappelijk doel. Doordat elk project te maken heeft met verschillende betrokkenen hebben we altijd een aantal verschillende, vaak persoonlijke, doelstellingen voor het project. Enkel opleggen van een doelstelling, zoals dit regelmatig voorkomt, werkt vaak averechts. Op het moment dat we weten met welk doel we aan de slag gaan worden keuzes, die later in het project naar boven komen, een stuk gemakkelijker.

Het stellen van de hoofddoelstelling is meestal een logisch vervolg op de zes basale vragen. Toch is het stellen van dit doel een groepsactiviteit. Probeer zoveel mogelijk belanghebbenden te betrekken bij dit proces. Maak het ook SMART (Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdgebonden). De antwoorden op de zes vragen zullen u hier zeker bij helpen.

Naast het veelal zakelijke SMART doel, is het tijdens een project heel fijn om een hoofdvraagstuk voor handen te hebben. Deze vraagstelling is een enkele zin waarop het project antwoord moet geven. Dit hoeft niet per se meetbaar te zijn, en kan indien gewenst compleet op emotie gebaseerd worden. Een voorbeeld zou kunnen zijn; ‘zorgen we hiermee dat die arme mensen hun geld eerder krijgen?’ voor een applicatie die geld aan minima uitkeert.

Doe eens gek!

Nu wordt het tijd om de oplossing te bedenken. Duik niet meteen achter het toetsenbord om het bekende verhaal uit te werken, maar probeer buiten het kader te denken. Om de essentie van een oplossingsrichting aan te kaarten kan het goed helpen om af en toe iets geks te doen.

Eén van de vragen die altijd goed is om te stellen, is wat het zou betekenen als we het doel niet zouden bereiken met automatisering. Kan het ook anders? Welke manieren of ingrepen in de organisatie zouden hetzelfde doel nastreven? Door deze vraag te stellen worden de kaders waarin we denken vaak duidelijk. Welke inspanning of investering is deze doelstelling ons eigenlijk écht waard?

Draai tijdens het ontwerp van de oplossing de rollen, eens volledig om. Laat ontwikkelaars het bedrijfsproces uittekenen, de eindgebruiker de entiteiten, de opdrachtgever een interactiescherm en vraag de projectmanager een verhaal te vertellen over kansen en uitdagingen (in plaats van problemen en beren op de weg). Deze activiteit kan heel goed helpen om te kijken of het team aan dezelfde oplossing denkt en of de neuzen daadwerkelijk dezelfde kant op wijzen.

Vraag ontwerpers en architecten of ze de oplossing die zij voor ogen hebben op 1 A4-tje te presenteren aan de groep. Dit lukt vaak niet, maar zorgt er wel voor dat we snel tot de essentie komen. Zo werkt het ook goed om tevens meetings te ´timeboxen´.

Bovenstaande voorbeelden hoeven zeker niet veel tijd te kosten, maar lossen vaak wel een aantal grote problemen op. Uiteraard hoeft dit alles niet in officiële documenten uitgewerkt te worden, maar kan juist een goede stimulans worden om de hele groep gezamenlijk aan de slag te zetten. Over het algemeen kom je met een ruimte met een whiteboard al een heel eind.

Iteratief

Elke activiteit van een project, ook analyse en ontwerp, kan iteratief opgepakt worden. Aan het begin van een iteratie bijvoorbeeld, of als iteratie 0. Pak het in ieder geval stukje bij beetje op. Als we direct beginnen met het opsommen van activiteiten en lastige vragen waar we antwoord op willen hebben, zullen we lang niet alles te weten te komen. Het kan ook anders.

Conclusie

Het doel van deze aanpak is simpel: aannames elimineren om de koppen dezelfde kant op te krijgen. Dit kan vaak snel en effectief door bovenstaande hulpmiddelen te gebruiken. Met een minimale inspanning kunnen effectieve oplossingen worden gecreëerd. Een frisse blik en creatieve invalshoek op probleemstelling en oplossing zorgen ervoor dat er in behoorlijk korte tijd zeer veel duidelijk wordt en dat we tijden ons (iteratieve) project beslissingen kunnen nemen die op onze gezamenlijke doelen gebaseerd zijn.

Door een aantal simpele en soms voor de hand liggende methoden te gebruiken kan snel en effectief omgegaan worden met beeldvorming. Met behulp van uw eigen inzicht kunnen alle elementen die hierboven beschreven zijn in korte tijd uitgevoerd worden. U zult zien dat het geen tijdsverspilling is en doorlopend op het project juist tijdswinst oplevert. In het begin zijn deze aanpakken misschien even raar of kunnen ze overkomen als niet serieus, maar het doel waarmee we het doen is duidelijk. Het is een kwestie van gewoon doen.

Meer informatie
Ome-B.nl – Creative Software Development