Projekthantering på Front Elin Andersson Front Capital Systems AB www.front.com
Vem är jag Drygt fem år sen jag kom ut härifrån KTH d92 (tog examen maj 97) Började exjobba på Front höst 96, och har blivit kvar Jobbar med produktutveckling Först som utvecklare Sen projektledare i många olika projekt Frågor? elin@front.se
Front Capital Systems Produktbolag verkar inom Finans / IT branschen Vi gör system som bankernas mäklare, analytiker använder Börshandelssystem, optionsvärdering, riskanalys, portföljhantering mm Grundades 1987, idag 230 anställda
Varför är kunskap om projekthantering viktigt? 90% av all systemutveckling sker i projektform i IT-industrin Ni kommer att jobba i projekt! Projekt misslyckas skrämmande ofta Projekt kan vara (mycket) svårt Orsaken till projektmisslyckande är ofta dålig planering och kontroll = dålig projektledning Vill inte bli ett museum
Projekt generellt Projektdefinition Innehåll Varför är det så svårt att få projekt i mål Exempel från verkligheten på Front Saker som vi gör bra på Front Saker som vi gör mindre bra på Front Hur vi lyckas få våra projekt i mål
Mål - vad vill jag att ni ska ha med er från denna föreläsning Vad ett projekt är Förstå några svårigheter med IT-projekt Få en inblick i hur verkliga projekt på Front ser ut och hanteras Varför är detta så viktigt?
En mindre lyckad projektkick-out
VASA Projektledare: Skeppsbyggmästare Henrik Hybertsson Beställare: Kung Gustaf II Adolf Mål: Världens största krigsfartyg Uppgift: Varför gick det fel? Vems var felet?
Vad är projekt? En organisationsform Projektgrupp, projektledare Beställare Styrgrupp Har ett sluttillstånd: målet Projektet ska anpassa systemet till derivathandel i Tyskland Har en projektdefinition: Resultat: Målbilden, som spjälkas upp i ett antal mål och uppgifter Tid Kostnad (resurser) Kvalitetskrav
Vad är projekt? (forts) Är av engångskaraktär Annars är det normal linjeverksamhet Har en beställare Är oftast ett förändringsarbete Har egen rapportering internt och externt Internt: projektmöten och protokoll Externt: Styrgruppsmöten och protokoll
IT projekt: Ett sorgligt kapitel Statistik: 15 % av alla projekt levererade inget alls Budget överskrids med 100-200% [DeMarco Controlling Software Projects, 1982] Tidsavvikelse med 34% (+/-60%) för 20 olika projekt Premie pensions systemet (PPM) Projektet försenat 1 år Bidragande orsak: Orutinerad beställare, saknades kompetens och tid för att göra bra kravspecifikationer för systemet Konsekvens: Lägre pensioner (missade börsrallyt hösten 1999)
Varför så svårt? "No silver bullet: Essence and accidents of software engineering" [Fredrick P. Brooks, IEEE Computer, 1987] Problemet är inbyggt: Vi försöker lösa komplicerade abstrakta problem, det ÄR svårt Bra geometriska representationer saknas
Vanliga problem i IT-projekt Beställarna vet inte vad de vill ha Beställarna fokuserar på Hur det ska göras Projektledningen kan inte säg nej Projektledningen gör orimliga planer och har dålig kontroll Tekniken driver utvecklingen Dåliga avtal mellan leverantörer och kund Dåliga tekniska lösningar ifrågasätts inte Beställarna inser inte att de inte är kompetenta att specificera vad de vill ha från en IT-lösning
Projekt på Front Vidareutvecklingen av vår produkt sker i projektform Bestämd grupp av personer som jobbar med viss del av produkten Ofta en given sluttidpunkt Krav från många olika håll Otydlig beställare
Krav på produkten FRONT ARENA Realtid STORA datamängder 100 order/s genererar 100 prisuppdateringar/s, som ska skickas till 1000 inloggade användare i realtid Uptime nästan 100 % (vår produkt hanterar miljontals kronor dagligen) Robust - inte krascha Korrekt - får inte visa fel priser på BMW, Coca cola, Nokia aktien eller Nasdaq indexen
Andra krav på produkten Mycket komplexa integrationer uppkopplingar mot börser koppling till Reuters eller SIX prisfeed, Back Office system, dvs. det system som banken har som facit för att hålla reda på allt om sina kunder, deras pengar etc. Trades ska flöda in, pengar ska dras rätt, notor ska skickas Lång livslängd! Bankerna måste kunna lita på oss att vi kan hantera alla deras pengar och flöden imorgon, nästa vecka, nästa år, om 5 år
Komplex kravbild och många kravställare Bankerna/mäklarna Rapporterar in alla buggar, önskemål om ny utvecklig Front måste kunna kundernas verksamhet så bra att vi kan förutspå vilka krav de kommer ha på oss (även outtalade krav), samt vilka av deras krav som verkligen är viktiga Våra egna önskelistor Saker vi vill fixa, som vi hittat själva Införa nya tekniker läsa in instrumenten(t ex Ericsson, Volvo) via XML filer Börserna förändras ständigt vi måste anpassa oss (produktionsstart 1 Juni)
Forts. komplex kravbild Vi vill till nya geografiska marknader Aktuellt exempel: Sydafrika. Då får vi bygga en ny modul som kommunicerar med Johannesburg Stock Exchange (JSE): Fungerar tekniskt på ett helt annat sätt Har nya features som inte vi stöder innan - detta bakas in i och anpassas till befintliga APIer, protokoll, datamodeller, gui etc. Besvärlig infrastruktur i Sydafrika (stulna koppartrådar) Slutsats: kraven kommer från många olika källor och kan vara av mycket skiftande karaktär, vilket tillsammans ger en komplex kravbild
Beställaren ProductManagement (grupp inom Front) agerar beställare, ger grundprioriteringar och målbilden Projektledningen och ProductManagement sätter upp mål, delmål och sammanställer kravlistor.
Yttre tidsramarna ofta redan satta Börsuppgradering; version X gäller från 1 April Ny börs som öppnar 1 juni bra tillfälle att få nya kunder Ny kund som ska gå i produktion 1 september
Projekt / utvecklingsmodell Vi kör en variant på vattenfallsmodellen, med viss påverkan från Ericsson modelller Definierar ett antal projektfaser Definierar milstolpar Milstolpar är konkreta tillstånd som man har uppnått Milstolpar har ett planerat datum (och ett verkligt datum när de avklarades)
Projektfaser Kravinsamling & prioritering Projekt kick-off med riskanalys Design och kodning, avslutas med milstolpe Feature Complete (inga nya features, bara test och buggfixning) Installera & få igång - rough test Intern test (vi testar) Field test (kunden testar) hos oss, hos kund Dokumentation och överlämning Produktionstagning (kan ta lång tid, beror på banken)
Milestone plan Milestone Plan Ready MS 1. Exit of Definition phase 1 December 1 December MS 2. Exit of Planning phase 10 December 10 December MS 3. Feature Complete 20 February 20 February MS 3.1 Feature Complete AWT 20 March 20 March MS 3.2 Feature Complete Java Client 17 April MS 4. Installed in FRONT ARENA 28 February 13 March MS 5. Exit of Execution Phase 13 March 20 March (ready to start Field Test) MS 6. Release Status white 13 March 22 March MS 7. Release Yellow 17 April MS 8. Project Conclusion 30 May
Snabbkurs NEJ! Projektledaren
Uppgift! Ange tre vanliga uppgifter en projektledare har
Projektledaren Planerar och leder arbetet Kontrollerar och följer upp aktiviteter: "Hur går det?" "Hur långt har du hunnit?" "När är du klar?" Informerar och rapporterar internt (i projektet) och externt (ut i organisationen)
Projektledare på FRONT Informera Ställa krav, följa upp Uppmuntra Skriva protokoll Köpa bullar, tårta, champagne
Uppskattningar, varför så fel? Experiment: Uppskatta antalet böcker du äger! Tid för detta: 15 sekunder
En aktivitets tidsuppskattning är.. ofta den mest optimistiska uppskattningen, som har noll sannolikhet att inträffa Gäller i IT-branschen Lär sig inte av sina tidigare erfarenheter Hur lång tid tar det att bygga en modul som hanterar handel av fonder?
Uppgift: Vanliga risker Personbortfall Orealistiska tidsplaner/budget Fel funktioner utvecklas Förändrade krav
Riskanalys på Front Vilka risker ser du? Risken är att vi bara håller på med support Risken är att designfasen av trading agenter tar dubbelt så lång tid Hur stor sannolikhet att risken inträffar? 5 hög risk (händer definitivt), 1 låg risk Hur stor blir effekten om det händer? Multiplicera ihop dessa två, så har du fått fram riskmått som du kan jämföra
Riskanalys på Front Diskutera riskerna, börja med den allvarligaste Vilka åtgärder kan sättas in för att undvika att detta händer? Distribuera ut ansvar för detta i projektgruppen Dokumentera och distribuera riskerna samt deras motåtgärder Återkom till dessa under projektets gång Var alert om du ser tecken på att risken håller på att bli ett faktum
Risker hittade under riskanalys 1. Nya och gamla krav utanför prioriteringslistan försenar projektet Sannolikhet Effekt Prio Ansvarig 4 5 20 ElinA - Okoordinerade krav från esales - Risken är att vi har svårt att säga nej till nya krav - Att vi får in nya kundkrav - typ kryptering från Bayerische LB - För hård prioritering -> viktiga punkter måste lämnas därhän - Risk för att vår egen ToDo -lista aldrig genomförs pga. kundkrav som prioriteras - Oförutsedda krav från Tyskland (Istron) - Risk att det finns saker lovade som ingen känner till. - Nya kundkrav försenar projektet - Ingen enhetlig kanalisering av kundkrav Åtgärdsidéer som kom fram under mötet: - Se till att alla kundkrav går genom projektledaren och att ingen gör sina egna sidospår. - Att client managers samlar in alla krav och rapporterar dem tydligt i Remedy - Vara hårdare mot client managers/kunder. Våga säga nej! - Ta höjd för libero tid för alla utvecklare
För att lyckas med IT-projekt Korta projekt! Mindre än 6 månader Dela upp projekt i olika faser Skriv tydliga kravspecifikationer Säg NEJ till nya saker, ta dessa i nästa fas Pressa beställarna att beskriva VAD de vill ha Använd mycket tid på arbetsmöten för att definiera vad det är som förväntas Använd prototyper (pappersvarianter av systemet)
Bra / mindre bra på Front Vad gör vi bra? Välfungerande metod för att driva projekt Duktiga på riskanalys Bra rutiner kring tester, releaser Bra på definiera milstolpar, projektfaser, samt uppfylla milstolparna och avsluta projektfaserna Vad gör vi mindre bra? Dåliga på att sammanställa kraven samt att prioritera kraven Låsta yttre tidsramar från början Dåliga på tidsuppskattningar Ibland otydlig beställare
Varför lyckas projekten på Front Kvalitetssäkringsmetoder inbyggda i projekten Testspecar, ordentliga testperioder, Överlämning till mottagare - bra fokus på dok Riskanalyser innan, projektutvärdering efter -lära av misstag Väl fungerande projektmodell / projektprocess Engagerade och duktiga kollegor Stor produktkännedom Vi vet VAD vi ska göra och varför Vi har kul! Bra gäng och bra atmosfär!
Kvalitetssäkring You don't have to do this, survival is not compulsory W. Edwards Deming