Consistentie. Officieel zal iedereen het natuurlijk belangrijk vinden. Binnen een product moet functionaliteit altijd gelijk werken, ongeacht waar het aangeboden wordt. Binnen een team moeten mensen op een soortgelijke manier werken. Waarom is consistentie dan zo moeilijk? Consistentie vraagt om "verder kijken dan je neus lang is". Consistentie vraagt om kijken naar de hele applicatie, als je bezig bent met 1 functie. Kijken naar het hele team, als je bezig bent met testen. Kijken naar het gehele proces, als je bezig bent met jouw applicatie. Kijken naar de hele organisatie, als je werk doet voor jouw team.
Waarom? Laten we beginnen binnen het team. Stel je hebt al een bestelproces gebouwd. In dit bestelproces was het mogelijk een adres in te voeren. Dit adres is opgeslagen in het klantaccount. Nu wil je de klanten de mogelijkheid bieden om hun adres te wijzigen. Qua consistentie houdt dit het volgende in: in beide schermen moeten dezelfde gegevens staan. Als je bij het bestelproces kon invoeren, dat je op kamer 784 3e etage woont, moet je dit op het te bouwen scherm ook kunnen wijzigen. Als je in het bestelproces een bezorgadres kon invoeren, moet je deze op het te bouwen scherm ook kunnen wijzigen.
Consistentie binnen een ontwikkelproces zal niemand onbelangrijk vinden. Om binnen testen te blijven: als een tester de regressietest belangrijk vindt, moet een ontwikkelaar het fixen van regressietestbugs ook belangrijk vinden. Er moeten afspraken zijn over de invoer ervan bugs, zodat een ontwikkelaar de informatie heeft, die nodig is om het probleem op te lossen. Enz., enz.
Samenwerken als een team en werken aan een product in plaats van een functie is voor te veel teams al moeilijk genoeg. En dan is het voor veel bedrijven niet eens voldoende als je consistentie op orde hebt in een team. De consistentie moet op orde zijn tussen teams onderling. Tenminste: als deze teams werken aan producten, die met elkaar verbonden zijn.
De argumenten zijn niet anders. Stel je hebt binnen je website het invoeren en wijzigen van een adres precies gelijk. In beide kan je aangeven dat je op kamer 784 3e etage woont. Maar vervolgens belt een klant naar de helpdesk om het adres te laten wijzigen. Een ander systeem, dus een ander team. De helpdesk vraagt het adres op om het te controleren. Dan zegt de klant "Dat adres is niet compleet. Ik woon op kamer 784 3e etage". Bij het bouwen van het helpdesk systeem was niet gekeken welke adresgegevens er bij het bestellen werden ingevoerd.
En vergeet consistentie in het proces niet. Neem nogmaals een bestelproces in de webshop. De artikelen worden beheerd in de backend. Dus in team A. Dit team heeft "Artikelen" als hoogste prioriteit en bouwt het, zodat team B deze straks kan tonen op de webshop. Team A is klaar en levert het werk op. Vervolgens krijgen ze een andere eerste prioriteit, tenslotte is het werk af. Team B gaat vervolgens de artikelen in de webshop tonen. En hierbij ontdekken ze een bug in het onderdeel "Artikelen". Maar bij het melden aan team A is het antwoord: "Artikelen heeft voor ons nu geen prioriteit. Dus je zal moeten wachten".
Consistentie heeft als grote probleem, dat niemand het belang ervan ontkent. Maar als je aan "Klantgegevens wijzigen" werkt, sta je er vaak niet bij stil dat "Product bestellen" hier een belangrijk raakvlak mee heeft. Het zijn tenslotte twee hele verschillende processen, die los van elkaar staan. En als je geconcentreerd aan het testen bent, kan je wel eens vergeten dat ontwikkelaars de informatie in gevonden bugs later ook moeten gebruiken. Het lijkt op dat moment niet belangrijk. Testen is nu tenslotte prioriteit 1. En datzelfde geldt breder. Als deel van het "helpdesk" team lijkt het "webshop" team nu niet echt belangrijk, niet hun product en niet hun proces. En dat maakt consistentie nu zo ontzettend moeilijk. Je moet stil staan bij belangrijke zaken, die voor jou op dat moment eigenlijk niet belangrijk zijn. Veel succes!
Geen opmerkingen:
Een reactie posten
Opmerking: Alleen leden van deze blog kunnen een reactie posten.