Dieses Video zeigt dir, wie du in der Komponentenbibliothek wiederverwendbare Projektvorlagen erstellst – der erste Schritt im Einzelprojekt-Lebenszyklus. Am Beispiel einer Webagentur, die WordPress-Projekte standardisieren will, lernst du den gesamten Aufbauprozess kennen.
Eine Component ist ein generischer Projektbaustein in der Bibliothek unter Administration → Project Components. Du erstellst sie einmal und importierst sie bei Bedarf in konkrete Kundenprojekte, wobei eine unabhängige Kopie entsteht. Die Struktur besteht aus Epics (große thematische Blöcke wie Design, Entwicklung, Testing), die Arbeitspakete enthalten. Jedes Arbeitspaket hat drei Säulen: eine Beschreibung (das Was), eine interne Notiz (das Wie, nur fürs Team sichtbar) und einen Minimum Effort in Stunden, der in die Kalkulation fließt.
Was die Vorlagen besonders mächtig macht, sind Fragebögen und bedingte Logik. Du kannst in jedem Arbeitspaket Fragen hinterlegen, deren Antworten den Projektumfang bestimmen. Fragetypen umfassen Person-Zuweisung, Radio Buttons, Multiple Choice und den Multiplier, der Aufwände automatisch anhand einer Mengenangabe berechnet. Über Conditions verknüpfst du Fragen mit Elementen: Ein Arbeitspaket wie "WooCommerce einrichten" erscheint nur, wenn die E-Commerce-Frage mit Ja beantwortet wird. So konfiguriert sich das Projekt anhand der Kundenanforderungen quasi von selbst.
Zusätzlich stehen Checklisten für Kundenbeiträge und Test Suites für die strukturierte Abnahme zur Verfügung – beide können ebenfalls an Bedingungen geknüpft sein. Tags werden automatisch an alle untergeordneten Elemente vererbt und erscheinen später auch auf den daraus erzeugten Tickets. Das Ergebnis ist eine vollständige, intelligente Projektvorlage, die dein Team bei jedem neuen Projekt einsetzt, ohne von vorne planen zu müssen.
Im letzten Video hast du den Lebenszyklus eines Einzelprojekts kennengelernt – von der Planung bis zur Abrechnung. Die erste Phase war: Projektvorlage entwerfen. Genau darum geht es jetzt.
Stell dir vor, dein Team macht ähnliche Projekte immer wieder. Websites, Onboardings, Migrationen. Jedes Mal von vorne planen? Das kostet Zeit und es gehen Dinge verloren.
In diesem Video zeige ich dir, wie du in der Komponentenbibliothek eine wiederverwendbare Projektvorlage baust. Mit Struktur, Fragebögen, Aufwandsschätzungen und intelligenter Logik. Wir gehen das an einem konkreten Beispiel durch: eine Webagentur, die ihre WordPress-Projekte standardisieren will.
Ich navigiere zu Administration und dann zu Project Components. Das ist die Komponentenbibliothek – die zentrale Sammlung aller wiederverwendbaren Projektvorlagen.
Eine Component ist ein generischer Projektbaustein. Nicht für einen bestimmten Kunden, sondern als Vorlage für eine Art von Projekt. Zum Beispiel: "WordPress Website-Entwicklung", "CRM Onboarding" oder "Messeauftritt vorbereiten".
Wenn du ein Kundenprojekt startest, importierst du eine Component in das Projekt. Dabei wird eine vollständige Kopie erstellt. Du kannst sie im Projekt frei anpassen, ohne dass das Original in der Bibliothek verändert wird. Einmal investieren, immer wieder einsetzen.
Wir bauen jetzt die Component "WordPress Website-Entwicklung". Ich klicke auf "Add Component" und fülle die Felder aus.
Name: "WordPress Website-Entwicklung". Beschreibung: Wofür diese Component gedacht ist. Tags: Ich vergebe "website". Tags werden automatisch an alle untergeordneten Elemente vererbt – Epics, Arbeitspakete, Checklisten, Test Suites. Wenn später Tickets erstellt werden, tragen sie diesen Tag automatisch mit. Enorm hilfreich fürs Filtern.
Interne Notiz: Hier schreibe ich Anweisungen für mein Team. Zum Beispiel: "Bitte bei jedem Website-Projekt verwenden und nach Projektende Lessons Learned dokumentieren." Interne Notizen sind nur fürs Team sichtbar – der Kunde sieht sie nie.
In der Baumansicht lege ich jetzt Epics an – die großen thematischen Blöcke meines Projekts. Ich klicke auf das Plus-Symbol und wähle "Create Epic".
Für unser Website-Projekt erstelle ich sechs Epics: Projekt-Setup und Briefing, Design und Konzept, Frontend-Entwicklung, Backend-Entwicklung und Integration, Testing und Qualitätssicherung, Go-Live und Deployment.
Jedes Epic bekommt eine Beschreibung, eine interne Notiz und eigene Tags. Die Reihenfolge passe ich per Drag and Drop an – sie soll den tatsächlichen Projektablauf widerspiegeln.
Das ist die Grundstruktur. Sechs Phasen, die jedes Website-Projekt durchläuft. Und genau die muss dein Team nicht bei jedem neuen Projekt neu erfinden.
Arbeitspakete sind die operativen Einheiten innerhalb eines Epics. Ich öffne "Projekt-Setup und Briefing" und erstelle das Arbeitspaket "Kickoff-Meeting durchführen".
Jedes Arbeitspaket hat drei Säulen.
Erstens: Beschreibung – das WAS. "Kickoff-Meeting mit dem Kunden durchführen, um Anforderungen, Ziele und Features zu klären."
Zweitens: Interne Notiz – das WIE. "Agenda erstellen, Meeting moderieren, Anforderungen dokumentieren, Protokoll versenden." Wenn jemand dieses Paket zugeteilt bekommt, weiß er sofort, wie er vorgehen muss.
Drittens: Minimum Effort – der geschätzte Aufwand in Stunden. Hier: 3 Stunden. Dieser Wert fließt in die Kalkulation und ins Angebot und dient dem Controlling.
Genauso lege ich weitere Pakete an: Anforderungsanalyse dokumentieren, Hosting-Infrastruktur vorbereiten, Projekt in Leadtime initialisieren. Jedes mit Beschreibung, interner Notiz und Aufwand.
Außerdem kann ich Checklisten anlegen – das sind To-Do-Listen, die einzeln abgehakt werden. Zum Beispiel "Kickoff-Vorbereitung" mit den Aufgaben: Agenda erstellen, Teilnehmer einladen, Meetingraum reservieren. Die Checkliste schiebe ich per Drag and Drop vor das Kickoff-Meeting.
Jetzt wird die Vorlage richtig mächtig. Ich öffne das Arbeitspaket "Kickoff-Meeting" und klicke auf "Add Question".
Jedes Website-Projekt ist anders. Manche Kunden brauchen einen Shop, andere nicht. Statt für jede Variante eine eigene Vorlage zu bauen, stellst du Fragen. Die Antworten bestimmen dann, welche Arbeitspakete relevant sind.
Erste Frage: "Wer übernimmt die Projektleitung?" Fragetyp: Person. Damit kann ich ein Teammitglied direkt zuweisen.
Nächste Frage: "Wer kümmert sich um das Hosting?" Fragetyp: Radio Button mit den Optionen "Kunde hostet selbst" und "Wir übernehmen das Hosting". Die Antwort löst später eine Bedingung aus.
Dann: "Braucht die Website E-Commerce-Funktionen?" Radio Button, Ja oder Nein. Und: "Wie viele Sprachen soll die Website haben?" mit den Optionen Einsprachig, Zweisprachig, Mehrsprachig.
Und ein besonders interessanter Fragetyp: der Multiplier. Frage: "Wie viele Personen nehmen am Kickoff teil?" Ich gebe an, dass pro Person 2 Stunden anfallen. Wenn später "5 Personen" eingetragen wird, rechnet Leadtime automatisch 10 Stunden. Der Aufwand passt sich automatisch an.
Dieses Prinzip gilt für alle Arbeitspakete: Überlege bei jedem Paket, welche Fragen den Umfang oder den Aufwand beeinflussen.
Jetzt kommt der Teil, der die Komponentenbibliothek wirklich besonders macht: Conditions.
Die Grundidee: Du verknüpfst eine Frage mit einem anderen Element. Wenn die Bedingung erfüllt ist, wird das Element sichtbar. Wenn nicht, bleibt es versteckt. Das Projekt konfiguriert sich quasi von selbst.
Erstes Beispiel: Ich erstelle im Epic "Backend-Entwicklung" das Arbeitspaket "WooCommerce einrichten" und füge eine Bedingung hinzu: Das Paket erscheint nur, wenn die E-Commerce-Frage mit "Ja" beantwortet wurde. Wird sie mit "Nein" beantwortet, bleibt es versteckt.
Zweites Beispiel: Das Arbeitspaket "WPML konfigurieren" erscheint nur bei "Zweisprachig" oder "Mehrsprachig". Hier nutze ich den Bedingungstyp "Antwort enthält" – damit kann ich mehrere Optionen auswählen.
Und nicht nur Arbeitspakete: Auch Fragen selbst können Bedingungen haben. Zum Beispiel: "Welche Shop-Features werden benötigt?" erscheint nur, wenn E-Commerce aktiviert wurde.
Mehrere Bedingungen an einem Element werden UND-verknüpft – alle müssen erfüllt sein. Conditions machen deine Vorlage von einer statischen Checkliste zu einem intelligenten System.
Neben Arbeitspaketen und Checklisten gibt es noch Test Suites – für die strukturierte Abnahme am Projektende.
Ich erstelle zum Beispiel den Test "Responsive Design" mit konkreten Testschritten: Website auf Desktop, Tablet und Smartphone prüfen. Erwartetes Ergebnis: Alle Layouts korrekt, keine Überlappungen. Der Tester kann jeden Schritt mit "Bestanden" oder "Nicht bestanden" bewerten und bei Problemen direkt ein Ticket erstellen. Auch Test Suites können Bedingungen haben.
Schauen wir uns das Ergebnis an: Unsere Component hat sechs Epics, Arbeitspakete mit Beschreibungen und Aufwänden, Fragebögen für Flexibilität, bedingte Logik für Relevanz, Checklisten für Kundenbeiträge und Test Suites für Qualitätssicherung. Eine vollständige Projektvorlage.
Kurzer Ausblick: Im nächsten Video importierst du diese Vorlage in ein Kundenprojekt. Du gehst die Fragen mit dem Kunden durch, die Struktur passt sich dynamisch an. Und wenn du Verbesserungen entdeckst, exportierst du die angepasste Component zurück in die Bibliothek. Ein lernendes System.
Die Komponentenbibliothek ist der Schlüssel zur Skalierung. Je besser deine Vorlagen, desto weniger Aufwand bei jedem neuen Projekt.
Im nächsten Video zeige ich dir den zweiten Schritt: Wie du eine Vorlage in ein echtes Kundenprojekt einsetzt – Anforderungen aufnehmen, Fragen beantworten, Produkte zuweisen und das Versionssystem nutzen.
