De software crisis is nog niet voorbij. Veel projecten zijn te laat en leveren onvoldoende kwaliteit. De zoektocht naar de 'heilige graal' gaf talrijke oplossingen in processen, methoden en tools, maar in de praktijk zijn ze geen garantie. Door aandacht voor de menselijke factor wordt het resultaat daadwerkelijk en blijvend beter. Communicatie, feedback, erkenning en waardering zijn essentiëel bij verbetering van software ontwikkeling.
Verbeteren van software ontwikkeling gebeurd al zeer lang. Al meer dan twintig jaar geleden zijn 'klassiekers' geschreven, zoals Principles of Software Engineering Management (Tom Gilb), Quality Software Management (Gerald Weinberg) en Managing the Software Process (Watts Humphrey). De term Software Process Improvement ontstond, afgekort tot SPI. Traditioneel lag de nadruk bij verbeteren van processen. Het meest gebruikte model was en is het Capability Maturity Model (CMM, nu opgevolgd door het CMMI) wat gepubliceerd is door het Software Engineering Institute (SEI). Aanname was dat als een organisatie zijn processen definieerde en de medewerkers opleidde, er vanzelf goede bedrijfsresultaten zouden volgen.
Naarmate het SPI-vakgebied zich ontwikkelde werd duidelijk dat een proces alleen niet voldoende is. Er kwam aandacht voor methoden en tools, waarmee de processen verfijnt en geautomatiseerd werden. Er volgde discussies over wat het belangrijkste is, het proces (beschrijft wat er moet gebeuren), de methode (hoe je het doet) of de tools (waarmee je het doet). De meningen verschilden hierover, maar men was het er wel over eens dat je alle drie nodig had voor succesvolle verbetering.
Een helaas nog teveel voorkomende praktijk bij verbetertrajecten is om alles vooraf te definiëren, en daarna in grote stappen in te voeren. En juist bij die invoering gaat het vaak niet allemaal zoals men in de definitie gepland had. Er ontstaat weerstand tegen de verandering, bijvoorbeeld omdat de voordelen van de nieuwe manier van werken niet duidelijk zijn. Ook komt het voor dat medewerkers zich gepasseerd voelen en niet serieus genomen; wie denkt die procesverbeteraar wel dat hij/zij is om hun te vertellen hoe het beter kan? Hebben ze het dan al die jaren fout gedaan? Een laatste factor die vaak vergeten wordt is het beloningssysteem. Krijgen medewerkers wel waardering voor hun werk? Waar worden ze op afgerekend? Allemaal aspecten waarin de mens centraal staat, niet de processen, methoden of tools, en die van wezenlijk belang zijn om een verandering door te voeren.
Op zich is het vreemd dat menselijke factoren te weinig aandacht krijgen. Is het een gebrek aan kennis? De vakgebieden psychologie, sociologie en de sociale psychologie bestaan al heel lang, daarbinnen is veel onderzoek gedaan naar gedragsverandering, communicatie, en beloningssystemen. Maar tijdens een it-opleiding werd dat vroeger nauwelijks behandeld, iets wat gelukkig tegenwoordig anders is. Misschien ontbreekt de toepassing ervan in de it-wereld? Deels waar, echter er zijn klassiekers als Peopleware (Tom DeMarco & Tim Lister) en The Mythical Man Month (Fred Brooks) die zowel problemen als oplossingen beschrijven, en er zijn netwerken waarin ervaringen uitgewisseld worden rondom menselijke aspecten. Maar het is geen eenvoudige materie en slechts een beperkt aantal software professionals is hier echt mee bezig. Hangt het dan samen met het type mens wat voor it kiest (de 'nerd')? Zelf geloof ik dat niet, in alle jaren dat ik werkzaam ben in de it ben ik mensen van de meest uiteenlopende pluimage tegengekomen, vele van hen zeer sociaal capabel en bewogen.
Ik denk dat een belangrijke reden voor de beperkte aandacht voor menselijke factoren in de it-cultuur zit, voornamelijk in de manier waarop we organisaties besturen. Software ontwikkeling wordt veelal gezien als engineering. Het werk wordt gepland, doorgerekend met een business case, en dan besluit men om het wel of niet te doen. In ons dagelijks werk gebruiken we modellen, templates en checklists om te voorkomen dat we iets vergeten. Deze aanpak van software ontwikkelingprojecten passen we ook toe voor verbeterprojecten. Maar waar er voor software-engineering een veelvoud aan modellen en methodes is, is de set voor verbetering beperkt. Vaak gebruiken we dan het CMMI (de industriestandaard), waarin echter de menselijke aspecten te weinig uit de verf komen. Het model geeft ons een onterecht gevoel van zekerheid, als we alles doen wat daarin staat, dan moet het toch lukken?
Bestaan er modellen die zich op de menselijke aspecten in software ontwikkeling richten? Jawel, die zijn er. Bekende modellen zijn het People Capability Maturity Model (P-CMM) en het Personal en Team Software Process. Daarnaast is er aandacht voor menselijk aspecten in agile-ontwikkelingsmethoden. Zijn deze modellen de nieuwe heilige graal van software ontwikkeling? Ze zijn zeker doordacht, gebaseerd op wetenschappelijk onderzoek en hebben in de praktijk al tot verbetering geleid. Echter, ook voor deze methoden hangt het resultaat sterk samen met de manier waarop de methoden toegepast worden. In een goed verbetertraject staat communicatie centraal, is er feedback van de resultaten, zijn er coaches die de verandering begeleiden en worden de prestaties van professionals erkend en gewaardeerd.
Ondanks alle processen, methoden en tools voor software ontwikkeling die in de loop van de jaren bedacht zijn, is en blijft het mensenwerk. Gelukkig wel, we zijn geen machines! Achter de processen en methoden zitten bepaalde gedachten, vooral over menselijke waarden en respect. Communicatie, feedback, coachen en erkenning en waardering van de medewerkers is cruciaal. Als een organisatie daadwerkelijk laat zien dat ze dat belangrijk vindt, is de kans op succes vele malen groter. En als we menselijke aspecten voldoende aandacht geven, leveren we op tijd het juiste resultaat, in een organisatie waar mensen met plezier werken. De kennis en ervaring is er, wat houdt je nog tegen om het te doen?
