Sleutelen aan het dashboard van de toekomst: van big bang naar ‘Extreme Programming’

27 sep Sleutelen aan het dashboard van de toekomst: van big bang naar ‘Extreme Programming’

Het leuke aan het werken aan de ‘voorkant van Guardian360’ is dat je mooie dingen kunt maken. Martin maakt graag ‘very pretty things’. Weten wat de klant wil, wat prettig werkt. Intuïtief.

Skip de overbodige dingen

Veel mensen (en met name technische mensen) verliezen soms zicht op het uiteindelijke doel. Ze worden snel in technische zaken getrokken. Functioneel dingen aanzetten omdat het kan. Maar er is ook een probleem met tijd, je wilt zowel technische collega’s als uiteindelijke gebruikers niet lastigvallen met overbodige dingen.

Wanneer het niet duidelijk is wat mensen precies willen of wat er technisch kan, dan is het prachtig om oplossingen te bedenken die aan beide zaken recht doen. Oplossingen voor zaken waarvan mensen niet wisten dat ze het wilden hebben of waarvan men weet dat ze het echt willen hebben. Ga er maar aan staan. En het moet er dus ook nog charmant uitzien.

Wat je daarvoor nodig hebt? Luisteren. De vraag achter de vraag beantwoorden. “We willen meer rapportage hebben!” – is dat wel zo? Of wil je eigenlijk bewijs hebben voor de vraag of je wel goed bezig bent? Grotere vragen. Rapportage is een middel, geen doel. Wat zijn de echte business vragen? Maar ook: wat maakt dat mensen “Wauw, dit is gaaf!” roepen?

Wij luisteren naar de wensen van onze klanten

Daarvoor werken we heel nauw samen met klanten, het is een wederzijds ding. Klanten op kantoor voor continue feedback. Uitdaging is wel dat we heel veel klanten hebben! Met een bepaalde grote klant zijn we door alle pijnpunten gelopen. Zij gebruiken Guardian360 heel veel, dus zij lopen tegen meer punten aan dan anderen. Dus de ‘Customer Relations Board’ is een kanaal waar we informatie uit krijgen, maar ook allerlei kleinere issues die van alle kanten komen en die we groeperen in zogenaamde Business Requirement Specifications (BRS). En dan maken we er een project van. Zodra het project de juiste prioriteit en een valide business case kent natuurlijk.

Keuzes maken en minder gebroken beloftes

Eerst hadden we een ‘backlog’ met duizenden stories, issues en verzoeken van klanten. Echt te veel informatie. Je moet dat echt anders vormgeven en kneden anders is het onwerkbaar. Maar ook nu we met BRS werken worden veel ideeën weggegooid. We voeren ‘triage’ uit en dumpen dan dingen. Je moet keuzes maken. Die enorme backlog gaf ons veel stress. Nu hebben we slechts een of twee projecten tegelijkertijd lopen. En dan, afhankelijk van de capaciteit die we hebben, leren we om prioriteiten te stellen en minder inschattingen te maken vooraf. En dan deadlines af te geven waarvan maar de vraag is of je het gaat halen. Je weet namelijk pas echt hoe lang een project gaat duren wanneer je ermee bezig bent. Dat leidt dan weer tot aangepaste levertijden en beloften – en deadlines die je niet hebt gehaald. We maken het nu veel kleiner. Kortere projecten, minder gebroken beloften en niet-gehaalde deadlines.

Kijk ons programmeren: Extreme programming!

Het is ooit een beetje fout gelopen toen we Agile Scrum gingen gebruiken als werkmethode. Scrum is echter naar onze mening helemaal niet agile of wendbaar. Scrum is voor sommigen bijna een soort religie geworden en dat moeten we niet willen. Software is alleen eigenlijk nooit ‘af’. We willen nu elke week of uiteindelijk zelfs dagelijks nieuwe features lanceren. Daar werken we nu hard aan. We willen onze code koppelen aan onze changelog zodat klanten bijna live kunnen zien waar we mee bezig zijn. Het liefst helemaal geautomatiseerd. Minder ‘black box’, veel meer ‘extreme programming’.

Dick heeft bijvoorbeeld iets ontwikkeld op verzoek van een klant waarmee je kunt zien hoe lang scans lopen en hebben gelopen. Dat komt dan zo snel mogelijk beschikbaar voor alle klanten.

We willen zo transparant mogelijk zijn en werken. Veel delen met klanten. Maar we zitten ook in de security industrie, dus je kan niet alles open op het internet plaatsen. Je moet het lot niet tarten. Maar laten we beginnen met onze partners, in Lighthouse. Kwestie van geven en nemen.

Functie-voor-functie aanpak maakt zichtbaar wat we doen

Iets dat we niet goed hebben gedaan in het recente verleden is de front-end beetpakken en helemaal opnieuw willen maken en het daarna aan de back-end proberen te koppelen en in elkaar te vlechten. Het werd een veel te groot ding. En klanten zien helemaal niets gebeuren aan de voorkant. We zijn eens gaan zitten en hebben geëvalueerd of we wel de juiste aanpak gebruikten. Nu doen we het stuk voor stuk, functie voor functie. Langzamerhand vervangt dan het nieuwe het oude onderdeel. Klanten zien dan ook vaker nieuwe functies en andere vormgeving. Dat haalde wel de druk van de ketel. We gaan ook niet onze eerdere fouten herbouwen! We maken een ‘minimal viable product’ en gaan daarop verbeteren en uitbreiden, in samenwerking met onze klanten. We beginnen nu met het dashboard, alles wordt gereorganiseerd. Veel logischer eigenlijk.

Beter en overzichtelijker dashboard: kleine dingen zijn essentieel

Het dashboard wordt veel logischer. Zaken groeperen bovenin, niet te veel toeters en bellen. Compliance z’n eigen hoekje. En heel belangrijke dingen als het ‘datum filter’, trends zien over een langere tijd. Ogenschijnlijk simpel, maar essentieel voor goede informatiebeveiliging. Het verschil duidelijk zien tussen nieuwe, bestaande en net vrijgevallen issues die tijdelijk geaccepteerd werden. Het zijn de kleine dingen die een enorm verschil maken. We doen nog steeds ‘grote dingen’, maar we lanceren het dashboard en presenteren daarna snel veel kleine verbeteringen. Dan hopen we ook dat we minder feedback krijgen als: “wat zijn jullie eigenlijk de hele dag aan het doen achter de schermen?”.