Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Innehållsförteckning


Inledning

image-20240628-055409.png

Under konceptfasen så utforskas behovet av förändring. Det kan handla om buggar som upptäckts och behöver åtgärdas, eller förändrade krav eller behov som uppkommit (från användare, team eller tex produktägare) och som behöver adresseras.

Om ändringen rör en liten lösning så handlar det ofta om en arbetsinsats på någon timme/timmar. Är det en mer komplex lösning kan arbetsinsatsen ökas till kanske 1-4 veckor.

Om behovet och lösningens art och omfattning ligger utanför utvecklings- och förvaltningsorganisationens (dvs de som har det operativa ansvaret för utveckling- och förvaltning av systemet) ramar i form av tex tillgängliga resurser och avtal, lyfts frågan om man skall utföra arbetet först till systemägare eller tex verksamhetsansvarig för vidare beredning och tex senare som ett behov till digitaliseringsportföljen.  

image-20240627-143526.png

Idé, behov och ändrade krav

I detta steg genereras en ny idé eller ett koncept. Det kan handla om att lösa ett problem, förbättra en befintlig process eller system, eller som att skapa en helt ny tjänst.

Det kan handla om buggar som upptäckts och behöver åtgärdas, eller förändrade krav eller behov som uppkommit (från användare, team eller tex produktägare) och som behöver adresseras.

Man prioriterar och utvärderar idén för att se om den är genomförbar och har potential. I detta steg är det också viktigt att identifiera och förstå de behov som idén ska uppfylla, vilket innebär att man måste förstå användarnas och olika målgruppers behov, samt tekniska krav. Genom att analysera behoven säkerställer man att idén är relevant och värdefull.

Baserat på idén och de identifierade behoven fastställs sedan specifika krav för ett kommande uppdrag eller projekt. Dessa krav beskriver vad systemet eller tjänsten ska göra, vilka funktioner den ska ha och vilka standarder den måste uppfylla.

Grov design lösning

Här skapas en initial, övergripande design eller struktur för en eller flera alternativa lösningar. Det kan innebära att identifiera lösningens komponenter, exempelvis olika moduler i en programvara, olika delar av en system eller olika steg i en process.

Baserat på de identifierade komponenterna skapas en övergripande struktur för lösningen.

Den grova designen kan behöva utvärderas för att bedöma dess genomförbarhet. Detta kan inkludera att bedöma tekniska utmaningar, kostnader, tidsramar och andra faktorer som kan påverka genomförandet av lösningen.

Baserat på feedback och utvärderingar görs sedan nödvändiga justeringar och förbättringar av den grova designen. Detta kan innebära att ändra designen, lägga till eller ta bort komponenter, eller ändra hur komponenterna interagerar med varandra.

Rent praktiskt kan steget innebära tex att teamet och produktägaren diskuterar problemet och skissar på möjliga lösningar.

I detta steg är det viktigt att man ta hänsyn till om det finns lagar och interna styrdokument som är viktigt att beakta redan i detta skede, så som krav på bevarande, informationssäkerhet, säkerhet, kontinuitetshantering.

Testa & validera idé

I detta steg tar man den initiala idén eller lösningen och utsätter det för en serie tester för att säkerställa att det fungerar som det ska och uppfyller de fastställda kraven. Valideringen kan vara allt från teoretiska resonemang (tex i teamet för ett system) och skisser kring lösningen, till mer praktiska tester.

Här är några steg som kan ingå i ett sådant test:

  • Prototypning: En prototyp eller en första version av lösningen skapas. Denna prototyp behöver inte vara perfekt, men den bör vara tillräckligt komplett för att kunna testas.

  • Testning: Prototypen testas sedan för att se hur den presterar. Detta kan innebära att man testar olika aspekter av lösningen, som dess funktionalitet, prestanda, användarvänlighet och så vidare.

  • Validering: Validering innebär att man bekräftar att lösningen uppfyller de krav och behov som identifierades i början av processen. Detta kan innebära att man samlar in feedback från användare, genomför användartester, eller använder andra metoder för att säkerställa att lösningen fungerar som den ska och uppfyller användarnas behov.

  • Iteration: Baserat på resultaten från testning och validering görs nödvändiga justeringar och förbättringar av lösningen. Detta kan innebära att man gör ändringar i designen, lägger till eller tar bort funktioner, eller gör andra justeringar för att förbättra lösningen.

Beslut väg framåt

Steget innebär att man utvärderar resultaten från de tidigare stegen i fasen och tar beslut om hur man ska gå vidare. Det skulle tex kunna resultera i ”refinement” och prioritering av ärende i en backlog.

Några aktiviteter som kan ingå i detta steg är:

  • Utvärdering av resultat: Resultaten från de tidigare stegen, såsom idégenerering, behovsanalys, kravspecificering, design och testning, utvärderas.

  • Säkra stöd: Det är också viktigt att säkra stöd för lösningen från relevanta intressenter, såsom ledning, anställda eller andra som kan påverkas av lösningen. Detta kan innebära att man behöver presentera och ”sälja in” lösningen för dessa intressenter och arbeta för att övervinna eventuellt motstånd.

  • Beslut om nästa steg: Baserat på utvärderingen tas ett beslut om vad nästa steg ska vara. Detta kan innebära att man går vidare till nästa fas i processen, gör ytterligare justeringar eller förbättringar, eller i vissa fall kanske till och med beslutar att avbryta om resultaten inte är tillfredsställande.

  • Planering för framtiden: Ett beslut om “väg framåt” innebär också att man planerar för framtiden. Detta kan innebära att man fastställer en tidslinje för de kommande faserna, tilldelar resurser, eller fastställer nya mål eller milstolpar.

  • No labels