Van idee naar uitvoering

Inmiddels zijn we gestart met de doorontwikkeling van het huurdersportaal. In deze blog laat ik je zien hoe dit project verloopt voor de developers. Zelf ben ik werkzaam als lead developer en samen met het team zijn wij op dit moment ontzettend hard aan het werk om alle ideeën (vanuit de verschillende corporaties en vanuit onszelf) te vertalen naar de techniek. Daarnaast bewaken wij de samenhang van het huurdersportaal met de overige Umbrella-onderdelen, zoals het KCC en de inspectiemodule.

De zes woningcorporaties die samen met ons het huurdersportaal (door)ontwikkelen, gaan in verschillende bijeenkomsten aan de slag met het uitdenken van het huurdersportaal. We hebben ondertussen al een klikmodel ontwikkeld, en op basis van het klikmodel ontstaan er een hoop nieuwe ideeën van de verschillende corporaties. Daarnaast zijn de corporaties actief in onze online samenwerkomgeving (op Embrace), waar nóg weer meer ideeën met elkaar worden gedeeld.

‍

Impact analyseren

Onze projectleider Eli maakt samen met de deelnemende woningcorporaties een actielijst en prioriteert deze. Wij gaan vervolgens met die acties aan de slag en proberen zo helder mogelijk in taken samen te vatten wat er moet gebeuren. We analyseren wat de impact is van bepaalde ideeën en werken dit vervolgens uit.

Hier zitten best complexe zaken tussen. Veel woningcorporaties werken toch net weer even anders, dus we zoeken naar manieren om de processen dusdanig te automatiseren, waarbij er toch ruimte is voor uitzonderingen.

Slimmer beheer van de vraagboom

Deze week zijn wij (onder meer) aan de slag gegaan met het beheer van de vraagboom. Huurders kunnen op de website van de woningcorporatie via een vraagboom zelf reparatieverzoeken melden. In de vraagboom klikken ze bijvoorbeeld aan ‘Binnen de woning’ -> ‘Woonkamer’ -> ‘Elektra’ -> ‘Schakelaar kapot’.

Op basis van de ingevoerde gegevens en het adres van de huurder, weet ons systeem:

of de woningcorporatie hiervoor langskomt
zo ja: hoeveel tijd dit in beslag neemt (en hiervoor dus gepland moet worden in de agenda van de vakman)
zo ja: welk type vakman moet langskomen
zo ja: welke tijden kunnen worden weergeven in het gedeelte waarin de huurder zelf een afspraak kan plannen
of de huurder lid is van een aanvullend servicefonds of niet
of er een externe leverancier moet langskomen
of de huurder dit probleem zelf moet verhelpen
etc

Je kunt je voorstellen, dat het beheer van een dergelijke vraagboom vrij complex kan zijn. Immers, iedere uitzondering moet worden ingevoerd. We zijn op dit moment heel ver met een nieuwe manier van het vraagboombeheer, waarin bekwaamheden op een slimme manier kunnen worden ingepland.

Unit testing

We maken gebruik van unit tests om via een soort Nederlandse beschrijvingen de vraagboom te testen. Dat ziet er in het meest simpele scenario ongeveer zo uit:

‍Scenario Defect met uitzondering op complex‍
Gegeven Voor complex IJlsterkade heeft het defect als actie Huurder zelf oplossen
Als ik een reparatieverzoek wil indienen voor IJlsterkade 47
Dan heeft het verzoek als actie Huurder zelf oplossen

Een complexer scenario ziet er bijvoorbeeld zo uit:

‍Scenario Andere actie geeft geen tijdsduur mee‍
Gegevens Het defect heeft als actie Actie woningcorporatie, wel gepland‍
En Het defect heeft een tijdsduur van 30 minuten‍
En voor complex Griffeweg heeft het defect als actie Huurder zelf oplossen‍
‍Als ik een reparatieverzoek wil indienen voor Griffeweg 97-8‍
Dan heeft het verzoek als actie Huurder zelf oplossen‍
En heeft het verzoek geen tijdsduur

Het achterliggende idee is, dat je deze ‘unit tests’ ook samen met de woningcorporaties kunt bespreken en/of opstellen. Op de achtergrond worden deze zinnen dan gekoppeld aan code, de zogenaamde unit tests.