Benutzer-Werkzeuge
se:projektmanagement
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung | Nächste Überarbeitung Beide Seiten der Revision | ||
|
se:projektmanagement [2009-04-13 18:46] stefan |
se:projektmanagement [2009-04-14 15:02] stefan |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| + | ====== Projektmanagement ====== | ||
| + | |||
| ===== Einführung ===== | ===== Einführung ===== | ||
| * Software-Projektmanagement überschneidet sich mit anderen Themengebieten der Softwareentwicklung | * Software-Projektmanagement überschneidet sich mit anderen Themengebieten der Softwareentwicklung | ||
| Zeile 343: | Zeile 345: | ||
| * Gespräche vor- und nachbereiten (am besten wieder zu zweit, da hochkomplexe Aufgabe) | * Gespräche vor- und nachbereiten (am besten wieder zu zweit, da hochkomplexe Aufgabe) | ||
| * Methoden zur Verständigungssicherung nutzen (Rückkopplungen, Visualisierungen) | * Methoden zur Verständigungssicherung nutzen (Rückkopplungen, Visualisierungen) | ||
| + | |||
| + | === Beratung als Prozess === | ||
| + | * mögliches Vorgehensmodell (Beratung ist immer dynamisch): SALVE-TE | ||
| + | * Start | ||
| + | * Begrüßung, Vorstellung, Warming-up | ||
| + | * Vorgehen, Regeln, Erwartungen klären | ||
| + | * Was wollen wir erreichen? Vision klären | ||
| + | * Analyse | ||
| + | * konkrete, detaillierte Beschreibung Ist-Zustand | ||
| + | * umfassende Informationssammlung und -auswertung | ||
| + | * zusammenfassende Beschreibung der Anforderungssituation | ||
| + | * Lösungssammlung | ||
| + | * kreative Ideensammlung (Brainstorming) | ||
| + | * ggfs. zurück zum Start | ||
| + | * Verhandlung | ||
| + | * Bewertung der Lösungsansätze, Feedback | ||
| + | * Diskussion und Abstimmung | ||
| + | * Abgleich kontroverser Interessen, Konfliktmanagement | ||
| + | * ggfs. zurück zur Lösungssammlung | ||
| + | * Entscheiden | ||
| + | * zwischen Alternativen entscheiden | ||
| + | * Vorgehen vereinbaren | ||
| + | * Commitment sicherstellen (sonst zurück zu Verhandlung, Lösungssammlung, Analyse oder Start) | ||
| + | * Verabschiedung von Maßnahmen (wer, wie, was, wann) | ||
| + | * Transfer | ||
| + | * Durchführung in der Praxis | ||
| + | * Ergebnissicherung | ||
| + | * Verfolgen der Umsetzung in der Praxis | ||
| + | * Bewertung der Veränderungen | ||
| + | * Abgleich mit Vereinbarungen der Entscheidung | ||
| + | * Vergleich mit Situation aus der Analyse | ||
| + | * Vergleich mit Vision vom Start | ||
| + | * ggfs. zurück zu einer anderen Stufe | ||
| ==== Grobplan ==== | ==== Grobplan ==== | ||
| Zeile 624: | Zeile 659: | ||
| Der Projektauftrag sollte in Form einer Beratung geklärt werden. Der Berater muss hierzu über Fachkompetenz verfügen, die er benötigt um dem Kunden Hilfestellung bei der Entscheidung für bestimmte Produkte oder Lösungen geben zu können (Was ist machbar? Was sind die jeweiligen Vor- und Nachteile?). Aber auch Methoden- und Sozialkompetenz ist wichtig, um die korrekten Informationen bzgl. der Wünsche des Kunden erarbeiten zu können. Der Berater steht mit seinen Fähigkeiten dem Kunden zur Seite und hilft ihm bei der exakten Formulierung von Anforderungen (etwa mit Hilfe von UML oder BPMN), um späteren Missverständnissen vorzubeugen. Nur auf Basis einer fundierten Anforderungsanalyse kann ein Projekt erfolgreich durchgeführt werden. | Der Projektauftrag sollte in Form einer Beratung geklärt werden. Der Berater muss hierzu über Fachkompetenz verfügen, die er benötigt um dem Kunden Hilfestellung bei der Entscheidung für bestimmte Produkte oder Lösungen geben zu können (Was ist machbar? Was sind die jeweiligen Vor- und Nachteile?). Aber auch Methoden- und Sozialkompetenz ist wichtig, um die korrekten Informationen bzgl. der Wünsche des Kunden erarbeiten zu können. Der Berater steht mit seinen Fähigkeiten dem Kunden zur Seite und hilft ihm bei der exakten Formulierung von Anforderungen (etwa mit Hilfe von UML oder BPMN), um späteren Missverständnissen vorzubeugen. Nur auf Basis einer fundierten Anforderungsanalyse kann ein Projekt erfolgreich durchgeführt werden. | ||
| - | ==== 2.5: Wann ist keine Vorstudie nötig? ==== | + | === 2.5: Wann ist keine Vorstudie nötig? === |
| Eine Vorstudie ist bei jedem Projekt nötig, um abzuklären, ob dieses überhaupt durchzuführen ist. Je nach Umfang des Projekts kann sich die Vorstudie zwar auf einige kurze Überlegungen beschränken, dennoch ist sie stets Teil des Projektverlaufs. | Eine Vorstudie ist bei jedem Projekt nötig, um abzuklären, ob dieses überhaupt durchzuführen ist. Je nach Umfang des Projekts kann sich die Vorstudie zwar auf einige kurze Überlegungen beschränken, dennoch ist sie stets Teil des Projektverlaufs. | ||
| - | ==== 2.6: Wie detailliert wird ein Grobplan? ==== | + | === 2.6: Wie detailliert wird ein Grobplan? === |
| Der Grobplan des Projektverlaufs enthält analog zur Grobgliederung einer Diplomarbeit o.ä. lediglich die zentralen Punkte des Projekts, etwa wichtige Meilensteine. Er dient als Basis für die detaillierte Feinplanung und kann im Extremfall sogar komplett umgeändert werden, wenn sich Anforderungen ändern. Auch bei der Erstellung eines Grobplans ist stets der Umfang des Projekts zu berücksichtigen (bei größeren Projekten wird der Grobplan im Verhältnis zu kleineren natürlich viel oberflächlicher sein). | Der Grobplan des Projektverlaufs enthält analog zur Grobgliederung einer Diplomarbeit o.ä. lediglich die zentralen Punkte des Projekts, etwa wichtige Meilensteine. Er dient als Basis für die detaillierte Feinplanung und kann im Extremfall sogar komplett umgeändert werden, wenn sich Anforderungen ändern. Auch bei der Erstellung eines Grobplans ist stets der Umfang des Projekts zu berücksichtigen (bei größeren Projekten wird der Grobplan im Verhältnis zu kleineren natürlich viel oberflächlicher sein). | ||
| - | ==== 2.7: Persönliche Checkliste für Präsentationen ==== | + | === 2.7: Persönliche Checkliste für Präsentationen === |
| * Zuhörer- und Situationsanalyse | * Zuhörer- und Situationsanalyse | ||
| * Angemessener Umfang der zu vermittelnden Informationen | * Angemessener Umfang der zu vermittelnden Informationen | ||
| Zeile 639: | Zeile 674: | ||
| * Zuhörer aktiv einbinden (direkt ansprechen, Aufgaben lösen lassen etc.) | * Zuhörer aktiv einbinden (direkt ansprechen, Aufgaben lösen lassen etc.) | ||
| - | ==== 2.8: Beispiele für Teams ==== | + | === 2.8: Beispiele für Teams === |
| * EDV-Abteilung | * EDV-Abteilung | ||
| - Kontakt: (wochen)täglich | - Kontakt: (wochen)täglich | ||
| Zeile 653: | Zeile 688: | ||
| - Wir-Gefühl: Studenten eines Jahrgangs | - Wir-Gefühl: Studenten eines Jahrgangs | ||
| - | ==== 2.9: Team zur Durchführung einer Vorstudie zur Entwicklung einer Projektmanagement-Software aufstellen ==== | + | === 2.9: Team zur Durchführung einer Vorstudie zur Entwicklung einer Projektmanagement-Software aufstellen === |
| * Softwareentwickler, da letztendlich eine Software zu erstellen ist | * Softwareentwickler, da letztendlich eine Software zu erstellen ist | ||
| * Projektleiter/-mitarbeiter, die praktische Erfahrung mit der Durchführung von Projekten haben und Hilfestellung bei der Anforderungsanalyse geben können | * Projektleiter/-mitarbeiter, die praktische Erfahrung mit der Durchführung von Projekten haben und Hilfestellung bei der Anforderungsanalyse geben können | ||
| * Zukünftige Benutzer der Software, da sie am ehesten die Zwischenergebnisse auf Tauglichkeit bewerten können | * Zukünftige Benutzer der Software, da sie am ehesten die Zwischenergebnisse auf Tauglichkeit bewerten können | ||
| - | ==== 2.12: Worauf ist bei der Übernahme von Projekten in funktionalen Unternehmen besonders zu achten? ==== | + | === 2.12: Worauf ist bei der Übernahme von Projekten in funktionalen Unternehmen besonders zu achten? === |
| * Kompetenzgerangel: Abteilungsleiter <> Projektleiter | * Kompetenzgerangel: Abteilungsleiter <> Projektleiter | ||
| * Die Projektmitarbeiter sind meist noch im Tagesgeschäft eingespannt | * Die Projektmitarbeiter sind meist noch im Tagesgeschäft eingespannt | ||
| Zeile 664: | Zeile 699: | ||
| * Mitarbeiter sind evtl. mit der Projektorganisation nicht vertraut (an Abteilungsdenken gewöhnt) | * Mitarbeiter sind evtl. mit der Projektorganisation nicht vertraut (an Abteilungsdenken gewöhnt) | ||
| - | ==== 2.13: Was bringt der Einsatz von Prozessbeschreibungsstandards für die Softwareentwicklung und die Informationstechnologie? ==== | + | === 2.13: Was bringt der Einsatz von Prozessbeschreibungsstandards für die Softwareentwicklung und die Informationstechnologie? === |
| * Eindeutige Prozessbeschreibungen mit weniger Interpretationsspielraum als bei Freitext | * Eindeutige Prozessbeschreibungen mit weniger Interpretationsspielraum als bei Freitext | ||
| * Erstellte Prozessbeschreibungen können evtl. zur automatischen Codegenerierung verwendet werden oder sind als Software lauffähig (z.B. in einer SOA) | * Erstellte Prozessbeschreibungen können evtl. zur automatischen Codegenerierung verwendet werden oder sind als Software lauffähig (z.B. in einer SOA) | ||
| Zeile 670: | Zeile 705: | ||
| * Bei der Modellierung von Prozessen mit Hilfe von Prozessbeschreibungssprachen muss von Anfang an eindeutig und umfassend modelliert werden, was die Qualität der Modelle erhöht | * Bei der Modellierung von Prozessen mit Hilfe von Prozessbeschreibungssprachen muss von Anfang an eindeutig und umfassend modelliert werden, was die Qualität der Modelle erhöht | ||
| - | ==== 2.14: Was ist die Hauptaufgabe des Projektleiters in prozessorientierten Unternehmen? ==== | + | === 2.14: Was ist die Hauptaufgabe des Projektleiters in prozessorientierten Unternehmen? === |
| * Der Pojektleiter ist in der bereits gut auf Projektarbeit vorbereiteten prozessorientierten Unternehmenskultur hauptsächlich für die Rahmenbedingungen (z.B. Arbeitsräume, Werkzeuge aber auch Kenntnisse von Methoden) zuständig. | * Der Pojektleiter ist in der bereits gut auf Projektarbeit vorbereiteten prozessorientierten Unternehmenskultur hauptsächlich für die Rahmenbedingungen (z.B. Arbeitsräume, Werkzeuge aber auch Kenntnisse von Methoden) zuständig. | ||
| * Des Weiteren hält er Kontakt zur übergeordneten Führungsebene und steuert das Projekt in die richtige Richtung. | * Des Weiteren hält er Kontakt zur übergeordneten Führungsebene und steuert das Projekt in die richtige Richtung. | ||
| + | |||
| + | ===== Planung ===== | ||
| + | * Ergebnis der Planung: Projektplan (auch Feinplan, Projektsteuerungsvorgabe) | ||
| + | * Aufgaben | ||
| + | * Steuerung des Projekts über die gesamte Laufzeit | ||
| + | * Fortschritt beobachten und dokumentieren | ||
| + | * Reaktion auf Risiken und Unvorhergesehenes | ||
| + | * kann jederzeit an neue Erkenntnisse angepasst werden | ||
| + | * vor Erstellen des Plans findet das Kick-Off mit allen Projektbeteiligten statt -> der Plan kann dann leichter erstellt werden (alle Beteiligten liefern Input) | ||
| + | * Kick-Off (mit allen Teilnehmern) | ||
| + | * Aufgaben | ||
| + | * Kennenlernen der Teilnehmer (-> später kurze Kommunikationswege, man kennt sich) | ||
| + | * einheitliche Informationen über Ziel und Inhalte des Projekts an alle Beteiligten vermitteln | ||
| + | * allen Beteiligten die eingesetzten Kommunikationswege/-medien näherbringen | ||
| + | * Verpflichtung der Teilnehmer zur Dokumentation | ||
| + | * Ziel: Absprachen gemeinsam treffen | ||
| + | * alle Teilnehmer unterschreiben, dass sie teilgenommen haben und erhalten ein Protokoll | ||
| + | * Vorbereitung ist sehr wichtig (was mache ich? was erarbeiten wir gemeinsam?) | ||
| + | * Tagesordnung aufstellen | ||
| + | * Einführung in Ziele durch Projektleiter | ||
| + | * Vorstellung aller Beteiligten | ||
| + | * Zusammenstellen und Verteilen der Aufgaben | ||
| + | * Kommunikations- und Informationswege festlegen | ||
| + | * Festlegen der konkreten nächsten Schritte | ||
| + | * Offene Fragen klären | ||
| + | * der Projektleiter sollte nicht als Moderator agieren (externer Moderator behält Zeit im Auge und greift bei ausschweifenden Diskussionen ein) | ||
| + | * Protokollführer und -form festlegen | ||
| + | * muss auf der Projektmanagementplattform veröffentlich werden | ||
| + | * sollte wenig Aufwand machen | ||
| + | * jede Sitzung muss protokolliert und allen Beteiligten zur Verfügung gestellt werden | ||
| + | |||
| + | ==== Moderation von Besprechungen ==== | ||
| + | * Phasen: Vorbereitung, Durchführung, Nachbereitung | ||
| + | * Vorbereitung | ||
| + | * klar werden über sachlichen Anlass der Besprechung (Sachebene) | ||
| + | * Informationsinput | ||
| + | * Informationsoutput | ||
| + | * Problemlösungen | ||
| + | * anstehende Entscheidungen | ||
| + | * psychosoziale Aspekte | ||
| + | * Stimmung der Gruppe (konfliktgeladen, konstruktiv) | ||
| + | * kennt sich die Gruppe bereits? | ||
| + | * Fragestellungen (der Besprechungsleiter muss diese vorab klären) | ||
| + | * Besprechungsanlass: warum, warum jetzt, fand vorher schon etwas statt, wer hat welches Interesse | ||
| + | * Besprechungsziele: mess- und prüfbare Ziele formulieren, sekundäre Ziele | ||
| + | * Zusammensetzung der Gruppe: wer, warum | ||
| + | * Ziele der Teilnehmer: Ziele, Absichten, Erwartungen der Teilnehmer, wer leistet Widerstand/Unterstützung | ||
| + | * Vorwissen der Teilnehmer: Kenntnisstand, Hintergründe, Fachwissen, Problemlage | ||
| + | * formales Ziel der Besprechung: wann ist sie ein Erfolg, was darf nicht passieren, was ist nicht Thema, Erfahrungsaustausch/Problembewusstsein/Lösungsansätze/erste Schritte | ||
| + | * Hindernisse | ||
| + | * Vorbereitung der Teilnehmer: wer, wie | ||
| + | * Konflikte: objektive/subjektive Ziel-/Interessendivergenzen | ||
| + | * Tabus | ||
| + | * Konsequenzen | ||
| + | * Gestaltung der Besprechung: Stil, Methodik, Zeit, Teilnehmer | ||
| + | * Rahmenbedingungen: Ort, Zeit, Pausen, Raumausstattung | ||
| + | * Lösungsdruck: schnelle Lösung oder langfristige Verbesserung | ||
| + | * Entscheidungsbefugnisse | ||
| + | * Besprechungsstil: kennen die Teilnehmer den Stil | ||
| + | * wenn die Moderation delegiert wird, sind die Fragen mit dem Verantwortlichen zu klären, insbesondere Anlass, Ergebniserwartung, Tabus, Entscheidungsbefugnis | ||
| + | * Einladung | ||
| + | * Bezug, Projekt, Arbeitsbereich | ||
| + | * Zweck/Grund der Besprechung | ||
| + | * Einlader | ||
| + | * Ansprechpartner und Form für Wünsche zur Besprechung | ||
| + | * Besprechungsziel | ||
| + | * Verteiler | ||
| + | * Datum, Uhrzeit, Beginn, Ende | ||
| + | * Ort und Raum | ||
| + | * Protokollführer | ||
| + | * geplante Tagesordnungspunkte einschließlich notwendiger Beiträge | ||
| + | * Materialien bereitstellen | ||
| + | * Tische/Stühle | ||
| + | * Pinnwände/Flipcharts | ||
| + | * Beamer/OHP | ||
| + | * Durchführung | ||
| + | * Besprechungen sind Prozesse (vorher andere Situation als nachher) | ||
| + | * immer sowohl auf der sachlichen als auch auf der psychosozialen Ebene | ||
| + | * Differenzen zwischen den Ebenen führen zu Problemen | ||
| + | * Ergebnisse werden meist nur erreicht, wenn Konflikte beigelegt werden und auf der sachlichen Ebene diskutiert wird | ||
| + | * Protokolle sind meist vorgefertigte Formulare (Ergebnisliste) | ||
| + | * Qualifizierung des Ergebnisses | ||
| + | * Feststellung: Tatbestand/Sachverhalt, Auswirkungen stehen fest | ||
| + | * Beschluss: bindende Einigungen der Teilnehmer, zukunftsbezogen | ||
| + | * Empfehlung: wenn kein Beschluss möglich oder Externe betroffen sind, zukunftsbezogen | ||
| + | * Auftrag: verpflichtet zum Handeln (Tun oder Unterlassen), inhaltlich fixiert, zukunftsbezogen, erfordert eine Einigung zwischen Auftraggeber und -nehmer | ||
| + | * betroffene Teilnehmer | ||
| + | * Erläuterungen | ||
| + | * Terminfestlegung | ||
| + | * sollten sofort nach Ende der Besprechung verteilt werden | ||
| + | * Nachbereitung | ||
| + | * Reflexion | ||
| + | * sachlich: Ziele prüf-/messbar erreicht? | ||
| + | * psychosozial: Klimaänderungen, unberücksichtigte Themen/Beteiligte? | ||
| + | * Checkliste für Reflexion | ||
| + | * äußere Bedingungen | ||
| + | * Besprechungsraum | ||
| + | * technische Hilfsmittel | ||
| + | * Besprechungszeit | ||
| + | * Besprechungsdurchführung | ||
| + | * Zielorientierung | ||
| + | * Gesprächsklima | ||
| + | * dominante/zurückhaltende Teilnehmer | ||
| + | * Kommunikationsstörungen | ||
| + | * Konflikte | ||
| + | * Dokumentation | ||
| + | * sind alle Ergebnisse fixiert? | ||
| + | * wurde das Protokoll an alle Teilnehmer verteilt? | ||
| + | * wurden alle Besprechungsunterlagen verteilt? | ||
| + | |||
| + | ==== Der Projektplan ==== | ||
| + | * Kern des Projektmanagements, ist immer zu erstellen | ||
| + | * enthält detailliert alle durchzuführenden Aktionen im Projekt | ||
| + | * bei agiler Entwicklung werden die Termine nicht geplant, sondern nur priorisierte Aufgaben | ||
| + | * Ziel ist eine Grundlage zum Zusammenstellen des Teams | ||
| + | * Aufgaben für den Projektleiter | ||
| + | * Ziele und Teilziele verständlich und treffend formulieren | ||
| + | * mehrere Möglichkeiten (Alternativen) zur Zielerreichung erarbeiten und gegenüberstellen | ||
| + | * abschätzen, was zu tun sein wird, wie lange es dauert, wie aufwändig es ist | ||
| + | * gemeinsam mit dem Team einen Projektplan erarbeiten, der beim Projekstart von der Leitung/dem Team freigegeben wird | ||
| + | * Form wählen, die das gesamte Projekt begleitet und eine Steuerung ermöglicht | ||
| + | * ggfs. Software auswählen | ||
| + | * Projektleiter erstellt ersten Plan, stellt das Team auf und überarbeitet mit ihm den Plan | ||
| + | * es muss nicht beim ersten Versuch die Endfassung entstehen | ||
| + | * Phantasie spielen lassen, es gibt kein richtig und falsch | ||
| + | * Projektdeckblatt, -fragebogen und LOP verwenden und abgleichen | ||
| + | * zuerst ohne Software arbeiten, um die einzelnen Schritte zu verstehen | ||
| + | * Zielkonflikte separieren, beschreiben und mit Team diskutieren | ||
| + | * nur das Projekt beschreiben, nicht die Lösung (z.B. Softwarearchitektur) entwickeln | ||
| + | * einfach gestalten, damit er laufend gepflegt werden kann | ||
| + | * einfach zu lesen (auch für Externe) | ||
| + | * einfach zu pflegen (vor allem schnell) | ||
| + | * einfach weiterzuverwenden (z.B. als Präsentation) | ||
| + | * als einfaches Projektcontrollinginstrument | ||
| + | * Modellbildung/Modellierung | ||
| + | * Möglichkeiten: UML, BPMN, Prototyping, agile Entwicklung | ||
| + | * abhängig von Auftraggeber, Projekt, Kenntnissen des Teams, Vorlieben des Projektleiters, vorhandene Software | ||
| + | * Inhalte | ||
| + | * {{:se:InhalteProjektplan.jpg|}} | ||
| + | * Strukturplan | ||
| + | * Zerlegung des Projekts in eine Struktur und grobe Zeitplanung | ||
| + | * Darstellung als Strukturdiagramm | ||
| + | * schafft Übersicht über die größeren Einheiten und ihre Beziehungen untereinander | ||
| + | * Netzplan | ||
| + | * stellt auch zeitliche und logische Zusammenhänge dar | ||
| + | * Dauer einer Aufgabe, spätester/frühester Beginn/Ende, Bearbeiter, benötigte Ressourcen | ||
| + | * kritischer Pfad: Tätigkeiten, die keinerlei Verschiebung erlauben | ||
| + | * Anordnung nach Wichtigkeit, muss etwas vor etwas anderem fertig sein? | ||
| + | * hilft, die Einträge im Strukturplan und in der Vorgangsliste zu ordnen | ||
| + | * Meilensteine | ||
| + | * wichtige Termine innerhalb des Projekts (Start, Ende, Präsentation, Test etc.) | ||
| + | * meist werden hier wichtige Entscheidungen für den weiteren Projektverlauf getroffen | ||
| + | * die Vorgangsliste | ||
| + | * erstellen mit Projektmanagementsoftware oder Excel | ||
| + | * alle wesentlichen Informationen sind in einer Datei verfügbar | ||
| + | * Nachhaltigkeit: immer alles sofort aufschreiben | ||
| + | * {{:se:ProjektplanTabelle.jpg|}} | ||
| + | * einfach zu erstellen, wenn Netzplan/Strukturplan vorhanden | ||
| + | * Überschriften aus Strukturplan als Trennzeilen | ||
| + | * Vorgänge aus Netzplan eintragen | ||
| + | * Meilensteine ergänzen | ||
| + | * fehlende Spalten füllen, Kommentare bei Unklarheiten erzeugen | ||
| + | * Balkendiagramme können zur Darstellung zeitlicher Zusammenhänge verwendet werden | ||
| + | * finalen Projektplan erstellen | ||
| + | * einer bereitet vor, alle lesen und arbeiten gemeinsam Änderungen ein (meist höchster Nutzen bei geringem Zeitaufwand) | ||
| + | * einer bereitet vor, alle lesen und reichen Änderungen zentral ein (meist viele Rückfragen nötig, bei allen bleibt weniger hängen) | ||
| + | * alle arbeiten gemeinsam am Ergebnis (höchster Nutzen, dauert aber lange) | ||
| + | * jeder erarbeitet einen Teil und einer macht ein Ganzes daraus (schwierig, da Teilbereiche sehr unterschiedlich ausfallen können) | ||
| + | * empfängergerechte Aufbereitung | ||
| + | * Hauptempfänger: Auftraggeber (entscheiden über Durchführung) und Team (lesen ihre Aufgaben ab) | ||
| + | * für Externe wird meist eine gekürzte Version des Plans erstellt | ||
| + | * der Plan muss sorgfältig erstellt werden, er ist das erste Dokument des Projekts und sollte stellvertretend für die Arbeitsweise im Projekt stehen | ||
| + | * das Format sollte sich in späteren Berichten wiederfinden, damit man Inhalte 1 zu 1 übernehmen kann (z.B. PowerPoint) | ||
| + | * Unterschiede bei Scrum | ||
| + | * kein fixierter Projektplan wie im klassischen Projektmanagement | ||
| + | * Elemente | ||
| + | * schriftlich formulierte Vision | ||
| + | * Product Backlog: priorisierte Anforderungsliste | ||
| + | * Sprint Backlog: Aufgaben für die Sprints | ||
| + | * Sprint: Zeiteinheit, über die konzentriert gearbeitet wird | ||
| + | * Burndown Chart: Darstellung des Projektfortschritts als Grafik | ||
| + | * Produktinkrement: potentiell lieferbares Produkt | ||
| + | * Rollen: Scrum Master, Product Owner, Team | ||
| + | * Selbstorganisation und Eigenverantwortung der Projektbeteiligten werden wichtiger | ||
| + | * Kostenschätzung | ||
| + | * Grundlage können Listen mit häufigen Projektschritten sein | ||
| + | * mögliche Vorgehensweisen | ||
| + | * alles selbst machen | ||
| + | * Berater/externe Programmierer einbinden | ||
| + | * Experten für Spezialthemen einbinden | ||
| + | * alles fremd vergeben | ||
| + | * Vorgehen lohnt sich, wenn wenig Informationen zum Projekt vorliegen oder dem Unternehmen die Kostenzusammenhänge noch nicht klar sind | ||
| + | |||
| + | ==== Übungen ==== | ||
| + | === 3.1: Warum ist ein gut moderiertes Kick-Off-Meeting wichtig für das Projekt? === | ||
| + | * Das Projektteam muss auf das gemeinsame Ziel eingeschworen werden | ||
| + | * Die Teilnehmer lernen sich besser kennen | ||
| + | * Alle Teilnehmer bedürfen klarer Anweisungen bzgl. ihrer Aufgaben | ||
| + | * Die Formalien (Protokolle, Besprechungen etc.) müssen verbindlich festgelegt werden | ||
| + | * Die Vorgehensweise wird zusammen erarbeitet (Grobplan durchgehen, Feinplan aufstellen) | ||
| + | |||
| + | === 3.3: Warum stellt man einen Projektplan auf, anstatt einfach loszulegen? === | ||
| + | * Eine Planung der benötigten Zeit und Ressourcen, sowie der Kosten ist ohne Projektplan nicht möglich. | ||
| + | * Ein Projektplan weist jedem Projektmitarbeiter seine Aufgaben zu. Nur so ist eine spätere Kontrolle der erreichten Ziele möglich. | ||
| + | * Der Projektplan bietet stets eine gute Übersicht zum aktuellen Stand des Projektes (wenn er gut gepflegt wird) und zeigt eventuelle Engpässe auf. | ||
| + | * Nur mit Hilfe eines zentralen Projektplans lassen sich die zu erledigenden Aufgaben der einzelnen Projektmitarbeiter so abstimmen, dass nicht redundant gearbeitet oder etwas vergessen wird. | ||
| + | * Auf Basis eines Projektplans, der vom Team gemeinsam erstellt und verabschiedet wird, ist eine optimale Zusammenarbeit ohne Interessens- oder Kompetenzkonflikte möglich. | ||
| + | |||
| + | === 3.4: Mögliche Vorgehensweisen/Hilfsmittel zur Modellierung === | ||
| + | |||
| + | == Strukturierte Programmierung == | ||
| + | * Größere Probleme werden in mehreren Schritten in Teilprobleme zerlegt. Verfeinere diese Teilprobleme weiter (eventuell mehrfach), bis nur noch elementare algorithmische Grundstrukturen vorliegen: Top-Down-Vorgehen. ([[http://www.saar.de/~awa/verfein.htm|Strukturierte Programmierung]]) | ||
| + | * Programme werden modularisiert | ||
| + | * Nur bestimmte Kontrollstrukturen sind erlaubt: Sequenzen, Schleifen, Bedingte Verzweigungen | ||
| + | * Grafisches Hilfsmittel: Struktogramm/Nassi-Shneiderman-Diagramm ([[http://www.mi.uni-koeln.de/c/mirror/f7alpha1.informatik.fh-muenchen.de/~schieder/programmieren-1-ws96-97/struktpgm.html|Strukturierte Programmierung]]) | ||
| + | * Vorteile | ||
| + | * Programmierung von Bibliotheken, Modulen | ||
| + | * Nachteile | ||
| + | * schwierige Fehlerbehandlung und Datenmodellierung | ||
| + | * Einsatzgebiet: Einfache Programme, prozedurale Programmierung | ||
| + | |||
| + | == UML == | ||
| + | * Die Unified Modelling Language ist eine Sprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Modellen für Softwaresysteme, Geschäftsmodelle und andere Nicht-Softwaresysteme. Sie bietet den Entwicklern die Möglichkeit, den Entwurf und die Entwicklung von Softwaremodellen auf einheitlicher Basis zu diskutieren. Die UML wird seit 1998 als Standard angesehen. Sie lag und liegt weiterhin bei der Object Management Group (OMG) zur Standardisierung vor. ([[http://ivs.cs.uni-magdeburg.de/~dumke/UML/index.htm|Unified Modelling Language]]) | ||
| + | * UML ist keine Methode, sondern definiert eine Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die Geschäftsprozessmodellierung und für die objektorientierte Softwareentwicklung. ([[http://www.torsten-horn.de/techdocs/uml.htm|UML Unified Modeling Language]]) | ||
| + | * Grafische Hilfsmittel: Mehrere (13) Diagrammtypen für unterschiedliche Anforderungen | ||
| + | * Vorteile | ||
| + | * Quasi-Standard, leicht zu verstehen/erlernen | ||
| + | * Diagramme können zur Codegenerierung verwendet werden | ||
| + | * Nachteile | ||
| + | * Nicht alle Anforderungen der Objektorientierung werden abgedeckt (aber durch die leichte Erweiterbarkeit von UML sind eigene Erweiterungen möglich) | ||
| + | * Einsatzgebiet: Objektorientierte Programmierung, Entwurf umfangreicher Software | ||
| + | |||
| + | == BPMN == | ||
| + | * The Business Process Modeling Notation (BPMN) is a graphical notation that depicts the steps in a business process. BPMN depicts the end to end flow of a business process. The notation has been specifically designed to coordinate the sequence of processes and the messages that flow between different process participants in a related set of activities. ([[http://www.bpmn.org/Documents/FAQ.htm|Business Process Modeling Notation (BPMN) Information]]) | ||
| + | * The unified modelling language (UML) takes an object-oriented approach to the modeling of applications, while BPMN takes a process-oriented approach to modelling of systems. | ||
| + | * [[http://www.omg.org/docs/dtc/06-02-01.pdf|Spezifikation]] | ||
| + | * Vorteile | ||
| + | * kann in BPEL umgewandelt werden -> lauffähige Prozesse | ||
| + | * was UML für die Objektorientierung, ist BPMN für Prozessorientierung | ||
| + | * Einsatzgebiet: Definition und Automatisierung von Geschäftsprozessen, SOA | ||
| + | |||
| + | == Rapid Prototyping == | ||
| + | * Das Prototyping ist eine Methode der Softwareentwicklung, die schnell zu ersten Ergebnissen führt und frühzeitiges Feedback bezüglich der Eignung eines Lösungsansatzes ermöglicht. ([[http://de.wikipedia.org/wiki/Prototyping_%28Softwareentwicklung%29|Prototyping (Softwareentwicklung)]]) | ||
| + | * In rapid prototyping interactive prototypes are developed which can be quickly replaced or changed in line with design feedback. This feedback may be derived from colleagues or users as they work with the prototype to accomplish set tasks. ([[http://www.usabilitynet.org/tools/rapid.htm|Rapid prototyping]]) | ||
| + | * Vorteile | ||
| + | * Schnelle Ergebnisse und Anpassbarkeit während der Erstellung | ||
| + | * Nachteile | ||
| + | * Gefahr, "unsauber" zu programmieren | ||
| + | * oftmals mangelnde Dokumentation, da Konzentration auf Entwicklung | ||
| + | * Einsatzgebiet: Maschinenbau, jegliche Programmierung (nicht praktikabel für große Anwendungen) | ||
| + | |||
| + | == Agile Programming == | ||
| + | * Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. ([[http://en.wikipedia.org/wiki/Agile_software_development|Agile software development]]) | ||
| + | * Although the various agile approaches are different, they have some things in common. They're intended to produce software that can be changed quickly, and all specify short iterations and maximize the amount of time spent face to face. They also focus on team morale. ([[http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,67950,00.html|Extremely Agile Programming]]) | ||
| + | * AP is a collection of principles and techniques that try to overcome the inflexibility of the strictly-design-based development cycle. ([[http://www.codeproject.com/gen/design/agileprogramming.asp|Agile Programming]]) | ||
| + | * Vorteile | ||
| + | * schnelle Ergebnisse, trotzdem folgt das Vorgehen einem klaren Plan mit bestimmten Methoden | ||
| + | * Einsatzgebiete: Webentwicklung (Ruby on Rails), Softwareentwicklung | ||
| + | |||
| + | === 3.6: Strukturdiagramm für Erstellung der Projektmanagementsoftware === | ||
| + | * Entwicklung der Projektmanagementsoftware | ||
| + | * Planung | ||
| + | * Fachliche Funktionalitäten festlegen | ||
| + | * Programmierkonzept festlegen | ||
| + | * Zu unterstützende Betriebssysteme festlegen | ||
| + | * Programmiersprache auswählen | ||
| + | * Groben Aufbau des Programms modellieren | ||
| + | * Voraussetzungen klären | ||
| + | * Benötigte Ressourcen ermitteln | ||
| + | * Benötigte Projektmitarbeiter ermitteln | ||
| + | * Implementierung | ||
| + | * Programmierung der Software | ||
| + | * Erstellen des GUI | ||
| + | * Dokumenation erstellen | ||
| + | * Anwenderdokumentation erstellen | ||
| + | * Technische Dokumentation erstellen | ||
| + | * Test | ||
| + | * Automatische (Fehler-)Tests durchführen | ||
| + | * Fachliche Tests durch Anwender durchführen lassen | ||
| + | * Usability-Test durchführen | ||
| + | * Endabnahme durchführen | ||
| + | * Schulungen | ||
| + | * Benutzerschulung durchführen | ||
| + | * Administratorenschulung durchführen | ||
| + | * Betrieb | ||
| + | * Installation der Software beim Kunden | ||
| + | * Parametrisierung vor Ort | ||
| + | |||
| + | ===== Projektsteuerung und -kontrolle während der Durchführung ===== | ||
| + | * Projektsteuerung | ||
| + | * der Projektplan im Dauereinsatz: jemand muss ihn ständig pflegen | ||
| + | * bei langen Projekten wöchentlich aktualisieren, monatlich reporten | ||
| + | * wichtig um die Projektbeteiligten bei der Stange zu halten (Zeiten eintragen etc.) | ||
| + | * in kleinen Projekten wird der Projektleiter selbst den Plan pflegen | ||
| + | * es gibt viele Verfahren zur Fortschrittsermittlung in Softwareprojekten, die sich allerdings in der Praxis nicht bewährt haben | ||
| + | * bei Scrum: Daily Scrum, Retrospective | ||
| + | * Teamentwicklung | ||
| + | * Förderung der Teambildung | ||
| + | * gemeinsam Aufgaben lösen, Not bewältigen, Gegner besiegen | ||
| + | * Gruppenidentität durch Symbole ausdrücken (Slogan, Namen, Zeichen, Sprache) | ||
| + | * die Gruppe kann sich meist nicht aus sich selbst heraus verbessern -> externe Unterstützung | ||
| + | * Ziele | ||
| + | * Probleme lösen, die die Gruppe belasten | ||
| + | * die Gruppe soll zu einem kooperierenden Team werden | ||
| + | * Gruppendruck | ||
| + | * führt dazu, dass im Team eine einhellige Meinung (egal ob falsch oder richtig) herrscht und Zweifler unterdrückt werden | ||
| + | * Indizien für group-thinking | ||
| + | * Teammitglieder haben das Gefühl, in der Gruppe unverwundbar zu sein -> übertriebener Optimismus, gehen Risiken ein, übersehen Warnzeichen | ||
| + | * Gruppe bildet plausible Scheinerklärungen um ihre Annahmen nicht hinterfragen zu müssen | ||
| + | * die Teammitglieder haben einen unhinterfragten Glauben an die moralische Integrität der Gruppe -> moralische Folgen von Entscheidungen werden ignoriert | ||
| + | * die Teammitgliedern haben ein stereotypes Bild von den Leitern gegnerischer Gruppen | ||
| + | * entweder als starrsinnig und andersdenkend, sodass keine Diskussion möglich ist | ||
| + | * oder als schwach und inkompetent, sodass keine Entscheidungen möglich sind | ||
| + | * die Mitglieder machen sich Illusionen über die Einmütigkeit der Gruppe -> fast alle Meinungen von Teammitgliedern werden für Mehrheitsmeinungen gehalten | ||
| + | * die Gruppe erzeugt Druck gegenüber jedem, der Zweifel an den Illusionen der Gruppe hat oder Argumente anzweifelt, die die Mehrheitsentscheidungen stützen | ||
| + | * Selbstzensur findet in großem Ausmaß statt: die Mitglieder weichen nicht vom Gruppenkonsens ab und spielen ihre eigenen Befürchtungen herunter | ||
| + | * die Mitglieder schirmen unliebsame Informationen, die die Selbstzufriedenheit der Gruppe beeinträchtigen könnten, von der Gruppe ab | ||
| + | * Maßnahmen gegen group-thinking | ||
| + | * der Projektleiter muss Kritik explizit einfordern | ||
| + | * Projektleiter und einflussreiche Teammitlglieder dürfen nicht zu früh zu erkennen geben, welchen Weg sie bevorzugen | ||
| + | * bei wichtigen Entscheidungen wird eine Planungsgruppe eingerichtet | ||
| + | * jedes Gruppenmitglied wird veranlasst, die Entscheidungen auch außerhalb der Gruppe zu diskutieren | ||
| + | * Experten von außerhalb der Gruppe werden um eine Einschätzung gebeten | ||
| + | * wenn ein Konsens der Gruppe abzusehen ist, sollte ein advocatus diaboli bestimmt werden | ||
| + | * die Entscheidungsgruppe trennt sich in zwei Gruppen auf, die getrennt diskutieren und am Ende ihre Ergebnisse vorstellen | ||
| + | * nach einer Einigung sollte diese immer noch einmal gezielt in Frage gestellt werden | ||
| + | * Aushandeln von Rollen | ||
| + | * Rollen betreffen nicht nur die Arbeitsverteilung, sondern auch Macht, Abhängigkeit, Konflikt und Konkurrenz im Team | ||
| + | * das Aushandeln von Rollen erfordert die Bereitschaft, Strukturen im Team zu verändern | ||
| + | * die Rolle, über die verhandelt wird, schließt nicht nur die formale Stellenbeschreibung ein, sondern auch informelle Ansichten und Erwartungen, die sich im Laufe der Zeit gebildet haben | ||
| + | * diese Verfestigungen des Rollenverständnisses führen zu dauerhaften Konflikten | ||
| + | * Vorgehen | ||
| + | * Schritt 0: Konfliktpositionen klären | ||
| + | * emotionale Konfliktlage klären, damit anschließend auf Sachebene verhandelt werden kann | ||
| + | * Schritt 1: Regeln beschließen | ||
| + | * es geht nicht um Gefühle, sondern um die Arbeit | ||
| + | * Erwartungen und Forderungen an das Verhalten anderer müssen schriftlich fixiert werden | ||
| + | * Forderungen werden nur erfüllt, wenn der Fordernde im Gegenzug auch etwas gibt | ||
| + | * über diese Leistungen und Gegenleistungen wird verhandelt, die Ergebnisse werden aufgeschrieben | ||
| + | * Schritt 2: Problemdiagnose | ||
| + | * jedes Teammitglied muss darüber nachdenken, was sich ändern müsste, damit es produktiver wird | ||
| + | * Rollenwunschzettel für die anderen Teammitglieder ausfüllen | ||
| + | * Es würde mir helfen, meine Effektivität zu steigern, wenn Sie Folgendes mehr oder besser tun würden... | ||
| + | * Es würde mir helfen, meine Effektivität zu steigern, wenn Sie Folgendes weniger oder gar nicht mehr tun würden... | ||
| + | * Mit folgenden Verhaltensweisen haben Sie mir geholfen, meine Effektivität zu steigern, und ich hoffe, dass Sie sie in Zukunft beibehalten... | ||
| + | * jede Person bekommt dann alle aus sie bezogenen Wunschzettel und erstellt einen Gesamt-Wunschzettel für sich selbst | ||
| + | * alle Gesamt-Wunschzettel werden aufgehängt und von der Gruppe begutachtet (Fragen nach dem Was, Warum, Wie sind erlaubt) | ||
| + | * Schritt 3: Rollen aushandeln | ||
| + | * zwei ausgewählte Teilnehmer führen den Prozess vor | ||
| + | * jeder sagt, was er sich am anderen wünscht und wo er ihm entgegenkommen kann | ||
| + | * Aushandeln: "Wenn Sie X tun, tue ich Y", bis beide zufrieden sind | ||
| + | * Ergebnis schriftlich fixieren, Sanktionen bei Nichteinhalten festlegen | ||
| + | * alle Übereinkünfte werden der gesamten Gruppe mitgeteilt | ||
| + | * Frühwarnsystem | ||
| + | * der Projektplan dient zunächst als Frühwarnsystem, da er alle Aufgaben, Meilensteine, Termine etc. enthält und ständig mit der Realität abgeglichen wird | ||
| + | * wird der Plan zu umfangreich, ist er nicht mehr pflegbar und wird zum Zeitfresser | ||
| + | * daher lohnt sich ein zusätzliches Frühwarnsystem | ||
| + | * Checklisten, die zu wichtigen Terminen geprüft werden | ||
| + | * Projektteilnehmer bekommen Themen zugewiesen, auf die sie achten sollen | ||
| + | * Umgangston der Projektbeteiligten | ||
| + | * Häufigkeit der Zeiterfassung | ||
| + | * bestimte Qualitätsmerkmale | ||
| + | * Krankheitstage | ||
| + | * Themen, mit denen sich die Entscheider befassen | ||
| + | * Gesetzesänderungen | ||
| + | * ideal sind wenige Messpunkte, die Details verbergen | ||
| + | * Beispiel Zeiterfassung deutet auf -> Motivation, Arbeitsbelastung, Fortschritt, destruktive Kraft | ||
| + | * das Projektmanagement beobachtet die Vergangenheit und das Ist -> Frühwarnsystem beobachtet die Zukunft | ||
| + | * Führung | ||
| + | * der Projektleiter hat explizit die Aufgabe, seine Mitarbeiter zu führen | ||
| + | * einzelne Mitarbeiter fordern und fördern | ||
| + | * Führen durch Ziele mit Kontrolle, Lob und Tadel | ||
| + | * die gesamte Gruppe fördern und fordern | ||
| + | * Konfliktmanagement | ||
| + | * die Außenbeziehungen pflegen | ||
| + | |||
| + | ==== Übungen ==== | ||
| + | |||
| + | === 4.1: Möglichkeiten der Fortschrittsermittlung in (Software-)Projekten === | ||
| + | inkl. Vor- und Nachteile sowie die Art von Projekten, für die sie geeignet sind ([[http://help.sap.com/printdocu/core/Print46c/de/data/pdf/PSPRG/PSPRG.pdf|SAP Projektfortschritt]]) | ||
| + | * Start-Ende (Vergleich der geplanten Zeiten) | ||
| + | * Vorteile: schnell, einfach | ||
| + | * Nachteile: ungenau | ||
| + | * Meilensteine (Erreichen der geplanten Meilensteine) | ||
| + | * Vorteile: sehr aussagekräftig, objektiv prüfbar | ||
| + | * Nachteile: detaillierte Zergliederung der Aufgaben nötig | ||
| + | * Funktionsumfang (Implementierungsgrad der benötigten Funktionen) | ||
| + | * Vorteile: objektiv messbar, geringer Planungsaufwand | ||
| + | * Nachteile: benötigte Zeit je Funktion teils sehr unterschiedlich | ||
| + | * Schätzen | ||
| + | * Vorteile: jeder Mitarbeiter kann schätzen, liefert schnell einen ersten Richtwert | ||
| + | * Nachteile: ungenau, subjektive Werte können erheblich von tatsächlichen abweichen | ||
| + | |||
| + | === 4.3: Wieso wird zusätzlich zum Projektplan noch ein Frühwarnsystem benötigt? === | ||
| + | * Der Projektplan behandelt das Ist und die Vergangenheit. Für die Zukunft ist das Frühwarnsystem zuständig. | ||
| + | * Der Projektplan sollte auf jeden Fall ständig aktualisiert werden, jedoch nicht selbst zum Zeitfaktor werden, was durch eine überbordende Erfassung möglicher Risiken schnell eintreten kann. | ||
| + | * Ein Frühwarnsystem, das die Projektmitarbeiter einbezieht, fördert deren Kompetenz und Einsatzbereitschaft und gibt ihnen das Gefühl, mitzubestimmen bzw. eine gewisse Kontrolle zu haben. | ||
| + | * Ein separates Frühwarnsystem entlastet den Projektleiter. | ||
| + | |||
| + | === 4.5: Was wirkt motivierend auf Projektmitarbeiter? === | ||
| + | * Interesse am Themengebiet (etwa Programmierung) | ||
| + | * Der messbare Erfolg beim Erreichen von Zielen | ||
| + | * Ein methodisch und fachlich fähiger Projektleiter | ||
| + | * Die gute Zusammenarbeit im Team | ||
| + | * Anerkennung der erbrachten Leistungen | ||
| + | * Hoher Grad an Eigenverantwortung | ||
| + | |||
| + | ===== Abschluss und Betrieb ===== | ||
| + | * Vorbereitung des Abschlusses | ||
| + | * bevor das Ergebnis an den Kunden geht, sollte eine interne Retrospektive durchgeführt werden | ||
| + | * Unterlagen, die zu Beginn des Projekts erstellt wurden, und der letzte Stand werden bereitgelegt | ||
| + | * Fragen | ||
| + | * Ist das ursprüngliche/zuletzt definierte Ziel erreicht worden? | ||
| + | * Sind alle Qualitätskriterien erfüllt? | ||
| + | * Sind alle Vorgaben des Kunden erfüllt? | ||
| + | * Wurde der Zeitplan eingehalten? | ||
| + | * Wurde der Kostenplan eingehalten? | ||
| + | * Entspricht der Bericht den Bedürfnissen des Lesers? | ||
| + | * weitere projektspezifische Fragen, die während des Projekts gesammelt wurden | ||
| + | * während der Bearbeitung der Fragen, sollte die Präsentation für den Kunden erarbeitet werden (Argumente festhalten) | ||
| + | * Chancen der Retrospektive | ||
| + | * gute Leistungen offensichtlich machen | ||
| + | * Glücksgefühl aufgrund des erreichten Plans | ||
| + | * nicht erreichte Ziele begründen (ggü. Kunden und Management) | ||
| + | * aus Fehlern lernen | ||
| + | * auch bei abgebrochenen Projekten wichtig, da auch aus den Teilergebnissen gelernt werden kann | ||
| + | * Abschluss | ||
| + | * jedes Projekt hat zwei definierte Abschlüsse | ||
| + | * die Übergabe an den Empfänger | ||
| + | * danach Abnahme durch den Kunden -> Rechnung schreiben | ||
| + | * selbst Checkliste vorbereiten, die der Kunde noch ergänzen kann | ||
| + | * der interne Projektabschluss | ||
| + | * Auflösen des Teams, Archivierung der Dokumentation, Abschlussfeier | ||
| + | * jedem muss klar sein, dass das Projekt nun beendet ist | ||
| + | * ansonsten frisst es unnütz Zeit, wird unfertig beendet oder verlängert sich selbst immer weiter | ||
| + | * Übergabe an den Empfänger | ||
| + | * nicht nur PowerPoint, auch das Produkt muss gezeigt werden | ||
| + | * je besser die begleitende Dokumentation war, umso weniger Zeit geht für die Abschlussberichte drauf | ||
| + | * auch beim Abschluss steht der Kunde im Mittelpunkt -> er kann uns weiterempfehlen | ||
| + | * Nachbereitung des Projekts | ||
| + | * die Auflösung des Teams sollte in einem eigenen Meeting stattfinden | ||
| + | * Spannungen und Ängsten entgegenwirken | ||
| + | * Moderator würdigt noch einmal angemessen alle Leistungen | ||
| + | * dann ggfs. eine Party | ||
| + | * Betrieb | ||
| + | * der Betrieb ist die entscheidende Phase einer Software | ||
| + | * Sicherheit ist gerade bei technischen Systemen zu beachten | ||
| + | * unnötige Arbeitsfolgen (zu viele Klicks) sind zu vermeiden | ||
| + | * Entwickler könnten durch ein Kennenlernen ihres Produkts im Arbeitsalltag viel für ihr nächstes Produkt lernen | ||
| + | * auch die Übernahme der Daten in das Nachfolgesystem kann schon von Anfang an eingeplant werden | ||
| + | * Zusammenfassung | ||
| + | * das Gesamtergebnis hängt davon ab, wie gut die Anforderungen abgedeckt sind | ||
| + | * eine wichtige Anforderung sind immer die Kosten -> Projekte müssen also wirtschaftlich ablaufen | ||
| + | * auch wichtig ist die Zeit -> der Zeitplan muss eingehalten werden und die Zeit des Benutzers geschont werden | ||
| ===== Lernziele ===== | ===== Lernziele ===== | ||
| Zeile 701: | Zeile 1190: | ||
| * Wie können Sie einen Projektplan mit einfachsten Mitteln aufstellen? | * Wie können Sie einen Projektplan mit einfachsten Mitteln aufstellen? | ||
| * Wie werden Kosten und Leistungen abgeschätzt? | * Wie werden Kosten und Leistungen abgeschätzt? | ||
| + | * Was ist bei der Projektsteuerung zu beachten? | ||
| + | * Wie ist mit dem Team umzugehen? | ||
| + | * Wozu wird ein Frühwarnsystem benötigt? | ||
| + | * Wie wird es gestaltet? | ||
| + | * Wie wird das Eintreten von Risiken behandelt? | ||
| + | * Was bedeutet Führung in einem Projekt? | ||
| + | * Warum ist ein konkreter Abschluss wichtig? | ||
| + | * Wie wird ein Software-Engineering-Projekt abgeschlossen? | ||
| + | * Was passiert mit dem Projektteam? | ||
| + | * Wieso ist der Betrieb mit zu beachten? | ||
| + | * Was bringt ein reibungsloser Betrieb und kostengünstiges Aussteigen? | ||
| ===== ToDo ===== | ===== ToDo ===== | ||
se/projektmanagement.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
