Så här sker utvecklingen i DIPS

Publiserad

 

Med ett komplett DIPS Arena på plats kan utvecklarna rikta blicken framåt och utveckla nya funktioner som kan förenkla och effektivisera arbetsvardagen på ett sjukhus. Här presenterar vi utvecklingsprocessen som den ser ut i DIPS.

Kvinnelig utvikler foran PC

Foto: Marthe Mølstre

 

Så här sker utvecklingen i DIPS

1. Idén eller ett förbättringsförslag kan komma som en konkret beställning från kund, eller genom att DIPS själva har en idé eller vision om en speciell produkt.

2. Planeringsfasen. DIPS bjuder in sina största kunder till en workshop för att presentera idén eller beställningen för att alla ska kunna komma med inspel, och för att DIPS ska vara säkra på att vi utve3kclar en lösning som kan användas och konfigureras för alla och inte är specialanpassad för en enskild kund. I den här fasen går vi till exempel igenom en patients resa för att finna det lämpligaste arbetsflödet som lösningen bör ha. Alternativt används interna konsulter och medicinska rådgivare om produkten är lite, och/eller området väl känt

3. UX-designern deltar i arbetet, gärna redan i workshopen för att kunna göra skisser för hur en lösning kan komma att se ut. Om produkten ska innehålla funktioner för kliniker deltar också medicinska rådgivare.

4. Vid behov hålls flera workshops, när produkten är mer verklig är det enklare att se vad vi menar och hur en lösning kan fungera.

5. Produktägare hos i DIPS är ansvariga för att utveckla goda specifikationer som levereras till ett eller flera utvecklingsteam beroende på vad som ska utvecklas. De listar upp och går igenom detaljer i det som ska utvecklas.

6. Specifikationen delas upp i funktioner, dvs utvecklingsdelar, som beskriver vad produkten ska göra. En funktion beskriver en del av en produkt och kan till exempel vara att en användare ska kunna förnya recept med en ändring.

7. Utvecklingsteamen bryter ner funktionerna i PBI:er. PBI:erna är i praktiken en kom-ihåg-lista över alla små detaljer som behöver göras. En Avbryt-knapp i skärmbilden för receptförnyelse kan vara en egen PBI. Teamet estimerar tid för utvecklingen av de enskilda PBI:erna, hur stor uppgiften är, och tar ägarskap över backlogen.

8. Produktägare prioriterar de olika funktionerna, med tillhörande PBI:er, enskilt eller tillsammans med produktlinjeledaren, andra produktägare och kliniska rådgivare. Produktägaren har ansvar för att prioritera vad som görs först i utvecklingsarbet.

9. Utvecklare jobbar med PBI:erna i sprintar, vilket inkluderar test och dokumentation av det som är byggt samt eventuella buggfixningar.

10. PBI:erna placeras i en gemensam testmiljö för att testa den kommande produkten mot övriga miljön. Detta kan också leda till nya justeringar som teamet måste göra för att sedan åter igen testa i den gemensamma testmiljön. Ibland vill kunder kunna vara med och testa innan en produkt färdigställs slutgiltigt.

11. Versionen färdigställs med alla produkter, databasändringar och dokumentation och ett sista installations och funktionstest körs.

12. Produkten lanseras via DIPS Kundportal

13. Varje kund lägger in sina specifikationer, det vill säga, de får tillgång till den generella versionen som de konfiguerar för sitt ändamål.

14. Produkten går i drift, för DIPS inkluderar detta fortlöpande underhåll och eventuell utbildning av kunder, om det är en stor och omfattande produkt.

 

DIPS Arena skjermbilde

 

-För vår huvudprodukt har vi två huvudversioner per år. -Vi använder cirka fem månader på att utveckla varje huvudversion genom sprinter, förklarar produktlinjeledare Annette Lund Lillegaard.

- För version 18.1 är det kodstopp i maj. Tiden fram till lansering läggs på test, justeringar och buggrättningar.

Mindre produkter brukar ta betydligt kortare tid. De kan gå från början till slut på en månad.

Utvecklarna i DIPS har flextid, men arbetar i huvudsak med utveckling på dagtid.

Related