Ik heb een team samengesteld. In totaal zijn het 10 mensen, maar ze zitten niet voltijds in het team. Ik weet dat dit geen ideale situatie is, maar het is niet anders. Iedereen zat op andere projecten of deed activiteiten voor de lijn. Aangezien ik twee petten op had, namelijk ook de manager pet voor 8 van de 10 mensen, kon ik wel de prioriteiten bepalen voor het merendeel van het team.
Wat een ander probleem vormde is het feit dat het team uit enorm verschillende functies en achtergronden komt. Namelijk zowel beheer, ontwikkeling en test, maar dus ook uit verschillende technologieën. Java, .Net en het financiële pakket. Dat betekent dat niet iedereen zomaar alles van elkaar over kan nemen. Sterker nog: het is een bak kikkers die alle kanten eruit springen als je niet uitkijkt.
Dan hebben we de start. We gaan gewoon beginnen!
Geen PID, Project Brief, geen governance die al dan niet bepaalt of we verder mogen. Allemaal weten we dat we in onze ontwikkelstraten veel beter, sneller en beheerster kunnen gaan bouwen. Maar dan moeten de straten wel beter opereren. We moeten alles wel veel beter beheersen dan we ooit gedaan hebben. Wat er fout is geweest?
Veel te veel handmatig; Aan de start van een nieuwe omgeving gaat alles nog wel redelijk synchroon over de verschillende omgevingen. Maar na een paar maanden zijn er (door omstandigheden zullen we maar zeggen) veel verschillen tussen bijvoorbeeld een T-omgeving en een A-omgeving. Wijzigingen die niet consequent doorgevoerd worden, configuraties die “even” aangepast worden omdat een test team even vast zit of teveel autorisaties voor teveel mensen. Letterlijk meegemaakt dat er een script geschreven werd om op een bepaalde omgeving het loglevel weer terug te zetten naar 1, aangezien er altijd wel iemand het loglevel op 5 zette.
Te foutgevoelig; Aan het einde van het programma, doorlooptijd van 2,5 jaar, hadden we het deployen van nieuwe versies over de OTAP-straat niet op orde. Bij de eerste tests bleken twee gebruikers verschillende tabbladen te zien toen ze hun testen startten op de acceptatie omgeving. Dat betekent dat je na 2,5 jaar nog steeds niet geleerd hebt van je werkzaamheden.
Te weinig een generieke aanpak; De technieken kunnen danig van elkaar verschillen. Een pakket is duidelijk iets anders dan zelfbouw. Maar ook de .Net en de Java straat waren danig verschillend. Niet alleen in tools, dat kan omdat een technologie nu eenmaal specifieks ondersteund wordt door een leverancier, maar ook in testsoorten of aanpak of methode. Dat is wel vreemd. Waarom gaat alles niet door dezelfde status kwaliteitscontrole? Waarin is Java daar anders dan .NET?
Gebrek aan metrics; In feite is dit geen ongewenste situatie. Een gebrek aan kennis is nooit een reden om te denken dat iets niet goed gaat. Ik weet zoveel dingen niet, maar dat is geen reden om me ongerust te maken. Echter in dit geval is er geen kennis van bijvoorbeeld de doorlooptijd van een change. Of het feit dat een change sneller opgepakt wordt met .Net dan met Java. Of hoeveel bevindingen er in een Systeem Test omgeving gevonden worden. Etc. Etc.
Het moest beter en het kan beter. Met dat gevoel creëer je een team. Alles wat we doen is een verbetering en is per definitie goed. Het schept een band.
