Prosjekthåndtering
•Transferir como PPTX, PDF•
0 gostou•113 visualizações
Addresses essentials when dealing with an IT developeent project (Norwegian language)
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Prosjekthåndtering
Semelhante a Prosjekthåndtering (20)
Prosjekthåndtering
- 2. Prosjekthåndtering – Prosjektleder ansvar Overvåke utviklingsprosessens progresjon: • Sørge for at utviklingsprosessen har nok ressurser • Har ansvar for å holde prosjektets drift innenfor gitte tids, kostnad og kvalitetsrammer for å sikre kundetilfredshet • Informere kunde om status og progresjon Utfører nødvendige tiltak for å holde prosjektet på rett kurs Vere talsperson for prosjektet
- 3. Prosjekthåndtering - Innsikt I form av et forprosjekt uten spesielle ressursallokeringer utenom de ressurser som er tilgjengelige i mitt konsulentfirma, ville jeg invitert kunden til kravspesifikasjons-workshop sammen med sentrale roller tilknyttet prosjektet. Der ville jeg først ville introdusert meg og firmaet mitt, og deretter bedt kunden fortelle litt om organisasjonens forretning og målsetting. Ville deretter ledet workshopen videre med å fortelle om utviklingsprosjektets prosess: Prosjektplanlegging: a. Først gjøre initiell case kartlegging sammen med kunde ved å revidere prosesser og brukerhistorier med en value-stream mapping for å kunne ta bort evt. waste for deretter beskrive prosessene i Jira med for eksempel. Gliffy plugin-en, oppdelt i sider med overordnede og underordnede prosesser. Prosesser blir da automatisk revidert i Jira så man får med endringshistorikk/dokumentasjon. Grunnen til at visuelle beskrivelsesverktøy er best er fordi materialet er lettere å kommunisere på tvers av roller slik og dermed reduserer misforståelser som tar tid å rette opp. Her avklares det også hvilke personer som skal vere kontaktpunkt på kundesiden etc. og dette aspektet har mye å si for utviklingsens agilitet. b. Ville så latt utviklerene ta fatt i brukerhistoriene/prosessbeskrivelsene sammen med en arkitekt som legger føringer sammen med kunde for hvilken plattform og hvilket rammeverk som egner seg best for løsningen. Brukerhistoriene brytes så grovt opp i moduler og komponenter basert på plattform, rammeverk og tredjeparts biblioteker/systemer som man har tatt utgangspunkt i og kommer frem til noen estimater for hvor lang tid det vil ta å få ut en prototype. Ville også bedt teamet kommunisere sine estimater gjennom en Critical Path Analyse for å øke egen bevisthet rundt tidsbruk og hvorvidt oppgaver kan samkjøres for så kommunisere til kunde når de kan forvente at prototypen er klar og kommunisert dette til kunden. c. Teamet begynner på utviklingen av prototypen og fokuserer på de elementer som er mest nødvendige for å få systemet opp å kjøre (Kanban).
- 4. Prosjekthåndtering - Utvikling Lean handler om å tilpasse det man utvikler så nært kunden og markedet som mulig, og med så lite mellomliggende tolkninger som mulig. Lean håndtering handler om å hele tiden fokusere på det viktige, og hele tiden revidere hva som er viktig. Dette fører indirekte til at man får et mer kritisk blikk som fører til at man kontunuerlig tar bort uviktige ting og kanskje forenkler ting der det lar seg gjøre. Kanban passer bra i en sånn sammenheng. En tradisjonell agil prosess kan fungere ok også, men da helst hos kunder som opererer i mer stabile markeder eller etablerte prosjektfaser. Agil utvikling verdsetter individer og interaksjoner mer enn prosess og verktøy, altså, kultur over effektiv interaksjoner/kommunikasjon. • Kultur og soft skills er viktig for mennesker. Likevel er det tall og nummer som teller til syvende og sist i forretningssammenheng. Jeg ville i utgangspunktet valgt å kjøre en lean utviklingsmetodikk i dagens marked og i så stor grad som mulig tilpasset denne til kunden ved å vere oppmerksom på kundens behov også iforhold til samarbeidsmetodikk og kommunikasjon siden kundeforholdet er minst like viktig.
- 5. Prosjekthåndtering - Utvikling Offisiell utvikling og implementasjon: a. Når kunde har fått testet prototypen, og komt med endringsønsker, og etter at utviklingsteam har tatt høyde for dette i sine nye estimater, da ligger det nok informasjon til grunne til å komme med et offisielt estimat på tidsbruk og kostnader for utviklingen, og det er tid for å utarbeide en kontrakt/SDA som både konsulentfirmaet og kunden føler seg konfident med. b. Når kunde har godkjent prosjektplanen/kontrakten begynner teamet på utviklingen. Utviklingsteamet innhenter informasjon til de tider og anledninger som avtalt med kunde/evt. har kontinuerlig kontakt med dedikert kundekontakt for kortest mulig tilbakemeldingsloop. c. Vil så kjøre pilottesten når kunde har verifisert siste akseptansetestkjøringer.
- 6. Prosjekthåndtering – Prøvedrift/prosjektferdigstilling Prøvedriftsperiode, opplæring og formell overlevering av dokumentasjon I dette stadiet handler det om å overlevere formaliteter og sikre at kunden har fått informasjon som trengst til å kunne vedlikeholde og drifte systemet. Her er det fremdeles risiko for at feil oppstår som kan føre til merkostnader for konsulentfirmaet. Derfor er det viktig å ha gjort alle preventive tiltak for tidligere identifiserte risikoer for å minimere denne risikoen.
- 7. Prosjekthåndtering – Sikring av kommunikasjon i prosjektet I utviklingsteamet Kommunikasjonen internt i utviklingsteamet er det best å la utviklerene bli enige om. Likevel vil jeg anbefale teamet å bruke Jira for å holde styr på daglig status over saker (Kanban board) og kun Jira for å unngå å måtte oppdatere status på to steder (waste). Videre jobber utviklere og testere tett sammen på samme kanban board. Med kunde Når man har både oppgaver og prosessene/brukerhistoriene beskrevet i Jira kan man også raskt generere brukbare statusrapporter såfremt teammedlemmer er instruert om bruk av linking. Om man også bruker Doxygen Jira plugin’en kan man få generert API dokumentasjon for moduler direkte i Jira sammen med oppdatert prosessbeskrivelse og oppgaver. Da lever også dokumentasjonen i samme loop som kode og er alltid oppdatert.
- 8. Prosjekthåndtering – Risikoanalyse/håndtering, risikotyper Typer risiko for prosjektet i omfang av alt fra generelle IT bransje relaterte risikoer til team og kundemiljøspesifikke risikoer: Kjente kjente For eksempel. utviklere som blir sykemeldt som forsinker prosjektleveransen. Kjente ukjente For eksempel. om kommunikasjonen med kunde fungerer Utilstrekkelig eller produksjonsfeil Ukjente ukjente Hendelser man ikke hadde grunnlag for å kunne forutse
- 9. Prosjekthåndtering – Risikoanalyse/håndtering, kjente risikoer 1. Menneskelige feil: påpek prosedyrer gjennom trening, peer reviews 2. Urealistisk tidsplan/budgett: kjør business case analyse; inkrementell dev. syklus, gjenbruk av komponenter 3. Utilstrekkelig grensesnitt/funksjon på basisprogramvare: kompatibilitetsanalyse, tilbyderanalyse 4. Spesifikasjon og implementasjon er ulike: ha gode vinn-vinn kontrakter til grunne for prosjekt; kjør business case analyser, prototyping og applikasjonsbeskrivelse i tidlige faser. 5. Grensesnitt er utilstrekkelig: prototyping, beskrivelse av typiske brukere/bruksscenario. 6. Utilstrekkelig arkitektur, ytelse eller kvalitet: benchmarking, simulering, tuning 7. Konstant endring av spesifikasjoner: ha god change management prosess, Lean for eksempel. 8. Overestimering av egen IT kyndighet: teknisk analyse, cost/nytte analyse, prototyping
- 10. Prosjekthåndtering – Risikoanalyse/håndtering, Ukjente risikoer I tilllegg til de kjente risikoene finst det kjente ukjente risikoer. I programvare sammenheng er dette som regel feil i forbindelse med drift og data systemet ikke har tatt høyde for, og desse kan utgjøre større eller mindre risiko for prosjektets suksess siden en gitt produksjonstid som regel inngår i prosjektets leveranse. Det beste prevantive tiltaket man kan gjøre for å minimere denne risikoen er ved å kjøre volumtester på produksjonsliknende data.
- 11. Prosjekthåndtering – Risikoanalyse/håndtering, konsekvenser Hvilke konsekvenser kan desse risikoene ha for et IT prosjekt? • Risiko for at systemet i drift gjør kritiske feil som fører til at kunde taper kunder og omdømme. Denne type risiko inngår som regel i selve prosjektleveransen. • Risiko for at prosjektet tar lengre tid å levere enn planlagt/estimert, og dermed taper penger og konkurransefortrinn.
- 12. Prosjekthåndtering – Risikoanalyse/håndtering, prevantive og mitigerende tiltak Alle typer kjent risiko kan altså håndteres på en prevantiv og en mitigerende måte i prosjektets faser: Prosjektleder bør sammen med prosjektteamet gå systematisk igjennom systemet og dokumentere kjente og potensielle feilkilder og avklare desse med forretning under utvikling og testing. Risikoanalysen kan gjerne ver kontinuerlig som en del av utviklingsprosessens PDCA syklus. Sjangs for risiko X risikokostnad = risikoeksponering
- 13. Prosjekthåndtering – Risikoanalyse/håndtering, Risikoregister Basert på identifiserte kjente og kjente ukjente risikoer bør man utarbeide et risikoregister med prevantive tiltak og evt. mitigeringstiltak om de skulle oppstå. Eksempel: Identifisert risiko Sannsynlighet Tap størelse (dager) Risiko eksponering (dager) Prevantivt tiltak Utilstrekkelig QA tid for validering av alle browsere og OS 65% 4 2,6 Bruk automatiske UI test verktøy som selenium Kundekontakt ikke tilgjengelig før veldig sent I prosjektet 34% 15 5,1 Påpek viktighet av tilgjengelighet så tidlig som mulig i planlegging og ta høyde for implikasjoner i kontrakt Spesifikasjon og implementasjon er ulike 22% 16 3,52 ha gode vinn-vinn kontrakter til grunne for prosjekt, kjør business case analyser, prototyping og applikasjonsbeskrivelse i tidlige faser. Utilstrekkelig arkitektur, ytelse eller kvalitet 72% 7 5,04 benchmarking, simulering, tuning Urealistisk tidsplan/budgett 90% 12 10,8 kjør business case analyse; inkrementell dev. syklus, gjenbruk av komponenter Ukjente systemfeil som kan oppstå i forbindelse med produksjon 90% 10 9 Total risikoeksponering: 36,06
- 14. Prosjekthåndtering – Risikoanalyse/håndtering, tvister Hvordan håndtere risiko for at prosjektleveransen tar lengre tid enn planlagt? • Ha gode kontrakter og avtaler klare i forkant for hvordan håndtere slike tvister om de skulle oppstå.
- 15. Prosjekthåndtering - Endringshåndtering Lean filosofi: ”Følg meg så ordner vi dette sammen” Mange føler seg mer tilfreds med den kjente onde enn den ukjente onde og vil dermed prøve å motarbeide endring. Man er gjerne redd for endring pga: • Konservativt/tradisjonelt syn • Usikkerhet i forhold til mestring • Mangel på tillit og forståelse Derfor er det viktig å ta høyde for desse tingene og vere en lagspiller om man også har rolle som endringsleder, der man ser på de ansatte som mennesker og ikke bare ressurser. Slik tror jeg man får det beste og mest ut av ansatte.
- 16. Prosjekthåndtering– Pilot testing Pilot testing blir gjort mellom akseptansetest fasen og deployment til produksjon, der systemet blir testet av en rekke sluttbrukere som helst ikke har vært involvert i systemets utvikling og vanligvis innenfor klient-organisasjonens fire vegger. Dette skjer typisk før beta testing. Mål: • å finne svakheter til systemet, og å bli kvitt så mange feil som mulig før produksjon/reelle kunder/brukere av klienten tar i bruk programvaren. •Å få nye øyne på produktet som kan fungere som tidlig ledetråd til hva som mest sannsynlig kommer opp som endringsønske senere.
- 17. Prosjekthåndtering – Pilot testing Strategi: 1. Lag Pilot plan, inneholder: • Opplysninger til deltagere/testere om formål, lengde og progresjon av Pilot testfasen. • En operasjonell IT teknisk plan for miljøoppsett, installasjon og konfigurasjon for testfasen. • Evaleringskriterier for kjøring, desse må alle kunder, brukere og prosjektteam bli enige om. For å innhente tilbakemeldinger kan man for eksempel bake inn kriteriene i spørsmål i et Google Forms skjema som brukere bes om å besvare for hver av kjøringene. 2. Forbered Pilot testen: • informer deltagere med informasojn som oppgitt i plan • Sett opp testmiljøene som beskrevet i plan. 3. Deploy og start Pilot testen 4. Evaluer kjøring: send ut skjemautfyllingsforespursler til testere for tilbakemeldinger 5. Handling: basert på tilbakemeldinger, velg enten å: fikse og fortsette, rulle tilbake eller ferdigstille pilot testingen.
Notas do Editor
- Prosjektlederen håndterer ytre rammer for prosjekt som tid, ressurs og økonomiske aspekter og risikoer involvert. Prosjektleder er også prosjektets talsperson som kommuniserer progresjon til kunde.
- Tolker det som at jeg/konsulentfirmaet trenger selge oss inn først siden kunde ønsker prototype. Forstå case: I forbindelse med innledende planlegging og prototypen ville jeg bakt dette inn i et salgs-prosjekt der målsetningen er å få kunden til å vere med videre og signere kontrakt for selve prosjektet. Her handler det iførste omgang om å bli kjent med kundens organisasjon og nøkkelpersoner, samt forstå problemstillingene/caset kunden kommer med, for deretter å ta fatt i forretningscaset til kunden, analysere dette, forstå sammenhenger med tanke på markedet kunden opererer i så man forstår hva som gir verdi i kundens løsninger. Beskrivelse: I forbindelse med beskriving av selve prosessene tror jeg flytdiagrammer er best siden de fleste forstår desse. Implementasjonsplanlegging: Vedrørende prototype planlegging er det best å la arkitekt og kunde sette føringer for de tekniske løsningene for så la dette vere fundament for videre tjenester og rammeverk. Likevel kan det vere greit at nøkkelutviklere er med. Estimering Som ”mind tool” ville jeg anbefalt critical path analyse/PERT analyse ettersom dette gjør de som bruker det mer beviste og istand til å forstå omfang i kompleksitet og dermed omfang av tidsbruk. Desse verktøyene gjør man istand til å se hvordan prosesser avhenger av hverandre og hva som kan gjøres samtidig. (Slik bruker man critical path analysis As with Gantt Charts, the essential concept behind Critical Path Analysis is that you cannot start some activities until others are finished. These activities need to be completed in a sequence, with each stage being more-or-less completed before the next stage can begin. These are 'sequential' activities. Other activities are not dependent on completion of any other tasks. You can do these at any time before or after a particular stage is reached. These are non-dependent or 'parallel' tasks.)
- Lean comes from Lean Manufacturing and is a set of principles for achieving quality, speed & customer alignment… altså, en litt annen vinkling for å komme imål enn med det man kaller “agil” utvikling selv om begge inngår I hverandre. Kort fortalt er forskjellen mellom Lean og Agil at Lean approachen er mer fokusert på struktur i kommunikasjonsprosessen mot målet mens den Agile approachen respekterer eksisterende kommunikasjonsprosess og kommunikasjonskultur på en annen måte. Lean: 1. Eliminate Waste 2. Build Quality In 3. Create Knowledge 4. Defer Commitment 5. Deliver Fast 6. Respect People 7. Optimize the Wholea Agil: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
- Når prototypen har overbevist kunde er det klart for å signere leveransekontrakt knyttet til prosjektet. Veldig viktig å avklare det med kundekontakt under utviklingsprosessen siden dette er helt avgjørende for å kunne utvikle lean/agilt. Det handler om å ha så kort tilbakemeldingsloop som mulig.
- Prøvedriftsperioden er som regel noe de fleste kunder ønsker bake inn som en del av prosjektet pga. at det historisk sett har vist seg å dukke opp en rekke feil i etterkant, noe som ingen er tjent med. Konsulentfirmaet tvinges derfor til å jobbe så proaktivt og systematisk med dette aspektet under hele utviklingsprosessen gjennom bredde og mengdetester.
- Jira er fint siden man kontinuerlig kan følge med på status, har mulighet til å samle alt av prosessdokumentasjon og kommunikasjon knyttet til denne og oppgaver på et sted. Dette krever naturligvis at man kommer med retningslinjer rundt dette i forkant.
- Ved hjelp av et risiko register kan man sette opp kjente kjente og kjente ukjente risikoer med prevantive og mitigerende tiltak. De ukjente ukjente risikoene har man ikke mulight for å kunne gjøre noe med.
- Her er 8 veldig vanlige kjente risikoer innen software utviklings prosjekter med prevantivt tiltak.
- Konsekvensene av systemfeil kan vere veldig store noen ganger, og kan skade både kunde og konsulentfirma.
- Risikoanalysen kan man godt gjøre kontinuerlig siden risikoer endrer seg med tiden.
- Eksempel på et risikoregister, med et risiko eksponeringstall. Dette kan sees på som en grad av alvorlighet. Dess høyere tall, dess mer alvorlig er det at om en slik risiko intreffer.
- Man bør alltid jobbe og sikte mot å lage vinn-vinn kontrakter. Gode forhold er på sikt mer verdt enn kontrakter.
- Lean leder filosoftien henter ideer fra tradisjonelt lederskap og ”empowering” lederskap. Balansen er kanskje beste form for lederskap gjennom et landskap som endrer seg, som gjerne fører til angst og stress hos mennesker.
- Man kan se på pilottestingen som siste sikkerhetsnett for feil før kundens brukere blir eksponert.