De betaalde software die niets oplevert: als 80 % van de functies niemand dient

U financiert de ontwikkeling van een software, uw team of uw dienstverlener levert functionaliteit na functionaliteit op, en toch stelt het resultaat teleur. Dat is geen indruk: studies tonen dat tot 80 % van de functionaliteiten van een softwareproduct bijna nooit wordt gebruikt. Dat is één ontwikkeling op twee, soms meer, voor niets betaald. De oorzaak is niet technisch, en de ontbrekende schakel heeft een precieze naam: de Product Owner.

Een kmo investeert in de ontwikkeling van een tool op maat, of in de evolutie van een bestaand platform. De weken gaan voorbij, het budget loopt, het technische team levert gewetensvol wat men heeft gevraagd. Dan komt het echte gebruik, en de koude douche: de gebruikers benutten maar een handvol schermen, negeren de helft van de functies, en vragen eenvoudige dingen die net nooit geprioriteerd zijn. De software werkt perfect. Ze dient enkel niet veel. Die verspilling heeft één enkele oorsprong: niemand heeft beslist wat echt telde.

Het cijfer dat de sector kent en verzwijgt

De gegevens zijn bekend bij de professionals en worden zelden aan klanten gezegd. De Standish Group heeft, door het reële gebruik van functionaliteiten in bedrijfstoepassingen te analyseren, vastgesteld dat 64 % ervan zelden of nooit wordt gebruikt, waarvan 45 % nooit. Recenter vond softwarebedrijf Pendo, op basis van gebruiksgegevens van honderden softwareproducten en tienduizenden applicaties, nog erger: ongeveer 80 % van de functionaliteiten wordt zelden of nooit gebruikt, en slechts ongeveer 12 % genereert 80 % van het dagelijkse gebruik. Omgezet in geld betekent dat dat het merendeel van de ontwikkelingsinspanning van de meeste producten dingen financiert die de gebruikers niet genoeg waarderen om ze te gebruiken.

Het echte probleem: niemand zegt neen

Waarom bouwt men zoveel nutteloze dingen? Omdat in de meeste projecten elke belanghebbende zijn vragen toevoegt zonder dat iemand arbitreert. De commercieel wil die optie, de boekhouding een andere, een belangrijke klant heeft een functie geëist, de leider heeft een idee gehad in een vergadering. Bij gebrek aan een verantwoordelijke die hiërarchiseert en weigert, zwelt de perimeter aan, voert het technische team alles uit, en lost het budget op in functionaliteiten die niemand zal gebruiken. Softwareontwikkeling mislukt bijna nooit door een gebrek aan technische competentie: ze mislukt door een teveel aan gebouwde dingen en door de afwezigheid van prioritering. Men verwart activiteit met waarde.

De Product Owner, die beslissende schakel

In de agile methodes bestaat er precies één rol om dat probleem op te lossen: de Product Owner. Zijn opdracht is niet coderen, het is beslissen. Hij houdt en hiërarchiseert het boek van de vragen, hij vertaalt de businessbehoefte in duidelijke prioriteiten voor het technische team, en vooral hij beslist: wat men nu doet, wat men uitstelt, wat men nooit zal doen. Hij vormt de brug tussen de leider die de businesswaarde kent en de ontwikkelaars die de technische kost kennen. Hij is het die garandeert dat elke euro ontwikkeling naar wat opbrengt gaat, en niet naar wat hindert. Zonder die rol stevig opgenomen, drijft een softwareproject bijna altijd af naar de catalogus van nutteloze functies.

Waarom kmo's die rol niet hebben, en hoe u ze wel krijgt

De meeste kmo's hebben geen Product Owner. De leider heeft er de tijd niet voor en niet altijd de methode, het technische team komt ertoe businessprioriteiten te beslissen die het niet beheerst, en de externe dienstverlener bouwt wat men bestelt zonder de relevantie te challengen. Het resultaat is voorspelbaar. Toch vereist die rol geen voltijdse aanwerving: ze vereist methode, aanwezigheid op de sleutelmomenten, en het mandaat om te beslissen. Dat is precies wat een Product Owner in deeltijd brengt, door de ontwikkeling te cadanseren, de prioritering vast te houden, en het budget te beschermen tegen de inflatie van de vragen. Het rendement is snel meetbaar: minder gebouwde functies, meer nuttige functies.

Minder bouwen, meer waarde opleveren