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?
Reacties
Bij de meeste gezinsauto's wordt in 80% van de tijd maar 20% van de capaciteit gebruikt: er zit dan maar 1 persoon in.
Is dat erg? Nee, want bij vakanties is het wel handig als er 5 personen plus bagage in past.
Met software is het ook zo: voor het dagelijkse gebruik wordt maar een klein deel van de mogelijkheden gebruikt. In sommige gevallen wordt er iets meer functionaliteit gebruikt. Een "overkill" aan functies is zelfs gewenst, want dan hoef je niet meteen te migreren naar nieuwe software als je eisen veranderen.
Een functionaliteitsoverkill, mits de functionaliteit relevant is voor het core product, is dus zeer gewenst.
@Frank: betaal jij in een restaurant voor de hele kaart, terwijl je maar drie gerechten aankunt? Of koop je een seizoenkaart, terwijl je maar 4 keer kunt? Wordt je lid van de golfclub als je maar 6 keer per jaar gaat golfen? Heb je een volledig abonnement op de krant, terwijl je hooguit op zaterdag de tijd hebt hem te lezen? Nee toch?
Maar ja, het lijkt een beetje de tendens van deze tijd: het hele jaar contributie betalen, terwijl je maar 1 x in de twee weken gaat fitnessen. Betalen voor 60 tv zenders, terwijl je er hooguit 12 regelmatig kijkt.
Waar iedereen in de supermarkt gaat voor ‘3 halen 2 betalen’, lijkt het op andere vlakken het tegenovergestelde en iedereen vindt dat nog normaal ook.
Nee, ik zie wel wat in deze stelling. Veel krijgen voor je geld is niet altijd recht evenredig aan je geld efficiënt besteden.
Gewenning aan het feit dat veel software zoveel mogelijk toeters en belle heeft speelt ook mee.
Dat is sinds de komst van 'apps' wel wat veranderd maar daar is weer een andere gewenning van toepassing dat het allemaal zo simpel mogelijk moet zijn.
Eigenlijk moet het nu zo simpel mogelijk maar wel zoveel mogelijk toeters en bellen hebben.
Ook simpele pakketsoftware voor de consument is vaak veel te ingewikkeld. Zoals voor het ontwerpen van je huis of je tuin. Die IT-ers maken het allemaal veel te mooi en daardoor te complex en daardoor onbruikbaar. Goed bedoeld ongetwijfeld.
Quote hk:
@Frank: betaal jij in een restaurant voor de hele kaart, terwijl je maar drie gerechten aankunt? Of koop je een seizoenkaart, terwijl je maar 4 keer kunt? Wordt je lid van de golfclub als je maar 6 keer per jaar gaat golfen? Heb je een volledig abonnement op de krant, terwijl je hooguit op zaterdag de tijd hebt hem te lezen? Nee toch?
Nee, hk, dat doe ik allemaal niet, omdat het pure BS is (restaurant) of omdat dat niet hoeft (de rest)!
Kranten kun je kopen op de dagen dat je er de tijd voor hebt, in het restaurant betaal je alleen voor wat je eet (en in all-you-can-eat restaurants betalen kleine eters mee aan de maaltijd van de grote eters).
Software is iets compleet anders dan de zaken die jij opnoemt. Je kunt de volledige executable leveren, en middels licenties alleen die delen vrijgeven die je hebt betaald en dus gebruikt. Of, in het geval van bv een office pakket: je hebt het hele pakket, en gebruikt de delen die je nodig hebt. De onderdelen die je niet gebruikt, bederven niet zoals eten kan bederven, of verouderen niet zoals nieuws uit een krant na een dag al oud nieuws is.
Analogieën zijn altijd gevaarlijk, want het is per definitie appels met peren vergelijken. Alleen in jouw geval is het appels met olifanten vergelijken.
Ik hou het liever bij mijn appels met perenvergelijking, de auto waarvan de capaciteit bijna nooit 100% gebruikt wordt.
En eigenlijk vind ik het probleem van deze discussie helemaal niet zo groot als je bedenkt dat er tot 60% van de functionaliteit wél gebruikt wordt. Ik had dat echt veel lager ingeschat!
Om weer even terug te gaan naar jouw restaurantvoorbeeld: er zijn mensen die veel minder dan 60% opeten van wat ze voorgeschoteld krijgen. En de restanten gaan direct de kliko in. Dat is pas verspilling!
Een waar woord "het belang van degelijk design".
Voor software zijn er grofweg 2 mogelijkheden.
1. altijd het komplete pakket en een overzichtelijke bediening
2. een slank kernpakket en uit te breiden met modules
Wat het beste functioneert hang af van de branche, bij grote 3d-planningssoftware in de bouw, hebben modules hun plaats. Bij een officepakket nauwelijks.
De kunst is een userinterface te bouwen (degelijk design) dat de meest gebruikte functies direkt ter beschikking stelt en de uitgebreidere functies met weinig kliks of een shortcut snel laat bereiken.
Bij "konfektie-software" zul je altijd een beperkt deel gebruiken omdat gebruikers nu eenmaal verschillende wensen en eisen hebben.
@Frank: ik begon niet met de analogie ;-)
Waar het om gaat is dat we in bepaalde gevallen kennelijk bereid zijn 100% te betalen voor iets dat we niet 100% benutten.
De hamvraag is dan: moet je 100% functionaliteit leveren, terwijl die maar door 20% van de gebruikers wordt gebruikt, of moet je 60% functionaliteit leveren voor 80% van de gebruikers, terwijl je weet dat ze ook voor die 100% willen betalen?
Het antwoord daarop is vanuit commercieel oogpunt gezien niet erg moeilijk, toch?
Toch blijf ik hopen op software versies waarbij je van te voren kan aangeven welke functies je wilt gebruiken en daar dan evenredig voor betaalt. Met een soort pay-per-use (wat op zichzelf al een goed begin is) in de Cloud zou dat moeten kunnen.
Diepere analyses in 100 bedrijven geven 100 verschillende zogezegd optimale oplossingen. Dan blijft alleen puur maarwerk over, met alle bekende problemen. Bij een degelijk pakket zijn de meeste fouten opgelost. En die bestaan weet ik uit eigen ervaring.
Pakketten die alleen de sympthonen bieden geven geen echte ondersteuning die het peil en service van een organisatie verhoogt. Dan moet je bij iedere stap als gebruiker zelf rekening houden met randvoorwaarden. Ook daar zijn genoeg populaire voorbeelden van. In werkelijkheid is niets eenvoudig. Het doel van een aantal pakketverkopers: alleen licensies, maatwerk, en helpdeskfacturen.
@hk:
Wil je wel altijd pay-per-use? Ik denk dat je dat per dienst moet gaan bekijken. Kijk je af en toe een film of serie, dan is per film betalen waarschijnlijk voordeliger. Kijk je elke avond wel een film en een serie of wat, dan is NetFlix veel goedkoper. Maar een NetFlix abonnement is net als een kabelabonnement: je betaalt wat de gemiddelde kijker aan betaalde content consumeert. Je betaalt dus nooit 100%, je betaalt nog geen procent van de kosten van alle individuele series en films bij elkaar opgeteld.
Bij NetFlix geldt hetzelfde als bij een all-you-can-eat restaurant: de weinigeters/kijkers betalen mee aan het (kijk)voer van de veeleters/kijkers!
Overigens, sommige dingen kun je niet opsplitsen, of moet je niet willen opsplitsen. Soms heb je atomaire (software) modules die je als softwaremaker niet aan wilt passen, om zo de beheerskosten niet te hoog te maken: elke module moet getest en goed zijn. Zo heb je een module Tekstverwerken, die altijd inclusief afdrukken, tabellen en woordafbreken wordt geleverd, ook al druk je nooit iets af, maak je nooit tabellen, en heb je woordafbreken uit staan.
@hk
Wanneer het maatwerk betreft, wil ik niet betalen voor functies die ik op dit moment niet gebruik, maar volgend jaar misschien wel. Ik wil namelijk ook niet volgend jaar moeten overstappen op een nieuw pakket.
Uiteindelijk gaat het om risico's en kosten.
"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...