Elke werkdag behandelt Computable een onderwerp waarover lezers kunnen discussiëren. Vandaag over 'ondergebruik' van software, door functionaliteitsoverkill.
Net zoals de mens maar een beperkt percentage van zijn brein benut, zo is veel functionaliteit van software niet of nauwelijks gebruikt. Volgens onderzoek door NovioData, in opdracht van Info Support, zou slechts 40 tot 60 procent van zakelijke softwarefuncties in de praktijk worden gebruikt. Ofwel, 60 tot 40 procent wordt níet gebruikt. It-leveranciers en it-managers overschatten dus het gebruik en daarmee ook nut van bedrijfssoftware.
De eindgebruikers betrekken in het ontwikkeltraject is een advies dat het gratis onderzoeksrapport geeft. Maar wat ook niet onderschat moet worden, is het belang van degelijk design. Functies moeten duidelijk aangedragen worden aan de gebruikers. Hoe? Met grotere tooltips dan maar? Voormalig Office- en Windows-topman Steve Sinofsky heeft lang geleden bij Microsoft een presentatie gemaakt om de absurditeit van zichtbaarheid aan te tonen voor iconen in Word. Toch is duidelijkheid te prefereren. Goed design moet gebruik vooruit helpen. Wat vind jij?
“Een methode om ervoor te zorgen dat eindgebruikers voortdurend worden bediend in hun wensen en behoeftes, is Continuous Delivery”. Waar. Maar ook vaak een garantie om op termijn een gigantische overkill aan functionaliteit te laten ontstaan want eindgebruikers kunnen eindeloos doorbedenken wat allemaal nodig is. In bepaalde situaties kan het omgekeerde, gebruikers vooral niet te veel betrekken, ook een prima aanpak zijn.
Ad, er zit een verschil tussen gebruikers en klanten.
En klanten niet teveel te betrekken is niet raadzaam als je Continuous Delivery wilt toepassen. Het leent zich wellicht ook niet voor toepassing.
De kosten overigens van *iedere* functionaliteit wordt zeer vaak onderschat. Elke functie kost niet alleen geld om te maken, maar ook om te testen en te onderhouden.
De modus operandi van Continuous Delivery is ongeveer dit.
Je bedenkt een oplossing voor een probleem. Je maakt de specs voor een MVP (minimum viable product), je maakt een paar scrum sprints om dit te realiseren en released dit naar een klant die het daadwerkelijk toe gaat passen. Vanaf dat moment ontstaat er feedback van de klant al dan niet op basis van de gebruiker. Deze feedback beoordeel je in wel of niet wenselijk, en als het wenselijk is neem je het op in de backlog. Developers gaan deze inschatten en op basis van prioriteit neem je deze mee in een sprint. Een sprint levert altijd een werkend product op basis van de definition of done en met je DevOps heb je als het goed is al een soort geautomatiseerde OTAP straat opgezet om uit te leveren naar je klanten.
Deze manier van werken zorgt voor voorspelbare veranderingen op basis van wat klanten aanmerken als belangrijk. Het zou er dus altijd moeten leiden tot meer product waarde, tot een function overkill zou dit nooit mogen leiden, dan ben je ergens uit de bocht gevlogen door je criteria niet goed in te stellen.
Overigens kan het verwijderen van een funcionaliteit dit bijvoorbeeld overbodig geworden is ook op eenzelfde manier worden uitgevoerd. Dit levert OOK geld op gezien het begin van mijn reactie dat iedere functionaliteit door de tijd heen geld blijft kosten.
Als je producten laat groeien op basis van echte klantwensen dan zou function overkill er vooral moeten zijn voor nieuwe klanten met beperkte behoeften.
Er is een leuk boek op de markt onder de titel “Why software Sucks and what you can do about it” Van een professor die de absurde functionaliteit in software beschrijft en bekritiseert. het lezen waard.
Steve Sinofsky zou een prijs verdienen voor het maken van software functionaliteit waar echt helemaal niemand op zit te wachten. Ik schat in dat van office maar 5% van de functionaliteit wordt gebruikt omdat niemand begrijpt wat welke functionaliteit doet of kan doen of oplevert.
Eindgebruikers betrekken is wel een erg open deur als conclusie van het rapport….
Ik ben altijd al een voorstander van minimalisme met een maximaal rendement, dus start met lean ontwerpen, discussieer over het nut en de noodzaak van elek functie met de gebruiker en probeer ook zoveel mogelijk automatisch te doen.
Denk maar eens aan die foutmeldingen in bijvoorbeeld Excel, als je een + of = teken vergeet, hoe irritant is dat al meer dan 20 jaar…De software weet dat je iets vergeet en kan een suggestie doen om het op te lossen, maar komt vervolgens met de kritiek dat er iets mist. Echt allemaal heel ouderwets…