De kosten van slechte softwarekwaliteit

Quality Software

Onlangs kwam het rapport ‘The Cost of Poor Software Quality in the USA 2020’ onder mijn aandacht, en ik was er behoorlijk onder de indruk van. Daarin staat dat organisaties tegenwoordig worstelen met de balans tussen snelheid van ontwikkeling en de kwaliteit van de applicaties en het onderhoud ervan. Omdat softwarekwaliteit vaak wordt beschouwd als ‘impliciet OK’, of ‘moet goed zijn omdat we alle bugs die we in al onze tests hebben gevonden hebben verwijderd’, wordt softwarekwaliteit en het effect ervan op de kosten voor onderhoud in de praktijk niet op grote schaal gemeten.

Het rapport toont aan dat de kosten van slechte software kwaliteit in de VS meer dan 2 biljoen dollar is. De meeste van deze kosten zijn gerelateerd aan productie-incidenten en het verlies van business als gevolg daarvan. Echter, daarnaast wordt 260 miljard US Dollar besteed aan mislukte IT-projecten. In de meeste gevallen is er onvoldoende aandacht voor kwaliteit en vaak worden deze projecten ook te optimistisch geschat.

Hoewel de bedragen in Nederland gelukkig veel lager liggen, worden dezelfde uitdagingen geconfronteerd als in de VS. Veel organisaties hebben een agile manier van werken gekozen, waarbij er de focus ligt op het zo snel mogelijk leveren van de meeste bedrijfswaarde. Het kwaliteitsaspect wordt vaak gedekt door tests en ontwikkelaarstools die op codeniveau meten, zoals bijvoorbeeld het veelgebruikte SonarQube. Dit zijn goede maatregelen, maar meestal niet voldoende. Het is belangrijk om te meten op systeemniveau, waarbij alle verbindingen tussen componenten, modules en lagen worden geanalyseerd. Bij Metri gebruiken we technologie om de kwaliteit van software op systeemniveau objectief te meten, tegen alle internationale normen en best practices. We rapporteren dit op managementniveau en bieden bruikbare inzichten aan ontwikkelaars: waar in de code kritische schendingen worden ontdekt, waarom dit kritieke schendingen zijn (met referentie naar de betreffende standaard of best practice) en vaak ook hoe deze op te lossen. Op deze manier kan het management inzicht krijgen in de trends in kwaliteit en bijbehorende risico’s en kunnen ontwikkelaars de code op een systematische en gerichte manier verbeteren, waardoor de systeemkwaliteit wordt verhoogd tegen weinig mogelijk inspanning.

De algemene aanbevelingen van het Consortium for IT Software Quality (CISQ) voor 2021 en daarna blijven de nadruk leggen op preventie. De beste aanpak is om zwakke punten en kwetsbaarheden in software zo snel mogelijk te detecteren en te corrigeren, bij voorkeur daar waar ze zijn geïnjecteerd, om de aangerichte schade en kosten voor het repareren te beperken. Meer specifiek  worden de volgende aanbevelingen gedaan voor softwareontwikkelingsorganisaties:

  • Vermijd ontwikkeling standaarden van lage kwaliteit en pas veilige coderingsstandaarden toe.
  • Erken de inherente moeilijkheden van het ontwikkelen van software en gebruik effectieve tools om te helpen omgaan met deze problemen.
  • Zorg voor een vroege en perdiodieke analyse van de ontwikkelde broncode om kritieke schendingen, zwakke punten en kwetsbaarheden vroegtijdig op te sporen.
  • Meet structurele kwaliteitskenmerken, zoals Robuustheid, Efficiency, Security, Onderhoudbaarheid en Overdraagbaarheid.
  • Focus op de evaluatie van opgenomen componenten (bijvoorbeeld open source) en platforms die onbekende zwakke punten of kwetsbaarheden kunnen hebben.
  • Verkrijg meer informatie over de typische kwetsbaarheden en misbruikbare zwakke punten die zijn toe te schrijven aan bepaalde programmeertalen.
  • Gebruik de best practices voor het beheer van een legacy-systeem – vooral als het gaat om het kennismanagement van hoe het systeem intern werkt. Benchmarking van de software risico’s en kwaliteit is een goede plek om te beginnen.
  • Vermijd mislukte projecten door deze professioneel te begroten door gecertificeerde Software Cost Estimators.
  • Besteed aandacht aan gedefinieerde kwaliteitsdoelstellingen en meet deze doelstellingen gedurende de hele levenscyclus van het project.
  • Investeer slim in verbeteringen in de kwaliteit van de software op basis van CPSQ-nummers.
  • Focus op de verschillende resultaten van goede versus slechte softwarekwaliteit in uw organisatie  en relevante benchmarkorganisaties. Door te proberen CPSQ te verbeteren, zullen andere economische doelgebieden worden beïnvloed, bijvoorbeeld eigendomskosten, winstgevendheid, menselijke prestatieniveaus, innovatievermogen en de effectiviteit van uw bedrijfskritieke IT-systemen.

Het klinkt misschien ongelofelijk, maar de diensten die Metri biedt als onderdeel van haar IT Intelligence propositie dekken eigenlijk al deze aanbevelingen.

Het is interessant om te zien dat CISQ een factor 5 tot 10 verschil ziet tussen goed presterende teams en slecht presterende teams, vergelijkbaar met de resultaten die Metri ook waarneemt in de Agile Team Performance Monitor studies die we hebben uitgevoerd. CISQ analyseerde de verschillen tussen de top 10% performers en de onderste 10% organisaties die ze bestudeerden. Wanneer u dieper in de gegevens graaft, is de duidelijke reden de toepassing van bepaalde kwaliteit en proces best practices.  

De belangrijkste enablers voor het bereiken van de beste kosten, planning en kwaliteitsprestaties zijn:

  1. Een goed gedefinieerd, maar aanpasbaar ontwikkelingsproces
  2. Uitstekende begrotingsmethoden (zie de Metri Cost Estimation suite: link)
  3. Projectmanagement discipline
  4. Uitstekende medewerker vaardigheidsniveaus
  5. Kwaliteitsvisie
  6. Focus op klanttevredenheid
  7. TQM managementcultuur
  8. Foutpreventie
  9. Voortgang en kwaliteit meten

Metri helpt haar klanten bij het implementeren van deze key enablers, terwijl ze verbeteringen en de voordelen meet. In bijna elke organisatie zal een verhoogde focus op kwaliteit resulteren in een lagere Total Cost of Ownership, vooral wanneer softwarefouten op een gerichte en kostenefficiënte manier worden opgelost.

Wil je meer weten?

Vul onderstaand formulier in om zelf een afspraak in te plannen voor een vrijblijvend gesprek. Kom je er niet uit? Bel ons dan op 020 655 1777.

Cloud readiness is een kwestie van meten

Stel, je overweegt je applicatieportfolio naar de public cloud te migreren. Hoe kies je een migratiestrategie? Er is maar één manier om deze te bepalen: op basis van feiten. Hieronder leg ik je uit hoe je dat kunt doen, en waarom je ten aanzien van je applicaties geen one size fits all-benadering kunt hanteren.

Bij het ontwikkelen van een migratiestrategie moet je keuzes maken. Deze keuzes, die voor iedere applicatie gemaakt moeten worden, liggen wat genuanceerder dan een simpele keuze tussen ‘lift and shift’ of de gehele applicatie vervangen. Sommige applicaties zijn geschikt om te landen op een PaaS-infrastructuur, terwijl andere van IaaS gebruik zullen maken. Ook zijn er applicaties die goed functioneren op een mix van IaaS en PaaS in de public cloud. Ten slotte kun je ook helemaal afscheid nemen van een applicatie, waarbij je kunt denken aan herbouw, of aan het inkopen van vergelijkbare functionaliteit als SaaS.

Per applicatie zijn er dus een aantal mogelijkheden in een migratieproject. Adviesbureau Gartner gebruikt het 5R-model om migratiepaden van applicaties te classificeren. Dit model stelt 5 paden voor, die variëren in de benodigde migratie-inspanning enerzijds en de haalbare cloud-voordelen anderzijds. Het is nu zaak om voor iedere applicatie het juiste migratiepad te kiezen. En nogmaals, dat doen we op basis van feiten.

Inzet migratie Metri

Metri kan deze feiten boven water halen, waardoor je voor iedere applicatie het juiste migratiepad kunt kiezen. Met slimme software kunnen we in korte tijd een groot aantal toepassingen in het applicatielandschap analyseren. Deze analyses leveren een compleet beeld van de gezondheid van een applicatie, waarbij cloud-geschiktheid een factor is.

Software Health Metri

De analyse van de gezondheid, gecombineerd met de business-impact van een applicatie, helpt ons om, goed onderbouwd, een aantal migratiepaden te overwegen:

  • Replace’: het gaat hier om applicaties met een lage business-impact en een slechte gezondheid. Vervanging van deze applicaties zal de bedrijfsvoering beperkt raken, terwijl de software in een te slechte conditie is voor het behalen van cloud-voordelen.
  • Revise’: dit zijn applicaties met een hoge business-impact en een goede gezondheid. Deze applicaties hebben een dusdanig hoge kwaliteit dat inzetten op cloud-voordeel reëel is. Door de hoge business-impact zijn deze toepassingen here to stay.
  • Rehost’: dit gaat om applicaties met een gemiddelde business-impact en van goede kwaliteit. Deze applicaties krijgen in beginsel niet genoeg prioriteit voor een intensieve revisie.

Het is duidelijk dat nog niet alle applicaties geraakt worden door bovenstaande analyse. Om ook over de overgebleven toepassingen een oordeel te kunnen vellen, zullen we moeten inzoomen en nieuwe inzichten moeten genereren.

Cloud readiness Metri

Door ook te kijken naar de individuele geschiktheid van applicaties voor de cloud, kunnen we nieuwe keuzes maken. In bovenstaand overzicht introduceren we de cloud readiness-score. Deze score drukt specifiek uit in hoeverre softwarecode geschikt is om in een cloud-omgeving te landen. Met de combinatie van business-impact en cloud-readiness kunnen we nieuwe conclusies trekken:

  • Rebuild’: het gaat om applicaties met een hoge business-impact en een lage cloud readiness. Deze applicaties zijn kritiek voor de bedrijfsvoering maar niet geschikt om in een cloud-omgeving te landen. Door de hoge business-impact is een investering in herbouw rendabel.
  • Refactor’: dit zijn de overgebleven applicaties met een redelijk gezonde cloud readiness-score. Deze applicaties kunnen met beperkte inspanning geschikt worden gemaakt voor cloud-infrastructuur.

Met bovenstaande voorbeelden probeer ik een versimpeld maar toegankelijk beeld te geven van een van de mogelijkheden van de overkoepelende dienstverlening van Metri om applicatieportfolio’s te beoordelen. Met geavanceerde tooling kunnen wij in korte tijd een geheel applicatieportfolio en een groot aantal aspecten van de software in kaart brengen. Bestuurders gebruiken deze inzichten onder andere voor:

  • Beheersing van risico’s als gevolg van software van lage kwaliteit
  • Kostenbesparingen
  • Het toewijzen van de juiste middelen aan de juiste applicaties

Metri meet een applicatieportfolio in zeer korte tijd, op een gestandaardiseerde en automatische manier. Vervolgens presenteren we de resultaten over een aantal assen, waarbij je met slechts één muisklik dieper kunt ingaan op de materie.

Het bepalen van een migratiestrategie is dus een kwestie van meten, presenteren en kiezen. Op deze manier wordt de drempel voor het ontwikkelen van een concrete migratiestrategie een stuk lager.

Wil je meer weten?

Vul onderstaand formulier in om zelf een afspraak in te plannen voor een vrijblijvend gesprek. Kom je er niet uit? Bel ons dan op 020 655 1777.

De kosten meten van change versus run binnen agile teams

Bron: Harold van Heeringen (Metri) en AGconnect

De meeste CIO’s hebben de opdracht om zo veel mogelijk business value te leveren, via IT, tegen zo laag mogelijke kosten. De vraag dient zich dan aan: hoe meten we business value en over welke kosten hebben we het dan? Business value is een zeer lastig te meten concept, volgens velen zelfs onmeetbaar. Daar zijn gestandaardiseerde methodes voor. Harold van Heeringen wijst er echter op dat niet alleen de functionaliteit die wordt opgeleverd bepalend is voor de business value, maar dat de kwaliteit daarvan ook zeer sterkt meetelt in deze metingen.

Over het algemeen is men het er wel over eens dat het ontwikkelen, wijzigen en/of verwijderen van softwarefunctionaliteit in ieder geval een belangrijk onderdeel van het creëren van business value is, mits de gevraagde en geleverde functionaliteit daadwerkelijk waarde oplevert voor het bedrijf. De ontwikkelkosten bestaan onder andere uit werkplekken en ontwikkeltoollicenties, maar vooral ook uit de bestede uren van mensen. Hoewel het zeker interessant is om bijvoorbeeld via een benchmark te besparen op werkplekken en licenties, focust dit artikel zich vooral op de bestede mensuren.

‘Vroeger’ werden er projecten opgestart om softwarefunctionaliteit te ontwikkelen, tegenwoordig zijn het vaak de agile werkende teams die aan een product werken en die periodiek een werkende versie van het product ter beschikking stellen aan de gebruikers. Je zou kunnen stellen dat hoe meer nieuwe en gewijzigde functionaliteit in een softwareproduct wordt verwerkt, hoe meer waarde dit zou moeten hebben voor de organisatie. De vraag is dan: hoe productief zijn de teams?

Productiviteit

Productiviteit is een kengetal waarmee de verhouding tussen inspanningen en resultaten inzichtelijk wordt gemaakt. De universele definitie is output gedeeld door de input. In softwareontwikkeling is dit bijvoorbeeld een aantal eenheden geproduceerde software gedeeld door een aantal uren inspanning.

In veel industrieën is dit een van de belangrijkste stuurmetrieken. In de IT weet men echter meestal niet hoe productiviteit objectief en gestandaardiseerd gemeten kan worden. Men wil het vaak wel, maar weet niet hoe. De reden hiervoor is dat het vaak relatief eenvoudig is de input te meten van de teams: de uren die worden besteed aan de verschillende activiteiten. Het wordt echter als moeilijk beschouwd om de output van softwareontwikkeling te meten op een gestandaardiseerde, objectieve manier.

Veel organisaties denken dat de output van agile teams gemeten kan worden in story points. Story points zijn een superhandig middel en nuttig voor het team, maar het betreft een subjectieve maat om een groepsinschatting te maken voor de hoeveelheid uren die nodig zijn. Metrieken gebaseerd op story points kunnen daarom niet buiten het team worden gebruikt om te schatten of om de productiviteit te meten. Zonder een gestandaardiseerde outputmetriek is vergelijken moeilijk.

Lastig maar belangrijk

Productiviteit is daarom in veel organisaties lastig te meten over de teams heen. Veel CxO’s hebben geen idee wat de productiviteit is van hun teams en hoe deze zich verhoudt met de markt. Maar de productiviteit bepaalt wel voor een groot deel de business value die geleverd kan worden, gegeven een bepaald budget. Het meten, vergelijken en verbeteren van de productiviteit van de teams is daarom een zeer belangrijke managementtaak.

Met formal-sizingtechnieken kan de functionele output van teams worden vastgesteld volgens ISO-gecertificeerde methoden, zodat teams onderling en met de markt vergeleken kunnen worden. Deze methode is al decennialang in gebruik en er zijn inmiddels veel data beschikbaar van gestandaardiseerde productiviteitscijfers in vrijwel alle technologieën. De standaard agile team performance metrics die worden gemeten en gebenchmarkt, zijn gebaseerd op de gerealiseerde functionele omvang: productiviteit, cost efficiency, delivery speed en sprint quality.

Metri Business Value

Business value

In de praktijk bevat het werk van agile teams meer dan het ontwikkelen van functionaliteit. In de bovenstaande figuur wordt duidelijk dat in de eerste sprint nog volop aan de functionaliteit kan worden gebouwd, maar dat naarmate er meer sprints zijn uitgevoerd, ook andere werkzaamheden de kop opsteken: de rode blokken. Daar waar de blauwe blokken te maken hebben met het creëren van businesswaarde, zijn de rode blokken weliswaar belangrijk, maar leveren deze niet direct zichtbare business value op.

Als er bijvoorbeeld een hoge-prioriteitincident optreedt door een probleem in de code, dan moet die code snel gerepareerd worden. De business vindt echter dat het incident nooit had mogen voorkomen. Onafhankelijk van de mate van volwassenheid van het team geldt dat hoe meer rode blokken er zijn en hoe groter deze rode blokken zijn, hoe lager de productiviteit is en hoe minder zichtbare business value geleverd kan worden. Er is echter een uitzondering hierop.

Kwaliteit

Bovenstaande figuur laat zien dat ook de kwaliteit van de applicatie belangrijk is. Een hoge productiviteit gaat soms ook gepaard met een steeds lager wordende kwaliteit van de applicatie, soms tot een punt waar in een of meerdere sprints moet worden gewerkt om de onderhoudbaarheid weer op peil te brengen. Binnen onze Agile Team Performance Monitor (ATPM)-metingen zien we dit vaak terug. We meten de kwaliteit van de software op de aspecten onderhoudbaarheid, robuustheid, security, efficiency en overdraagbaarheid tegen alle gangbare internationale standaarden en best practices. Het gericht verbeteren van de kwaliteit leidt tot minder verstoringen en snellere oplostijden. Door te focussen op de juiste code refactoring, en dan met name gericht op de onderhoudbaarheid, wordt dat rode blok mogelijk tijdelijk wat groter, maar vervolgens worden de andere rode blokken kleiner, terwijl de blauwe blokken groter worden bij gelijk bestede uren. Het gericht oplossen van technical debt lijkt dus in eerste instantie uren te kosten die ten koste gaan van de doorontwikkeling, maar uiteindelijk zien we in onze onderzoeken dat dit uiteindelijk veel oplevert: meer business value voor hetzelfde budget, minder verstoringen, lagere runkosten en uiteindelijk meer tevreden gebruikers en medewerkers.

Een praktijkvoorbeeld van twee teams 

Het standaardteam waarin geen extra aandacht is voor technical debt management, realiseert bij gelijkblijvende productiviteit minder functionaliteit door de tijd heen, omdat er steeds meer tijd besteed wordt aan het oplossen van issues. Het team dat voldoende tijd besteedt aan het voorkomen van deze issues, wordt productiever en levert uiteindelijk meer business value, terwijl het aantal verstoringen lager is.

De change-versus-run-kostenbalans binnen agile teams is dus sterk afhankelijk van de kwaliteit van de applicatie. Het gericht verbeteren of in stand houden van de kwaliteit lijkt counterproductief, maar levert uiteindelijk de meeste business value.

Meer weten?

Spreek direct een specialist, neem contact op met IDC Metri voor een snel en duidelijk antwoord:

De coronabezem door het portfolio

Coronabezem

De effecten van COVID-19 zijn wereldwijd voelbaar. In de gezondheidszorg, in stilgevallen bedrijven, maar ook in de politiek en de onderwijswereld heeft deze pandemie in een korte periode vele levens geraakt. Ook de IT van veel organisaties kraakt in zijn voegen. In een tijd die vorig jaar nog voor onmogelijk werd gehouden hebben veel organisaties het voor elkaar gekregen om hun bedrijfsprocessen door te laten draaien vanuit de huizen van hun medewerkers. Nu dat geregeld is en we tijd hebben om na te denken wat het ‘nieuwe normaal’ gaat worden en wat voor gevolgen dat heeft voor de bedrijfsvoering.

We zien steeds meer organisaties even een stap terug doen en nog eens kritisch kijken naar hun IT-portfolio. Hoe praktisch is het nog om de belangrijkste bedrijfsapplicaties on-premise te hebben, als daar nauwelijks nog gebruikers zijn te bekennen? Ook heeft COVID-19 laten zien dat lang niet alle applicaties zo essentieel blijken te zijn om de bedrijfsvoering door te laten draaien. Nu is het tijd om eens kritisch te bekijken wat er nodig is aan technologie om klaar te zijn voor de nieuwe toekomst. Tijd voor een – wat verlate – voorjaarsschoonmaak.

Waar de voorjaarsschoonmaak precies vandaan komt is niet helemaal duidelijk, maar het is een wijdverbreid gebruik in landen met koude, natte winters. In het voorjaar wordt het warm genoeg om de ramen open te zetten om het huis goed door te laten waaien, zonder je druk te hoeven maken over schadelijke insecten. Hierdoor kan de muffigheid uit het huis en kan het huis worden klaargemaakt voor het warmere seizoen met meer sociale activiteiten en vrije dagen. Door de voorjaarsschoonmaak wordt het huis weer gezond, zodat er weer efficiënt geleefd kan worden en er ruimte is voor nieuwe spulletjes.

Ook in het applicatieportfolio is het nu juist het moment om de ramen eens goed open te zetten en applicaties op te ruimen die we eigenlijk niet meer nodig hebben. Zo kunnen we ruimte maken voor nieuwe technologie die organisaties in staat stelt waar dan ook te werken en elkaar op een veilige manier te ontmoeten, zonder ons druk te hoeven maken over schadelijke virussen.

Helaas zijn er zijn nog te weinig betrouwbare statistieken, maar de verwachting is dat er minder op kantoren en meer in de buurt van thuis gewerkt gaat worden. Hierdoor moeten organisaties kritisch kijken naar hun vaste infrastructuur en zich meer richten op toegankelijk zijn via het internet. Zowel voor werknemers als klanten. Ook lijkt het erop dat COVID-19 zorgt voor een versnelde adoptie van cloudgebaseerd werken in veel organisaties.

Veel organisaties willen een digitale transformatie opstarten en hun applicatie landschap moderniseren, maar hebben geen goed overzicht van de technische staat van het portfolio en het bedrijfsbelang van de individuele applicaties. Ze weten niet goed waar te beginnen, kunnen geen gerichte keuzes maken en het opbouwen van het benodigde inzicht kan vele maanden duren.

Wacht dus niet tot het voorjaar, maar begin nu met het voorbereiden op uw nieuwe toekomst.

Meer weten?

Spreek direct een specialist, neem contact op met IDC Metri voor een snel en duidelijk antwoord:

Hoeveel rente betaal je over je technische schuld?

Geld lenen kost geld

Let op, geld lenen kost geld! Alle reclame-uitingen die ook maar iets naar krediet ruiken moeten deze slogan in Nederland gebruiken. Maar ja, waarom geldt dat nu niet voor de aanschaf van nieuwe software?

Het klinkt misschien gek maar ook hier is sprake van rente. We bouwen ‘technische schuld’ op doordat we nieuwe features snel laten opleveren om de architectuur up-to-date te houden. Het idee erachter: nu geld verdienen met nieuwe features, zodat die inkomsten straks gebruikt kunnen worden om de zaken die zijn blijven liggen weg te werken. Deze focus levert dus technische schuld op. Soit. Maar ook daar moet rente over betaald worden. En omdat er ook over die rente weer rente betaald moet worden, leiden zaken die we ‘even laten liggen’ tot zwaar achterstallig onderhoud.

Overuren

Rente op rente? Jazeker. Dit heeft vele oorzaken. Zo verspillen ontwikkelaars tijd door te bekijken hoe ze stukken code kunnen repareren waar ze niet meer zo bekend mee zijn en die ze er beter gelijk goed op hadden kunnen zetten. Ook het refactoren van code om te zorgen dat deze beter te beheren en te schalen is, had beter gelijk gedaan kunnen worden. Ook in de infrastructuur wordt rente betaald door het in de lucht houden van verouderde apparatuur. Of het maken van overuren door het snel opzetten en configureren van noodinfrastructuur om de IT draaiend te houden. Okay, een deel van dit soort rente is niet te voorkomen, maar je houdt de zaken wel beheersbaar als je regelmatig aandacht besteedt aan het afbetalen van technische schuld.

Hoe dan? Je kunt kijken naar de Cost of Delay en de Opportunity Cost van het wegwerken of niet opbouwen van technische schuld. Het kan zeker helpen om budget en tijd vrij te maken voor het wegwerken of voorkomen van technische schuld. Een van onze klanten heeft becijferd dat 5-10% van de nieuwe features niet kan worden uitgevoerd, omdat er te veel technische schuld zit in de systemen waar die features in verwerkt zouden worden.

Wetmatigheid

Toch gaat het niet alleen over te veel focus op nieuwe features. Het is voor een deel een wetmatigheid van het maken van software. Als je een systeem verstoort blijft de wanorde gelijk – of neemt toe. Dit geldt ook voor software.

Zelfs het beste systeem staat in de loop van de tijd bloot aan verval. Moeten we ons daarbij neerleggen? Zeker niet. We moeten ons wel meer bewust zijn van de natuurwetten. Zo moeten we voldoende aandacht geven aan de architecture runway van onze applicaties om te zorgen dat de architectuur van applicaties meegroeit met de complexiteit. Bij het realiseren van nieuwe features moet er een realistische balans zijn tussen de gewenste functionaliteit en de beschikbare doorlooptijd. Sneller opleveren gaat ten koste van de kwaliteit op langere termijn. Realistisch begroten van software ontwikkeling is een vak apart, waar we u graag bij helpen.

Ook het inzichtelijk maken van de complexiteit van applicaties helpt bij het tegengaan van technische schuld. Het af en toe bespreken van de architectuurplaat tijdens een retrospective is daarbij niet genoeg. Voor zeer complexe applicaties kan Metri zelfs de architectuur visualiseren.

Door breder te kijken dan alleen de nieuwe features waar (nieuwe) klanten blij van worden blijft de technische schuld beheersbaar. En daar helpt Metri u graag bij.

Kleine moeite, grote winst

IT kost veel geld. Vaak te veel als je het ons vraagt. Overal stijgen de kosten, want, zo is de redenering, alles wordt duurder en de vraag naar IT wordt door de vele veranderingen en vernieuwingen steeds groter. Toch laten veel bedrijven ook ontzettend veel geld liggen, zo blijkt uit onderzoek van Metri. Natuurlijk moet de focus altijd gericht zijn op het verbeteren en behouden van IT-diensten. Maar er zijn ook veel kansen op het besparen van kosten. Metri schotelt u er 10 voor.