Kundens forpliktelser software2011 03
•Download as PPTX, PDF•
0 likes•254 views
Produkteier- og prosjektlederrollen i smidige prosjekter.
Recommended
Recommended
More Related Content
Similar to Kundens forpliktelser software2011 03
Similar to Kundens forpliktelser software2011 03 (20)
Kundens forpliktelser software2011 03
- 1. Produkteierrollen, kundens medvirkning og forankring i linjen - sett fra en Leverandør Anne Kristine Næss
- 2. Bakgrunn fra offentlig sektor. Jobbet med både fossefallsprosjekter og halvsmidige prosjekter fra 2004-2007. Siden 2007 har jeg stort sett bare jobbet i og med smidige prosjekter. E-post: anne.kristine.ness@edb.com Blogger: http://gevinstrealisering.blogspot.com/http://agileandadaptive.blogspot.com/ Linkedin: http://no.linkedin.com/in/kristinenaess Om meg EDB 2010 Page 2
- 3. Hovedspørsmål: Utviklerne lever i stadig smidigereomgivelser – men gjør produkteieren? Hvor viktig er det at produkteieren tar aktivt del i smidige prosjekter? Hvordan beholder man fokus på gevinster før, under og etter en leveranse? Hvordan skaper man effektive feed-backsløyfer gjennom smidig? Disposisjon: EDB 2010 Page 3
- 4. Teamet: Forstår kundens behov Tar ansvar for egen fremdrift Reflekterer over forbedringsmuligheter ihver sprint Prøver raskt ut tiltak Prosjektet: God rolleforståelse hos produkteier og scrum master Opplegg for endringsledelse og gevinstrealisering Suksessfaktorer ved smidig 4 EDB 2010
- 5. Behov
- 6. Grov-skisse av behov Løsningen blir sjelden smartere enn tanken bak den EDB 2010 Page 6 Bedret behovs- forståelse Produkteier Scrumteamet
- 7. Som vi har hørt, er det sjelden nok med én Typiske roller og ansvarsoppgaver: Bestiller Spesifikatør Produktkøansvarlig Prosjektleder Orakeltjeneste Koordinator Endringsleder Innføringsansvarlig Opplæringsansvarlig Håndterer interessentene Kommunikasjonsleder Osv. Akhilleshælen i et hvert prosjekt Produkteieren 7 EDB 2010 ProductOwner
- 8. Kjente argumenter? 8 EDB 2010 Jeg må sile behovene fra systembrukerne, så de kan ikke snakke med dere direkte. Jeg har ikke anledning til å skaffe avklaringer på dette nå, men bruk de overordnede beskrivelsene. Produkteier Jeg husker ikke helt hvorfor, men dette har vært prioritert lenge.
- 9. Fra unik kunnskap til delt kunnskap EDB 2010 Page 9 Fagavdeling Produkteier Systembrukere Scrum team
- 10. Hva kan gå galt? EDB 2010 Page 10 Får ikke tak i kunden
- 11. Hva kan gå galt? EDB 2010 Page 11
- 12. Kunden må være tilstede fra initiell behovsfase til gjennomføringsløpet til godkjenning og implementering. Slutte med «multitasking» og lave allokeringsgrader i prosjektene. Jobbe fysisk sammen med scrumteamet i større grad. Hvordan løse dette? EDB 2010 Page 12
- 13. Gevinster
- 14. Vil kunden ikke ha gevinster? EDB 2010 Page 14 Tiske, hviske Produkteier Scrumteamet
- 15. EDB 2010 Page 15 Prosjektplan/produktkø Investeringsanmodning
- 16. Hva er viktigst nå? EDB 2010 Page 16
- 17. Gevinstplanen EDB 2010 Page 17 Sikre at saksbehandlerne forstår og tar i bruk den nye funksjonaliteten Sikre at frigjort tid blir brukttil å bygge ned restanser Arbeidspakke A: Automatisert ”datafangst” Forbedret arbeidsprosess Redusert saksbehandlingstid Bedre ressurs-utnyttelse Tiltak: Muliggjøre gevinst Mål Gevinst IT-resultat Forretningsendringer Tiltak: Minimere risiko Sikre tilstrekkelig ytelse og lav nedetid i hele systemløsningen Nye/endrede behov?
- 19. Feedback-sløyfer EDB 2010 Page 19
- 20. Tre nivåer av feedbacksløyfer EDB 2010 Page 20
- 21. Å spille hverandre gode EDB 2010 Page 21 Flere obligatoriske felter gir lengre saksbehandlingstid og økt misnøye med løsningen.
- 22. Spille hverandre gode: Leverandøren EDB 2010 Page 22
- 23. Spille hverandre gode: Kunden EDB 2010 Page 23
- 24. Måling av effekt EDB 2010 Page 24
- 25. Kontinuerlig forbedring EDB 2010 Page 25 Økt effektivitet: redusert klokketid og kalendertid
- 26. Å gi de avklaringene som er nødvendige Synliggjøre mål Avklare relevante behov Gi en absolutt prioritering Vurdere foreslått løsning gjennom demo/review Å holde i sin del av gevinstrealiseringsplanen? Gjennomføre relevante forretningsmessige tiltak Gjennomføre målinger Sørge for gode feedback-sløyfer tilbake til scrum teamet Kundens forpliktelser EDB 2010 Page 26
- 27. Takk for meg! 27 EDB 2010 anne.kristine.ness@edb.com
Editor's Notes
- Mye tyder på at vi har reservert smidige teknikker til kodeutvikling, mens produkteierens organisasjon sjelden reflekterer over egne arbeidsmetoder.I dette foredraget ønsker jeg å peke på ulike mekanismer for å kartlegge, kommunisere og følge opp behovene for gevinster av IT-prosjektene.Vise hvordan dynamikken i smidig kan bidra til faktisk realiserte gevinster etter implementering. Og hvordan kontraktene faktisk kan hjelpe produkteierne med å lykkes i dette.
- Behovsanalysen en ment for å kartlegge hvilke behov som må dekkes gjennom løsningen. Den skal sikre at kunden har tenkt igjennom behovene skikkelig, at kunden har satt rammer rundt disse, prioritert ned mindre viktige behov og endt opp med en forståelse av scope. Men: det er en like viktig del å sørge for at leverandøren har forstått disse behovene. De må med andre ord kommuniseres på en god måte. Scrum fremelsker direkte, muntlig dialog mellom kunden og leverandøren gjennom etableringen av en grovkornet produktkø, og direkte avklaringer med scrum teamet når sprintkøen skal etableres. Kontrakten skal som et minimum definere ytterpunktene i produktbackloggen, og gi muligheter for leverandøren til å sette sammen gode team for å løse oppgavene.
- Tenk deg at du som kommende produkteier valgte å gjøre en slett jobb med kravspekken fordi du visste at dette prosjektet skulle kjøre smidig basert på PS2000-kontraktsstandarden. Prosjektet starter opp, men du blir pålagt å jobbe fulltid med nok en kravspekk – og denne gangen for et langt mer rigid prosjekt. Dermed har du ikke tid til å gi de nødvendige, planlagte avklaringene på daglig eller ukentlig basis. Og dere får ikke lov til å ta direkte kontakt med systembrukerne, da kan de komme til å påvirke scope i feil retning. Eller scrumteamet spør deg om hvorfor i all verden de skal jobb med feature X, når ingen av de øvrige kunderepresentantene skjønner hva den skal være godt for. Og når andre i linja spør om det er mulig å smette inn et nytt element, får de beskjed om å melde dette inn på vanlig vis, som du vet tar årevis å få svar på.
- Kundens organisasjon er ofte svært hierarkisk oppbygget. Kravene til produktivitet og mangelen på ressurser i form av mennesker med kunnskaper om fagfeltet gjør at ledelsen ofte utnevner eksperter. Ofte er det kun én som behersker et fagfelt eller en disiplin. Denne blir gjerne oppnevnt til produkteier for et prosjekt. Ulempen er at dette blir en flaskehals for prosjektet. I små, enkle prosjekter er det ikke noe problem, men straks antallet team som trenger avklaringer fra den samme produkteieren øker utover ett, får man problemer. Dessuten ønsker ofte kunden å skjerme systembrukerne fra prosjektet fordi de ideelt sett ikke skal merke noe til prosjektet før opplæringen starter. Dette er kanskje en form for overbeskyttelse som ikke gavner noen. For mens risikoen for at produkteieren overser ting øker, øker også sjansene for at systembrukerne ikke er godt nok mentalt forberedt på endring. I riktig ille tilfeller fungerer fagavdelingen som et tett skott mellom systembrukerne og produkteieren. Dermed vet heller ikke produkteieren hva den enkelte systembruker sliter med. Legg gjerne på et hierarki av ledere mellom systembrukerne og fagavdelingen, og kunnskapsdelingen forverres ytterligere. Dette er ting prosjektene lider voldsomt under, og kanskje spesielt de smidige. Her er det ikke noen komplette kravspekker og løsningsbeskrivelser som kan sendes på forankringsrunder og QA rundt i organisasjonen. Scrum er basert på muntlig dialog.Hva kan man gjøre med dette? Også her er det å gi slipp på kontroll i form av hierarkier svaret. Tenk feedback-sløyfer! Hva er det du ønsker å vite noe om? Jo, hva systembrukerne trenger for å gjøre jobben sin på en slik måte at vi oppnår de gevinstene vi trenger. Hvem må denne informasjonen komme til? Jo, de som skal lage løsningen (scrum teamet) og den som skal prioritere mellom behovene (produkteieren). Hvis scrum teamet kjenner og har internalisert produkteierens prioriteringer, kan man våge å slippe dialogen mellom systembrukerne og scrum teamet løs.
- La oss tenke oss kua som scrum teamet eller sprinten. Det vesentlige er hva du putter i den (gress, kraftfôr, høy, etc), og hva som kommer ut (melken). Men hvis du måler det som går inn og det som kommer ut, kan du i tillegg se andre ting som kan gi variasjon på output selv om input holdes lik: hvor godt stell den får (miljø), på hvilken tid den melkes, hvordan, etc. Det fine er at du har korte sykluser mellom input og output. Tenk nå på melken som leveranser (releaser). Det er ikke vesentlig for releasen hvor mange iterasjoner som trengtes for å lage den, bare den gir et etterspurt produkt, nemlig melk. Men hvis melken er klar etter bare én dag, hvorfor vente på å sende den ut til en kunde? Med andre ord: styrken i smidig svekkes ved å samle opp lenger enn det som er meningsfylt for kunde og sluttbruker.
- Det er som regel kundens forpliktelse å gi relevante avklaringer. Men burde det også være en forpliktelse å sørge for den endelige gevinstrealiseringen?