Bitte wählen Sie die Bereiche, die Sie exportieren möchten:
Alle Projektmanagement SchulungenSchulung Requirements Engineering für Product Owner: Von Epics zu Akzeptanzkriterien
Schulung Requirements Engineering für Product Owner: Von Epics zu Akzeptanzkriterien
Anforderungen, die das Team versteht und der Kunde abnimmt: RE-Handwerk für die PO-Praxis
2 Tage / S6865
Neues SeminarSchulungsformen
Offene Schulung
- 2 Tage
- 5 gesicherte Termine
- Köln / Online
- 1.440,00 p. P. zzgl. MwSt.
- Dritter Mitarbeitende kostenfrei
- Learning & Networking in einem. Garantierte Durchführung ab 1 Teilnehmenden.
Präsenz Online
Inhouse-/Firmenschulung
- 2 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- 2 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Beschreibung
Product Owner schreiben jeden Tag Anforderungen - User Stories, Epics, Akzeptanzkriterien, Ticket-Beschreibungen. Aber die wenigsten haben gelernt, wie man gute Anforderungen schreibt. Die PSPO-Zertifizierung lehrt die Rolle (Backlog-Verantwortung, Stakeholder-Management, Sprint Review), RE-Seminare lehren die Methodik (Ermittlung, Dokumentation, Validierung) - aber in einer Sprache, die POs nicht sprechen (Lastenheft, Pflichtenheft, Anforderungsspezifikation).
Dieses Seminar vermittelt das RE-Handwerk für den PO-Alltag - nicht das Scrum-Framework (dafür: PSPO I, S1958), nicht die Mapping-Technik (dafür: User Story Mapping, S6298), nicht die Priorisierungsmethodik (dafür: RICE/WSJF/Kano, S6296). Wer klassisches Requirements Engineering vertiefen möchte, findet „RE Grundlagen" (S1845, 3T) und „IREB CPRE-FL" (S1952, 3T).
Dieses Seminar vermittelt das RE-Handwerk für den PO-Alltag - nicht das Scrum-Framework (dafür: PSPO I, S1958), nicht die Mapping-Technik (dafür: User Story Mapping, S6298), nicht die Priorisierungsmethodik (dafür: RICE/WSJF/Kano, S6296). Wer klassisches Requirements Engineering vertiefen möchte, findet „RE Grundlagen" (S1845, 3T) und „IREB CPRE-FL" (S1952, 3T).
Erfahren Sie mehr durch einen zusätzlichen Projektmanagement Kurs aus unserem Seminarangebot.
Schulungsziel
Jede teilnehmende Person verlässt das Seminar mit 5+ überarbeiteten User Stories (INVEST-geprüft, mit Akzeptanzkriterien und NFRs), einem zerlegten Epic (vertikal geschnitten), einer Definition of Ready für das eigene Team, einem Refinement-Canvas als Vorbereitungsvorlage und einem Prompt-Set für KI-gestützte Anforderungsarbeit.
Details
Inhalt
Tag 1: Stories schreiben, die das Team versteht
- Ziele und Erwartungen der Teilnehmenden
- Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
- 1. Warum Anforderungsqualität die wichtigste PO-Kompetenz ist
- Das teuerste Problem in Scrum-Teams: Nicht falsche Prioritäten, nicht schlechte Schätzungen - sondern unklare Anforderungen . Studien zeigen: 50 % der Nacharbeit in Sprint-Teams entsteht durch Missverständnisse zwischen PO und Team, nicht durch technische Fehler.
- Die typischen Symptome: Refinements dauern ewig (das Team versteht die Story nicht), Sprint-Ergebnisse entsprechen nicht den Erwartungen (PO meinte etwas anderes), Stakeholder lehnen im Sprint Review ab (Akzeptanzkriterien waren unklar oder unvollständig), technische Schulden entstehen (NFRs waren nicht spezifiziert).
- RE-Kernprinzipien für POs: Eindeutigkeit (eine Story, eine Interpretation), Testbarkeit (jede Story hat messbare Kriterien), Vollständigkeit (keine impliziten Annahmen), Konsistenz (keine Widersprüche im Backlog).
- Praxis-Übung: Teilnehmende bringen 3 eigene User Stories mit. Gruppe bewertet: Versteht jeder dasselbe? Könnte ein Entwickler sofort anfangen? Könnte ein Tester sofort testen?
- 2. User Stories richtig formulieren: Über das „Als... möchte ich..." hinaus
- Das Format ist nicht das Problem: „Als [Rolle] möchte ich [Funktion], damit [Nutzen]" ist ein Startpunkt, keine Lösung. Die meisten schlechten Stories haben das richtige Format, aber den falschen Inhalt.
- Die Rolle präzisieren: Nicht „Als Nutzer" (zu generisch), sondern „Als Erstbesteller, der noch kein Kundenkonto hat" - die Rolle bestimmt den Kontext und die Erwartungen.
- Die Funktion abgrenzen: Nicht „möchte ich suchen können" (zu breit), sondern „möchte ich Produkte nach Name und Kategorie filtern können" - klar, umsetzbar, testbar.
- Den Nutzen hinterfragen: „damit ich schneller finde, was ich suche" ist ein Nutzen. „damit ich das Produkt kaufen kann" ist kein Nutzen der Suchfunktion, sondern des gesamten Shops. Der Nutzen erklärt, warum diese Story Priorität hat.
- INVEST-Kriterien als Qualitäts-Check: Independent (keine Abhängigkeit zu anderen Stories), Negotiable (verhandelbar, nicht festzementiert), Valuable (liefert Wert für den Nutzer), Estimable (Team kann Aufwand schätzen), Small (passt in einen Sprint), Testable (Akzeptanzkriterien vorhanden).
- Anti-Patterns erkennen: „Als Entwickler möchte ich die Datenbank migrieren" (technische Story ohne Nutzerwert), „Als Nutzer möchte ich alles" (Epic als Story getarnt), „Als PO möchte ich diese Story im Sprint" (keine User Story).
- Praxis-Übung: Die 3 eigenen Stories aus Topic 1 mit INVEST prüfen und umformulieren. Peer-Feedback: Was hat sich verbessert? Was fehlt noch?
- 3. Epics zerlegen: Vertikaler Schnitt statt Schichten
- Das Zerlegungsproblem: Ein Epic „Online-Bezahlung" enthält hunderte Stunden Arbeit. Wie wird daraus ein Satz von Stories, die jeweils in einen Sprint passen?
- Horizontaler Schnitt (falsch): „Backend für Zahlungsverarbeitung", „Frontend für Checkout-Formular", „Datenbank-Schema für Transaktionen". Problem: keine Story liefert allein einen Nutzerwert. Am Sprint-Ende funktioniert nichts end-to-end.
- Vertikaler Schnitt (richtig): „Kunde kann mit Kreditkarte bezahlen" (dünn durch alle Schichten: UI + Backend + DB), „Kunde kann per PayPal bezahlen" (zweiter Zahlungsweg), „Kunde erhält Bestätigungs-E-Mail nach Zahlung" (Folgefunktion). Jede Story liefert sichtbaren Nutzerwert.
- 9 Zerlegungstechniken: Nach Workflow-Schritten, nach Geschäftsregeln, nach Datentypen, nach Operationen (CRUD), nach Plattform, nach Nutzerrolle, nach Komplexität (einfach zuerst), nach Performance-Level (Happy Path zuerst, Edge Cases später), nach Akzeptanzkriterien (jedes Kriterium = eine Story).
- Wann ist eine Story „small enough"? Faustregel: ein erfahrener Entwickler schätzt 1-3 Tage. Wenn das Team „13 Story Points" sagt, ist die Story zu groß. Wenn das Team nicht schätzen kann, ist die Story unklar.
- Praxis-Übung: Teilnehmende bringen ein eigenes Epic mit (oder nutzen ein Beispiel). In 20 Minuten: Epic in 5-8 vertikal geschnittene Stories zerlegen. Peer-Review: Liefert jede Story Nutzerwert? Ist jede unabhängig? Ist jede schätzbar?
- 4. Akzeptanzkriterien: Die Sprache zwischen PO, Team und Stakeholder
- Warum Akzeptanzkriterien die wichtigste Zeile im Ticket sind: Sie definieren, wann eine Story „fertig" ist. Ohne sie entscheidet jeder Entwickler selbst - und jeder entscheidet anders.
- Regelbasierte Kriterien: Einfache Wenn-Dann-Regeln: „Wenn der Warenkorb leer ist, wird der Bestell-Button deaktiviert." „Wenn die E-Mail-Adresse ungültig ist, erscheint eine Fehlermeldung unter dem Feld." Klar, testbar, unmissverständlich.
- Szenario-basierte Kriterien (Given-When-Then): Gegeben [Ausgangszustand], wenn [Aktion], dann [erwartetes Ergebnis]. „Gegeben ein eingeloggter Kunde mit Artikeln im Warenkorb, wenn er auf 'Bestellen' klickt, dann wird die Bestellung angelegt und eine Bestätigungs-E-Mail gesendet." Brücke zu BDD (Cucumber S2664, SpecFlow S4165).
- Edge Cases und Negativszenarien: Die meisten POs schreiben nur den Happy Path. Aber: Was passiert bei leerem Eingabefeld? Bei Sonderzeichen? Bei gleichzeitigem Zugriff? Bei Netzwerkabbruch? Bei fehlendem Lagerbestand? Die besten Akzeptanzkriterien decken den Happy Path UND die 3 wichtigsten Fehlerszenarien ab.
- Wie viele Kriterien pro Story? Faustregel: 3-7. Unter 3: wahrscheinlich unvollständig. Über 7: die Story ist wahrscheinlich zu groß und sollte zerlegt werden.
- KI als Akzeptanzkriterien-Generator: ChatGPT/Claude: „Formuliere 5 Akzeptanzkriterien für diese User Story, einschließlich 2 Negativszenarien." KI denkt an Edge Cases, die Menschen übersehen. Ergebnis prüfen, anpassen, übernehmen.
- Praxis-Übung: Für 3 Stories Akzeptanzkriterien formulieren - mindestens 1 Happy Path, 1 Edge Case, 1 Negativszenario pro Story. Dann: ChatGPT/Claude zusätzliche Kriterien generieren lassen. Vergleich: Was hat die KI gefunden, was der Mensch übersehen hat?
- 5. Definition of Ready: Wann ist eine Story bereit für den Sprint?
- Das Problem ohne Definition of Ready: Stories kommen unfertig ins Sprint Planning. Das Team stellt 20 Fragen, der PO kann 5 beantworten, der Sprint beginnt mit 15 offenen Punkten. Ergebnis: Nacharbeit, Missverständnisse, unfertige Increments.
- Checkliste erstellen: Was muss eine Story haben, bevor sie in den Sprint darf?
- User Story im korrekten Format (Rolle, Funktion, Nutzen)
- Mindestens 3 Akzeptanzkriterien (inkl. Negativszenario)
- Abhängigkeiten identifiziert und aufgelöst
- UX-Entwurf vorhanden (falls UI-relevant)
- Technische Fragen geklärt (API-Schnittstelle, Datenformat)
- Vom Team geschätzt (Story Points oder T-Shirt-Sizes)
- NFR-Kriterien benannt (falls relevant: Performance, Sicherheit)
- Definition of Ready vs. Definition of Done: DoR (Eingangs-Qualität: Story ist bereit) vs. DoD (Ausgangs-Qualität: Increment ist fertig). Beide zusammen bilden den Qualitätsrahmen.
- DoR nicht als Gate missbrauchen: DoR soll den Flow verbessern, nicht blockieren. Wenn eine Story 80 % der Checkliste erfüllt und die fehlenden 20 % im Refinement klärbar sind, darf sie trotzdem in den Sprint. Pragmatismus schlägt Bürokratie.
- Praxis-Übung: Teilnehmende erstellen eine Definition of Ready für ihr eigenes Team - 7-10 Kriterien. Peer-Feedback: Zu streng? Zu locker? Passt sie zum Team-Kontext?
- 6. Nicht-funktionale Anforderungen im Backlog sichtbar machen
- Das NFR-Problem im agilen Kontext: NFRs haben keinen natürlichen Platz im Product Backlog. „Das System soll performant sein" ist keine User Story. Aber wenn Performance nicht spezifiziert wird, wird sie auch nicht gebaut - und das fällt erst in Produktion auf.
- Drei Patterns für NFRs im Backlog:
- Als Akzeptanzkriterium: „Diese Story ist nur Done, wenn die API-Antwortzeit unter 200ms liegt (gemessen mit k6 unter 500 concurrent Users)." -> NFR wird mit der funktionalen Story umgesetzt und getestet.
- Als eigenständige Story: „Als Operations-Team möchte ich, dass der Service bei Ausfall einer Datenbankinstanz automatisch auf das Replikat umschaltet, damit die Verfügbarkeit 99,9 % beträgt." -> Für große NFR-Initiativen (Failover einbauen, Caching einführen).
- Als Definition-of-Done-Kriterium: „Jede Story, die eine API berührt, muss einen Performance-Test beinhalten." -> NFR wird global erzwungen, nicht pro Story.
- Die 5 NFRs, die jeder PO kennen muss: Performance (wie schnell?), Verfügbarkeit (wie oft erreichbar?), Sicherheit (wer darf was?), Skalierbarkeit (wie viele Nutzer?), Wartbarkeit (wie schnell änderbar?). Brücke zu „Nicht-funktionale Anforderungen" (NEU, 2T) für tiefere Methodik.
- Praxis-Übung: 3 eigene Stories um NFR-Akzeptanzkriterien erweitern. Für das eigene Produkt die 3 wichtigsten NFRs identifizieren und als Backlog Items oder DoD-Kriterien formulieren.
- 7. Refinement-Vorbereitung: Der PO als Anforderungs-Profi
- Warum Refinements scheitern: PO kommt unvorbereitet (Story-Text ohne Kontext), Team fragt „Was genau meinst du?" (Story ist vage), Diskussionen über Lösungen statt Anforderungen (Team designt statt versteht), Ergebnis: 2 Stunden Refinement, 1 Story geschafft.
- Refinement-Vorbereitung in 3 Schritten:
- Kontext liefern: Warum brauchen wir diese Story? Welches Stakeholder-Problem löst sie? Welche Daten/Erkenntnisse stützen die Entscheidung?
- Entscheidungen vorwegnehmen: Welche Fragen wird das Team stellen? Antworten vorbereiten. Welche Optionen gibt es? Empfehlung formulieren.
- Visuell unterstützen: Wireframes, Mockups, Flussdiagramme, Beispieldaten - ein Bild sagt mehr als 500 Worte Ticket-Text.
- Das Refinement-Canvas: Einseitige Vorlage pro Story: Kontext (warum?), User Story (was?), Akzeptanzkriterien (wann fertig?), Abhängigkeiten (was noch?), Offene Fragen (was klären?), Risiken (was könnte schiefgehen?).
- KI-gestützte Vorbereitung: ChatGPT/Claude: „Ich habe diese User Story. Welche Fragen wird mein Entwicklungsteam wahrscheinlich stellen? Welche Edge Cases habe ich übersehen?" -> Vorbereitung in 10 Minuten statt 60.
- Praxis-Übung: Teilnehmende bereiten ein Refinement für 2 eigene Stories vor - mit Refinement-Canvas, Akzeptanzkriterien, vorbereiteten Antworten auf erwartete Teamfragen. Rollenspiel: ein Partner spielt das Entwicklungsteam und stellt kritische Fragen.
- 8. Backlog-Hygiene: Anforderungsqualität dauerhaft sichern
- Backlog-Verschmutzung erkennen: 200 Items im Backlog, davon 150 seit 6 Monaten nicht angefasst. Doppelte Stories, widersprüchliche Anforderungen, veraltete Epics, „Zombie-Stories" (niemand will sie, niemand löscht sie).
- Regelmäßige Backlog-Reviews: Quartalsweise: Alles unter der Sprint-Grenze prüfen - ist es noch relevant? Hat sich der Kontext geändert? Kann es gestrichen werden? Faustregel: Wenn eine Story seit 3 Monaten nicht priorisiert wurde, wird sie gelöscht. Wenn sie wichtig ist, kommt sie zurück.
- Konsistenz-Prüfung: Widersprechen sich Stories im Backlog? Gibt es doppelte Anforderungen in verschiedener Formulierung? KI als Helfer: „Prüfe diese 20 Stories auf Überschneidungen und Widersprüche."
- Backlog als lebende Dokumentation: Das Backlog ist keine Feature-Liste, sondern die aktuelle Produkt-Roadmap in Story-Granularität. Es muss den aktuellen Stand der Erkenntnis widerspiegeln - nicht die Ideen von vor 6 Monaten.
- 9. Praxis-Workshop: „Mein Backlog - überarbeitet"
- Phase 1 - Story-Qualität verbessern (25 Min):
- 5 eigene Stories überarbeiten: INVEST-Check, Rolle präzisieren, Funktion abgrenzen, Nutzen schärfen.
- Für jede Story 3-5 Akzeptanzkriterien formulieren (inkl. Edge Case).
- KI-Gegenprüfung: ChatGPT/Claude identifiziert fehlende Kriterien.
- Phase 2 - Epic zerlegen (20 Min):
- Ein eigenes Epic in 5-8 vertikal geschnittene Stories zerlegen.
- Peer-Review: Liefert jede Story Nutzerwert? Passt jede in einen Sprint?
- Phase 3 - NFRs und Definition of Ready (15 Min):
- 3 Stories um NFR-Akzeptanzkriterien erweitern.
- Definition of Ready für das eigene Team finalisieren.
Zielgruppe & Vorkenntnisse
- Product Owner: Die bessere User Stories, präzisere Akzeptanzkriterien und klarere Epics schreiben möchten - ohne ein dreijähriges RE-Studium.
- Proxy Product Owner und Business-Analysten: Die zwischen Fachbereich und Entwicklungsteam übersetzen und Anforderungen strukturieren.
- Produktmanager: Die Feature-Anforderungen aus Kundenfeedback, Stakeholder-Wünschen und Marktanalysen in ein brauchbares Backlog überführen.
- Scrum Master: Die ihr Team bei der Verbesserung der Anforderungsqualität unterstützen und Refinements effizienter gestalten möchten.
Ihre Schulung
In Präsenz | Online |
|---|---|
| Lernmethode | |
Ausgewogene Mischung aus Theorie und praktischen Übungen auf persönlichem Schulungs-PC. | Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent. |
| Unterlagen | |
Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. | Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. |
| Arbeitsmaterialien | |
DIN A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its | |
| Teilnahmezertifikat | |
Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF. | |
Organisation
In Präsenz | Online | |
|---|---|---|
| Teilnehmendenzahl | ||
min. 1, max. 8 Personen | ||
| Garantierte Durchführung | ||
Ab 1 Teilnehmenden* | ||
| Schulungszeiten | ||
| ||
| Ort der Schulung | ||
 GFU SchulungszentrumAm Grauen Stein 27 51105 Köln-Deutz oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden. Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen. | ||
| Räumlichkeiten | ||
Helle und modern ausgestattete Räume mit perfekter Infrastruktur | Bequem aus dem Homeoffice von überall | |
| Preisvorteil | ||
Dritter Mitarbeitende nimmt kostenfrei teil. Eventuell anfallende Prüfungskosten für den dritten Teilnehmenden werden zusätzlich berechnet. Hinweis: Um den Erfolg der Schulung zu gewährleisten, sollte auch der dritte Teilnehmende die erwarteten Vorkenntnisse mitbringen. | ||
| All-Inclusive | ||
Gebäck, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch | Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu. | |
| Barrierefreiheit | ||
Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei | - | |
Buchen ohne Risiko
| Rechnungsstellung |
Erst nach dem erfolgreichen Seminar. Keine Vorkasse. |
| Stornierung |
Kostenfrei bis zum Vortag des Seminars |
| Vormerken statt buchen |
Sichern Sie sich unverbindlich Ihren Seminarplatz schon vor der Buchung - auch wenn Sie selbst nicht berechtigt sind zu buchen |
Kostenfreie Services
In Präsenz | Online |
|---|---|
|
|
Buchungsmöglichkeiten
Online oder in Präsenz teilnehmen
Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.
Gesicherte offene Termine
| Termin | Ort | Preis | ||
|---|---|---|---|---|
| 03.08.-04.08.2026 Plätze vorhanden Köln / Online 1.440,00 | Köln / Online | 1.440,00 | Buchen Vormerken | |
| 05.10.-06.10.2026 Plätze vorhanden Köln / Online 1.440,00 | Köln / Online | 1.440,00 | Buchen Vormerken | |
| 07.12.-08.12.2026 Plätze vorhanden Köln / Online 1.440,00 | Köln / Online | 1.440,00 | Buchen Vormerken | |
| 2027 | ||||
| 15.02.-16.02.2027 Plätze vorhanden Köln / Online 1.440,00 | Köln / Online | 1.440,00 | Buchen Vormerken | |
| 22.04.-23.04.2027 Plätze vorhanden Köln / Online 1.440,00 | Köln / Online | 1.440,00 | Buchen Vormerken | |
Inhouse-/Firmenschulung
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Nachbetreuung
Unterstützung nach der Schulung durch
individuelle Nachbetreuung
FAQ für Offene Schulungen
Welche Schulungsform ist ideal für mich?
- Alle folgenden Schulungsformen können auch Online als Virtual Classroom durchgeführt werden.
- Eine Offene Schulung findet zu einem festgelegten Zeitpunkt im voll ausgestatteten Schulungszentrum oder Online/Remote statt. Sie treffen auf Teilnehmende anderer Unternehmen und profitieren vom direkten Wissensaustausch.
- Eine Inhouse-/Firmen-Schulung geht auf die individuellen Bedürfnisse Ihres Unternehmens ein. Sie erhalten eine kostenfreie Beratung von Ihrem Seminarleiter und können Inhalte und Dauer auf Ihren Schulungsbedarf anpassen. Inhouse-Schulungen können Europaweit durchgeführt werden.
- Bei einer Individual-Schulung erhalten Sie eine 1-zu-1 Betreuung und bestimmen Inhalt, Zeit und Lerntempo. Der Dozent passt sich Ihren Wünschen und Bedürfnissen an.
Wie kann ich an einer Online Schulung teilnehmen?
Sie können unsere Schulungen auch als Remote Schulung im Virtual Classroom anfragen.
In drei Schritten zum Online Seminar im Virtual Classroom:
- Seminar auswählen und auf "Buchen" klicken
- Wählen Sie bei "Wie möchten Sie teilnehmen?" einfach "Online" aus.
- Formular ausfüllen und über den Button "Jetzt buchen" absenden.
Unser Kundenservice meldet sich bei Ihnen mit der Buchungsbestätigung.
Was ist ein Virtual Classroom?
Unsere Online Schulungen finden im Virtual Classroom statt. Ein Virtual Classroom bündelt mehrere Werkzeuge, wie Audio-Konferenz, Text-Chat, Interaktives Whiteboard, oder Application Sharing.
Vorteile von Virtual Classroom:
- Sie erhalten 1 zu 1 die gleiche Lernumgebung, die Sie auch vor Ort bei uns vorfinden
- Die technische Vorbereitung wird von den GFU-Technikern vorgenommen
- Sie erhalten remote Zugriff auf Ihren persönlichen Schulungs-PC im GFU-Seminarraum
- Die Virtual Classroom Lösung lässt sich auch im Browser betreiben
- Die GFU-Technik leistet wie gewohnt Soforthilfe bei Problemen
- Die Schulungsunterlagen bekommen Sie via DHL zugeschickt
- Sie sparen Reisekosten und Zeit
Welche gesicherten Termine gibt es?
- 03. Aug. - 04. Aug. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 05. Okt. - 06. Okt. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 07. Dez. - 08. Dez. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 15. Feb. - 16. Feb. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 22. Apr. - 23. Apr. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- Auch als Inhouse-Schulung, bundesweit mit Termin nach Wunsch und individuellen Inhalten
- Buchen ohne Risiko! Kostenfreie Stornierung bis zum Vortag des Seminars
Das GFU-Sorglos-Paket
Die Seminare der GFU finden in angenehmer Atmosphäre statt und sind perfekt organisiert. Profitieren Sie von dem Rundum-Service der GFU!
Shuttle-Service
Machen Sie sich keinen Kopf um die Anreise! Unser Shuttle fährt Sie. Oder Sie parken einfach auf einem extra für Sie reservierten Parkplatz.
Hotelreservierung
Hotelzimmer gesucht? Wir organisieren Ihnen eins. Ihr Vorteil: Sie sparen Zeit und Geld!
Kostenfreies Storno
Stornierung bei offenen Seminaren kostenfrei bis einen Tag vor Schulungsbeginn.
Technik-Support
Unsere Techniker sind immer zur Stelle, egal ob online oder vor Ort.