ISBSGIk ben er sterk van overtuigd dat dit het geval is en ik ben vaak verrast en teleurgesteld dat meer organisaties geen functionele groottemaatregelen implementeren.

Productiviteit is een concept dat breed wordt besproken, van regeringen op nationaal niveau tot individuele bedrijven, in alle bedrijfstakken die goederen produceren of diensten verlenen. Voor de doeleinden van deze discussie, Ik neem productiviteit om de hoeveelheid hulpbronnen aan te duiden die wordt verbruikt om een ​​outputeenheid te produceren. De sleutel hier is dat er een uitvoer is die kan worden geïdentificeerd en geteld om te vergelijken met de gebruikte bron.

Bedrijfsleiders en hoofden van overheidsdepartementen machtigen regelmatig dat hun organisaties de productiviteit elk jaar verbeteren met ofwel, Grootteklasse van de tellingen van het monster, het produceren van meer output met hetzelfde niveau van middelen of dezelfde output met minder middelen. Ze zijn ook geïnteresseerd in de prestaties van hun organisatie in vergelijking met soortgelijke bedrijven waarmee ze concurreren.

In de IT-industrie is het niet anders. Voorbeelden zijn onder meer dienstverleners die hun concurrentievermogen moeten aantonen om zaken binnen te halen, Interne IT-afdelingen die moeten laten zien dat ze meer opleveren voor het bedrijf met de budgetten die ze toegewezen krijgen en Chief Financial Officers die ervoor moeten zorgen dat uitbestedingsovereenkomsten echte voordelen opleveren voor het bedrijf, niet alleen een goedkoper arbeidstarief.

Op het gebied van softwareontwikkeling, coderegels zijn gebruikt als maatstaf voor de geproduceerde output, maar met de komst van moderne ontwikkelingstechnieken en -tools is dit niet langer een bruikbare maatstaf in de meeste moderne omgevingen.

Een meer bruikbare techniek is om de output van een softwareontwikkelingsproject te meten in termen van de hoeveelheid functionaliteit die het aan de klant levert, ongeacht de gebruikte technologie/platform/ontwikkelingsmethodiek. Om dit te doen heeft men een gestandaardiseerd, herhaalbare manier om de geleverde bedrijfsfuncties te identificeren en te beoordelen en zo een numerieke waarde af te leiden voor de omvang van de geleverde software.

Enkele van de belangrijkste lessen die zijn geleerd bij het implementeren van Functional Sizing zijn:

Meet wat je doet en verbeter vervolgens

  • Tenzij u een baseline van de huidige prestaties heeft, is het niet mogelijk om een ​​verbeterprogramma te managen. Ik heb managers meerdere keren horen zeggen: “We willen de productiviteit verhogen met 10% per jaar” maar ze wisten niet wat de huidige prestatie was. Ook, je moet weten of de huidige prestaties goed zijn, gemiddeld of slecht. Afhankelijk van waar je staat, je kunt het begrijpen als je moet verbeteren, en als het zo is, hoeveel zou realistisch zijn. De ISBSG-gegevens kunnen u hierbij helpen.

Uw gegevens begrijpen en acties ondernemen.

  • Meten heeft weinig waarde, tenzij het wordt gebruikt om acties aan te geven die kunnen worden genomen om te verbeteren. Daarom is een proces van "Causale Analyse" vereist om de attributen/factoren/gebeurtenissen te begrijpen die resulteerden in de prestaties van elk individueel project.
  • Pas op voor de "driepotige kruk" van de kosten, kwaliteit en planning. Ze zijn allemaal onderling afhankelijk en mogen niet geïsoleerd worden beheerd.

Pas op voor misbruik van gegevens

  • heb ik ooit gehoord 2 senior Executives die opscheppen over de prestaties van hun IT-afdelingen met Uren/Functiepunt. Ze waren afkomstig van bedrijven in verschillende bedrijfstakken met substantieel verschillende bedrijven, dus een dergelijke vergelijking is bijna zinloos
  • Het gevaar van oversimplificatie bestaat. Omdat projecten, zelfs in vergelijkbare domeinen, zal wisselende resultaten opleveren, enige statistische basisanalyse die verder gaat dan alleen gemiddelden, is vereist om de resultaten goed te begrijpen.

Correlatie met inspanning

  • Het gebruik van functionele omvang om productiviteit te meten of in te schatten veronderstelt dat er voldoende correlatie bestaat tussen de omvang en de inspanning. Niet alle taken vereisen dat recht evenredig met de functionele omvang, moet dus mogelijk uit de productiviteitsberekening worden verwijderd en apart worden behandeld

Uren/FP of $/FP

Sommigen definiëren productiviteit Inspanning/ Eenheid van output, terwijl anderen de voorkeur geven aan Kosten / Eenheid van uitvoer. Elke statistiek heeft waarde omdat er vaak een verband bestaat tussen het arbeidsloon en het aantal uren dat nodig is om een ​​taak te voltooien. Ik raad aan om beide te gebruiken.

Ik ben benieuwd naar je ervaringen (goed en slecht) en vooral redenen waarom u geen functionele dimensionering heeft geïmplementeerd. Neem dan contact met mij op via john.ogilvie@isbsg.org als je geïnteresseerd bent.

 

Over de auteur

John Ogilvie is CEO van de International Software Benchmarking Standards Group.

 

Een blogpost vertegenwoordigt de persoonlijke mening van de auteur
en hoeft niet noodzakelijkerwijs samen te vallen met het officiële Nesma-beleid.
Deel deze post op:

1 Opmerkingen

Laat een reactie achter
  1. Wat jij omschrijft als de “driepotige kruk” van kosten, kwaliteit en planning is in mijn ervaring de reden waarom veel meetprogramma's mislukken. Ze slagen er niet in om de drie met elkaar in verband te brengen en te beheren – of nog erger – alleen kosten in een prachtige isolatie. Wanneer u zich alleen op de kosten richt, kunt u eindigen met zeer efficiënte softwareontwikkeling die niet oplevert wat een organisatie nodig heeft van hun IT-portfolio. Elk meetprogramma moet worden gefocust “de juiste dingen doen” eerste, voordat je ernaar kijkt “dingen goed doen”. Dat betekent kwaliteit voorop, dan plannen en dan kosten. Ik ben veel bedrijven tegengekomen die het andersom doen en dan falen.

Laat een antwoord achter