Onderstaande tekst is geanonimiseerd. De exacte namen van mensen en bedrijven zijn niet relevant. De blog is geschreven om lessons learned te delen.
In deel 1 van deze blogserie hebben we uitgelegd wat er gebeurde n.a.v. de “cry for help” van Jan, en Jan’s bedrijf. Voor wie dat gemist heeft, zie https://m2-d2.com/nl/kunnen-jullie-het-ff-overnemen-deel-1/ . In deel 2 pakten we draad weer op. Het platform was live gegaan en er waren meer dan tachtig change requests. Zie https://m2-d2.com/nl/kunnen-jullie-het-ff-overnemen-deel-2/ . In dit 3e en laatste deel geven we antwoord op 2 vragen: zouden we het morgen weer doen? En zo ja, zouden we het dan anders aanpakken?
Okee, straight to the point: zouden we het morgen weer doen?
Ja, absoluut. Er is stront aan de knikker, iemand heeft hulp nodig, en wij lossen het op. Da's gewoon een mooie rol. Een beetje een "heldenrol" :-) En nee, wij zijn niet bang voor spaghetticode van een ander, want we verbeteren dat gewoon stap voor stap. Wij zijn niet bang voor klanten die geen ervaren IT-ers zijn, die veel uitleg nodig hebben van waarom en hoe iets werkt zoals het moet werken. Da’s ons vak, we zijn er goed in en vinden het superleuk.
Zouden we het morgen anders aanpakken? Ja, op onderdelen wel.
Zo zouden we de UAT omgeving nog sneller in het leven roepen om de klant, dus de gebruiker, duidelijk te maken dat zij verantwoordelijk zijn voor het testen, voor het goedkeuren of dat wij hebben gemaakt ook voldoet aan hun wensen. Juist omdat die wensen vooraf niet altijd even duidelijk geformuleerd zijn, en je er niet in productie achter wilt komen dat de dingen anders zijn dan men voor ogen had.
Zo zouden we de volgende keer ook nog meer tijd besteden, in het begin van de samenwerking, aan het expliciteren van verwachtingen en in ons geval dus het uitleggen van de werkwijze., Zeker als de klant niet doorheeft dat wat er voor hem in het verleden is gebouwd geen “Wordpress voorkantje” is maar een Python/Django based front-end applicatie (en een back-end applicatie).
Zo zouden we de volgende keer meer tijd besteden, bij aanvang van de samenwerking, om de bestaande functionaliteit en dus werking te documenteren. Niet in de zin van uitgebreide documentatie schrijven of zo, maar bv. met behulp van videofilmpjes van alle schermen, alle clicks op alle buttons, en alle rapportages. Die baseline gaat helpen om daar waar onbedoeld misverstanden ontstaan over "dat zat er toch al in?" en "dat werkte toch vroeger wel goed?" die misverstanden simpel op te kunnen lossen.
Zo zouden we de volgende keer meer tijd besteden aan het geven van een mondelinge toelichting op de wekelijkse rapportage. Iedere zaterdag kregen Jan en zijn mensen een update van de werkzaamheden, en de resultaten, van de afgelopen week. Van de status van de sprint en dus van de geplande werkzaamheden voor de komende week of weken. Plus alvast een voorstel voor de invulling van de sprint erna. In een stuk of 5 tot 10 slides. Maar ... het helpt om dat maandagmorgen toch nog even met elkaar door te nemen, leert de ervaring. Dat kost een half uur tot een uur maar helpt enorm om de klant in zijn rol te laten klimmen, en te laten snappen waar hij sturing op dient te houden.
En we zouden de volgende keer de rolverdeling aan de klantenkant nog duidelijker willen vastleggen. Misschien zelfs wel laten ondertekenen “met bloed” :-) Want dat was met Jan en zijn bedrijf nog wel een ding. Na de prioriteringsworkshop dachten wij dat duidelijk was welke tickets we wanneer gingen oppakken. Bv. het verplicht gaan stellen van een aantal door de eindgebruiker in te vullen velden. Een kleine change maar toch. Vervolgens leverden wij die change op, werd ie goedgekeurd, ging ie naar productie en een week later kwam Jan in de lucht met “nee, da’s onzin, dat willen we niet, we gaan dat niet verplicht stellen”. Waarop ik enigszins flabberguested uitlegde dat we in de workshop toch echt … en dat zijn functioneel beheerder toch echt … maar nee hoor, Jan had anders bedacht. Geen punt, passen we aan, maar dat zijn wel weer extra kosten voor Jan. Daar ontstaat dan een discussie over waar niemand blij van wordt. Vandaar: hele duidelijke verantwoordelijkheden vaststellen, en daar op blijven hameren, zodat de klant weet dat als hij zijn functioneel beheerder de verantwoordelijkheid geeft om ons aan te sturen ...
Vandaag zijn we wijzer dan gisteren. Mooi. Misschien is dat wel de definitie van werken, en leven trouwens. En dus zeg ik tegen iedereen die ruzie heeft met of ontevreden is over de software development en het operationeel beheer door zijn huidige IT provider … hulp nodig? Bel ons! Da’s ons vak, we zijn er goed in en we vinden het superleuk!