Hantera förändringar under förvaltning

2007-11-05 Artikelbanken Test Läst 7400 gånger

Förvaltaren som spindel i nätet har kontakter med många intressenter på både beställarsidan och leverantörssidan. Dessa intressenter har ofta olika uppfattningar om vad som ska prioriteras högst. Förvaltarens uppdrag från systemägaren är att säkerställa ett bra IT-system med god kvalitet som förvaltas på ett kostnadseffektivt sätt. Allt detta sammantaget gör förvaltarrollen svår. Eftersom det inte finns oändliga resurser, måste förvaltaren säkerställa en klok prioritering bland ändringsönskemålen samtidigt som man upprätthåller goda relationer även med de intressenter som inte får sina krav tillgodosedda i den här leveransen. Vem ska man lyssna på? Den som "skriker högst" eller den som sitter på pengarna?

Ingen av lösningarna är optimal, man måste väga in många faktorer och genomföra en strukturerad prioritering av ändringsönskemålen. För att minimera gnissel måste processen från det att ett förändringsönskemål uppstår tills det är beslutat vara känd och förankrad i organisationen. Processen måste även hantera ändringar som kan påverka andra system. En vanlig lösning är att använda ett förvaltningsråd där beslut fattas om ändringar ska genomföras eller inte.

Resultatet av en tydlig process för ändringar är också att brandkårsutryckningar undviks. Sådana leder till bristande arbetsro och om ändringar inte görs på ett strukturerat sätt kommer systemet att degenerera på sikt. Det finns också en risk att viktiga aktiviteter inte hinns med, exempelvis test.

Rutin för ändringshantering

Ändringar kan hanteras på många olika sätt. En vanligt förekommande rutin för ändringar börjar med att ett problem eller ändringsönskemål uppstår hos en användare. Användaren vänder sig till en systemadministratör eller till help desk som skapar ett nytt ärende. Ärendet skickas till systemförvaltaren och om ärendet är akut hanterar förvaltaren det direkt tillsammans med med leverantören eller en utvecklare internt. Många ärenden är av mindre allvarlig karaktär och samlas på hög för att gås igenom i ett förvaltningsråd i samband med planering av nästa version av systemet. En utvecklare genomför ändringen och återkopplar till systemförvaltaren som genomför tester tillsammans med en eller flera slutanvändare.

Hantera ändringar iterativt

Allt förvaltningsarbete bör bedrivas iterativt, i varv eller iterationer med ett annat ord.

 

Bild 1 - Iterativt arbete.

Varje iteration inleds med en kravhanteringsfas där man går igenom restlistan från föregående iterationer, dokumenterar nytillkomna krav, samlar in ytterligare krav, prioriterar kraven och fattar beslut om vad som ska göras i den kommande iterationen. Därefter designar man systemet, kodar ändringarna och testar systemet i separata faser. När en iteration är slutförd inleds nästa. Varje iteration omfattar vanligen 3-12 veckor. Om ändringarna är stora eller många kan de delas upp i flera iterationer där endast den sista iterationen avslutas med driftsättning. Det leder till högre kvalitet eftersom en ändring därmed testas flera gånger.

Genom att arbeta iterativt hanteras de flesta viktigaste kraven först men det innebär inte att de mindre viktiga kraven blir bortglömda. Intressenterna ska vara medvetna om att även "små, mindre viktiga" krav har sin plats i processen. Nyckeln är att processen ska vara känd, hela processen som täcker alla krav genom flera iterationer.

Aktiviteter under kravhanteringsfasen

Intressentanalys

Om man inte vet åt vilket håll man ska springa, spelar det ingen roll hur fort man springer. Om man inte vet vilka intressenterna är, spelar det ingen roll hur väldokumenterade kraven är.

Eftersom omvärlden ändras under systemets hela livslängd är det klokt att då och då genomföra en intressentanalys. Jag rekommenderar att intressentanalysen görs åtminstone en gång per år. Ett effektivt sätt att göra intressentanalysen är att arbeta iterativt. Börja med att i den första iterationen lista alla intressenter du kan komma på. Definiera sedan vad varje intressent vill ha från förvaltningen och/eller vad förvaltningen vill ha från intressenten. Gå avslutningsvis igenom listan en gång till för att hitta luckor. Listan blir mycket mer komplett om den arbetas fram iterativt än om du från början försöker beskriva all information. Gör gärna intressentanalysen i en grupp, fler personer tänker bättre än en ensam.

Kravinsamlingstekniker

För att samla in krav kan många olika tekniker användas. Workshops och intervjuer är två vanliga tekniker under förvaltning. Med workshops menar jag en övning där man sätter upp gula lappar på en whiteboard-tavla under ledning av en workshopledare. Deltagarna är representativa intressenter från både beställar- och leverantörssidan. Workshops är en utmärkt teknik för att samla in, strukturera och prioritera idéer av alla möjliga slag, till exempel krav och ändringsönskemål. Workshops används med fördel när det finns lite fler ändringsönskemål. Det är inte meningsfullt att arrangera en workshop om det bara finns ett behov av en handfull ändringar, i en sådan situation kan man istället intervjua intressenterna. Till fördelarna med workshops är deltagarna ”spinner vidare” på varandras idéer ur flera olika perspektiv så att resultatet blir mycket fler idéer än om man sitter ensam eller i små grupper och tar fram kraven. Grundtanken är att det är bättre att ha fler idéer att välja bland när man i nästa steg gör prioritering.

Ett alternativ eller komplement till workshops är intervjuer. Alla kan genomföra intervjuer med viss träning och en del förberedelser. Syftet med att genomföra en intervju kan vara att försöka identifiera så kallade underförstådda, eller förväntade, krav. Det är sådana krav som är så självklara för den som ställer kraven att denne missar att nämna dem. Tyvärr kan man inte fråga ”vad har du för krav som är så självklara för dig så att du inte tänker på att nämna dem?”. I stället får man försöka göra sig en så komplett bild som möjligt med andra frågor.

Exempel på intervjufrågor:

  • Hur många användare kommer att använda funktionen?
  • Finns det något som systemet inte får/bör/behöver göra?
  • Är det något som behöver ske med viss periodicitet?
  • Hur och när ska data försvinna från systemet?

Det är inte möjligt att fånga samtliga underförstådda krav med intervjuer. Vid större ändringar bör man även ta fram prototyper och genomföra observationer där man studerar användare som använder funktionen.

Prioritera ändringsförslagen

Efter insamling och genomgång av restlistan sker prioriteringen baserat på den nytta och kostnad som ändringen är förknippad med. Flera parter behöver delta i prioriteringen. Representanter från beställarsidan kan bedöma ändringens värde för verksamheten. Leverantörssidan kan bedöma ändringens komplexitet, risker och kostnad. Genom att diskutera prioriteringen gemensamt, ökar förståelsen för varandras åsikter.

Jag rekommenderar att varje ändringsönskemål prioriteras dels baserat på kostnad, dels på värde för verksamheten. Det är bra om man gemensamt kommer fram till vilka skalor man prioriterar mot. Om gruppen som deltar i prioriteringen är överens om skalorna blir det enklare att få acceptans för de beslut som fattas om vilka ändringar som ska genomföras. Processen bör vara visuell och tydlig, det gör det lättare att förstå att anledningen till att mitt krav inte kom med är att det inte är lika viktigt ur verksamhetens perspektiv i förhållande till det där kravet som blev godkänt. Prioriteringen kan göras i Excel eller på en whiteboard-tavla eller genom att använda ett kravhanteringsverktyg. I Excel kan man sortera fram de ändringsönskemål som ger högst värde för verksamheten samtidigt som de kostar minst pengar att realisera.

Bild 2 - Exempel på visuell prioriteringsteknik på whiteboard-tavla.

Fatta beslut om ändringar i förvaltningsråd

Det sista steget i krav/analysfasen är att fatta beslut om vilka ändringar som ska genomföras. Detta sker i ett förvaltningsråd. Andra termer är ändringsråd, change control board eller CCB. Ett förvaltningsråd bör finnas i samtliga större förvaltningsuppdrag och förekommer mycket ofta när utvecklingen bedrivs i projektform. Förvaltningsrådet är en liten grupp människor som träffas i möten som kallas förvaltningsmöten. Förvaltningsrådet granskar ändringsönskemål och behöver därför besitta flera sorters kompetenser såsom verksamhet, användarperspektiv och teknikkompetens. Gruppen bör vara liten och beslutsmässig, ofta räcker det med 2-4 personer. Kärnan utgörs av förvaltare från verksamhets- och tekniksidan kompletterat vid behov av systemägare, IT-chef, utvecklare, användare etc.

Ändringar görs på flera nivåer i organisationen beroende på ändringens storlek och konsekvenser. Många ändringar kan hanteras i daglig kommunikation mellan personerna som arbetar i förvaltningsobjektet. Systemägaren fattar ofta större beslut som påverkar tidplan, resurser och kvalitet. Riktigt stora ändringar beslutas av organisationens ledning. På flera av dessa nivåer kan förvaltningsråd förekomma. Det kan till exempel finnas ett förvaltningsråd för ändringar inom ett förvaltningsobjekt och ett annat förvaltningsråd för att hantera ändringar som kan påverka andra system. Om organisationen är liten eller om förvaltningsobjektet är litet kan besluten fattas av förvaltaren eller av systemägaren, i dessa fall finns inget förvaltningsråd.

Sammanfattning

  • Det är viktigt att processen för ändringar är känd och förankrad i organisationen.
  • Genom att prioritera iterativt tar man med de flesta viktiga kraven först utan att glömma bort mindre krav.
  • Både beställare och leverantör behöver delta i prioriteringen.
  • Efter prioriteringen fattar förvaltningsrådet beslut om vilka ändringar som ska genomföras.

Tips för vidare läsning

  • Boken ”Kravhantering för IT-system” av Ulf Eriksson, Studentlitteratur 2006. Boken behandlar kravhantering i både nyutveckling och förvaltning.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln