Vakmanschap

 
18 februari 2010

De laatste tijd duikt de term vakmanschap (craftsmanship) regelmatig op.  Achter deze term gaat veel schuil denk ik. Ik vermoed dat het voor iedereen wat anders betekent. Waarschijnlijk één van de redenen van haar populariteit. In een poging om er enige helderheid in te brengen, schrijf ik deze post. We hebben besloten dat we hier ook soms wat kortere berichten willen plaatsen. Heel mooi, want ik wou deze graag kort houden. Ik steek dan ook maar meteen van wal: wat wordt er zo ongeveer verstaan onder craftsmanship of vakmanschap?

Vakmanschap als stijl van leren
Het heeft een duidelijke link met vroeger, met ambachten. Met meesters, gezellen en leerlingen. Dit wordt ook doorgetrokken naar de oosterse vechtsporten, waar men de shu, ha en ri niveaus gebruikt om iemands competentie in een bepaalde vaardigheid mee uit te drukken. Het is in dit geval dus een aanduiding voor een bepaalde denkwijze over hoe het vak van software-ontwikkeling gezien moet worden. Vooral het aspect van de manier van leren lijkt hier van belang. Softwarebouw is in deze gedachtenlijn vooral een ervaringsvak, wat je in de praktijk en soms met gerichte oefeningen moet leren onder een ervaren meester. Dit staat vooral tegenover certificering en schools onderwijs.

Vakmanschap als bron van kwaliteit
Als variant op het bovenstaande kan ook de nadruk gelegd worden op het aspect van het ambachtelijke. In die gedachtenlijn is software-ontwikkeling een ambacht. Kenmerkend hieraan is dat het lastig is om objectief de kwaliteit van het werk en het eindproduct te bepalen.  Een ambachtelijk vakman luistert naar zijn klant, kijkt naar de steen of het hout waar hij mee moet werken en laat het op zich inwerken. Als vanzelf begint de vakman te hakken of te zagen. Hij (vaak een hij) kan het niet uitleggen of beschrijven. Maar het eindresultaat heeft wel een herkenbare kwaliteit. Ook die is niet te vangen, maar je ziet, nee voelt hem wel. Probeer je hem wel vast te leggen, dan verdwijnt hij direct. Als zand dat tussen je vingers wegloopt als je het hard vastgrijpt. Denk bijvoorbeeld aan de nadelige effecten van KPI’s, bonussen, etc. De nadruk ligt in deze zienswijze op het afschaffen of los gebruiken van vaste procedures . Het staat met name tegenover Software Engineering. Lees “Zen, or the art of motorcycle maintenance” om dit dilemma (of deze paradox?) goed uitgediept te zien worden.

Vakmanschap als beschrijving van competentie
Ook lijkt het een normerende uitspraak te (kunnen) zijn. Een vakman is iemand die een hoog niveau bereikt heeft in een bepaald vak. Vakmanschap is een dan een bepaald niveau, een ideaal om na te streven voor de mensen in het vak. Helaas voor recruiters, project managers en anderen die met software-ontwikkelaars moeten werken, geeft het weinig houvast om de norm ook objectief vast te stellen. Deze gedachtenlijn is al eens mooi samengevat in de slogan “Vakmanschap is meesterschap”.

Conclusie
Het kan een aantal kanten uit, maar één aspect is wel in alle richtingen terug te vinden:  het ongrijpbare, het niet objectief normeerbare. In feite sluit het daarmee aan in een grotere beweging van ‘professionals’ tegen ‘het management’.  Met name in het onderwijs zie je dit terug, maar je hoeft niet ver te zoeken om er nog veel meer voorbeelden van te vinden. Deze grotere beweging lijkt als kerngedachte te hebben: er zijn sowieso teveel managers, ze kunnen niet veel en zijn eerder een stoorfactor dan dat ze iets toevoegen. Als professionals maar de ruimte krijgen om hun eigen gevoel voor kwaliteit te laten spreken, dan komt het goed en zijn die managers verder niet nodig.

Ik denk dat daar een kern van waarheid in zit. Software-ontwikkeling is veel te ingewikkeld, veranderlijk en situationeel om door niet-inhoudelijke managers ‘bestuurd’ te kunnen worden. Deze gedachte (die ik toch echt wel vaker heb gehoord), dat een manager niets hoeft te weten van het ‘proces’ dat hij ‘aanstuurt’, is volgens mij gewoon niet houdbaar. De enige keren dat ik dat goed heb zien gaan is als de manager in kwestie beseft dat hij helemaal niks aanstuurt en zich dan ook bezig houdt met andere zaken zoals externe obstakels voor zijn team of afdeling opruimen, voldoende budget regelen of support bij de stakeholders verzorgen. Allemaal nuttige taken die het team niet hinderen of zelfs helpen, maar het heeft weinig te maken met ‘aansturen’, gelukkig.

Daarentegen is het wel zo dat er software-ontwikkelaars zijn die sturing nodig hebben. Niet iedereen die net een boek heeft gelezen en een eerste project heeft gedaan is gelijk een meester in het vak. En zet een aantal onervaren ontwikkelaars bij elkaar en je hebt een kans dat er een ramp gebeurd. Vrij grote kans. Natuurlijk kan er uit zoiets soms wel iets goeds komen, maar daar komt een grote mate van geluk bij kijken. Niet bepaald iets dat je vakmanschap zou noemen. En natuurlijk zijn er gevallen dat iemand jong is en onervaren lijkt, maar eigenlijk al zijn 10.000 uur gemaakt heeft, alleen dan op een andere manier. Dus dit is zeker geen pleidooi om jonge collega’s als idioten te behandelen.

Het is denk ik wel zo dat naarmate je je meer ontwikkelt, je meer wilt dan gestuurd worden of een opdracht goed uitvoeren. Je wilt doelen bereiken, iets moois maken. Iets van blijvende waarde, misschien zelfs. Dat kan allemaal, maar dan moet je wel bereid zijn om je kennis en ervaring te gebruiken, over de grenzen van je team of opdracht heen te kijken en anderen mee te nemen naar waar je naartoe wilt. Niet aan de haren, maar omdat ze graag meegaan.

Mijn aanbevelingen voor verder vakmanschap
Eigenlijk weet je nooit hoe goed je ergens in bent en zelfs al ben je het (ooit) geweest, de wereld draait door en wie weet loop je alweer achter de feiten aan. Dus deze aanbevelingen zijn volgens mij nuttig voor iedereen. Een aantal vormen van gedrag zorgen er denk ik voor dat je je vakmanschap zo goed mogelijk ontwikkelt, in de stijl van een echte vakman:

–  Blijf open om je heen kijken, kijk om je heen naar ‘meesters’ waar je iets van kunt leren door te luisteren, te observeren en hetzelfde uit te proberen. Vraag om hulp als je die nodig hebt.
–  Als je iemand treft met een andere mening, beschouw dat als een leermogelijkheid. Stel vragen,  onderzoek hoe iemand tot zijn mening komt. Ervaring kan daarin een argument zijn, maar laat die ander het wel zo concreet mogelijk maken
–  Denk niet bij alles wat je net gelezen hebt dat de waarheid tot je gekomen is. Een boek, een blogpost, etc zijn ideale mogelijkheden voor iemand om zijn (of haar) redenering volledig te ondersteunen en het logisch te laten lijken.  Denk aan de treffende wijsheid van Mike Tyson: “Everybody has a plan, until they get hit in the face”
–  Wees nederig, maar onbevreesd. Overschreeuw jezelf niet, durf te laten merken dat je iets niet weet. Maar houd ook in gedachten dat anderen ook niet alles weten of het fout kunnen hebben. Dus als je het ergens niet mee eens bent, laat het horen. Of als er een plan nodig is, vertel gewoon eens wat jij zou doen.
–  Luister naar je gevoel. Als dat zegt dat iets saai is, dan is het misschien voor jou al te bekend of juist nog te onbekend. Door dan te luisteren naar wat je wilt en je op iets anders te richten, doe je waarschijnlijk datgene wat je op dat moment het meeste oplevert.  Echter, soms moet je wel je gevoel trainen. Je gevoel kan je best iets onzinnigs vertellen over wat je nog niet gedaan hebt. Probeer het dan in ieder geval één keer van harte uit.

Tenslotte nog even het opvolgen van mijn eigen advies: nederigheid. Bovenstaande tekst is er vrij snel uitgerold en het kan goed zijn dat ik iets over  het hoofd heb gezien of gewoon domweg verkeerd heb. En ja, het is ook langer geworden dan gepland. Bij voorbaat mijn verontschuldigingen.  Hopelijk heb je er toch iets aan gehad. Geef mij de gelegenheid om ook iets van jou te leren door je reactie hier achter te laten. En Wilco, ik weet het, dit klinkt allemaal weer erg groen. :-)


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Professionele vaardigheden

Tags: , , ,


Reacties (2)

  • @Wilco

    Heel groen, zeker weten. :)

    Ben het met je eens dat zelfreflectie een belangrijke manier is om te leren. Je kunt ook veel van anderen leren door hen te laten reflecteren op jouw gedrag, maar dat is niet voor alles en voor alle situaties mogelijk.

    Belangrijke voorwaarde voor zelfreflectie is volgens mij dat je zelfverzekerd bent (je moet kunnen omgaat met de mogelijkheid dat je het verkeerd had) en bewust van jezelf en anderen (als je niet weet wat jij en anderen precies hebben gedaan en willen, dan kun je er ook vrij weinig over zeggen, laat staan uit leren). Kom zo alweer op genoeg stof voor een nieuwe post op deze manier.

    Denk overigens zeker dat er een plaats is voor anderen (noem ze managers) die niet inhoudelijk ingewijd zijn in de software-ontwikkeling. Zij kunnen bijvoorbeeld een bijdrage leveren in het bepalen van het wat er gemaakt zou moeten worden en waarom. In het ‘hoe’ kun je als niet-inhoudelijk persoon echter weinig bijdragen, behalve als sparring partner misschien.

    Geplaatst op 19 februari 2010 om 11:59 Permalink

  • Ter toelichting voor mensen die onze dialoog anders misschien niet kunnen volgen :-)
    Ik heb bij Sogyo ooit een training verzorgt, waarbij het model van de Caluwe hebben gebruikt.
    Groen staat hierbij voor leren, ontwikkelen, bewust onbekwaam zijn, etc. etc. zie voor een beschrijving van het model o.a.:
    http://www.leren.nl/cursus/management/verandermanagement/vijf-kleuren-om-te-veranderen.html
    Je groene opmerking is trouwens gelijk een mooie aanvulling/voorbeeld: een goede professional/vakman is in staat om kritisch te kijken naar het eigen handelen. Kortweg: zelfreflectie.

    Je doet het zelf in je blogpost en is wat mij betreft een goede aanvulling.
    Gerelateerd aan posting:
    – zelfreflectie als manier om (meer en beter) te leren
    – zelfreflectie gaat over het eigen handelen (dus zowel de weg, de route, het proces, de reis, etc.)
    – zelfreflectie is een competentie. Je moet jezelf een spiegel voor willen en kunnen houden.
    De goede niet inhoudelijke manager geeft ruimte en verantwoordelijkheid om de professional zijn vakmanschap optimaal in te zetten EN om dit verder te laten ontwikkelen.

    (@Rick een groene reactie hè? ;-))

    Geplaatst op 19 februari 2010 om 8:34 Permalink