[0:01] Hi, hier ist Stefan. In dieser Podcast-Episode geht es um die schriftliche IHK-Prüfung.

[0:05] Wenn du dazu noch mehr Informationen von mir haben willst, dann schau doch mal auf meiner Website vorbei unter dieperfekteihkprüfung.de.

[0:14] Und jetzt wünsche dir viel Spaß bei der Podcast-Episode.

[0:20] Herzlich willkommen zum IT-Berufe-Podcast, dem Podcast rund um die Ausbildung in den IT-Berufen.

[0:26] In dieser Episode geht es um die Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung zum Thema Projektmanagement. Viel Spaß!

[0:38] Hallo und herzlich willkommen zur 172. Episode des IT-Berufe-Podcasts.

[0:44] Mein Name ist Stefan Macke und heute soll es mal mit einer kleinen Podcast-Episode-Reihe losgehen und zwar zur Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung.

[0:55] Das neue Lieblingswort meiner Azubis und von mir, diese blöde gestreckte Abschlussprüfung.

[1:01] Und die ist halt für viele ITler in der Ausbildung ganz neu, sowohl für die IT-Ausbilder und Ausbilderinnen als auch für die Azubis.

[1:08] Zumindest im Jahr 2022, wo ich das hier gerade aufnehme.

[1:12] Und ich möchte jetzt mal so ein bisschen die einzelnen Bereiche der Prüfung in mehreren Episoden durchgehen und vielleicht mal ein paar Stichworte nennen, was man sich da vielleicht mal angucken sollte für die Prüfungsvorbereitung.

[1:22] Wir haben ja schon ganz schön viel Zeug, was da abgefragt wird jetzt in Teil 1 der Prüfung, also schon nach 18 Monaten.

[1:28] Und ja, ich glaube, da braucht man ein bisschen Unterstützung.

[1:31] Was soll ich mir angucken? Wie tief muss man das lernen? Was könnten Fragen sein?

[1:34] Und ich habe schon zwei Episoden aufgenommen zur Prüfungsvorbereitung.

[1:37] Habe ich auch ganz viel Literaturempfehlungen schon gegeben, womit ich mir das anschauen will, wenn man das lernen kann.

[1:42] Aber natürlich auch der klassische Tipp, alte Prüfungen durcharbeiten.

[1:45] Nur solange das noch nicht so richtig geht, weil wir halt noch nicht so viele alte Prüfungen haben, sollte man sich vielleicht auf anderem Wege auf diese Themen vorbereiten, die in der Prüfung abgefragt werden können.

[1:55] Und die Prüfungsthemen stehen relativ deutlich fest.

[1:59] Die kann man einfach nachlesen.

[2:01] Da braucht man sich auch nichts verkaufen.

[2:02] Da kann man sich einfach in der Berufsverordnung nachschauen.

[2:04] Da steht jedes Thema einzeln drin mit Unterpunkten.

[2:09] Das ist ja der Teil des Ausbildungsrahmenplans, der vorgibt, welche Inhalte dort vermittelt werden sollen im Betrieb.

[2:14] Und was dann entsprechend auch prüfungsrelevant ist.

[2:16] Zusätzlich mit den Sachen aus dem Lehrplan der Berufsschulen haben wir da eigentlich einen ganz guten Überblick, was die Themen sind.

[2:22] Die Frage ist einfach nur, wie sehen die Klausuren aus?

[2:25] Die Prüfung, was wird da abgefragt und in welcher Tiefe?

[2:28] Und da kann man sich natürlich am besten einen Überblick verschaffen, wenn man sich alte Prüfungen anguckt.

[2:32] Logischerweise hatte ich gerade gesagt, vielleicht gibt es davon aber aktuell noch nicht so viele.

[2:36] Vielleicht hörst du die Episode ja auch im Jahr 2027 und kannst dir locker einfach die letzten fünf Jahre der Prüfung durchschauen.

[2:44] Kannst du einfach kaufen und dir angucken oder irgendwo besorgen in Anführungszeichen.

[2:48] Aber wenn das noch nicht der Fall ist, das dauert ja noch ein paar Jahre mindestens, bis die alle verfügbar sind, muss man sich irgendwie anders vorbereiten.

[2:57] Und selbst wenn du die letzten Prüfungen durcharbeitest, heißt das ja nicht, dass du alle Themenbereiche abgedeckt hast.

[3:02] Es kann natürlich immer noch mal wieder was dazukommen oder andere Schwerpunkte in der Prüfung gelegt werden.

[3:06] Und ich möchte jetzt einfach mal in den nächsten Podcast-Episoden die einzelnen Prüfungsbereiche oder Themenbereiche der Prüfung durchgehen.

[3:13] Die sind ja wirklich genau aufgeschrieben. Es sind sieben Stück.

[3:16] Da habe ich auch in meinen vorherigen Podcast-Episoden einiges zu erzählt.

[3:20] Du kannst es auch auf der Website einfach angucken.

[3:22] Und ich habe jetzt einfach mal jeden dieser Themenbereiche genommen.

[3:24] Und heute fangen wir mit dem ersten an.

[3:26] Das ist Projektmanagement. Und dazu habe ich dann verschiedene Quellen mal durchgeguckt, was da konkrete Fragen sein könnten in der Prüfung.

[3:33] Ich habe ganz konkret einmal natürlich mir die Vorgaben angeschaut, was in dem Ausbildungsrahmenplan steht.

[3:39] Das Problem ist, dass die natürlich sehr schwammig gehalten sind, bewusst allgemein gehalten sind, damit man nicht halt in fünf Jahren das nächste Mal die Ordnung anpassen muss, weil sich wieder irgendwas verändert hat.

[3:48] Deswegen kann man da sehr wenig für die Praxis mitnehmen.

[3:51] Trotzdem stehen dort die Themen, die verbindlich sind, für die Prüfung drin.

[3:55] Also sollte das der erste Ansatz sein, da nachzugucken.

[3:58] Jetzt gibt es noch als Ergänzung dazu relativ zeitbezogen, sage ich mal, eine Handreichung von dem Prüfungserstellungsausschuss, die so ein bisschen konkreter definieren, was denn unter diesen Bereichen zu verstehen ist.

[4:13] Und die habe ich auch schon damals aufbereitet, als ich meine anderen Podcast-Episoden genutzt habe.

[4:17] Da stehen konkrete Stichworte drin, wie zum Beispiel bei Versionsverwaltung GIT.

[4:21] Kann sein, dass GIT in zehn Jahren nicht mehr cool ist und man was anderes hat.

[4:25] Dann muss das angepasst werden.

[4:26] Deswegen ist die Ordnung auch bewusst allgemein formuliert.

[4:29] Aber heutzutage, und ich spreche heute im Jahr 2022, ist GIT zum Beispiel der Standard für Versionsverwaltung.

[4:34] Also sollte man das können.

[4:35] Das ist jetzt nur ein Beispiel.

[4:37] Das heißt nicht, dass du GIT für die Prüfung können musst.

[4:38] Das ist nur ein mögliches Thema.

[4:42] Diese Handreichung macht es, wie gesagt, schon etwas konkreter.

[4:46] Da stehen allerdings auch eher so Stichwortlisten drin, was man vielleicht können sollte oder anwenden sollte.

[4:52] Das heißt immer noch nicht, dass man so direkt daraus ablesen kann, was ich jetzt für die schriftliche Prüfung lernen muss.

[4:57] Denn der Ausbildungsrahmenplan legt natürlich auch einen großen Wert darauf, dass ich handlungsfähig werde in der Praxis.

[5:02] Und das ist jetzt halt schon ein bisschen was anderes, ob ich etwas in der Praxis umsetzen kann oder ob ich darüber eine schriftliche Prüfung schreiben kann.

[5:08] Das kann man natürlich nicht so ganz vergleichen.

[5:10] Dass du wirklich in der Praxis deinen Beruf ausüben kannst, wird natürlich auch mit deinem Abschlussprojekt bewiesen.

[5:16] Das ist allerdings erst nach drei Jahren.

[5:18] Das heißt, man kann jetzt im ersten Teil der Prüfung eigentlich nur so ein bisschen Theoriewissen abfragen.

[5:22] Das heißt, nehmen wir noch mal ein anderes Beispiel.

[5:24] DHCP-Server kann man super in der schriftlichen Prüfung erklären, was da der Sinn ist und wie dieses DORA-Verfahren abläuft, wenn ich eine IP-Adresse kriege.

[5:32] Ich kann aber nicht von dir verlangen, dass du weißt, wie man den installiert.

[5:35] Wie sollst du das aufschreiben?

[5:37] So was geht natürlich nicht.

[5:38] Also wir müssen immer unterscheiden Praxis und Prüfungswissen.

[5:41] Und mir geht es jetzt erstmal ums Prüfungswissen.

[5:43] Logischerweise kann man auch, glaube ich, ein bisschen besser auf der Audiospur vermitteln als das Praxiswissen.

[5:48] Also wir gucken uns den Teil an, den ich dann auch aus dieser Handreichung extrahiert habe, den man auf Prüfungsfragen übertragen kann, sage ich mal.

[5:56] Wenn da so was steht wie, du musst anhand betriebsspezifischer Kennzahlen irgendwas berechnen.

[6:02] Ja, wie soll ich daraus was für die Prüfung ableiten?

[6:05] Betriebsspezifisch ist ja für jedes Unternehmen unterschiedlich.

[6:07] Auch jetzt hier wieder nur als Beispiel.

[6:09] Von daher bin ich jetzt diese Handreichung nochmal durchgegangen und habe zu allen Punkten, wo ich mir denke,

[6:13] da könnte man was in der Prüfung abfragen, eine schöne schriftliche Aufgabe daraus formulieren.

[6:18] Dazu habe ich dann ein bisschen was ergänzt.

[6:20] Das heißt, wenn du in die Shownotes zu dieser Episode schaust, wirst du das auch genauso aufgebaut finden.

[6:25] Du wirst die Oberpunkte sehen.

[6:28] Wir fangen heute an mit Oberpunkt 1, Projektmanagement.

[6:30] Das ist schon mal unterteilt, ich glaube in sieben oder acht Unterpunkte.

[6:34] Diese Unterpunkte haben dann einmal die Hinweise aus der Handreichung ergänzt,

[6:39] die schon etwas konkreter werden.

[6:41] Und dann habe ich darunter noch meine persönliche Empfehlung ergänzt, was ich mir anschauen würde.

[6:45] Das heißt also eine Mischung aus verschiedenen Quellen, sage ich mal.

[6:49] Ich habe auch noch andere Quellen zu Rate gezogen.

[6:51] Ich hatte schon einige Literaturempfehlungen gegeben.

[6:53] Ich habe mir zum Beispiel nochmal die Lernkarten aus dem U-Form Verlag angeschaut.

[6:56] Oder auch das Schulbuch, was ich empfohlen habe für die Lernfelder 1 bis 5 mit dem zugehörigen Arbeitsbuch.

[7:02] Und aus dem Europa Verlag gibt es auch noch ein schönes Übungsbuch.

[7:06] Da habe ich auch nochmal für den Bereich jetzt mir die Sachen angeschaut.

[7:08] Das heißt, ich habe verschiedene Quellen zusammengetragen und einfach mal so meine Empfehlungen zusammengestellt,

[7:13] was ich mir mindestens anschauen würde.

[7:15] Die Betonung liegt auf mindestens.

[7:17] Das ist natürlich nicht abschließend und vollständig.

[7:19] Das muss dir ganz klar sein.

[7:21] Das heißt, wenn du diese eine Episode hier hörst, heißt das nicht, dass der erste Themenbereich abgehakt ist.

[7:25] Du musst dir das natürlich auch schon nochmal angucken und auch selber nochmal überlegen,

[7:29] was könntest du vielleicht noch ergänzen müssen.

[7:31] Und außerdem kann ich das natürlich jetzt hier auf der Audiospur auch nicht in der Tiefe vermitteln, wie du es lernen musst.

[7:36] Das heißt, es wird natürlich auch etwas oberflächlich her hier laufen müssen einfach.

[7:41] Ich will jetzt hier nicht 20-Stunden-Episode zum Projektmanagement machen.

[7:44] Und ich glaube, das könnte man locker.

[7:46] Sondern ich muss das natürlich ein bisschen kürzen.

[7:48] Von daher, nur weil du das jetzt hier anhörst, bist du jetzt nicht fit für die Prüfung.

[7:52] Du musst noch ein bisschen selber was machen.

[7:53] Aber ich glaube, als Ergänzung kann das nicht schaden, wenn ich mal meine Sicht der Dinge darstelle

[7:57] und wie ich was erklären würde und Schwerpunkte legen würde.

[8:00] Also, so komme ich auf die Themen.

[8:02] Rahmenplan genommen, dann ergänzt um Handreichungen, Lernkarten, Übungsbücher, alles, was ich gefunden habe.

[8:07] Und auch ein bisschen natürlich meine persönliche Erfahrung aus den bisherigen alten IHK-Prüfungen mit einfließen lassen.

[8:13] Und einfach aus meiner Praxis als Ausbilder.

[8:15] Da kriege ich ja auch mit, was man da vielleicht können sollte und was nicht.

[8:18] Ja, das war jetzt eine ganz lange Einleitung für die erste Episode hier.

[8:22] Das gleiche gilt natürlich für die noch kommenden.

[8:24] Da spare ich mir dann diese Erklärung und verweise einfach hier drauf.

[8:27] Ansonsten würde ich sagen, wir steigen einfach mal ein in das erste Thema der Prüfung, nämlich Projektmanagement.

[8:34] Beziehungsweise, wenn man ganz genau sein will, heißt das Ding eigentlich Planen, Vorbereiten und Durchführen von Arbeitsaufgaben

[8:40] in Abstimmung mit den Kunden spezifischen Geschäfts- und Leistungsprozessen.

[8:44] Wow, also sehr, sehr sperrig.

[8:46] Allerdings heißt der erste Unterpunkt direkt Grundsätze und Methoden des Projektmanagements anwenden.

[8:51] Und Überraschung, der ganze Rest, der da noch kommt, hat auch irgendwie was mit Projektmanagement zu tun.

[8:55] Deswegen nenne ich das Ganze etwas kürzer Projektmanagement.

[8:58] Aber in Wirklichkeit gehen wir heute auf Punkt 1 ein, nämlich dieses Planen, Vorbereiten und Durchführen, wie ich gerade genannt habe.

[9:04] Okay, dann steigen wir doch da direkt mal ein.

[9:06] Wie gesagt, der erste Unterpunkt 1a Grundsätze und Methoden des Projektmanagements anwenden.

[9:11] Da steht jetzt dann zum Beispiel in der Handreichung dazu, dass man so etwas können sollte wie initiieren,

[9:16] planen, steuern, kontrollieren und abschließen von Projekten nach aktuell gängigen Projektmanagement-Standards.

[9:22] Das fand ich schon mal sehr interessant.

[9:24] Denn man kann jetzt in der schriftlichen Prüfung schlecht testen, ob man ein Projekt abschließen kann.

[9:27] Aber was man natürlich gut prüfen kann, ist, kennt man die Projektmanagement-Standards.

[9:30] Wie heißen die, was machen die und so weiter.

[9:32] Und da gehen dann auch meine Hinweise entsprechend in die Richtung, dass man die kennen sollte.

[9:37] Gehen wir aber zuerst noch einmal die Tipps der Handreichung durch.

[9:40] Einmal Anwendung von Methoden, Hilfsmitteln, Techniken und Kompetenzen in einem Projekt.

[9:44] Dazu gehört zum Beispiel Projektplan, Meilensteine, Risikoanalyse, Standards und Normen, Projektmanagement-Systeme.

[9:50] Dann Basiskenntnisse des Veränderungsmanagements, also Change-Management.

[9:54] Und unterscheiden verschiedene Projektmanagement-Methoden und Vorgehensmodelle.

[9:58] Zum Beispiel agiles Projektmanagement, V-Modell, Spiralmodell, Wasserfreimodell.

[10:01] Das sind erstmal die Tipps, mit denen ich da reingegangen bin.

[10:04] Jetzt habe ich geguckt, was würde ich darunter konkret verstehen, was verbirgt sich dahinter,

[10:08] was solltest du dir vielleicht für die Prüfung anschauen.

[10:11] Und da würde ich jetzt erstmal loslegen mit so ein paar grundlegenden Definitionen.

[10:15] Zum Beispiel, was ist überhaupt ein Projekt?

[10:17] Und ein Projekt ist ja, je nachdem wo man guckt, gibt es da unterschiedliche Formulierungen.

[10:21] Aber grundsätzlich geht es darum, dass es etwas zeitlich befristet ist.

[10:25] Eine Aufgabe, die ich nicht immer wieder mache, jedes Jahr wiederkehrend oder die zehn Jahre dauert.

[10:30] Also doch, das kann eigentlich schon, Projekte können auch über zehn Jahre laufen, das ist nicht das Problem.

[10:34] Sondern, dass es eine einmalige Situation ist und die nicht immer wiederkehrt.

[10:38] Das ist eigentlich erstmal die wichtigste Definition beim Projekt.

[10:41] Jetzt kann man genau, wie gesagt, wo man guckt, sieht man noch ein bisschen Ergänzungen dazu.

[10:46] Ich persönlich würde es so definieren, dass es meistens auch etwas Innovatives ist.

[10:50] Also etwas, was man vorher noch nicht so gemacht hat.

[10:53] Also nicht zum x-ten Mal dasselbe machen, sondern aus dem Motto,

[10:55] dann gibt es da vielleicht auch ein bisschen ein Risiko, was daran haftet.

[10:58] Es könnte sein, dass das scheitert, dass ich es nicht umgesetzt bekomme.

[11:01] Und es sollte auch eine gewisse Komplexität haben.

[11:04] Das heißt, so ein Projekt, was einen Tag dauert, das ist dann vielleicht eher kein Projekt.

[11:09] Und was ich auch noch an verschiedenen Stellen gesehen habe, ist,

[11:11] dass das Projekt auch ein Projektmanagement erfordert.

[11:15] Was bedeutet das?

[11:16] Ja nun, wenn ich jetzt irgendwie alleine fünf Wochen an einer Aufgabe sitze und dann ist die fertig,

[11:21] dann ist das vielleicht einmalig und auch zeitlich befristet.

[11:23] Aber ich brauche kein Projektmanagement, weil ich ganz alleine daran sitze und das irgendwann fertig habe.

[11:28] Und im Zusammenspiel mit dieser Komplexität ist das dann vielleicht kein Projekt mehr,

[11:33] weil ich halt nicht mit mehreren Leuten arbeite, keine Aufgaben abstimmen muss etc.

[11:37] Also kein Projektmanagement brauche.

[11:40] Und jetzt, um nochmal auf diese Projektmanagement-Standards zu gehen,

[11:45] die waren ja auch Teil der Handreichung, da gibt es dann verschiedene.

[11:48] Und ich würde jetzt mal empfehlen, dass man sich mindestens zwei anschauen sollte.

[11:51] Nämlich einmal die Definition nach der DIN-Norm.

[11:54] Ich meine, alles, was genormt ist in Deutschland, kann man natürlich perfekt in Prüfungen abfragen.

[11:58] Und alles rund um dieses Projekt und Projektmanagement kann man da sehr schön nachschauen in der DIN-Norm.

[12:03] Und das ist die DIN 69901.

[12:06] Und da steht dann zum Beispiel die Definition eines Projekts wie folgt.

[12:09] Ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist.

[12:16] Das ist auch schön.

[12:17] Ganz allgemein formuliert, alles was ich nur einmal mache im Prinzip, das ist dann schon ein Projekt.

[12:22] Und dann kommen wir aber auch schon zum zweiten Projektmanagement-Standard, nämlich PRINCE2.

[12:26] Das hast du vielleicht auch schon mal gehört.

[12:28] PRINCE steht für Projects in Controlled Environments.

[12:32] Und das ist auch ein sehr gängiges Projektmanagement oder ein Standard für Projektmanagement, der dann ganz viele Sachen definiert.

[12:38] Also was machen diese Standards überhaupt?

[12:40] Die legen zum Beispiel fest, welche Rollen gibt es im Projekt, was ist überhaupt ein Projekt, wie soll das Projekt durchgeführt werden.

[12:45] Also Projektmanagement, worauf muss ich da achten, wer hat welche Aufgabe, wer macht was, bis wann im Prinzip.

[12:50] Und das PRINCE2 ist da auch sehr etabliert und könnte man sich auch einen Teil mal angucken.

[12:54] Da PRINCE2 aber, wie man am Akronym schon gesehen hat, Englisch ist, wäre da das Projekt dann auch auf Englisch definiert.

[13:01] Und zwar a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case.

[13:10] Das heißt, hier geht es auch wieder darum, dass es einmalig, weil einmalig steht nicht explizit drin, nur temporary.

[13:16] Das heißt, es wird einmalig für dieses Ding ins Leben gerufen und danach fällt es dann weg quasi.

[13:20] Also Projekt, einmalig, dann ist es abgeschlossen.

[13:22] Aber hier ist nochmal explizit mit drin, dass es darum geht, ein Produkt zu erstellen.

[13:27] Was auch irgendwie, das ist dann der letzte Punkt, Business Case, was uns auch irgendwie ein bisschen Geld einbringen sollte.

[13:32] Oder zumindest irgendeine Form von Vorteil für das Unternehmen verschafft.

[13:35] Also eine leicht andere Definition aus PRINCE2.

[13:38] Trotzdem sollte man beide kennen und ich könnte mir auch vorstellen, dass es dazu dann Abfragen halt in der Prüfung gibt.

[13:43] Okay, wir haben jetzt also geklärt, was ein Projekt ist.

[13:46] Irgendwas Einmaliges, was ich durchführe und wo ich irgendwie Projektmanagement für brauche.

[13:50] Und dann kommen wir vielleicht gleich zum nächsten Punkt.

[13:52] Wofür brauche ich überhaupt Projektmanagement?

[13:54] Naja, es gibt im Projektmanagement so ein magisches Dreieck.

[13:58] Und im Prinzip ist die Aufgabe des Projektmanagements, genau dieses magische Dreieck so ein bisschen unter Kontrolle zu halten.

[14:04] Magisches Dreieck, warum heißt das so?

[14:06] Es gibt drei Ecken des Dreiecks, nämlich Qualität, Kosten und Zeit.

[14:11] Und es gibt dann immer so den schönen Spruch, hier, Qualität, Kosten, Zeit.

[14:14] Wähl dir mal zwei davon aus, die du einhalten kannst.

[14:17] Und das dritte Ding, ja, da musst du eine Abstriche machen quasi.

[14:20] Beispiel, was heißt das?

[14:22] Also erstmal erklären wir kurz, was das ist.

[14:24] Also Qualität vielleicht, das ist so ein Begriff, den man auch öfter mal benutzt.

[14:27] Aber was ist das eigentlich?

[14:29] Eine ganz kurze, einfache Definition ist, Qualität ist die Übereinstimmung mit den Anforderungen.

[14:34] Ich erkläre das immer so, stellen wir uns vor, was ist ein qualitativ hochwertiges Flugzeug?

[14:39] Und dann ist die Antwort, naja, kommt drauf an, wen man fragt.

[14:42] Wenn man den Passagier fragt, dann sagt der oder die, Mensch, wenn ich hier meine Beine ausstrecken kann, dann habe ich ein tolles Flugzeug.

[14:48] Ja, der Pilot, dem ist das allerdings ziemlich wurscht.

[14:51] Der Pilot will, dass das Ding vielleicht einen tollen, keine Ahnung, Autopilot hat.

[14:55] Dass er seine Sachen, die er bedienen muss, gut in der Sichtweite hat.

[14:59] Dass er, keine Ahnung, möglichst viel unterstützt wird beim Fliegen oder weiß der gar nicht.

[15:02] Also ganz andere Anforderungen.

[15:04] Und die Stewardess, die hat nochmal andere Anforderungen.

[15:06] Die will zum Beispiel einen breiten Gang, damit dieser Wagen da immer schön durchrollen kann.

[15:09] Oder? Ich weiß es nicht, ne?

[15:11] Das heißt, man sieht schon in diesem einfachen Beispiel mit dem Flugzeug, Qualität hängt davon ab, wen man fragt.

[15:16] Weil jeder unterschiedliche Anforderungen an dieses Flugzeug hat.

[15:20] Deswegen kann man auch nicht sagen, Qualität ist erfüllt oder nicht.

[15:23] Sondern es kommt immer auch auf den Blickwinkel an.

[15:26] Trotzdem haben wir Qualität als Wort, als Begriff in diesem magischen Dreieck.

[15:31] Das heißt, wir wollen natürlich in unserem Projekt auch qualitativ hochwertig arbeiten und die Qualität erreichen.

[15:36] Qualität könnte man also übersetzen mit Übereinstimmung mit den Anforderungen.

[15:40] Also, was soll das Ding überhaupt machen?

[15:42] Wenn ich jetzt ein Software entwickel für einen Buchhalter, dann würde ich mir wünschen,

[15:45] dass die Software am Ende auch Buchhaltungsvorgänge, wie zum Beispiel Buchungssätze oder sowas, korrekt umsetzen kann.

[15:51] Und nicht irgendwie, keine Ahnung, eine Registrierkasse darstellt.

[15:54] Weil dann haben wir das falsche programmiert, ne?

[15:56] Das heißt, wir wollen natürlich das entwickeln, in diesem Fall, was der Kunde haben will.

[16:00] Also dessen Anforderungen erfüllen.

[16:02] Das ist die Qualität. Das sollte das Ziel des Projekts sein.

[16:05] Aber wir sind natürlich immer eingeschränkt durch zwei andere Faktoren, nämlich die Kosten und die Zeit.

[16:10] Wenn wir das perfekte Programm fertig machen wollen, dann brauchen wir wahrscheinlich unendlich viel Geld und unendlich viel Zeit.

[16:16] Weil die Anforderungen sich ja auch ständig ändern können.

[16:18] Da kommt ein neues Gesetz wieder dazu.

[16:20] Dann ist das Programm schon nicht mehr perfekt, wenn es diese Gesetze nicht einhält.

[16:23] Das heißt, wir haben immer so ein Wechselspiel zwischen, was müssen wir tatsächlich umsetzen, wie lange brauchen wir dafür und wie teuer wird das?

[16:31] Und wenn ich mir jetzt überlege, wenn ich zwei davon nur auswählen kann, dann könnte das so aussehen.

[16:36] Ich will die Qualität hochhalten und zwar in wenig Zeit.

[16:40] Dann heißt das automatisch, dass ich mehr Kosten habe.

[16:43] Können wir uns auch überlegen, wenn ich schneller fertig sein will, brauche ich vielleicht mehr Leute, die daran arbeiten.

[16:47] Mehr Leute kosten mehr Geld.

[16:49] Andersherum, wenn ich die Qualität hochhalten will, aber ich will, dass es wenig kostet, dann wird es wahrscheinlich so rum sein, dass die Zeit dadurch verlängert wird.

[16:57] Denn wenig Kosten, im Zweifel setze ich nur einen Entwickler dran, der braucht dann halt fünf Jahre anstatt drei Entwickler in einem oder so.

[17:03] Nur als Beispiel.

[17:05] Was man vielleicht nicht machen sollte, wäre, die Qualität niedrig zu halten, dafür aber die Kosten und die Zeit kurz.

[17:10] Das heißt, billiges Projekt, schnell fertig, heißt automatisch schlechte Qualität, logischerweise.

[17:15] Schlechte Software ist nicht fertig, unvollständig, etc.

[17:18] Gut, also dieses magische Dreieck, das müssen wir irgendwie im Zaume halten und dafür brauchen wir Projektmanagement.

[17:23] Denn es ist halt immer so ein Trade-off.

[17:26] Das haben wir in der IT ganz oft.

[17:27] Gerade an diesem magischen Dreieck sieht man das.

[17:29] Wenn es billiger werden soll, dann könnte es sein, dass die Qualität leidet oder es eben teurer wird.

[17:34] Das heißt, es ist immer so ein Wechselspiel, was wir im Auge behalten müssen.

[17:38] Und das ist dann auch die Aufgabe der Projektmitarbeiter, insbesondere des Projektleiters.

[17:44] Gut, da kommen wir gleich nochmal drauf, was jetzt vielleicht im Umfeld des Projekts noch interessant ist,

[17:48] nämlich die Rollen und die Aufgaben und verschiedene Meetings, die man machen kann.

[17:52] Vorher würde ich aber gerne noch eine Sache einstreuen, und zwar nochmal zur Qualität.

[17:55] Wenn ich Anforderungen definiere, dann sieht man das auch ganz oft und wurde auch schon mehrfach abgefragt,

[17:59] in solchen Prüfungen smarte Ziele zu setzen.

[18:02] SMART, das Akronym, wofür steht das?

[18:05] Damit kann man nämlich dann auch qualitativ hochwertige Anforderungen erfassen, quasi.

[18:10] Und zwar steht das SMART für spezifisch, messbar, attraktiv, realistisch und terminiert.

[18:16] Grundsätzlich sagt man, SMART wird häufig im Zusammenhang mit Zielen benutzt.

[18:20] Und da wir beim Projekt auch ein Ziel haben, was wir erreichen wollen, können wir das da auch gut einhalten.

[18:24] Und es war sogar eins zu eins auch schon in der schriftlichen Prüfung dran,

[18:27] dass man diese Buchstaben mal aufdröselt und erklärt, was dahinter steckt.

[18:31] Deswegen machen wir das auch einmal.

[18:33] Smarte Ziele benutze ich übrigens auch in der Ausbildung.

[18:35] Meine Azubis müssen sich auf smarte Ziele setzen.

[18:37] Und dann gucken wir, ob die Azubis die erfüllen können.

[18:40] Und diese fünf Punkte, spezifisch, messbar, attraktiv, realistisch, terminiert.

[18:44] Wahlweise gibt es auch manchmal andere Begrifflichkeiten dafür.

[18:47] Aber ich nehme jetzt einfach mal die fünf.

[18:49] Auch wenn es andere Begrifflichkeiten dafür gibt, es meint immer dasselbe.

[18:53] Also das A steht immer für irgendwas Attraktives, für ein Ziel, das ich auch erreichen will, zum Beispiel.

[18:58] Auch wenn man es vielleicht anders formuliert.

[19:00] Gut, fangen wir vorne an mit spezifisch.

[19:02] Das bedeutet, es soll kein allgemeines Ziel sein, sondern sehr konkret.

[19:06] Also nicht sowas wie, Beispiel, ich will reich werden.

[19:09] Das ist zu unspezifisch.

[19:11] Sondern ich müsste sagen, ich möchte eine Million Euro auf meinem Tagesgeldkonto haben.

[19:15] Das wäre spezifisch.

[19:17] Also etwas Konkretes, nicht allgemein.

[19:19] So ein allgemeines Ziel, was ich aus der Software häufig kenne, ist, die Software soll benutzerfreundlich sein.

[19:23] Ja, das ist super. Was heißt das jetzt konkret?

[19:26] Das kann man daraus nicht ableiten.

[19:28] Da müsste man schon etwas konkreter werden.

[19:30] Wie zum Beispiel, für jede Schaltfläche soll es ein Popup geben, in dem erklärt wird, was die Schaltfläche macht.

[19:36] So, das wäre schon ein konkreteres, spezifischeres, eine spezifischere Anforderung.

[19:41] So, dann machen wir weiter mit M, messbar. Das ist ganz, ganz wichtig. Wenn ich diese Liste auf zwei

[19:48] Eigenschaften eindampfen müsste, dann wäre es messbar und terminiert. Messbar bedeutet nämlich,

[19:53] dass ich irgendwie zeigen muss, dass ich das Ziel auch erreicht habe. Das heißt, ich brauche am

[19:58] besten eine Zahl, die ich vergleichen kann. Und wenn ich das erreicht habe, dann ist das Ziel

[20:02] abgehakt, ansonsten nicht. Beispiel, ich möchte reich werden, ist wieder ein schlechtes Beispiel,

[20:06] weil ich nicht weiß, was heißt denn reich? Reicht eine Million, muss es eine Milliarde sein? Weiß

[20:11] ich nicht. Aber wenn da steht, ich habe eine Million auf dem Konto, dann kann ich exakt sagen,

[20:14] habe ich die oder nicht? Und wenn ich sie nicht habe, habe ich das Ziel nicht erreicht. So einfach.

[20:18] Also es muss messbar sein. Dann attraktiv hatte ich eben schon ganz kurz. Es sollte auch für mich

[20:23] ein gewisses Interesse dahinterstehen, das Ziel zu erreichen. Und es soll nicht irgendetwas,

[20:27] keine Ahnung, Vorgegebenes sein, was mich eh nicht interessiert oder was mich nicht weiterbringt.

[20:31] Beispiel wieder mit, ich möchte reich werden. Ja gut, das sollte sehr attraktiv sein,

[20:35] zumindest für die meisten Menschen. Wenn das Ziel jetzt wäre, ich möchte möglichst arm werden,

[20:41] sehr konstruiert. Aber das wäre vielleicht nicht so ganz attraktiv für viele Menschen.

[20:44] So, nächster Punkt, realistisch. Das heißt, wir müssen das Ziel auch erreichen können. Bleiben

[20:50] wir mal mal ein Beispiel mit dem Geld, eine Million. Da kann man sich jetzt überlegen,

[20:53] wie realistisch das ist. Vielleicht fängt man erst mal mit einem kleineren Ziel an,

[20:57] so nach dem Motto, ich möchte jeden Monat 100 Euro sparen und das dann für das nächste Jahr.

[21:02] Das kann man vielleicht etwas realistischer erreichen, wenn man aktuell vielleicht noch

[21:05] in der Ausbildung ist. Da wird es sehr unrealistisch, eine Million auf dem Konto

[21:08] zu bekommen wahrscheinlich. Und letzter Punkt, terminiert. Das ist auch nochmal ganz wichtig,

[21:12] hatte ich gerade gesagt. Messbar und terminiert wären so meine beiden Favorites. Da muss ein

[21:16] Datum daneben stehen, ganz einfach gesagt. Das heißt, wenn man jetzt wieder das Beispiel von

[21:19] eben nimmt, ich möchte reich werden, dann ist die Frage, bis wann denn? Bis ich in Rente bin,

[21:24] bis nächstes Jahr, vielleicht heute noch. Also wann soll das fertig sein? Auch ganz wichtig,

[21:30] um bewerten zu können, ob das Ziel erreicht wurde oder nicht. Deswegen wäre ein besseres

[21:34] Ziel als, ich möchte reich werden, so etwas wie, ich möchte in den nächsten beiden Jahren

[21:40] jeden Monat 100 Euro auf ein Tagesgeldkonto einzahlen. Da habe ich alles drin. Da habe ich

[21:47] den Termin, das heißt, am 31.12.2024 oder so, kann ich nachgucken, ob ich das Ziel erreicht

[21:54] habe oder nicht. Jeden Monat 100 Euro ist vielleicht realistisch, attraktiv ist es auch,

[21:58] weil es mich voranbringt und ich mehr Geld habe am Ende. Und messbar eben auch, weil ich genau

[22:02] gucken kann, wenn ich nur 99 Euro überwiesen habe, habe ich das Ziel halt nicht erreicht. Gut,

[22:07] das waren die smarten Ziele. Dann gehen wir jetzt mal weiter zum Thema Projektmanagement,

[22:12] noch wieder etwas konkreter zurück. Und zwar gibt es da so ein Vierphasen-Modell. Das würde

[22:16] ich mir auch mal anschauen. Das ist irgendwie so ein bisschen gesunder Menschenverstand,

[22:19] denke ich, aber trotzdem sollte man es mal gehört haben. Und zwar sind das so die vier Phasen,

[22:24] in denen Projekte ablaufen. Da gibt es einmal die Projektdefinition, danach kommt die Projektplanung,

[22:29] dann kommt die Projektdurchführung und das Controlling und dann kommt der Projektabschluss.

[22:34] Das ist jetzt irgendwie nicht, das ist keine Raketenwissenschaft, sag ich mal. Trotzdem kann

[22:38] man sich jetzt mal vor Augen halten, wie so ein Projekt abläuft. Und je nachdem, welches

[22:41] Projektmanagement-Werkzeug, z.B. Prince2, man sich anguckt, gibt es auch unterschiedliche Aufgaben

[22:46] und Definitionen von diesen Projektphasen. Deswegen grundsätzlich schon mal eine gute

[22:49] Geschichte. Ich fange an und definiere erstmal, was will ich erreichen? Also Zieldefinition. Was

[22:54] möchte ich überhaupt haben? Ich möchte reich werden, wie eben. Natürlich dann als smartes

[22:58] Ziel formuliert, damit wir es auch erreichen können. Dann weiß ich, was ich machen will. Dann

[23:02] gucke ich mir an, plane ich das Projekt. So, wen brauche ich? Wer hat wann wie Zeit? Welche Skills

[23:07] brauche ich? Wie werden die eingesetzt? Welche Deadlines haben wir? Also, wer macht was bis wann?

[23:12] Das fand ich eine ganz schöne Zusammenfassung von Projektmanagement. Es geht eigentlich nur um

[23:15] die Frage, wer macht was bis wann? Und das ist auch schon das Geheimnis des Projektmanagements,

[23:21] weil wir wollen das Ziel ja erreichen. Und im Prinzip geht es immer nur darum, welche Aufgaben

[23:24] gibt es? Bis wann werden die erledigt und wer muss sie umsetzen? So, das ist die Planung. Und

[23:29] dann haben wir natürlich die Projektdurchführung und auch das Controlling. Also immer während der

[23:34] Projektlaufzeit zu gucken, sind wir noch im Plan? Haben wir irgendwo eine Verzögerung drin? Brauchen

[23:38] wir mehr oder weniger Leute? Brauchen wir mehr oder weniger Geld? Das heißt, alles, was mit

[23:42] Zahlen auch zu tun hat, das ist das Controlling. Zu gucken, ob wir irgendwo gegensteuern müssen,

[23:46] mehr Budget brauchen, mehr Leute im Team etc. Und dann, ganz am Ende, wenn wir fertig sind,

[23:51] Projektabschluss. Und das sollte man auch nicht vernachlässigen. Da gibt es dann zum Beispiel auch

[23:55] so eine Projektparty, finde ich. Gehört auch zu so einem Projekt dazu, dass der Projektleiter am

[23:58] Ende alle einsammelt, vielleicht für ein nettes Essen oder wirklich eine Party, um zu feiern,

[24:02] dass man das Ziel auch erreicht hat. Auch das ist wichtig für die Motivation der Projektbeteiligten.

[24:06] Ja, das war das Vier-Phasen-Modell. Und dann können wir mal in eine davon einsteigen. Da

[24:11] gibt es dann so etwas wie ein Kick-Off-Meeting. Und weil das so einen schönen Namen hat,

[24:14] kann man das sicherlich auch gut in Prüfungen abfragen. Ein Kick-Off heißt ja so ein bisschen

[24:19] der Anstoß beim Fußball. Das heißt, jetzt geht es richtig los. Und dann ist die Frage erstmal,

[24:23] wo platziert man das? Und meistens wird das dann zu Beginn der Projektplanung gemacht. Also,

[24:27] nachdem die Projektdefinition durch ist, ich weiß jetzt, was ich erreichen will. Ich habe mein Ziel

[24:32] vor Augen, beispielsweise Software für Buchhaltungssysteme programmieren. Und jetzt geht

[24:37] es los mit der Projektplanung. Und zum Start dieser Planung machen wir dann ein Kick-Off-Meeting.

[24:41] Dabei sollten dann alle Projektbeteiligten an einen Tisch kommen. Also alle, die im Projekt

[24:46] mitarbeiten, aber auch die Projektleiter und im besten Fall sogar vielleicht der Kunde,

[24:50] der nochmal mit dazukommt, wo dann wirklich definiert wird, was machen wir jetzt. Und als

[24:55] Ergebnis dieses Kick-Off-Meetings kann dann zum Beispiel ein sogenannter Projektstrukturplan

[24:59] herauskommen. Und der Projektstrukturplan, da gehen wir nochmal drauf ein, bei einem der nächsten

[25:04] Unterpunkte. Im Prinzip geht es darum, das Projekt in Teile zu zerlegen, die dann wieder in Teile

[25:09] zerlegt werden, bis wir dann irgendwo bei Aufgaben sind, die wir auch einzelnen Mitarbeitern und

[25:13] Mitarbeiterinnen zuordnen können. Also Beispiel Buchhaltungssoftware entwickeln. Da haben wir

[25:17] vielleicht als erstes mal die Unterteilung in, weiß ich nicht, Eingabemasken entwickeln,

[25:22] Berechnungsprogramme entwickeln, Druckoutput erzeugen und keine Ahnung, Anbindung an die

[25:28] Steuersoftware des Unternehmens oder so. Und dann brechen wir das wieder runter, zum Beispiel

[25:32] Anbindung an die Steuersoftware, Schnittstelle programmieren, Datenaustausch definieren, keine

[25:39] Ahnung, Datensicherung einrichten, was auch immer dazugehört. Also das heißt, man hat eine

[25:43] hierarchische Struktur, wie das Projekt aufgebaut ist, aus welchen Teilen das Projekt besteht. Das

[25:48] kann man gemeinsam am besten im Kick-Off-Meeting erarbeiten. Da sind alle Projektbeteiligten dabei

[25:52] und am Ende haben dann alle ein gemeinsames Bild davon, was überhaupt in dem Projekt gemacht werden

[25:57] muss und vielleicht auch schon so eine grobe zeitliche Einteilung, wer was wie wann tun soll.

[26:02] Ein weiterer Punkt in dem Kontext wären dann die Meilensteine. Auch das sollte man mal gehört

[26:08] haben, Meilensteinplanung. Meilensteine sind in einem Projekt so wichtige Ereignisse, könnte man

[26:14] das nennen, oder ein wichtiger Zeitpunkt, wo etwas Besonderes erreicht ist. Wenn wir unser Projekt

[26:18] zum Beispiel aufteilen in fünf solcher Meilensteine, vielleicht sogar analog zu unserem Projektstrukturplan,

[26:22] was hatten wir da eben? Erfassungsmasken programmieren. Dann könnte ein Meilenstein im Projekt sein,

[26:27] dass alle Erfassungsmasken programmiert sind und man jetzt damit quasi fertig ist. Und jetzt

[26:32] könnte man darauf aufsetzend den nächsten Meilensteinplan, zum Beispiel die Kalkulationsalgorithmen

[26:38] fertig machen, weil ich kann jetzt die Daten erfassen und jetzt sollen sie auch verarbeitet

[26:42] werden. Das baut dann zum Beispiel aufeinander auf. Das heißt, nach dem ersten Meilenstein kann

[26:46] ich mit dem zweiten weitermachen und so weiter. Und diese Meilensteine sind halt eben etwas

[26:49] Wichtiges im Projekt. Der letzte Meilenstein wäre natürlich Projekt in Produktion überführt zum

[26:54] Beispiel. Damit sollte dann das Projekt beendet werden. Also nichts anderes als wichtige Zwischenergebnisse

[27:00] in meinem Projekt. Und die können aber auch mit verschiedenen Visualisierungstechniken dann

[27:05] dargestellt werden und auch geplant werden, also auch zeitlich. Und auch wer daran mitarbeiten muss,

[27:10] da kommen wir aber gleich drauf. Stichwort wäre hier zum Beispiel das Gantt-Diagramm. In einem Gantt-Diagramm

[27:14] kann man sehr schön Meilensteine darstellen, zum Beispiel auch im Kalender. Das heißt, am 27. Februar

[27:22] sollen alle Erfassungsmasken fertig sein. Dann wäre das ein Meilenstein, der auch konkret terminiert ist.

[27:28] Und dann kann man auch bei seinem Projekt-Controlling nachher prüfen, habe ich den eingehalten oder nicht?

[27:32] Haben wir einen Verzug drin? Brauchen wir länger? Was heißt das für die folgenden Meilensteine? Verzögern

[27:36] die sich auch? Und so weiter und so fort. Gut. Und dann habe ich nochmal hier was aufgenommen, was ich

[27:42] auch sehr wichtig finde. Lasten- und Pflichtenheft. Das wird in vielen klassischen Projekten auch noch

[27:48] verwendet, auch heute noch. Es ist auch nicht verwerflich, das zu machen, auch wenn man vielleicht eher

[27:52] agil unterwegs ist. Ganz viele Projekte arbeiten noch mit Lasten- und Pflichtenheft. Das sollte man

[27:56] also auch kennen. Und hier nochmal eine ganz kurze Zusammenfassung. Beide Dokumente enthalten die

[28:02] Anforderungen des Kunden an unsere Software. Das Lastenheft wird aber vom Auftraggeber geschrieben.

[28:08] Das heißt, der Kunde sagt, was er gern haben möchte. Und das ist eher fachlich getrieben. Das heißt,

[28:14] unser Buchhalter sagt zum Beispiel, ich brauche eine Software, die fachlich korrekt und auch

[28:19] rechtlich korrekt Buchungssätze verarbeiten kann. So, ganz konkret. Da sagt er mir aber natürlich

[28:26] nicht, dass das in der Datenbank soll und welche Version und welche Promissprache ich nutze,

[28:29] sondern wirklich nur, was seine fachlichen Anforderungen sind. Deswegen schreibt er dieses

[28:34] Lastenheft und legt mir das dann als Auftragnehmer, zum Beispiel als Softwareentwickler, auf den Tisch.

[28:39] Und jetzt ist es mein Job, daraus das sogenannte Pflichtenheft zu machen. Das heißt,

[28:44] ich nehme die Anforderungen des Kunden aus dem Lastenheft und übersetze die in konkrete

[28:48] technische Lösungsvorschläge. Das heißt, Lastenheft hat den Fokus auf die Problemstellung,

[28:54] Pflichtenheft hat den Fokus auf die Lösung. Das heißt, das wird auch nicht vom Auftraggeber,

[28:59] also vom Kunden erstellt, sondern von mir als Auftragnehmer, von mir als Entwickler,

[29:03] als IT-Unternehmen, als der, der es umsetzt. Da schreibe ich jetzt auf, wie gedenke ich denn

[29:08] die Anforderungen des Kunden umzusetzen? Also, welche Programmiersprache nehme ich? Welche

[29:12] Version? Welche Datenbank? Wie sieht das Sicherungskonzept aus? Was ist mit der

[29:16] Authentifizierung? Und so weiter. Ganz konkrete technische Vorschläge. Und dieses Pflichtenheft,

[29:21] das ist jetzt auch das Interessante, was wir in der Prüfung immer sagen und schreiben müssen,

[29:25] ist auch Vertragsbestandteil. Das heißt, wenn ich jetzt den Auftrag von meinem Kunden annehme und

[29:30] sage, jo, ich liefere dir das, dann unterschreibe ich in Anführungszeichen nicht sein Lastenheft,

[29:35] sondern das Pflichtenheft. Das heißt, dagegen kann der Kunde am Ende prüfen, ob ich alles

[29:39] umgesetzt habe. Wenn im Pflichtenheft drinsteht, es gibt diese Maske mit grüner Überschrift und

[29:44] wenn ich auf diesen Button klicke, passiert Folgendes. Dann kann der Kunde das am Ende nehmen,

[29:48] prüft das und wenn der Button, oder was habe ich gerade gesagt, nicht grün ist, sondern blau,

[29:52] dann ist das Pflichtenheft nicht erfüllt und dann muss er mir auch kein Geld zahlen. Jetzt

[29:55] mal ganz weit runtergebrochen, so wäre das quasi. Alles, was im Pflichtenheft steht,

[30:00] ist Vertragsbestandteil und dagegen nimmt der Kunde mir am Ende das Produkt ab. Deswegen ist

[30:06] das deutlich wichtiger als ein Lastenheft. Okay, kurz und knackig zusammengefasst,

[30:11] was brauche ich für die Prüfung? Lastenheft kommt vom Auftraggeber, Pflichtenheft kommt

[30:16] vom Auftragnehmer und ist Vertragsbestandteil. Das ist im Prinzip alles, was man wissen muss.

[30:21] Gut, dann kommen wir gleich nochmal auf die Vorgehensmodelle zu sprechen. In einigen davon

[30:25] gibt es aber eine Besonderheit, die man schön visualisieren kann, und zwar den sogenannten

[30:29] kritischen Pfad. Den solltest du auch schon mal gehört haben. Der kritische Pfad, das ist der Pfad

[30:35] durch deine Projektaufgaben der Reihe nach, in dem der Gesamtpuffer null ist. Was heißt das jetzt?

[30:44] Stellen wir uns unser Projekt vor, wir haben eben diesen Projektstrukturplan grob kennengelernt,

[30:48] wo wir unsere Aufgaben runterbrechen und jetzt wollen wir die auch in eine zeitliche Reihenfolge

[30:51] bringen. Es gibt ja bestimmte Abhängigkeiten in unserem Projekt. Ich kann zum Beispiel schlecht

[30:55] eine, keine Ahnung, ich kann zum Beispiel nicht programmieren, etwas aus der Datenbank zu holen,

[31:00] wenn ich noch gar keine Datenbank habe, logischerweise. Dann muss ich erst mal die

[31:03] Datenbank erstellen. Das heißt, allein diese beiden Aufgaben werden ja schon in eine zeitliche

[31:06] Abhängigkeit zu bringen. Erst Datenbank erstellen, dann programmieren, dass ich was draus lesen kann

[31:12] quasi. So, und jetzt können wir uns vorstellen, dass wir das gesamte Projekt so aufbauen, dass

[31:15] es immer diese Abhängigkeiten gibt, zeitlicher Natur zum Beispiel. Und das würde jetzt bedeuten,

[31:19] bei diesem einfachen Beispiel, wenn es länger dauert, als erwartet, diese Datenbank zu erstellen,

[31:24] kann ich auch erst später anfangen, die Zugriffe zu programmieren, logischerweise. Wenn der

[31:28] Datenbankadministrator jetzt einen Tag krank ist, dann kann der Entwickler erst einen Tag später

[31:33] anfangen, die Datenbank anzubinden, weil die ist halt nicht vorher da. Und ob das Auswirkungen hat

[31:39] oder nicht, das wird halt durch diesen Puffer bestimmt. Manchmal hat man Aufgaben, die können

[31:44] theoretisch auch ein bisschen später anfangen und der Rest des Projekts verzögert sich allerdings

[31:48] nicht. Das Beispiel mit der Datenbank war jetzt ein Gegenbeispiel. Wenn der Datenbankadmin länger

[31:52] braucht, kann der Programmierer erst später anfangen. Das heißt, wenn der DBA einen Tag

[31:56] krank ist, wird das Gesamtprojekt einen Tag länger dauern, weil der Entwickler einfach nicht vorher

[32:01] anfangen kann. Bei anderen Sachen ist das nicht so. Wenn jetzt der Programmierer vielleicht die

[32:05] Oberflächen gestaltet, während der Datenbankadministrator noch die Datenbank einrichtet,

[32:09] dann gibt es da vielleicht gar keine zeitliche Abhängigkeit und dann ist es mir auch egal,

[32:12] ob der DBA einen Tag krank ist. Das interessiert den Entwickler dann nicht. So, und jetzt interessiert

[32:17] uns natürlich als Projektleitung und als Kunden vor allem auch in unserem Projekt, gibt es

[32:22] irgendwelche Aktivitäten, die eine krasse Verzögerung zur Folge hätten, wie das Beispiel mit

[32:27] der Datenbank. Dann guckt man sich genau diesen Pfad durch das Projekt an. Aha, Datenbank erstellen,

[32:32] Datenbankzugriff programmieren, die hängen voneinander ab. Wenn ich dazwischen keinen Puffer

[32:36] habe, bedeutet das, wenn der DBA länger braucht, verzögert sich das gesamte Projekt, weil alle

[32:42] folgenden Aktivitäten von der einen abhängen. Und jetzt kann ich durch meinen Pfad, durch das

[32:47] Projekt, wo ich auch Sachen parallel bearbeiten kann, nacheinander bearbeiten muss oder wie auch

[32:51] immer, kann ich jetzt so einen Pfad ableiten, wo eben dieser gesamte Puffer Null ist. Das bedeutet,

[32:58] wenn sich irgendeine der Aktivitäten auf diesem Pfad verlängert, verlängert sich auch das Projekt

[33:03] Ende. Deswegen ist das der kritische Pfad, denn wir wollen ja immer pünktlich fertig werden und

[33:08] immer wenn es länger dauert, kostet uns das Geld und logischerweise Zeit. Das heißt, wir wollen

[33:12] sehen, ob wir auf diesem kritischen Pfad sind oder nicht. Und diesen Pfad kann man jetzt auch

[33:17] in Visualisierungstechniken für die Projektplanung sehr gut darstellen, deswegen sollte man den

[33:21] kennen. Also, kritischer Pfad, Gesamtpuffer ist Null. Sobald sich eine Aktivität verschiebt, verschiebt

[33:27] sich das gesamte Projekt. Gut, gehen wir später noch mal darauf ein, ganz konkret beim Gantt-Diagramm

[33:32] und beim Netzplan. Da kann man das nicht sehr schön daran sehen. Wir sind aber immer noch bei

[33:36] Oberpunkt 1a und hier steht noch was zum Thema Vorgehensmodelle. Und da möchte ich auch noch mal

[33:40] kurz darauf eingehen, weil die sollte man auf jeden Fall kennen. Zumindest sollte man sie nennen

[33:44] können. Und ich hatte sie vorhin schon mal erwähnt. Es gibt so die klassischen Vorgehensmodelle, so

[33:49] nennt man die. Das ist das Wasserfallmodell, das V-Modell, das Spiralmodell. Und es gibt auch die

[33:54] agileren oder agilen Vorgehensmodelle, beispielsweise Scrum, Kanban und Extreme Programming. Die werden

[34:00] teilweise sogar explizit so genannt in der Handreichung zum Ausführungsrahmenplan. Deswegen

[34:06] würde ich mir die wirklich auch im Detail anschauen. Können wir hier jetzt nicht machen, sonst brauche

[34:10] ich noch länger. Aber grundsätzlich ist es ja so, das Wasserfallmodell, ganz klassisch, hat ein paar

[34:15] Projektphasen, wie zum Beispiel Analyse, Entwurf, Implementierung, Test, Einführung. Ein Beispiel. Je

[34:21] nachdem, welche Wasserfallmodelle man sich anguckt, sind es auch manchmal sieben Phasen. Manchmal sind

[34:25] Rücksprünge erlaubt, also vom Entwurf wieder zurück in die Analyse oder auch nicht. Das kommt

[34:29] immer ganz darauf an, welche Version man sich anschaut von diesem Wasserfallmodell. Das ist aber

[34:33] tendenziell so das klassische Vorgehen. Ich plane irgendwas, dann setze ich das um und am Ende gucke

[34:38] ich, ob ich es auch erreicht habe. So, ganz klassisches Vorgehen. Es gibt noch das V-Modell. Das ist im

[34:43] Prinzip ähnlich wie das Wasserfallmodell, nur wenn man den Wasserfall runtergelaufen ist, geht es auf

[34:48] der anderen Seite nochmal in umgekehrter Reihenfolge wieder hoch mit Tests für die einzelnen Phasen. Das

[34:53] heißt, ein ganz einfaches Wasserfallmodell. Wir haben sowas wie einen Entwurf und eine

[34:59] Implementierung. Dann würde ich links quasi runtergehen, Entwurf, Implementierung. Im Entwurf

[35:05] entwerfe ich zum Beispiel meine Oberflächen. In der Implementierung implementiere ich die dann.

[35:09] Und dann bin ich fertig mit dem Wasserfallmodell, in diesem sehr, sehr einfachen Wasserfallmodell.

[35:13] Beim V-Modell käme jetzt auf der rechten Seite quasi aufsteigend ein zweiter Ast dazu. Deswegen

[35:18] heißt es auch V-Modell. Links geht es runter, rechts geht es wieder hoch, wie ein V. Und bei

[35:23] unserem sehr einfachen Beispiel, Entwurf und Implementierung, hätte ich jetzt auf der rechten

[35:26] Seite eine Testphase für die Implementierung. Das wäre dann vielleicht sowas wie ein Unit-Test

[35:30] oder ein Integrationstest, der automatisch meine Software prüft, weil es halt sehr dicht an der

[35:35] Implementierung ist. Wenn ich jetzt noch einen Schritt weiter hochgehe, komme ich zur Testphase

[35:39] für die Entwurfsphase auf der linken Seite. Und da kann ich jetzt zum Beispiel einen Oberflächentest

[35:44] durch die Benutzer machen. Die Benutzer haben irgendwo aufgeschrieben, wie die Oberfläche

[35:48] aussehen soll. Jetzt können die sich auch an die tatsächliche Oberfläche dransetzen und gucken,

[35:51] ob die so aussieht, wie sie aussehen soll. Also das Testen quasi. Das heißt, hier habe ich dann

[35:56] vielleicht eher einen etwas abstrakteren Test, weil das nicht so hart an der Implementierung

[35:59] ist. Also kein Unit-Test, sondern vielleicht ein menschlich durchgeführter, manueller Test

[36:03] der Oberfläche. So, das ist jetzt beim V-Modell gibt es noch deutlich mehr Phasen als die zwei.

[36:08] Aber nur vom Prinzip her. Für jede Phase gibt es auf der gegenüberliegenden Seite eine

[36:12] entsprechende Testphase. Das ist im Prinzip das V-Modell. Wird heute auch immer noch gerade in

[36:17] vielen staatlichen Projekten umgesetzt, weil die sehr, sehr viel Wert auf diese Verifizierungsphase

[36:23] legen. Und deswegen ist das tendenziell auch sehr bürokratisch. Also ich nenne das immer gerne so,

[36:29] beim V-Modell fängst du erst an, wenn du sieben Ordner voll mit irgendwelchen Dokumentationen

[36:33] erstellt hast, und dann darfst du die erste Zeile Code schreiben. Übrigens, alle Beispiele,

[36:38] die ich heute bringe, sind immer sehr programmierlastig, weil ich daran als erstes denke,

[36:40] gilt natürlich auch für alle anderen Projekte. Auch für ein Physi-Projekt, das könnte man mit

[36:45] dem V-Modell umsetzen. Dann teste man halt am Ende nicht die Programmierung, sondern die

[36:48] Installation der Software oder so. Also bitte sieh mir das nach. Ich komme halt aus der

[36:51] Anwendungsentwicklung, aber Projekt ist völlig unabhängig von der Programmierung. Es kann auch

[36:55] jeden anderen IT-Beruf betreffen, logischerweise. Gut, und letztes klassisches Modell wäre das

[37:01] Spiral-Modell. Das hat so die ersten Ansätze zumindest der Agilität, aber eigentlich nicht.

[37:07] Also agil habe ich schon mal in einem separaten Podcast definiert, was das eigentlich ist. Das

[37:11] will ich hier nicht nur mal wiederholen. Aber im Prinzip geht es bei der Agilität auch darum,

[37:14] dass ich den Prozess an sich anpassen kann, wenn der nicht mehr so ganz zu meiner Realität passt.

[37:19] Und das ist bei den klassischen Modellen eben nicht. Da gibt es beim Wasserfall halt die

[37:23] vordefinierten Phasen, die durchlaufe ich und dann ist halt Feierabend. Beim V-Modell noch

[37:27] schlimmer. Da ist das ja sogar noch genau vorgegeben, was ich wann zu machen habe und

[37:30] was wie aufgeschrieben werden muss. Also da komme ich gar nicht raus aus diesem Modell.

[37:33] Und beim Spiral-Modell ist das eigentlich auch vorgezeichnet, welche Phasen durchlaufen werden.

[37:38] Aber ich habe zumindest eine gewisse Iteration da drin. Das Spiral-Modell erkläre ich immer gerne

[37:43] so. Das ist das Wasserfall-Modell, nur mehrfach hintereinander durchlaufen. Das heißt, ich mache

[37:47] die gleichen Phasen, Analyse, Entwurf, Implementierung, Test. Ich mache die aber etwas

[37:52] kleiner und ich mache die mehrfach hintereinander, sodass ich mein Produkt auch inkrementell und

[37:58] iterativ entwickle. Unterschiede habe ich schon mal erklärt. Inkrementell heißt, es kommt immer

[38:03] was dazu. Meine Anwendung wird also immer umfangreich her. Mehr Features kommen hinzu.

[38:07] Iterativ bedeutet, dass ich etwas wiederholend mache. Das heißt also immer wieder den gleichen

[38:14] Zyklus durchlaufe. Und das ist beim Spiral-Modell der Fall. Das heißt deswegen so,

[38:17] weil wenn man das aufzeichnet, sieht das aus wie eine Spirale, also wie so ein Schneckenhaus quasi.

[38:21] Ich fange innen an mit einer kleinen Iteration. Dann kommt ja durch das Inkrement ein bisschen

[38:25] was dazu. Das heißt, außen drumherum gibt es die nächste Iteration, nochmal drumherum wieder die

[38:29] nächste Iteration. Das heißt, mein Kreis wird immer größer. Stichwort Spirale. Und innerhalb

[38:35] dieser Durchläufe mache ich immer den gleichen Ablauf. Also klassisch das Wasserfall-Modell

[38:39] eigentlich nur mehrfach wiederholt. So, und dem gegenüber gibt es jetzt natürlich noch die agilen

[38:44] Vorgehensweisen. Die solltest du natürlich auch kennen. Auch wieder völlig unabhängig von der

[38:48] Programmierung, weil man davon viele auch einfach auf alle anderen Projektformen übertragen kann.

[38:53] Und da ist natürlich der Platz hier Scrum. Das kann ich jetzt hier tatsächlich nicht in der Tiefe

[38:57] durchgehen, weil da habe ich eine separate Episode zu, zu allem was man zu Scrum wissen muss. Ist in

[39:01] den Shownotes verlinkt. Hör dir die gerne an. Dann haben wir noch Kanban. Kanban ist auch ein

[39:05] sehr verbreitetes Vorgehensmodell und auch gerade nicht unbedingt in der Softwareentwicklung,

[39:09] sondern gerade auch bei Support-Prozessen und deswegen auch für viele andere IT-Berufe

[39:13] logischerweise interessant. Gehen wir später aber nochmal darauf ein. Gerade bei der

[39:16] Visualisierungstechnik, dem Kanban-Board, worauf man da achten sollte.

[39:20] Und letzter Punkt, der aber wirklich jetzt für Programmierprojekte dann eher geeignet ist,

[39:23] das Extreme Programming. Und aus dem Extreme Programming gibt es auch ganz, ganz viele

[39:27] konkrete Techniken, die man im Alltag anwenden kann. Die haben da ihren Ursprung, wie zum Beispiel

[39:31] Test-Driven Development oder Peer Programming oder die 40-Stunden-Woche, ja, dass man keine

[39:36] Überstunden machen soll. Also ganz viele konkrete Sachen, die man auch für den Entwickleralltag

[39:40] mitnehmen kann. Und das kann man jetzt halt dann eher schlecht auf andere Projektformen übertragen,

[39:44] weil das halt sehr viele Vorgaben wirklich zur Programmierung macht. Das kann man halt nicht so

[39:48] eins zu eins übernehmen. Aber Scrum und Kanban sind wirklich völlig allgemeingültige Vorgehen

[39:53] für beliebige Projekttypen. Das muss man nicht auf Programmier- oder Entwicklungsprojekte anwenden.

[39:59] Man kann das auch auf ganz andere Projekte anwenden. So, die sollte man auf jeden Fall

[40:03] gehört haben. Und da empfehle ich dir dringend, höre dir mal meinen Podcast zum Thema Scrum an.

[40:08] Da gehe ich das Ding im Detail komplett durch. Gut, das waren jetzt meine Punkte. Erst mal zum

[40:14] Oberpunkt 1a. Du siehst, da ist es allein schon zum ersten Unterpunkt. Ziemlich viel Zeug,

[40:18] was wir hier gemacht haben. Also Grundsätze und Methoden des Projektmanagements haben wir

[40:22] abgehakt. Jetzt kommen wir zu 1b. Oh Gott, oh Gott. Auftragsunterlagen und Durchführbarkeit

[40:28] des Auftrags prüfen, insbesondere im Hinblick auf rechtliche, wirtschaftliche und terminliche

[40:33] Vorgaben und den Auftrag mit den betrieblichen Prozessen und Möglichkeiten abstimmen. Das heißt,

[40:38] nur die Überschrift dieses Punktes geht bei mir schon über zwei Zeilen. Also das ist verrückt.

[40:42] Trotzdem weiß man jetzt nicht so richtig, was sich dahinter verbirgt. Und das wird durch die

[40:46] Handreichung etwas klarer, nämlich beachten der Voraussetzungen im eigenen Arbeitsumfeld. Das ist

[40:54] jetzt wieder bewusst schwammig, glaube ich. Aber der nächste Unterpunkt ist ein bisschen konkreter.

[40:57] Definieren von Aufgaben, Rollen und Verantwortlichkeiten für alle Projektbeteiligten,

[41:02] zum Beispiel Projektauftraggeber, Projektleiter, Projektsteuerkreis, Projektmitarbeiter. So,

[41:08] da wird es jetzt etwas konkreter. Und meine Tipps dazu wären jetzt, schau dir unbedingt den Begriff

[41:13] der Steakholder an. Was ist ein Steakholder? Steak geschrieben S-T-A-K-E, also nicht E-A-K.

[41:20] Es geht hier nicht ums Grillen. Und ich hatte, glaube ich, schon mal irgendwo die Anekdote

[41:23] erzählt, dass ein Prüfling bei uns in der mündlichen Abschlussprüfung das tatsächlich

[41:26] E-A-K geschrieben hat. Und wir ihn dann gefragt haben, was hat das mit dem Grillmeister zu tun?

[41:31] Und das wusste er dann nicht und das war dann nicht so gut. Also das hat nichts mit dem Fleischstück

[41:35] zu tun, sondern es geht Steak, S-T-A-K-E. Das englische Wort heißt so etwas ungefähr wie

[41:41] einen Anteil an etwas haben. Und Steakholder ist also jemand, der ein Interesse oder einen Anteil,

[41:48] irgendetwas mit unserem Projekt zusammenhängendes hat und irgendwie darauf Einfluss nehmen möchte

[41:53] oder muss. Das heißt also Gruppen oder Personen, die ganz allgemein gesagt irgendein Interesse an

[41:59] unserem Projekt haben, das sind Steakholder. Und da geht es halt eben nicht nur um den Kunden.

[42:04] Der Kunde ist ein Steakholder, aber es gibt noch ganz, ganz viele mehr. Wie zum Beispiel die

[42:08] Projektmitarbeiter, die Programmierer, die UX-Designer, der Projektleiter, der Chef der

[42:13] ganzen Mannschaft, das Unternehmen, der Vorstand. Aber auch so etwas wie das Land, in dem ich bin.

[42:19] Vielleicht gibt es da einen Kulturkreis, der eine Auswirkung hat. Also sehr abstrakt. Wenn

[42:23] ich zum Beispiel irgendwo in arabischsprachigen Ländern Software programmiere, dann sollte die

[42:27] vielleicht nicht mit englischem Text von links nach rechts arbeiten, sondern mit Schrift von

[42:31] rechts nach links. Wobei ich jetzt gar nicht weiß. Ich glaube, man schreibt arabisch von rechts nach

[42:34] links. Aber noch ein anderes Beispiel. Japan. Japanische Schrift zum Beispiel. Die wird ja

[42:39] wirklich, glaube ich, von rechts nach links und sogar von unten nach oben gelesen. Ehrlich gesagt,

[42:42] ich weiß nicht. Ich kenne mich nicht gut genug aus damit. Auf jeden Fall weißt du, wenn man in

[42:46] unterschiedlichen Ländern ist, gibt es unterschiedliche Anforderungen an ganz simpel die

[42:49] Oberflächen unserer Software. Da muss halt die Schrift mal von links nach rechts, mal von rechts

[42:53] nach links laufen. Und wenn man das nicht weiß, ja, dann macht man da Probleme oder kriegt man

[42:58] Probleme im Projekt. Also Stakeholder bewusst allgemein. Alles mögliche, was irgendwie Einfluss

[43:03] auf unser Projekt hat, kann ein Stakeholder sein. Und einige davon wurden hier auch sogar schon

[43:08] genannt eben, nämlich die Projektbeteiligten sind natürlich auch alle Stakeholder. Und der

[43:12] Projektleiter hat vielleicht auch ganz andere Anforderungen unser Projekt als der Projektmitarbeiter,

[43:16] der Programmierer. Der Programmierer hat vielleicht Lust auf eine moderne Programmiersprache, coole

[43:20] Tools, automatischen Bild. Den Projektleiter interessiert hauptsächlich, ob die Leute die

[43:23] Zeit einhalten, ob wir das Budget einhalten, etc. Das heißt, auch die unterschiedlichen Stakeholder

[43:27] haben teilweise konkurrierende Anforderungen an das Projekt. Der Entwickler hat vielleicht Bock,

[43:32] noch ein bisschen mehr Unit-Tests zu schreiben, weil er sich dann sicherer ist. Der Projektleiter

[43:35] sagt aber, sorry, wir müssen fertig werden, lasst das mal weg. Also schönes, klischeehaftes Beispiel,

[43:41] aber nur, um das mal zu verdeutlichen. Und das ist halt fast unmöglich, alle Ansprüche aller

[43:45] Stakeholder im Projekt zu berücksichtigen. Das funktioniert meistens nicht. Deswegen ist dann

[43:49] auch eine Aufgabe, diese Anforderungen zu priorisieren und dann letztlich zu entscheiden,

[43:53] was davon setzen wir um und was nicht. Und dann nimmt man auch bewusst in Kauf,

[43:56] dass bestimmte Stakeholder vielleicht ein bisschen verärgert sind oder nicht mit im Boot sind,

[44:00] aber das ist dann so. Man kann halt keine 100% perfekte Software für alle bauen. Das

[44:04] funktioniert halt nicht. So, trotzdem waren hier auch nochmal die Hinweise auf die Aufgaben der

[44:09] einzelnen Projektbeteiligten und da ist natürlich prüfungsrelevant meistens die Aufgaben des

[44:14] Projektleiters oder übrigens natürlich auch der Leiterin. Die kann man sehr schön aufzählen und

[44:18] auch mal bewerten und beschreiben, was da zu tun ist. Ich habe mal ein paar mitgebracht. Was macht

[44:22] eigentlich ein Projektleiter? Zum einen sollte er bei der Zieldefinition mitwirken, also definieren,

[44:27] was wollen wir im Projekt überhaupt erreichen. Smarte Ziele, das sauber aufschreiben, vielleicht

[44:32] das Pflichtenheft schreiben, also einfach zu definieren, was soll erreicht werden. Dann während

[44:36] des Projekts natürlich das Team zu koordinieren. Wer hat welche Aufgabe, wer hat wann fertig zu

[44:42] sein, wurden die auch fertig, das Controlling machen etc. Dann, wer soll überhaupt was machen,

[44:47] also die Aufgaben verteilen, die Zusammenarbeit koordinieren, aber auch vorher verteilen, wer was

[44:51] machen soll. Dann natürlich die Projektvorschritte überwachen, das heißt regelmäßig abfragen, sind

[44:56] die Aufgaben fertig? Wenn nicht, wann werden sie denn fertig? Hat das eine Verzögerung zur Auswirkung?

[45:00] Etc. Kommunikation, eines der wichtigsten oder doch ein wichtiger Skill jedes Projektleiters. Mit

[45:08] den Leuten reden. Ganz oft hat der Projektleiter nämlich keine Führungsverantwortung, sondern

[45:13] der, das nennt man dann auch gerne, man führt bilateral. Das heißt, ich stehe nicht hierarchisch

[45:18] über meinen Mitarbeitern, weil ich deren Chef bin. Ich kann die nicht anweisen,

[45:24] irgendwas zu tun. Ich bin nicht der Chef, sondern ich bin quasi ein Peer, ein Gleichrangiger, habe

[45:28] nur die Rolle des Projektleiters. Und das ist halt sehr, sehr schwierig, denn ich würde den Leuten

[45:32] gerne sagen, was sie machen sollen. Ich kann es aber nicht, weil ich nicht der Chef bin. Deswegen

[45:36] muss ich ganz viel über Kommunikation lösen, nett und freundlich sein, fragen, trotzdem aber auch

[45:41] bestimmt sagen, so jetzt mach mal fertig, wir müssen vorankommen. Also das ist eine besondere

[45:45] Herausforderung eines Projektleiters, außerhalb dieser Hierarchie des Unternehmens trotzdem solche

[45:50] Weisungen zu geben. Das ist nicht einfach. Dann Projektcontrolling macht der Leiter auch,

[45:54] muss natürlich gucken, haben wir es eingehalten, sind wir noch im Budget, haben wir mehr ausgegeben

[45:57] als geplant oder vielleicht weniger. Das sind alles Dinge, die laufend im Projekt geprüft werden

[46:01] müssen. Dann nicht zu vergessen, Dokumentation, zum Beispiel Protokolle von Besprechungen,

[46:06] Anforderungsänderungen irgendwo schriftlich festhalten, sich irgendwas gegenzeichnen lassen,

[46:11] Pflichtenheft oder sowas. Das ist auch eine ganz wichtige Aufgabe. Aufwandsschätzung, natürlich

[46:16] wichtig, wenn wir wissen wollen, ob wir noch fertig werden oder nicht. Verzögert sich das Projekt,

[46:19] dafür müssen wir wissen, wie lange brauchen wir überhaupt noch und das muss irgendwer schätzen.

[46:22] Das macht meistens auch der Projektleiter, zumindest mit oder er betreut das oder fasst

[46:26] das zusammen. Dann ganz wichtige Aufgabe, die Ergebnisse auch bei dem sogenannten Lenkungsausschuss.

[46:31] Bei uns heißt das zum Beispiel der PLA, Projektlenkungsausschuss, gibt es für alle

[46:36] wichtigen Projekte und da sitzt dann zum Beispiel der Auftraggeber drin, aber auch der Chef,

[46:41] der da mal drauf guckt, Kunden. Das kann man beliebig zusammensetzen, wird dann zum Beispiel

[46:45] auch durch die einzelnen Vorgehensmodelle wie PRINCE2 definiert, wer wo zu sitzen hat und da

[46:50] wird dann entschieden zum Beispiel, ob das Projekt verlängert werden soll, ob mehr Geld bewilligt

[46:54] wird und ob bestimmte Funktionen rausgenommen werden, weil sie zu umfangreich sind oder was

[46:58] auch immer. Immer wenn etwas entschieden werden muss, macht das der Lenkungsausschuss, dafür muss

[47:02] aber informiert werden, was überhaupt zu entscheiden ist und das ist dann die Aufgabe des Projektleiters.

[47:06] Also ganz blöd gesagt, Präsentationen halten. Wo stehen wir? Wie ist das Projekt? Rot, Grün, Gelb?

[47:12] So nach dem Motto. Geht es noch weiter? Sind wir im Plan oder nicht? Also wichtige Aufgabe hier,

[47:16] Kommunikation, in diesem Fall Präsentation der Ergebnisse beim Ausschuss. Aber auch sowas wie

[47:22] Konflikte eskalieren, das wäre auch im Lenkungsausschuss korrekt aufgehoben, wenn wir irgendwie zwei

[47:27] konkurrierende Meinungen haben. Ich will das mit Java machen. Nein, das muss aber mit C-Sharp

[47:30] gemacht werden. Da muss vielleicht irgendwo entschieden werden, wie wir diesen Konflikt

[47:34] beheben und das sollte dann der Projektleiter mitnehmen in den Lenkungsausschuss zum Beispiel.

[47:37] Und zum Schluss, wenn das Ding fertig ist, Projektabschlussbericht erstellen, wäre vielleicht

[47:42] auch ganz nett. Einfach mal zusammenfassen, was haben wir erreicht? Wie ist dann tatsächlich das

[47:45] Budget ausgefallen? Wann waren wir fertig? Was waren die Probleme? Lesson learned, was kann man

[47:50] alles daraus ziehen? Das macht der Projektleiter auch, geht in die Richtung wie eben Dokumentation.

[47:55] So, das kann man jetzt für jeden der genannten Bereiche der Rollen im Projekt machen. Ich habe

[48:01] jetzt mal auf den Projektleiter bezogen. Du kannst dir auch die anderen Rollen im Projekt

[48:05] angucken und dann auch solche Aufgaben definieren. Aber Projektleiter ist am wahrscheinlichsten,

[48:10] dass das mal abgefragt wird. So, dann wäre es das zu dem Unterpunkt. Dann kommen wir zu 1c.

[48:16] Zeitplan und Reihenfolge der Arbeitsschritte für den eigenen Arbeitsbereich festlegen. Gut,

[48:22] hier wird es etwas konkreter. Definieren und festlegen von Arbeitspaketen und Abhängigkeiten.

[48:26] Erleichterung der Planung und der Fortschrittskontrolle durch Aufteilung des Arbeits-

[48:30] beziehungsweise Projektverlaufs in überprüfbare Etappen mit Zwischenzielen. Ha, unsere Meilensteine

[48:35] von eben. Umsetzung der Arbeitspakete in konkrete Handlungen und Messen anhand von

[48:39] Prüfkriterien und Ableiten einer Prognose für den weiteren Fortschritt beziehungsweise den

[48:45] Endtermin. Also gucken, sind wir noch im Plan, werden wir rechtzeitig fertig. Das würde ich

[48:49] jetzt ganz gerne konkretisieren, diese allgemeinen Punkte, durch drei Unterpunkte und zwar ein

[48:54] sogenanntes Ticketsystem, ein Netzplan und ein Gantt-Diagramm. Ticketsystem ist so ein Ding,

[48:59] das hast du vielleicht sogar in deinem Unternehmen schon selber im Einsatz. Du kriegst vielleicht

[49:02] sogar deine Aufgaben darüber zugeteilt. Was ist das für ein Ding? Das ist meist eine Online-Anwendung,

[49:07] eine Web-Anwendung, wo halt Tickets, ob man sie jetzt Issues oder Aufgaben oder Tasks oder was

[49:12] auch immer nennt, in den meisten Fällen halt eben Tickets, zugewiesen bekommt, wo halt

[49:16] Aufgabenbeschreibungen drinstehen. Das heißt, da steht jetzt drin, hier, wir brauchen eine neue

[49:19] Datenmarke mit diesen drei Tabellen und diesen Spalten, so ganz konkret als technisches Ticket.

[49:23] Und in diesem Ticketsystem kann ich diese Aufgaben jetzt verwalten. Ich kann sie priorisieren. Ich

[49:28] kann sie Leuten zuweisen. Ich kann gucken, wie der Fortschritt ist. Das heißt, man kann vielleicht

[49:32] sogar noch eine Arbeitszeiterfassung da dranhängen und so weiter. Und so ein Ticketsystem ist deswegen

[49:36] sehr wichtig, weil es genau diese Aufgaben übernimmt. Ich kann die Aufgaben im Projekt

[49:40] verteilen. Ich kann die Beteiligten koordinieren. Ich kann zum Beispiel einen Workflow definieren,

[49:45] nachdem das Ticket bei der Datenbankabteilung war, muss es in die Entwicklungsabteilung und

[49:49] danach in die Testabteilung. Also auch solche Sachen kann ich da festlegen. Ich habe natürlich

[49:53] eine Bearbeitungshistorie. Leute können Kommentare an die Tickets schreiben. Ich habe das und das

[49:58] gemacht. Das Problem ist aufgetreten. Für die Zukunft merken wir uns. Und so weiter. Das ist

[50:03] auch gleich ein wichtiger weiterer Faktor, nämlich die Dokumentation. Kann ich in so einem Ticketsystem

[50:08] auch machen. Ich kann genau als Entwickler zum Beispiel festlegen, wann habe ich was gemacht und

[50:12] warum. Welche Entscheidung habe ich getroffen. Und dann kann ich später das Ticket wieder reinschauen

[50:16] und kann mir das nochmal durchlesen. Und was ich auch machen kann für das Projekt Controlling,

[50:20] natürlich wichtig, Auswertungen. Wie viele Tickets sind noch offen? Wie ist die Gesamtschätzung der

[50:25] Tickets? Wie viele Stunden, wie viele Tage brauchen wir noch, bis wir fertig sind? Wer hat wie viele

[50:29] Tickets bearbeitet und wer hat das vielleicht nicht gemacht? Wobei, das darf man nicht auswerten. Das

[50:34] wäre eine Überwachung der Mitarbeiter. Aber man könnte das ja auswerten auf einer etwas anonymisierten

[50:39] Form. So was wie, wir haben noch 27 Tickets offen. In der letzten Iteration haben wir 23 davon

[50:44] bearbeitet, aber 14 sind immer noch offen. Oder ich weiß nicht. Solche Zahlen kann natürlich auch

[50:48] gut aus so einem technischen System abbleiben. Das wären jetzt so die Aufgaben und Vorteile des

[50:54] Ticketsystems. Könnte ich mir auch gut als Prüfungsfrage vorstellen. Und dann haben wir noch

[50:59] zwei konkrete Visualisierungstechniken, um Projektabläufe darzustellen. Und das sind der

[51:03] Netzplan und das Gantt-Chart oder das Gantt-Diagramm. Netzplan ist etwas, was so gut wie in jeder Prüfung

[51:10] irgendwie dran kam, die ich in den letzten Jahren gesehen habe, weil man das so schön zeichnen kann.

[51:14] Wenn du das jetzt gerade nicht vor Augen hast, da sind so kleine Rechtecke, wo die Aufgaben drin

[51:18] stehen. Und dann gibt es da den sogenannten frühesten und spätesten Anfangs- und Endezeitpunkt,

[51:23] einen Gesamtpuffer und einen freien Puffer. Wenn dir das was sagt oder du das schon mal

[51:28] irgendwo gesehen hast, dann weißt du jetzt, was der Netzplan ist. Und das Ding würde ich mir rauf

[51:32] und runter angucken, weil das ist halt so eine schöne Prüfungsaufgabe. Da kann man vorgefertigte

[51:37] Netzpläne bekommen, die man ausfüllen muss oder man muss selber einen erstellen oder man muss den

[51:41] kritischen Pfad finden oder oder oder. Es gibt so viele schöne schriftliche Aufgaben und das kann

[51:45] ich jetzt hier auch im Podcast nicht im Detail erklären, wie man den zeichnet. Das musst du dir

[51:49] einfach angucken. Schau dir mal ein paar Aufgaben an oder suche nach Netzplan und da findest du

[51:53] Riesenhaufen an Möglichkeiten, die du selber üben kannst. Auch in der Literatur, die ich schon für

[51:58] Prüfungsvorbereitungen empfohlen habe, sind auch ganz viele Aufgaben zu Netzplänen drin. Also von

[52:02] daher, das Ding musst du dir angucken. Und was man da jetzt eigentlich immer wissen muss, ist,

[52:06] wie der aufgebaut ist. Du hast deine Aufgaben, die du runterbrichst in eine zeitliche Abhängigkeit.

[52:12] Das heißt, du sagst, welche Aufgabe muss nach welcher anderen stattfinden, weil die darauf

[52:17] aufbaut. Mein Beispiel von eben, Oberflächen kann ich erst bauen, wenn die Datenbank steht,

[52:21] als Beispiel. Ich kann aber auch Sachen parallelisieren und im Netzplan kann ich

[52:26] jetzt vor allem diese ganzen zeitlichen Sachen eintragen. Also wann ist der früheste,

[52:30] späteste Anfangszeitpunkt? Wann kann ich frühestens damit starten oder eben spätestens?

[52:34] Und wann ist das Ding zu Ende, frühestens oder spätestens? Und daraus berechnen kann ich dann

[52:38] so etwas wie einen Puffer, Gesamtpuffer und freien Puffer. Auch das hier führt im Detail

[52:42] jetzt zu weit. Das kannst du dir besser auf so einem Netzplan mal angucken. Es lässt sich ziemlich

[52:46] einfach ausrechnen dann die einzelnen Fälle. Du musst es einfach ein paar mal machen und dann

[52:50] kriegst du es sicherlich hin. Und dann kann man an diesem Netzplan hervorragend den kritischen

[52:54] Pfad sehen. Du musst dir nämlich im Prinzip nur den Pfad durch den Netzplan angucken,

[52:57] wo der Puffer null ist. Das war ja die Definition des kritischen Pfads. Und dann zeichnest du den

[53:01] ein und bist fertig. Also das ist ein super Prüfungsding. Deswegen wird das auch immer

[53:06] wieder abgefragt. Von daher angucken, machen, machen, machen. Das wäre meine zentrale Empfehlung

[53:12] dazu. Und dann haben wir noch das Gant-Diagramm. Das ist eine andere Form der Visualisierung für

[53:17] Projektabläufe. Wenn du da jetzt nichts vor Augen hast, das ist im Prinzip das Ding,

[53:20] was aus Microsoft Project rauspurzelt. Das ist meistens auch farblich gestaltet. Der

[53:25] Netzplan ist eher so schwarz-weiß. Da habe ich ja so ein paar Kästen mit ein paar Pfeilen

[53:28] dazwischen. Und ein Gant-Diagramm ist jetzt so aufgebaut im Prinzip wie eine Art Balkendiagramm.

[53:33] Das geht üblicherweise von oben nach unten. Und ich habe hier auch einen Zeitstrahl. Und auf diesem

[53:40] Zeitstrahl werden jetzt meine Arbeitspakete hintereinander angeordnet. Beim Netzplan habe

[53:45] ich zwar auch eine zeitliche Komponente, aber da steckt jetzt weniger sowas drin wie am 31. März

[53:50] sind wir fertig, sondern steckt halt sowas wie nach 57 Tagen sind wir fertig. Da sind also keine

[53:55] Zuordnung zu einem Kalender drin, sondern einfach so Dauern in Tagen zum Beispiel. Und beim Gant-Diagramm

[54:01] kann man das aber auch hervorragend eben auf einen Kalender legen. Das heißt, ich sehe auch,

[54:04] wann an welchem Tag bin ich wirklich fertig und nicht nur nach wie vielen Tagen. Beispiel,

[54:10] ich will das Ding vor Weihnachten eingeführt haben. Dann kann ich im Gant-Diagramm sehen,

[54:14] am 13.12. sind wir fertig. Das ist ja super. Beim Netzplan würde ich das nicht so explizit sehen,

[54:19] das müsste ich mir dann ausrechnen. Und das Gant-Diagramm ist jetzt einfach eine andere

[54:23] Form der Darstellung. Auch hier kann ich parallele Aufgaben zeigen, indem ich die einfach untereinander

[54:28] schreibe. Ich kann aber auch Sachen hintereinander, also eine Abhängigkeit zeigen, indem ich noch so

[54:32] kleine Pfeile da reinmale und dann zu sagen, die Aufgabe B setzt aber voraus, dass Aufgabe A fertig

[54:37] ist und so weiter. Das kann ich also genauso machen wie im Netzplan. Es ist einfach nur eine

[54:41] andere Darstellungsweise. Und je nachdem, ob ich jetzt viele oder wenige Aufgaben habe,

[54:44] eignet sich das Gant-Diagramm oder Netzplan besser oder schlechter. Grundsätzlich kann ich mit beiden

[54:49] ein komplettes Projekt im Ablauf visualisieren und du solltest auch beide beherrschen. Auch ein

[54:54] Gant-Diagramm kann man mal zeichnen müssen, auch in so einer Prüfung. Und man wird es auch in der

[54:58] Praxis relativ häufig sehen, weil gerade so für so einen Projektlenkungsausschuss wird gerne mal

[55:03] ein Gant-Diagramm erstellt, weil dieser Netzplan dann auch zu detailliert ist. Ob ich hier noch

[55:07] einen Tag Puffer habe oder nicht, das wollen die da gar nicht sehen, sondern die wollen im Prinzip

[55:10] am Ende ja sehen, haben wir das Ding vor Weihnachten fertig oder nicht. Und das kann man

[55:14] halt bisher im Gant-Diagramm sehen. Deswegen wird das meistens für solche Präsentationen beim

[55:18] Lenkungsausschuss erstellt. Alles meistens. Es kann natürlich auch Ausnahmen geben. Vielleicht

[55:23] wollen die auch mal einen Netzplan sehen. Ich kann jetzt nur aus der Erfahrung berichten,

[55:26] was in der Praxis häufig eingesetzt wird. Kann aber auch anders sein. Wie auch immer,

[55:31] du musst eh beide kennen. Also guck dir die Dinger an und das kann man jetzt hier auf der

[55:35] Audiospule nicht mehr gut machen. Deswegen such dir Aufgaben, zeichne mal selber diese

[55:39] Diagramme, verstehe die vernünftig und sei auch in der Lage, die selber zu erstellen. Das ist wichtig.

[55:45] So, wenn ich mal auf die Uhr gucke, glaube ich, schaffe ich heute nicht mehr alles. Überraschung,

[55:49] aber einen Punkt mache ich noch. Passt noch ganz gut dafür, weil wir noch ein Artefakt mit drin

[55:53] haben. Und zwar ist das Unterpunkt 1d. Termine planen und abstimmen sowie Terminüberwachung

[55:59] durchführen. Da steht jetzt in der Handreichung sowas wie verschiedene Projektmanagementsysteme

[56:03] kennen und einsetzen. Die haben wir schon kennengelernt. Erstellung von Projektstrukturplänen

[56:09] zur Gliederung von Projekten in Planung kontrollierbare Elemente. Projektstrukturplan,

[56:13] gehen wir kurz auf ein. Dann vollständige Erfassung aller relevanten Tätigkeiten eines

[56:17] Projekts im Top-Down, Bottom-Up oder Jo-Jo-Ansatz und Visualisierung. Zum Beispiel Netzplan-Technik,

[56:25] Scrum-Board, Kanban-Board, Gantt-Diagramme. So, da haben wir jetzt auch schon einiges zu

[56:28] gemacht. Deswegen mache ich nicht mehr alles. Meine Ergänzungen zu diesem Unterpunkt wären

[56:32] Projektstrukturplan und Kanban-Board. Die anderen Sachen hatten wir gerade schon. Projektstrukturplan

[56:37] ist quasi die statische Sicht auf mein Projekt. Während ich beim Netzplan und beim Gantt-Diagramm

[56:43] ja wirklich eine Reihenfolge sehe, also auch eine zeitliche Sicht, wie läuft das Projekt nacheinander

[56:48] ab, sehe ich im Projektstrukturplan nur die statische Struktur, das heißt, wie es grundsätzlich

[56:54] aufgeteilt ist. Das war das Beispiel. Ich habe oben mein Projekt und mache jetzt, wenn ich einen

[56:59] Top-Down-Ansatz habe, sage ich, ich möchte die Buchhaltungssoftware entwickeln. Und jetzt breche

[57:03] ich das runter auf Teile und jeden dieser Teile breche ich wieder runter und noch mal runter,

[57:08] bis ich irgendwann ganz unten angekommen bin. Das wäre der Top-Down-Ansatz oder auch deduktives

[57:13] Verfahren genannt. Wenn ich das genau umgekehrt mache, sowas wie, ich müsste eine Datenbank

[57:18] aufsetzen, ich brauche eine Oberfläche, ich muss hier noch einen Algorithmus entwickeln und daraus

[57:21] setze ich dann quasi nach oben hin abstraktere Arbeitspakete zusammen, dann ist das das Bottom-Up-Verfahren

[57:28] oder das induktive Verfahren. Das Endergebnis ist in beiden Fällen gleich. Ich habe eine

[57:34] hierarchische Darstellung meines Projekts in Form von Teilaufgaben, die wieder runtergebrochen werden.

[57:39] Nur wie ich da hinkomme, entweder zeichne ich es von oben nach unten oder von unten nach oben.

[57:43] Und es gibt noch eine Kombination aus beiden, nämlich das Jo-Jo-Verfahren oder auch Gegenstromverfahren

[57:49] auf Deutsch. Sehr schön. Das heißt, so eine Mischung aus beiden. Ich weiß vielleicht,

[57:54] dass ich ein paar kleine Aufgaben erledigen muss, die ich dann zusammenfasse zu einer großen. Ich

[57:58] weiß aber auch, dass ich noch was ganz Neues machen muss, wo ich noch gar nicht weiß, aus

[58:01] welchen Teilaufgaben die besteht. Das heißt, das eine mache ich vielleicht von unten nach oben,

[58:04] während ich das andere von oben nach unten runterbreche. So kann ich auch mit einem Mischverfahren

[58:08] quasi zu einem Projektstrukturplan kommen. Und wenn du dir das vorstellen willst, es ist so

[58:12] ein bisschen wie ein Organigramm. Das zeigt ja eine Hierarchie. Ein Organigramm bricht ja auch

[58:17] zum Beispiel Vorstand drunter, dann kommt die erweiterte Geschäftsführung, dann kommen

[58:21] Abteilungsleiter, darunter kommen dann Teamleiter und darunter kommen dann die Mitarbeiter. Auch

[58:25] eine Form von Hierarchie. Und genau so sieht auch ein Projektstrukturplan aus. Einfach nur

[58:30] von der visuellen Darstellung. Genau. Und das Ding soll halt eben das Gesamtprojekt in Teilschritte

[58:36] zergliedern. Aber es sagt halt eben noch nicht aus, in welcher Reihenfolge und wann die gemacht

[58:40] werden müssen, sondern nur, dass sie gemacht werden müssen. Dementsprechend auch nur die

[58:44] statische Sicht. Gut. Auch den kann man zeichnen. Müssen habe ich auch schon mal in einer Prüfung

[58:50] gesehen. Hier sind folgende Projektteilschritte. Zeichne die mal in dem Projektstrukturplan ein.

[58:55] Da muss man die da halt eingliedern quasi. Es ist ein sehr einfaches Verfahren. Das sind im

[59:00] Prinzip Rechtecke, wo ich ein bisschen Namen reinschreibe. Und dann gibt es da Pfeile dran

[59:03] und noch nicht mal Pfeile, Striche nur. Und dann war es das schon. Also das kann man sehr

[59:06] einfach machen. Ist, glaube ich, auch gut zu verstehen. Guck dir mal ein paar visuelle

[59:10] Beispiele an. Das kann man jetzt hier auf der Audioschule wieder schlecht darstellen. Aber

[59:13] das sollte also im Vergleich mit dem Netzplan und mit dem Gantt-Chart, glaube ich, noch einfacher

[59:17] darzustellen sein.

[59:19] Ja, letzter Punkt für diesen Unterpunkt wäre noch das Kanban-Board. Über Scrum, wie gesagt,

[59:24] wollte ich nicht so viel erzählen. Guck, hör dir einfach die Podcast-Episode an. Aber Kanban,

[59:28] das sehe ich halt auch in den praktischen Prüfungen ganz am Ende bei den Projektarbeiten,

[59:32] dass viele Leute mit Kanban arbeiten, das aber eigentlich nicht richtig einsetzen. Und wenn wir

[59:36] schon mal Visualisierungsverfahren sind, das Kanban-Board, das ist ja im Prinzip einfach eine

[59:41] spaltenorientierte Darstellung, wo ich von links nach rechts meine Aufgaben, zum Beispiel aus

[59:46] meinem Ticketsystem, durch den Prozess gebe. Simpelstes Kanban-Board wäre sowas wie To-Do,

[59:52] Doing, Done. Was muss ich noch machen? Was mache ich gerade? Was ist fertig? Das ist also

[59:57] sehr simpler Workflow. Das ist so das absolute Minimum. In anderen normalen Projekten wäre das

[1:00:02] wahrscheinlich ein bisschen größer, sowas wie, vielleicht sind das sogar die Wasserfall-Phasen,

[1:00:08] Entschuldigung, wie Analyse, Entwurf, Implementierung, Test. Also bei der Softwareentwicklung wäre mindestens

[1:00:14] eine Spalte für Test ganz sinnvoll. Ich bin fertig mit der Implementierung, dann schubse ich das

[1:00:18] Ding rüber in die Testabteilung, die gucken sich das an. So und wie dieser Workflow gestaltet ist,

[1:00:22] das kommt auf das Projekt an. Das kann man auch nicht allgemein vorgeben, das muss wirklich jedes

[1:00:27] Projekt für sich selber definieren. Was aber ganz wichtig ist an diesem Board ist, das soll die

[1:00:31] Funktionsweise von Kanban darstellen. Denn bei Kanban geht es nicht darum, dass Leute Aufgaben

[1:00:36] zugeteilt bekommen, sondern dass sie sich selber Aufgaben nehmen. Denn bei Kanban habe ich ein

[1:00:41] Pull-Prinzip und kein Push-Prinzip. Und deswegen ist es auch so wichtig, dass ich diese Spalten

[1:00:46] sauber modelliere und dass sie eine Überschrift haben, und zwar das VIP-Limit, W-I-P, für Work

[1:00:53] in Progress. Denn was ein ganz ganz wichtiger, ein ganz wichtiges Ziel von Kanban ist, Flaschenhälse

[1:01:00] zu erkennen. Wenn ich jetzt zum Beispiel wie gerade zwei Spalten habe, Implementierung und Test,

[1:01:05] und ich sehe in der Implementierung habe ich zehn Tickets, im Test aber nur eins, dann merke ich

[1:01:10] da habe ich ja ein Ungleichgewicht. Das könnte jetzt sein, dass unsere Entwickler überfordert

[1:01:15] sind, dass sie viel zu viel zu tun haben für zu wenig Leute oder sonst irgendwas. Und das will

[1:01:20] Kanban visualisieren. Das ist Ziel dieses Prozesses. Ich möchte Flaschenhälse erkennen, damit ich dann

[1:01:24] etwas dagegen tun kann. Zum Beispiel könnte ich sagen, ich habe zu wenig Entwickler, ich brauche

[1:01:28] noch einen zweiten. So, ganz simpel gesagt. Und deswegen muss jede Spalte so ein VIP-Limit haben.

[1:01:34] Das ist eine Zahl, die kennzeichnet, wie viele Aufgaben sich maximal in dieser Spalte befinden

[1:01:40] dürfen. Und wenn das VIP-Level zwei ist, weil jetzt mal ganz einfach gesagt, weil ich zwei Entwickler

[1:01:45] habe, ich habe aber drei Tickets in der Spalte. Was bedeutet das jetzt? Das bedeutet, dass mindestens

[1:01:50] ein Entwickler an zwei Aufgaben gleichzeitig arbeiten muss, weil sonst könnten da keine drei

[1:01:55] Tickets drin liegen. Und das würde mir jetzt aufzeigen, dass das vielleicht irgendwie nicht

[1:01:59] ganz so optimal ist. Aber wenn er jeden Tag immer zwischen zwei Aufgaben hin und her springen muss,

[1:02:03] dann macht er vielleicht keine von beiden richtig. Beide dauern insgesamt länger, Qualität sinkt,

[1:02:07] wie auch immer. Wichtig ist, dass ich jetzt erst mal sehe, dass ich zu viele Tickets in dieser

[1:02:11] Spalte habe. Und jetzt muss ich tätig werden, etwas tun. Und bei ganz vielen Camemberts, die

[1:02:16] ich dann sehe, fehlt dieses VIP-Limit. Und das ist nicht gut, weil dann ist eigentlich der Kern

[1:02:23] des ganzen Prozesses nicht eingehalten. Und wenn wir jetzt zum zweiten Prinzip kommen, nämlich dem

[1:02:27] Pull-Prinzip, dann können wir auch sehen, wie jetzt der Prozess arbeitet. Wenn ich jetzt in

[1:02:30] meiner Entwicklungsspalte, wo das VIP-Limit zwei ist, nur ein Ticket habe, dann heißt das, da wird

[1:02:36] zu wenig gemacht. Das heißt, ein Entwickler darf jetzt hergehen und sich ein nächstes Ticket in

[1:02:39] diese Spalte ziehen. Er kann jetzt entscheiden, ich bin fertig, ich habe ein Ticket rübergegeben

[1:02:44] in den Test. Das heißt, ich habe jetzt quasi eine Lücke in der Spalte. Also gehe ich jetzt her und

[1:02:49] ziehe mir aktiv ein Ticket rüber. Ich entscheide jetzt, was als nächstes gemacht wird, um diese

[1:02:54] Spalte quasi wieder aufzufüllen. Da kommt jetzt also keiner und sagt, du musst jetzt dies und das

[1:02:59] machen. Sondern eben Pull-Prinzip. Erst wenn ich fertig bin, ziehe ich mir das nächste Ding nach.

[1:03:04] Und auch dadurch wird nochmal sehr schön so etwas wie ein Flaschenhalt sichtbar. Wenn zum Beispiel

[1:03:09] in der Testspalte jetzt nur ein Ticket liegen darf, Beispiel, weil wir nur einen Mitarbeiter

[1:03:14] haben, dann darf da erst ein Ticket wieder reinkommen, wenn die Spalte leer ist. Das heißt,

[1:03:19] erst wenn der Tester sein Ticket abgearbeitet hat, darf er sich das nächste Ticket pullen. Dafür

[1:03:24] muss er in die Entwicklungsspalte. Da kann er sich natürlich nur eins wegpullen, wenn da auch

[1:03:28] eins liegt. Aber erst wenn er das da weggepullt hat, darf auch der Entwickler wieder sein nächstes

[1:03:33] Ticket reinpullen, weil sonst würde er sein Wipplimit von zwei in der Entwicklungsspalte

[1:03:37] ja überschreiten. Und dadurch werden nochmal krass Flaschenhälse sichtbar. Denn wenn der

[1:03:41] Tester jetzt überhaupt nicht hinterherkommt und nie seine Tickets quasi frei macht, dann kommt

[1:03:46] der Entwickler nicht hinterher, weil er darf sich ja nicht ziehen, weil er noch ein Ticket liegt,

[1:03:49] das nicht getestet werden kann. Und dadurch wird sehr, sehr schnell sichtbar, wo wir in unserem

[1:03:53] Prozess Probleme haben, wo wir vielleicht aufstocken müssten oder den Prozess anders definieren müssen.

[1:03:59] Gut, das zum Thema Cam-in-Board. Auch dazu kann man sich sicherlich noch mehr angucken,

[1:04:02] auch zu den Prinzipien, zu den Vorgehensweisen. Ich habe das mal auf das Cam-in-Board reduziert.

[1:04:06] Aber Projektstrukturplan, Cam-in-Board, beide Sachen, die du dir angucken solltest, auch für

[1:04:11] die Prüfung und auch sogar für die Praxis. Da wird man sie sicherlich auch häufiger mal

[1:04:14] wiederfinden. Okay, so, jetzt habe ich jetzt schon die Stundenmarke geknackt und ich habe

[1:04:20] noch nicht mal die Hälfte der Themen durch. Das wird dann wohl eine längere Reihe werden. Heute

[1:04:25] haben wir auf jeden Fall die Unterpunkte 1a, b, c und d besprochen. Und beim nächsten Mal geht es

[1:04:29] dann weiter mit Probleme analysieren und als Aufgabe definieren sowie Lösungsalternativen

[1:04:34] entwickeln und beurteilen. Eieiei, so sehr abstrakt geht es mal wieder weiter. Ich mache

[1:04:39] für heute erst mal Schluss. Wir hören uns dann beim nächsten Mal wieder. Du siehst,

[1:04:42] es ist ganz schön viel Zeug, was du dir angucken musst. Deswegen meine Empfehlung,

[1:04:46] fang früh genug an, dich vorzubereiten. Die gilt weiterhin. Das wird noch mal bestätigt

[1:04:51] durch die Episode, mit der ich heute angefangen bin. Gut, ich wünsche dir jetzt schon mal

[1:04:55] Erfolg bei deiner Prüfung und bei der weiteren Prüfungsvorbereitung. Ich sage schon mal danke,

[1:04:59] dass du mir heute so lange dein Ohr geliehen hast. Wenn du dir die konkreten Inhalte und

[1:05:04] Themen und auch die Links zu den erwähnten Episoden, zum Beispiel zu Scrum und zum

[1:05:08] Agilen Manifest anschauen willst, dann guck einfach in die Shownotes. Die findest du wie

[1:05:12] immer unter itberufepodcast.de slash 172 für die 172. Episode, die das hier heute war. Ich hoffe,

[1:05:24] es hat dir ein bisschen Spaß gemacht und bringt dir auch ein bisschen was für die

[1:05:26] Prüfungsvorbereitung. Ich würde mich freuen, wenn wir uns wiederhören. Das ist am einfachsten,

[1:05:30] wenn du den Podcast einfach abonnierst. Ob jetzt bei Apple Podcast, bei Amazon,

[1:05:33] bei Spotify, ich bin überall. Du kannst mich einfach abonnieren und kriegst dann jederzeit

[1:05:37] die Episoden natürlich kostenfrei und zeitgerecht geliefert auf dein Handy zum Beispiel oder wo

[1:05:42] immer du das hier hörst. Als letzter Tipp. Es geht ja heute um die Prüfungsvorbereitung. Ich

[1:05:47] habe gerade für die Prüfungsvorbereitung auf Teil 2 ganz, ganz, ganz, ganz, ganz viele Tipps per

[1:05:52] E-Mail vorbereitet. Die kannst du einfach abonnieren, wenn du auf itberufepodcast.de

[1:05:56] slash Newsletter gehst. Alles komplett kostenfrei und du kriegst das genau zeitgerecht für deine

[1:06:01] Prüfungsvorbereitung dann in deinen Postfach. Wenn du darauf keine Lust mehr hast, kannst du

[1:06:05] das auch jederzeit abbestellen. Aber wenn du einmal drin bist, wird das System dich automatisch zum

[1:06:09] Beispiel ins dritte Lehrjahr hochstufen und dann starten wir die Prüfungsvorbereitung für die

[1:06:13] Abschlussprüfung. Das heißt, ich habe wirklich eine Ausbildungsbegleitung über die ganzen drei

[1:06:17] Ausbildungsjahre fertiggestellt. Die gibt es auch nicht auf der Website, sondern nur per E-Mail.

[1:06:21] Von daher melde dich gerne an, wenn du daran Interesse hast. itberufepodcast.de slash Newsletter.

[1:06:25] So, das soll es für heute sein. Ich sage nochmal vielen Dank fürs Zuhören und bis zum nächsten Mal.