• de huur van een server,
• de bepalingen in het onderhoudscontract, of
• de afspraken over aanlevering van operationele gegevens

Maar vooral ook afspraken met en over mensen en de operationele organisatie liggen op het bordje van de productmanager, zoals

• het voorbereiden van een gebruikerscursus,
• een marketingcampagne voorbereiden of
• het aanstellen van een applicatiebeheerder

Je zou bijna vergeten dat de productmanager verantwoordelijk is voor de zakelijke inhoud van de software in ontwikkeling! De bouwers zullen ervoor zorgen dat het product opstart, rekent en misschien zelfs “gebruiksvriendelijk” is. Maar hij moet ervoor waken dat het product de investering waard wordt.

Conceptuele Integriteit

Ik zie een leidraad die de product owner kan volgen tijdens de ontwikkelingsfase. Hij moet streven naar Conceptuele Integriteit. Eigenlijk beantwoordt hij doorlopend de vraag: Kan elke functie in de applicatie zijn eigen broek ophouden?

Concept. Integer. Twee moeilijke woorden. Het woordenboek helpt ons gelukkig op weg:

Concept:

Algemeen idee, Intentie, Bedoeling

Integer:

1. Eerlijk en oprecht zijn, morele principes

2. Compleet en inwendig samenhangend. Solide constructie.

Streven naar conceptuele integriteit betekent letten op de Compleetheid, Samenhang en Consistentie ten opzichte van de zakelijke Intenties. Laten we daar eens induiken.

Compleetheid

Een softwareproduct moet in meerdere opzichten compleet zijn, af zijn.

Puzzelstukjes

Bovenal vervult de software een paar stappen van een bedrijfsproces. Elke stap moet het product netjes uitvoeren en elke stap moet ook netjes aansluiten op zijn naburige stappen in de workflow. Mens en machine wisselen hun beurt af om samen een taak uit te voeren. Op de overdrachtspunten tussen beide moet de software netjes in de organisatie passen.

ontbreekt er een puzzelstukje?

Maar ook de gegevens binnenin de software moeten volledig zijn. Gegevensbestanden moeten foutloos ingeladen kunnen worden, per bestand, database of met een externe koppeling.

Mag ik er even bij?

Complexere organisaties vereisen tenslotte ook nog een hiërarchisch systeem van applicatierollen en daaraan gekoppelde rechten. De rechten van elke rol moet de volledige taak van een persoon met die rol ondersteunen. Dat betekent dat elke gebouwde functie die nodig is om de rol op je te nemen ook tot je beschikking staat. (Genoeg rechten.) Door het proces na te spelen blijkt al snel waar nog rechten ontbreken, of welke rollen  teveel rechten hebben. (“Verrek! De conciërge mag de directiesalarissen wijzigen! Oeps.”)

Samenhang & Consistentie

Dat een applicatie alle functies op de lijst van eisen bevat, wil nog niet zeggen dat ze ook te gebruiken zijn. De samenhang van functies en de gelijkvormigheid van systeeminteracties maakt de applicatie voorspelbaar en breed inzetbaar.

Anders dan de rest

Eén stijl

Ten eerste moet de lay-out consistent zijn. De kleuren, lettertypen en de vlakverdeling zijn een houvast voor de gebruikers. Ze maken de applicatie herkenbaar en bieden houvast bij navigatie (“waar ben ik?”). Doordat alle webapplicaties in dezelfde browser, hetzelfde window op je scherm staan is dit tegenwoordig onmisbaar.
En als de gebruikersinterface steunt op een metafoor, moet die metafoor ook consequent doorgevoerd zijn.

Eén ding, één naam

Ook de terminologie snakt naar consistentie. Als je bijvoorbeeld klikt op een link die belooft te leiden naar een “Registratieoverzicht”, mag de pagina waarop je uitkomt niet “Inschrijvingenrapportage” heten, ook al is dat synoniem. Dezelfde naam voor hetzelfde artefact door de hele applicatie dus.
Soms is dit verrassend lastig, omdat bij automatisering van bedrijfsprocessen taken voor het eerst een unieke naam moeten krijgen. Een nieuwe naam bedenken dus en die meteen consequent inzetten, zowel in de applicatie (makkelijk) als in de organisatie (moeilijk).

Eén taak, één manier

Tenslotte moeten systeeminteracties gelijkvormig zijn. Als je een weekrapportage op dezelfde manier opvraagt als de jaarrapportage, hoef je die handeling maar één keer te leren om het allebei te kunnen.
En als je beide rapportages exporteert, voelt het natuurlijk raar als er één in Excel97 en de ander in Excel2007 formaat uitkomt. (Eigen ervaring!)

De keerzijde

Nu een situatie uit het harde leven. Met Conceptuele Integriteit heb je als productmanager telkens alle features waaraan men begonnen is, vol vertrouwen naar vervolmaking gestuurd. Het projectbudget is bijna op, oplevering (van de Scrum sprint) in zicht. Gesteund door je toetsing aan Conceptuele Integriteit concludeer je geschrokken dat één applicatieonderdeel nog niet klaar is. Maar er is ook niet genoeg budget meer om het af te bouwen. Het is geen extra investering of vertraging waard. Wat dan?
Welnu, dan snijd je het rottende orgaan uit de patiënt. Een half werkend feature is geen feature. Het is ballast.

Auw! Dat doet zeer dokter!

In Scrumprojecten, adviseer ik de klant (product owner) over Conceptuele Integriteit, in plaats van er zelf over te beslissen. Dat is een ‘world of pain’.  Ik vermoord niet alleen het hobbyproject van een collega, maar ik doe ook de klant pijn als ik vraag afstand te doen van een half voltooid feature. Dit voelt de klant als een misdaad, als kapitaalvernietiging. Houd de tissues in de aanslag!

Waardeloze, kostbare ballast

Jammer maar helaas

Maar een onaf feature is ballast:

• het belooft een ontwetende gebruiker waarde en stelt hem dan keihard teleur
• het levert negatieve, nettowaarde
• het verwart ontwikkelaars tijdens onderhoud. “Wat is dit nu weer? Dit werkt niet eens!“
• het neemt waardevolle ruimte in, op het scherm en in ieders gedachten

De tijdsinvestering die gemoeid is met het orgaan heeft geld gekost. Maar kapitaal is het niet, want die investering heeft geen waarde opgevelerd. Wat aan het eind van de rit niet werkt, dat zet je buiten de deur. Een programmeur wist alle sporen ervan, de onafgeronde resultaten gaan in quarantaine (versiebeheersysteem) en daarna praten we er niet meer over. Een gezondere applicatie is het resultaat.

Het beoordelen van conceptuele integriteit vereist domeinexpertise en een zakelijke blik. Het is soms confronterend, maar zeker de moeite waard. En als de applicatie dan live gaat, is de kans het grootst dat alle betrokkenen werkelijk iets te vieren hebben wat later geld oplevert!

Met dank aan Marco Plaisier, sparringpartner in de voorbereiding en aangever van de term Conceptuele integriteit.