ݺߣ

ݺߣShare a Scribd company logo

Kas svarbu vykdant projektus užsakovo akimis

•Download as PPSX, PDF•
•
Agile Lietuva
Agile Lietuva

Edmundo Vasonskio skaitytas pranešimas Agile dienoje 2013 gegužės 9 d. Patirtis vystant informacines sistemas tiek organizacijos viduje tiek perkant projektus iš išorės. Kaip efektyviai vystyti projektą/produktą, išgryninti suinteresuotų šalių norus, formuoti tiklus vykdytojams ir gauti poreikius atitinkantį rezultatą.

1 of 38
Download to read offline
Kas svarbu vykdant projektus Užsakovo akimis Edmundas Vasonskis, IT vadovas, Avia Solutions Group
Edmundas Vasonskis - Apie mane • IT vadovas Avia Solutions Group tarptautinėje įmonių grupėje • IT vadovas ŽIA valda įmonių grupėje vieninančioje įmones aviacijos, žemės ūkio ir maisto pramonės, NT ir kitų paslaugų srityse. • Locatory.com akcininkas prisidėjęs prie įmonės kurimo • 8 metai IT sektoriuje, 6 metai vadovavimo ir projektų valdymo bei vystymo patirtis.
Įgyvendinti projektai • Cloud Infrastruktūros pirkimas ir diegimas • In-house CRM vystymas 5 metus • ECM sistemos pirkimas • ERP kūrimas pasitelkiant tiekėjus • Dešimtys didesnių ir mažesnių projektų specifiniams tikslams pasiekti
Apie Avia Solutions Group Tradicinis požiūris vs Agile Užsakymo derinimas - kas svarbu Nuosavų vykdytų projektų patirtis Usability / UX Agenda
• Verslo šaknys nuo1938. • Pirmoji Lietuviška kompanija listinguojama Varšuvos akcijų biržoje. • ASG įmonių grupę sudaro virš 17 dukterinių įmonių dirbančių daugiau kaip 40 lokacijų pasaulyje. • Virš 1300 darbuotojų kalbančių daugiau kaip 10 skirtingų kalbų. • Atstovybės Lietuvoje, Lenkijoje, UK, Italijoje, Malaizij oje bei Rusijoje. • Sertifikuotas aukštos kvalifikacijos personalas iš daugiau kaip 400 instruktorių, inžinierių bei technikų.
• Base maintenance • Line maintenance • Engine maintenance management • Parts & components support • Full aircraft engineering • Technical training and consulting • Landing gear overhaul • Delivery & redelivery solutions • Logistics & Distribution •Passenger services •Aircraft handling •Fuelling •Catering Delivery Services •Airport terminal engineering •Aviation personnel resourcing •Crew lease Online 24/7 aircraft spare parts marketplace: •to search •to buy •to sell aviation inventory •Ab Initio pilot training •Type rating training •Instructor type rating •Cabin crew training •Dry/ Wet Lease •Technical maintenance training •FFS MRO and Renewal •Full charter •Aircraft wet lease •Ad hoc flights
Kas svarbu vykdant projektus užsakovo akimis
Kas svarbu vykdant projektus užsakovo akimis
Kas svarbu vykdant projektus užsakovo akimis
Ateities planai • FL Technics angarai Kauno oro uoste • FL Technics Ulyanovsk – Rusija, laisvoji ekonominė zona, Ulyanovsk
Apie Avia Solutions Group Tradicinis požiūris vs Agile Užsakymo derinimas - kas svarbu Nuosavų vykdytų projektų patirtis Usability / UX Agenda
Pažvelkime iš kitos pusės Užsakovo lūkesčiai Projekto Gamyba
Каip gimsta tradicinis projektas įmonėje Projektų vadovas užtikrina, kad rezultatas atitiktų reikalavimus Teisininkas Vadovybė Suinteresuoti asmenys Liepia užtikrinti, kad nieko nepraleidom Įdeda saugiklius, kad nebūtų nukrypimų Specifikacija
Keičiam požiūrį Reikalavimai VS Poreikis
Mums reikia „programos“ Reikalingas verslo problemos(-ų) sprendimas
Svarbu tiekėjui iškomunikuot tinkamą poreikį • Pasitelkiam visus suinteresuotus asmenis • Rezultatas kurio siekiame, kokią verslo problemą sprendžiame – o ne techniniai reikalavimai
DILEMA – „overspecification“ • Geri reikalavimai reikalauja detalizavimo • Pridėkim dar baimę kažką praleist, todėl dar daugiau įtraukiam ir detalizuojam Užsakovas pats save įvaro į kampą • Nelieka jokio lankstumo • Prarandamas fokusas į verslo poreikius
Užsakovas ateina su savo REIKALAVIMAIS • Turint reikalavimus reikalingi tik techniniai resursai įgyvendinimui • Užsakovas iš anksto aiškiai (dažnai klaidingai) įvardina ko jam reikia • Orientacija į sistemos/produkto pagaminimą
Užsakovas turi suformuoti poreikius ir tikslus Gimsta diskusija tarp Užsakovo ir Tiekėjo Tiekėjas gali pasiūlyti geriausią sprendimą Rezultatas bus Užsakovo problemos sprendimas
Ar „serverių“ pirkimas gali būt Agile?  Identifikuojame problemines sritis  Paklausiame suinteresuotų šalių ar jie mato tas problemas ir koks rezultatas juos tenkintų  Išgryninam kokius TIKSLUS norim pasiekti  Iškomunikuojame tai Tiekėjui  Atmetam Tiekėjus kurie perša produktus ne sprendimą  Sutartyje įrašome kokias problemas/tikslus turi išspręsti įdiegtas sprendimas
IT ir Verslo sinergija IT techninė kalba IT verslo kalba RPO – 2h RTO – 30min Pasiekiamumas – 99,9% HDD greitis, RAID Megabaitai Megahercai Labai svarbu iš kur šie rodikliai gimsta – jie turi būti suderinti su SUINTERESUOTAIS ASMENIMIS
Apie Avia Solutions Group Tradicinis požiūris vs Agile Užsakymo derinimas - kas svarbu Nuosavų vykdytų projektų patirtis Usability / UX Agenda
Kodėl poreikis naudingesnis • Rezultatas orientuotas į problemos sprendimą - suteikia laisvę surasti optimaliausią sprendimą – Tiekėjas profesionalas yra tikras galėsiantis išspręsti problemą ir niekas jam netrukdys • Kai ant stalo dedam techninius reikalavimus – tiekėjas tėra įrangos (HW ar SW) pardavėjas – Gamindamas produktą pagal Užsakovo specifikaciją tiekėjas įspraustas į rėmus
Pavyzdys, kai specifikacija apriboja • Informacinė sistema turi dirbti su tam tikra periferine įranga – Užsakovui parinkus įrangą Tiekėjas gali susidurt su kliūtimis integruojant ją, Užsakovo rizika - netinkamai veikiantis sprendimas – Tiekėją įtraukiant į įrangos parinkimą Užsakovas garantuotas rezultatu, Tiekėjas pats kontroliuoja visą procesą (mažiau rizikų)
Vystymas per poreikius Nauda Užsakovui • Užsakovui nereikia būti aiškeregiu ir apgalvoti visus techninius niuansus • Neturint labai detalios specifikacijos nebus kliūčių realizuoti norimą rezultatą Kaip reaguoja Tiekėjas • Rizika, kad Užsakovas poreikio apimtyje labai išsiplės • Nauda: visgi rizika išsiplėsti yra tik žinomo poreikio rėmuose, todėl turint patirties galima įvertinti • Saugiklis – įgyvendinus poreikį įvykdomi įsipareigojimai
Rizika kurią turime suvaldyti Užsakovo baimė, jeigu iškart nebus įtraukta į reikalavimus - nebus įgyvendinta Atsirinkti tiekėją kuris nebijo bendrauti per poreikius, o ne per sausą įrangos specifikaciją Smulkmenos poreikio rėmuose vis tiek lieka derybų reikalas ginčo atveju
Iš patirties... – FRAUD! • Neapsigaukit ant visiško Agile‘izmo • Tiekėjas nepateikia nei kainos, nei laiko, grįsdamas dirbantis Agile principais
Fiksuota kaina ar valandinis įkainis • Užsakovas nežino kainos • Užsakovas turi patirties Time & Material • Užsakovas žino už ką moka • Rizika tiekėjui = buferis Fixed price Fixed scope • Kaina už poreikį • Tiekėjas turi patirties Agile metodas
Apie Avia Solutions Group Tradicinis požiūris vs Agile Užsakymo derinimas - kas svarbu Nuosavų vykdytų projektų patirtis Usability / UX Agenda
Diegimo iteracijomis pavyzdys I etapas Sistemos diegimas/pridavimas Administratorių mokymai „pirminiai“ Mokymai tikslinei darbuotojų grupei Tikslinė darbuotojų grupė pradeda naudotis II etapas Programavimas/pridavimas: Prioritetiniai išplėtimai Administratorių mokymai „pažengusiems“ Visi darbuotojai dirba su sistema III etapas Priežiūra po paleidimo Programavimas/pridavimas: Kiti išplėtimai Duomenų importas iš kitų sistemų
Įgimta dirbti pagal specifikacijas Gyvenimiška patirtis: sistema buvo vystoma palaikymo skyriaus esamos apimties ribose, darant daug „workaround“ Sprendimas: suinteresuotų šalių susitikimas kurio rezultatas dedikuota vystymo komanda
Apie Avia Solutions Group Tradicinis požiūris vs Agile Užsakymo derinimas - kas svarbu Nuosavų vykdytų projektų patirtis Usability / UX Agenda
Nesutarimų priežastys “Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.” ~ Albert Einstein~
Sprendimas • Sutartyje įrašom, jog funkcionalumas turi būti maksimaliai efektyvus • Jeigu akivaizdžiai procesas iš vartotojo pusės gali būti atliktas paprasčiau, suprantamiau ir greičiau tuomet jis turi būt efektyvinamas • Priklausomai nuo specifikos konkretizuojam žingnių skaičiumi, laiku procesui atlikti ar pan. • Pvz: Keleivio aptarnavimas – ne ilgiau 3 min.
Jeigu Tiekėjui netinka sąlygos Reikia rinktis Tiekėjus kuriems tai priimtina Užsakovai irgi turi reikalauti geresnio produkto Tiėkėjai pirmi pradėjo siūlyti Agile koncepciją
CRM Kas yra Nr.1 CRM sistemų nesekmės priežastis? Vartotojų pasitenkinimas sistema
Kaip padidinti CRM efektyvumą Turime „parduoti“ CRM‘ą naudotojams Komunikacija (intranetas, video, naujienlaiškis) Naujų ir esamų darbuotojų mokymai Įsiklausymas į visų suinteresuotų asmenų poreikius Nuolatinis procesų efektyvinimas Nedideli bet dažni atnaujinimai
Kas svarbu vykdant projektus užsakovo akimis

More Related Content

Kas svarbu vykdant projektus užsakovo akimis

  • 1. Kas svarbu vykdant projektus Užsakovo akimis Edmundas Vasonskis, IT vadovas, Avia Solutions Group
  • 2. Edmundas Vasonskis - Apie mane • IT vadovas Avia Solutions Group tarptautinėje įmonių grupėje • IT vadovas ŽIA valda įmonių grupėje vieninančioje įmones aviacijos, žemės ūkio ir maisto pramonės, NT ir kitų paslaugų srityse. • Locatory.com akcininkas prisidėjęs prie įmonės kurimo • 8 metai IT sektoriuje, 6 metai vadovavimo ir projektų valdymo bei vystymo patirtis.
  • 3. Įgyvendinti projektai • Cloud Infrastruktūros pirkimas ir diegimas • In-house CRM vystymas 5 metus • ECM sistemos pirkimas • ERP kūrimas pasitelkiant tiekėjus • Dešimtys didesnių ir mažesnių projektų specifiniams tikslams pasiekti
  • 4. Apie Avia Solutions Group Tradicinis požiūris vs Agile Užsakymo derinimas - kas svarbu Nuosavų vykdytų projektų patirtis Usability / UX Agenda
  • 5. • Verslo šaknys nuo1938. • Pirmoji Lietuviška kompanija listinguojama Varšuvos akcijų biržoje. • ASG įmonių grupę sudaro virš 17 dukterinių įmonių dirbančių daugiau kaip 40 lokacijų pasaulyje. • Virš 1300 darbuotojų kalbančių daugiau kaip 10 skirtingų kalbų. • Atstovybės Lietuvoje, Lenkijoje, UK, Italijoje, Malaizij oje bei Rusijoje. • Sertifikuotas aukštos kvalifikacijos personalas iš daugiau kaip 400 instruktorių, inžinierių bei technikų.
  • 6. • Base maintenance • Line maintenance • Engine maintenance management • Parts & components support • Full aircraft engineering • Technical training and consulting • Landing gear overhaul • Delivery & redelivery solutions • Logistics & Distribution •Passenger services •Aircraft handling •Fuelling •Catering Delivery Services •Airport terminal engineering •Aviation personnel resourcing •Crew lease Online 24/7 aircraft spare parts marketplace: •to search •to buy •to sell aviation inventory •Ab Initio pilot training •Type rating training •Instructor type rating •Cabin crew training •Dry/ Wet Lease •Technical maintenance training •FFS MRO and Renewal •Full charter •Aircraft wet lease •Ad hoc flights
  • 10. Ateities planai • FL Technics angarai Kauno oro uoste • FL Technics Ulyanovsk – Rusija, laisvoji ekonominė zona, Ulyanovsk
  • 11. Apie Avia Solutions Group Tradicinis požiūris vs Agile Užsakymo derinimas - kas svarbu Nuosavų vykdytų projektų patirtis Usability / UX Agenda
  • 12. Pažvelkime iš kitos pusės Užsakovo lūkesčiai Projekto Gamyba
  • 13. Каip gimsta tradicinis projektas įmonėje Projektų vadovas užtikrina, kad rezultatas atitiktų reikalavimus Teisininkas Vadovybė Suinteresuoti asmenys Liepia užtikrinti, kad nieko nepraleidom Įdeda saugiklius, kad nebūtų nukrypimų Specifikacija
  • 16. Svarbu tiekėjui iškomunikuot tinkamą poreikį • Pasitelkiam visus suinteresuotus asmenis • Rezultatas kurio siekiame, kokią verslo problemą sprendžiame – o ne techniniai reikalavimai
  • 17. DILEMA – „overspecification“ • Geri reikalavimai reikalauja detalizavimo • Pridėkim dar baimę kažką praleist, todėl dar daugiau įtraukiam ir detalizuojam Užsakovas pats save įvaro į kampą • Nelieka jokio lankstumo • Prarandamas fokusas į verslo poreikius
  • 18. Užsakovas ateina su savo REIKALAVIMAIS • Turint reikalavimus reikalingi tik techniniai resursai įgyvendinimui • Užsakovas iš anksto aiškiai (dažnai klaidingai) įvardina ko jam reikia • Orientacija į sistemos/produkto pagaminimą
  • 19. Užsakovas turi suformuoti poreikius ir tikslus Gimsta diskusija tarp Užsakovo ir Tiekėjo Tiekėjas gali pasiūlyti geriausią sprendimą Rezultatas bus Užsakovo problemos sprendimas
  • 20. Ar „serverių“ pirkimas gali būt Agile?  Identifikuojame problemines sritis  Paklausiame suinteresuotų šalių ar jie mato tas problemas ir koks rezultatas juos tenkintų  Išgryninam kokius TIKSLUS norim pasiekti  Iškomunikuojame tai Tiekėjui  Atmetam Tiekėjus kurie perša produktus ne sprendimą  Sutartyje įrašome kokias problemas/tikslus turi išspręsti įdiegtas sprendimas
  • 21. IT ir Verslo sinergija IT techninė kalba IT verslo kalba RPO – 2h RTO – 30min Pasiekiamumas – 99,9% HDD greitis, RAID Megabaitai Megahercai Labai svarbu iš kur šie rodikliai gimsta – jie turi būti suderinti su SUINTERESUOTAIS ASMENIMIS
  • 22. Apie Avia Solutions Group Tradicinis požiūris vs Agile Užsakymo derinimas - kas svarbu Nuosavų vykdytų projektų patirtis Usability / UX Agenda
  • 23. Kodėl poreikis naudingesnis • Rezultatas orientuotas į problemos sprendimą - suteikia laisvę surasti optimaliausią sprendimą – Tiekėjas profesionalas yra tikras galėsiantis išspręsti problemą ir niekas jam netrukdys • Kai ant stalo dedam techninius reikalavimus – tiekėjas tėra įrangos (HW ar SW) pardavėjas – Gamindamas produktą pagal Užsakovo specifikaciją tiekėjas įspraustas į rėmus
  • 24. Pavyzdys, kai specifikacija apriboja • Informacinė sistema turi dirbti su tam tikra periferine įranga – Užsakovui parinkus įrangą Tiekėjas gali susidurt su kliūtimis integruojant ją, Užsakovo rizika - netinkamai veikiantis sprendimas – Tiekėją įtraukiant į įrangos parinkimą Užsakovas garantuotas rezultatu, Tiekėjas pats kontroliuoja visą procesą (mažiau rizikų)
  • 25. Vystymas per poreikius Nauda Užsakovui • Užsakovui nereikia būti aiškeregiu ir apgalvoti visus techninius niuansus • Neturint labai detalios specifikacijos nebus kliūčių realizuoti norimą rezultatą Kaip reaguoja Tiekėjas • Rizika, kad Užsakovas poreikio apimtyje labai išsiplės • Nauda: visgi rizika išsiplėsti yra tik žinomo poreikio rėmuose, todėl turint patirties galima įvertinti • Saugiklis – įgyvendinus poreikį įvykdomi įsipareigojimai
  • 26. Rizika kurią turime suvaldyti Užsakovo baimė, jeigu iškart nebus įtraukta į reikalavimus - nebus įgyvendinta Atsirinkti tiekėją kuris nebijo bendrauti per poreikius, o ne per sausą įrangos specifikaciją Smulkmenos poreikio rėmuose vis tiek lieka derybų reikalas ginčo atveju
  • 27. Iš patirties... – FRAUD! • Neapsigaukit ant visiško Agile‘izmo • Tiekėjas nepateikia nei kainos, nei laiko, grįsdamas dirbantis Agile principais
  • 28. Fiksuota kaina ar valandinis įkainis • Užsakovas nežino kainos • Užsakovas turi patirties Time & Material • Užsakovas žino už ką moka • Rizika tiekėjui = buferis Fixed price Fixed scope • Kaina už poreikį • Tiekėjas turi patirties Agile metodas
  • 29. Apie Avia Solutions Group Tradicinis požiūris vs Agile Užsakymo derinimas - kas svarbu Nuosavų vykdytų projektų patirtis Usability / UX Agenda
  • 30. Diegimo iteracijomis pavyzdys I etapas Sistemos diegimas/pridavimas Administratorių mokymai „pirminiai“ Mokymai tikslinei darbuotojų grupei Tikslinė darbuotojų grupė pradeda naudotis II etapas Programavimas/pridavimas: Prioritetiniai išplėtimai Administratorių mokymai „pažengusiems“ Visi darbuotojai dirba su sistema III etapas Priežiūra po paleidimo Programavimas/pridavimas: Kiti išplėtimai Duomenų importas iš kitų sistemų
  • 31. Įgimta dirbti pagal specifikacijas Gyvenimiška patirtis: sistema buvo vystoma palaikymo skyriaus esamos apimties ribose, darant daug „workaround“ Sprendimas: suinteresuotų šalių susitikimas kurio rezultatas dedikuota vystymo komanda
  • 32. Apie Avia Solutions Group Tradicinis požiūris vs Agile Užsakymo derinimas - kas svarbu Nuosavų vykdytų projektų patirtis Usability / UX Agenda
  • 33. Nesutarimų priežastys “Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.” ~ Albert Einstein~
  • 34. Sprendimas • Sutartyje įrašom, jog funkcionalumas turi būti maksimaliai efektyvus • Jeigu akivaizdžiai procesas iš vartotojo pusės gali būti atliktas paprasčiau, suprantamiau ir greičiau tuomet jis turi būt efektyvinamas • Priklausomai nuo specifikos konkretizuojam žingnių skaičiumi, laiku procesui atlikti ar pan. • Pvz: Keleivio aptarnavimas – ne ilgiau 3 min.
  • 35. Jeigu Tiekėjui netinka sąlygos Reikia rinktis Tiekėjus kuriems tai priimtina Užsakovai irgi turi reikalauti geresnio produkto Tiėkėjai pirmi pradėjo siūlyti Agile koncepciją
  • 36. CRM Kas yra Nr.1 CRM sistemų nesekmės priežastis? Vartotojų pasitenkinimas sistema
  • 37. Kaip padidinti CRM efektyvumą Turime „parduoti“ CRM‘ą naudotojams Komunikacija (intranetas, video, naujienlaiškis) Naujų ir esamų darbuotojų mokymai Įsiklausymas į visų suinteresuotų asmenų poreikius Nuolatinis procesų efektyvinimas Nedideli bet dažni atnaujinimai

Editor's Notes

  • #8: SPA dirba LT, PL, IT, UK, FRBGS – LT, PL, IT
  • #11: Iššūkiai – dinamiškas IT pasirengęs plėtraiAugimas nebūtinai viskas sudėtingėja ir reikalauja naujos infrastruktūros, naujų sprendimų, papildomų žmonių. Reikalinga strategija
  • #14: Klaidingas manymas, kad didelė išpūsta specifikacija užtikrins projekto sėkmęOrientacija į sistemos atitikimą specifikacijai
  • #18: Pavyzdys – gamybos sistema vystoma specifikacijos remuoseTai galioja visam projektui / jo startui, eigoje mes giliname ir galim detalizuot
  • #19: dažnai reikalavimai surašomi vieno ar kelių žmonių kurie daro prielaida, kad žino už visą įmonė ko jai reikia šiandien ir rytoj!
  • #24: Kai ant stalo dedam techninius reikalavimus tiekėjas bus tik įrangos ar programavimo resursų pardavėjas
  • #25: Galbūt tiekėjui atsakomybė už įranga yra papildoma rizika, bet ar ne didesnė rizika pasižadėti sukurti sprendimą įrangai kuri parinkta neatsižvelgiant į programinį suderinamumą ?
  • #29: Time & MaterialEsam tikri kad tiekėjas dirba „teisingais“ metodaisKlientas turi projektų vykdymo patirtį ir stiprų PVLabiau tinkamas papildomiems darbamsFixed price Fixed scopeKlientas žino kiek mokės už galutinį rezultatąTiekėjas mato rizika todėl „užsimeta“ buferįJeigu kaina už specifikaciją neturim lankstumoAgile metodas (?)Kiekvienas poreikis (user story) įvertinamas $Galutinė kaina yra suma atskirų poreikiųPapildomi darbai gali būt TnM
  • #32: Pridavimas po kiekvieno etapoRealus naudojimasis sistema jau po pirmojo etapo!Eigoje keiteme prioritetusTurėdami patirties su sistema jau kitaip galėjom planuoti ir ruoštis sekantiems etapams
  • #35: Ilja Laurs pasakojo, kad jam pateike 100tukst saskaita uz front page dizainaDaznai Vykdytojo darbas baigtas igyvendinus funkcionaluma, jo efektyvumas mazai diskutuotinas
  • #39: Sukurti produktą tik dalis įdirbioAGILE: Sistema turi but „gyva“, nuolatos tobulinama pagal vartotoju poreikius ir besikeiciancius poreikius