Fallet Vasa
Den här veckan har vi i grupp fått analysera varför skeppet Vasa sjönk. Vi har fått använda oss av de olika metoder man använder sig av vid planering av ett projekt. Intressentkarta: Man kartlägger intressenter. Intressenterna är de som behövs, påverkas eller bevakar projektet. Investerare Marknad * Kung Gustav II Adolf * Vapenleverantör* Admiral Klas Fleming * Timmerleverantör* Kommandör Erik Jönsson Kremer * Hantverkare * Besättning Skeppet Vasa Medarbetare Samhälle* Henrik Hybertsson * Svenska folket* Ardent de Groot * Danska flottan* Hein Jacobsson* Johan Isbrandsson* 400 arbetare Tidslinje: Visar händelseförloppen 1625Kontrakt - Beställer timmer - Storm i Riga - Tre kronor klar - Ny Spec: två små skepp men större 1626Fallar för timmerproblem - Ny Spec: 1 stort skepp - Skarvar motvilligt 111 fotare - Ny spec: 2 däck 1627 Hybertsson dör - Ny spec: fler kanoner - Sjösätter skrov och utsmyckar - Ny spec: större kanoner 1628Test utförs - Sjösättning WBS över hur det borde gått till när man bygger ett skepp: En strukturering där man bryter ner projektets mål i mindre delar Administration Konstruktion Material Test * Design * Täta * Råmaterial * Hållbarhet * Ritningar * Köl * Utsmyckning * Tyngdpunkt * Materialberäkning * Mast * Kanoner * Stabilitet * Arbetsplan * Skrov * Segel * Läckage * Rekrytering * Däck * Ankare * Inreda * Rep Aktivitetsplan Förändringar som hade negativ påverkan: * Vid aktiviteten bygga köl ändras först måtten och lite senare ändras kraven till en stor båt. * Vid aktiviteten bygga skrov ändras kraven till dubbla däck och senare även till fler kanoner. * Vid aktiviteten bygga däck ändras kraven så att större kanoner ska få plats och senare utförs tester utan att kommuniceras. Fallgropar - varför sjönk Vasa? * Velig kund med orimliga krav * Dålig dokumentationshantering så som ritningar och kravspecfikation * Begränsad kunskap * Avsaknad av kommunikation * Brist på tester Självklart finns det paralleller att dra till nutida mjukvaruprojekt. Jag anser att alla projekt kommer sluta dåligt om de här fem punkterna jag nämnde finns med som fallgropar. För att ge några exempel så kan det vara så att kunder saknar domänkunskaper och därför blir kraven orimliga. Gällande dokumentationshantering kan koden vara dåligt dokumenterad. Avsaknad av kommunikation kan bero på att man har för få möten och gällande begränsad kunskap kan det handla om nya tekniker.