ICT Valley

Richtlijnen voor offshore ontwikkeling. (3/5)

Niet alleen in Nederland, maar op veel meer plaatsen in de wereld zitten interessante ICT professionals. Deze experts kunnen Nederlandse bedrijven aanvullen op kennisgebieden waarvoor in Nederland minder specialisten te vinden zijn of waarvoor de kosten van Nederlandse ICT professionals te hoog zijn.

Zelf werk ik al meer dan 10 jaar samen met ICT professionals uit de westelijke kant van Oekraïne. De kennis, kwaliteit en werkmentaliteit zijn uitstekend, terwijl de kosten lager zijn dan in Nederland.

Deze voordelen komen alleen tot hun recht als
1) het team van ICT professionals de juiste aansturing op afstand krijgt
2) de documentatie goed wordt opgebouwd
3) men elkaar begrijpt.

In deze blog in vijf delen neem ik u mee naar “efficiënter werken met nearshore specialisten.” In deze derde blog leert u hoe u kunt werken met fouten tijdens projecten.

Waarom fouten het project verbeteren!

Juist door het maken van fouten ervaren programmeurs hun eigen grenzen en worden ze gedwongen om mee te denken. Zij worden bijvoorbeeld geactiveerd om na te denken over hoe men documentatie zou moeten vormgeven, om op deze manier fouten in de toekomst te voorkomen.

Natuurlijk zijn fouten een aanslag op het budget en op planningen. En natuurlijk leveren fouten stress op. Maar dat komt omdat we aan de voorkant er niet vanuit gaan dat fouten een normaal onderdeel zijn van de bedrijfsontwikkeling. Bij de opstelling van het plan en bij de uitvoering hiervan moet deze natuurlijke eigenschap van projecten meegenomen worden.

Herkennen en beheersen van fouten.

Er zijn verschillende soorten fouten:

• Structurele fouten, zoals een verkeerde database opbouw of een foute bibliotheek keuze
• Functionele fouten, zoals onjuiste proces resultaten
• Programmeursfouten, dit is het meest bekende type fout. zoals syntax fouten, structuur fouten, gebruik van verkeerde bibliotheken en dergelijke.

Structurele fouten mogen eigenlijk niet voorkomen. Daarom moet voldoende tijd besteedt worden aan database structuren, bibliotheek keuzes en uniformiteit van opmaak en de gebruikersinterface.

Functionele fouten ontstaan doordat programmeurs onvoldoende kennis hebben van de te programmeren procedures. Mogelijke oorzaken zijn een onjuiste of onvolledige documentatie of onvoldoende kennis van de Engelse taal.
Maar meestal is de oorzaak dat programmeurs niet de juiste vragen (durven) te stellen.

De meest domme fouten zijn basis programmeursfouten. Deze leveren altijd irritatie op. De programmeur test zelf is onvoldoende. Introduceer Alfa en Bèta testen waarbij de programmeur de Alfa test doet en ook vastlegt dat deze is uitgevoerd. De Bèta test gebeurt door testers.


 

Leren van fouten
Als er fouten gemaakt worden, bespreek deze met gepaste emotie. Vraag welke oplossing de programmeur in gedachte heeft en geef hem ook de ruimte om zichzelf te verbeteren

Bij het beheersen van fouten speelt communicatie (weer) een hoofdrol.

Beperk communicatie niet tot de hiërarchische lijn. Directe communicatie tussen alle leden van het team draagt sterk bij aan een beter overzicht. Het is daarom van belang dat alle teamleden het Engels goed beheersen en alle documentatie kennen en begrijpen.

Dus neem de angst weg bij de programmeur voor het maken van fouten. Geef wel aan hoe het project team hiermee om wil gaan. En geef aan dat fouten, mits goed afgehandeld, altijd een verrijking zijn van het project.