Zusammenarbeit mit einer Drupal-Agentur: Rollen, Verantwortlichkeiten und Governance
Die Zusammenarbeit mit einer Drupal-Agentur sollte Ihrem Team den Freiraum geben, sich auf das Geschäft zu konzentrieren, mit einem technischen Partner, auf den Sie sich verlassen können. Das gelingt leichter, wenn alle wissen, welche Entscheidungen sie selbst treffen können und wann sie jemand anderen ins Gespräch holen sollten.
Angenommen, eine neue mehrsprachige Funktion ist fertig. Die Entwickler haben sie geprüft, das Marketing hat den Launch vorbereitet, und dann taucht eine Frage auf: Hat jemand die Leistungsbedingungen für jeden Markt freigegeben? Alle haben ihren Teil erledigt, aber eine Entscheidung ist zwischen den Teams liegen geblieben.
Ein paar klare Vereinbarungen helfen, solche Pausen zu vermeiden. Genau das bedeutet Governance hier: zu wissen, wer entscheidet, wer die Arbeit erledigt und wer das Go gibt. Dieser Artikel zeigt, wie Sie diese Verantwortlichkeiten rund um die Menschen und das Know-how organisieren, die Sie bereits haben.
In diesem Artikel:
- Geben Sie Menschen Raum für Entscheidungen
- Verbinden Sie Fachwissen aus dem Business mit technischer Expertise
- Vereinbaren Sie, wer sich um welchen Teil der Arbeit kümmert
- Machen Sie Änderungen leichter besprechbar
- Verantwortung bleibt bei Menschen, wenn KI in den Workflow kommt
- Wen rufen Sie nach dem Launch an?
- Halten Sie Zugänge und Wissen erreichbar
- Achten Sie auf kleine Anzeichen von Unklarheit
- Eine Partnerschaft, auf die sich beide Teams verlassen können
Geben Sie Menschen Raum für Entscheidungen
Ein Backlog sagt, was zu tun ist. Es sagt aber nicht immer, wer eine Frage klären kann, deren Antwort nicht im Ticket steht.
Es hilft, vier Rollen zu unterscheiden: die Person, die die Richtung vorgibt, das Team, das die Arbeit erledigt, die Personen, die sie prüfen, und die Person, die das Ergebnis abnimmt. Manchmal übernimmt eine Person mehrere Rollen. Wichtig ist, dass alle Beteiligten das wissen.
Ein Satz wie „Marketing und IT geben das frei“ kann einen Entwickler zum Beispiel ratlos lassen, wen er fragen soll, wenn die beiden Teams unterschiedlicher Meinung sind. Wird eine Person benannt, die beide Sichtweisen zusammenführt, kann die Arbeit weitergehen.
Diese Person muss nicht jedes technische Detail freigeben. Vereinbaren Sie, welche Entscheidungen die Agentur innerhalb des Budgets und der technischen Rahmenbedingungen treffen kann und welche ein breiteres Gespräch brauchen. Ein interner Tech Lead kann die Hoheit über die Architektur behalten und alltägliche Umsetzungsentscheidungen der Agentur überlassen.
Ziel ist so viel Klarheit, dass Menschen ihre Arbeit erledigen können. Wenn jede kleine Änderung ein weiteres Meeting braucht, sollte die Vereinbarung wahrscheinlich vereinfacht werden.
Verbinden Sie Fachwissen aus dem Business mit technischer Expertise
Ihr Team kennt die Kunden, das Angebot und den Druck hinter dem Projekt. Die Agentur bringt eine technische Perspektive darauf mit, wie sich diese Anforderungen in eine funktionierende Drupal-Plattform übersetzen lassen. Eine gute Partnerschaft lässt Raum für beides.
Auf Unternehmensseite kann ein Product Owner oder Platform Owner die Anfragen aus Vertrieb, Marketing und Betrieb in Einklang bringen. Diese Person muss nicht jede Antwort selbst kennen, braucht aber Zugang zu den Menschen, die sie kennen, und die Befugnis, Prioritäten festzulegen.
Aufgabe der Agentur ist es, technische Entscheidungen verständlich zu machen. Das heißt: die Optionen erklären, was jede davon umfasst und was die Wartung des Ergebnisses bedeuten wird. Würde eine Anfrage unnötige Komplexität erzeugen, ist eine klare Alternative mit ihren Vor- und Nachteilen die hilfreiche Antwort.
Ihr Team wünscht sich zum Beispiel ein eigenes Feld auf jeder Länderseite. Die Agentur könnte stattdessen einen gemeinsamen Datensatz mit lokalen Varianten vorschlagen. Sie bestätigen, ob das zur Arbeitsweise des Unternehmens passt; die Agentur erklärt und setzt den vereinbarten technischen Ansatz um.
Ihre internen Entwickler decken vielleicht schon einen Teil dieser Arbeit ab. Die Aufteilung kann sich an der tatsächlichen Expertise orientieren statt an einer starren Formel „Kunde gegen Agentur“. Unser Artikel darüber, wie man ein Webentwicklungsteam für eine große Website zusammenstellt, bietet weiteren Kontext zu den beteiligten Personen.
Eine Grenze sollte klar bleiben: Fachliche Abnahme und technische Prüfung sind unterschiedliche Aufgaben. Ihr Team bestätigt, dass eine Funktion das leistet, was das Geschäft braucht. Die Agentur prüft ihre Engineering-Arbeit weiterhin gegen die vereinbarten technischen Anforderungen.
Vereinbaren Sie, wer sich um welchen Teil der Arbeit kümmert
Für den Einstieg in dieses Gespräch brauchen Sie kein kompliziertes Dokument. Eine Tabelle wie die folgende hilft beiden Teams, Fragen zu erkennen, die sonst unausgesprochen blieben.
Verstehen Sie sie als Beispiel, das Sie anpassen. Nehmen Sie Ihren Hosting-Anbieter und andere Dienstleister auf, wenn sie Verantwortlichkeiten haben, und ergänzen Sie namentliche Ansprechpartner für die wichtigen Entscheidungen.
| Bereich | Ihr Teil als Unternehmen | Der Teil der Agentur | Eine Frage, die geklärt werden sollte |
|---|---|---|---|
| Ziele und Budget | Ergebnisse erläutern und Prioritäten setzen | Optionen, Schätzungen, Abhängigkeiten und Risiken erläutern | Wer kann eine Änderung an Budget oder Umfang freigeben? |
| Architektur und Content-Modell | Geschäftsregeln und die Bedeutung der Daten bestätigen | Das vereinbarte Design empfehlen und umsetzen | Welche technischen Entscheidungen braucht die Freigabe Ihres Teams? |
| Inhalte und Übersetzungen | Die Fakten liefern und freigeben | Die vereinbarten Felder und den Publishing-Prozess bauen | Wer gibt jede Sprache oder jeden Markt frei? |
| Integrationen und Zugänge | Systemverantwortliche und zulässige Nutzungen benennen | Die vereinbarten Verbindungen umsetzen und prüfen | Wer betreut jeden externen Dienst und jedes Konto? |
| Tests und Abnahme | Bestätigen, dass das Ergebnis den fachlichen Bedarf erfüllt | Die vereinbarten technischen Anforderungen prüfen | Wie dokumentieren beide Teams, dass die Arbeit abgenommen ist? |
| Releases | Zeitpunkt und fachliche Bereitschaft abstimmen | Das Deployment im Rahmen des Umfangs vorbereiten und durchführen | Wer gibt das Go, und wer kann ein Release stoppen? |
| Wartung und Incidents | Für einen Verantwortlichen und einen Kontaktweg sorgen | Die vereinbarte Wartung und den Support leisten | Wer kümmert sich um ein Problem, auch außerhalb der normalen Abdeckung? |
| Dokumentation und Übergabe | Zugänge in der Organisation halten und eine übernehmende Person benennen | Die Arbeit dokumentieren und das vereinbarte Wissen teilen | Kann eine andere berechtigte Person die Arbeit übernehmen? |
Für einen Bereich verantwortlich zu sein heißt nicht, jede Aufgabe selbst zu erledigen. Ein Platform Owner kann sicherstellen, dass die Wartung einen Verantwortlichen hat, während ein Support-Team der Agentur die Arbeit ausführt.
Wirkt eine Zeile zu allgemein, teilen Sie sie in kleinere Entscheidungen auf. „Gemeinsame Verantwortung“ ist nur dann hilfreich, wenn beide Teams wissen, was ihr Anteil umfasst.
Machen Sie Änderungen leichter besprechbar
Ein Projekt kann sich aus guten Gründen ändern. Der Vertrieb erfährt etwas von Kunden, ein Markt braucht ein anderes Angebot, oder eine Integration hat eine Einschränkung, mit der niemand gerechnet hat. Die Partnerschaft braucht einen entspannten Weg, über die nächsten Schritte zu sprechen.
Konsequenzen erklären, bevor eine Entscheidung gefragt ist
Ein Änderungswunsch lässt sich leichter abwägen, wenn er den Grund, die Optionen und die Auswirkungen auf Umfang, Kosten und Zeitplan enthält. Ihr Team entscheidet, was am wichtigsten ist; die Agentur erklärt die Abhängigkeiten und empfiehlt einen Weg.
Angenommen, Sie brauchen einen neuen Produkt-Feed. Sind die benötigten Informationen noch nicht in Drupal gespeichert, kann die Arbeit neben dem Feed auch eine Änderung des Content-Modells umfassen. Wer das früh weiß, kann eine vernünftige Entscheidung über den Umfang treffen.
Nicht jede Klärung ist Mehraufwand, und nicht jede neue Anfrage ist bereits abgedeckt. Verweisen Sie auf den vereinbarten Umfang und halten Sie das Ergebnis fest, damit sich später kein Team auf sein Gedächtnis verlassen muss.
Hilfe bei blockierten Entscheidungen leicht machen
Liegt eine Frage außerhalb der eigenen Befugnisse, muss die Person wissen, wen sie hinzuziehen kann. Vereinbaren Sie, wer konkurrierende fachliche Prioritäten klärt, wer technische Meinungsverschiedenheiten auflöst und wer einspringt, wenn eine entscheidende Person abwesend ist.
Eine hilfreiche Nachricht erklärt die Frage, die verfügbaren Optionen und was auf eine Antwort wartet. So hat die andere Person genug Kontext, um zu antworten, ohne die ganze Diskussion rekonstruieren zu müssen.
Diese Gewohnheiten geben der Zusammenarbeit zwischen Entwicklungsteam und Kunde eine praktische Grundlage. Der Meeting-Rhythmus kann sich dann nach der Arbeit richten, statt selbst zum Ziel zu werden.
Raum für technische und fachliche Prüfungen lassen
Vereinbaren Sie, wie Erfolg aussieht, bevor die Arbeit beginnt. Unterscheiden Sie dann zwischen Umsetzung, technischen Prüfungen, fachlicher Abnahme und Veröffentlichung.
In unserem mehrsprachigen Beispiel können die Entwickler bestätigen, dass das Sprach-Routing funktioniert, während eine Marktverantwortliche die lokalen Leistungsbedingungen prüft. Beide Prüfungen sind sinnvoll; keine ersetzt die andere. Sind sie abgeschlossen, kann die vereinbarte Release-Verantwortliche das Go geben.
Verantwortung bleibt bei Menschen, wenn KI in den Workflow kommt
KI bringt weitere Entscheidungen in die Partnerschaft. Wer gibt die Quellinformationen frei? Was darf die Automatisierung tun? Wer hilft, wenn das Ergebnis falsch ist?
Es gibt zwei Gespräche zu führen. Das eine betrifft den Einsatz von Coding-Tools durch die Agentur: welche Informationen Entwickler dort eingeben dürfen und wie die gelieferte Arbeit geprüft wird. Das andere betrifft KI-Funktionen in Ihrer Plattform, etwa das Vorbereiten von Übersetzungen oder das Entwerfen von Beschreibungen.
Bei einer KI-Funktion legt Ihr Unternehmen die zulässige Nutzung seiner Informationen fest und die Aktionen, die es erlauben möchte. Die Agentur erklärt die vorgeschlagene Integration, ihre Grenzen, Abhängigkeiten und Zugriffsgrenzen. Gemeinsam vereinbaren Sie den Review-Prozess und wer die Automatisierung bei Bedarf anhalten kann.
Nehmen wir eine übersetzte Leistungsbeschreibung. Ihr Team gibt die Quellfakten frei und prüft, ob die lokale Formulierung das richtige Angebot beschreibt. Die Agentur baut den vereinbarten Prozess aus Entwurf und Review. Geht etwas schief, hat die gemeinsame Korrektur Vorrang. Zu verstehen, ob die Ursache eine falsche Quellinformation oder ein Fehler beim Publishing war, hilft, eine Wiederholung zu vermeiden.
Einen Entwurf vorbereiten und automatisch veröffentlichen sind unterschiedliche Berechtigungen. Der Schritt vom einen zum anderen braucht eine ausdrückliche Entscheidung, auch wenn die technische Änderung klein aussieht.
Dieselbe Sorgfalt gilt, wenn KI beim Schreiben von Code hilft. Die Agentur bleibt dafür verantwortlich, die gelieferte Arbeit zu reviewen und zu prüfen. Das Tool übernimmt diese Verantwortung nicht.
Wen rufen Sie nach dem Launch an?
Der Launch ist ein guter Anlass zum Feiern. Er lässt sich noch besser genießen, wenn beide Teams wissen, wer sich in der Woche danach um die Website kümmert.
Klären Sie vor diesem Tag, wie die Projektumsetzung mit laufendem Support, Hosting, Content-Pflege und Weiterentwicklung zusammenhängt. Manche dieser Aufgaben bleiben vielleicht bei derselben Agentur, andere liegen bei Ihrem Team oder einem separaten Dienstleister.
Ein kurzes Gespräch klärt die praktischen Fragen: Wer plant Updates, wer behält externe Abhängigkeiten im Blick, wo wird ein Incident gemeldet, und wer hält das Business während der Behebung auf dem Laufenden?
Auch Inhalte brauchen einen Verantwortlichen. Ihr Team braucht einen Weg, Leistungsbeschreibungen, Produktinformationen und Übersetzungen aktuell zu halten. Eine Agentur kann diesen Prozess unterstützen, braucht aber Zugang zu jemandem, der die zugrunde liegenden Informationen bestätigen kann.
Seien Sie konkret bei Support-Abdeckung und Ausschlüssen. Wenn der Application Support die Verwaltung Ihres Identity Providers nicht umfasst, benennen Sie das Team, das dafür zuständig ist. Unser Vergleich Entwicklungsteam vs. Support geht auf diesen Unterschied näher ein.
Es hilft außerdem, die Wiederherstellung des Betriebs von der Ursachenanalyse und der Freigabe einer langfristigen Korrektur zu trennen. Wer diese Verantwortlichkeiten vorab klärt, hat während eines ohnehin stressigen Incidents weniger offene Fragen.
Halten Sie Zugänge und Wissen erreichbar
Eine gesunde Partnerschaft ermöglicht es, Urlaub zu nehmen, die Rolle zu wechseln oder eine weitere Fachperson einzubinden, ohne dass alle anderen festhängen.
Halten Sie Repositories, Domains, Hosting und relevante Service-Konten unter der Kontrolle der Organisation, mit Agenturzugängen, die zur Arbeit passen. Das heißt nicht, dass alle Administratorrechte brauchen. Es heißt, dass berechtigte Personen den nötigen Zugang erhalten können, ohne von einem privaten Konto abhängig zu sein.
Dokumentation ist am nützlichsten, wenn sie praktische Fragen beantwortet: Warum wurde diese Architektur gewählt, woher kommen die Produktdaten, wer verwaltet die Integration, und wen kontaktieren wir, wenn sie nicht mehr funktioniert?
Vereinbaren Sie Dokumentation und Schulungen als Teil der Arbeit. Geben Sie einer Person auf Ihrer Seite Zeit, dieses Wissen aufzunehmen und Fragen zu stellen. Ein Ordner mit Dateien ist ein Anfang; das übernehmende Team muss auch verstehen, wie es damit arbeitet.
Sie können die Agentur direkt fragen: „Wenn jemand anderes übernehmen müsste, was bräuchte diese Person von uns und von Ihnen?“
Das ist eine Frage der Kontinuität, kein Zeichen von Misstrauen. Sie gibt beiden Seiten die Chance, Abhängigkeiten, Kontoregelungen und mögliche Lizenzbeschränkungen von Drittanbietern zu erklären, solange noch Zeit bleibt, sich darum zu kümmern.
Achten Sie auf kleine Anzeichen von Unklarheit
Sind Verantwortlichkeiten unklar, ist das erste Anzeichen oft ein wiederkehrender Satz statt eines großen Incidents. Die folgenden Beispiele sind Anlässe für ein Gespräch, keine Gründe für Schuldzuweisungen.
| Was Sie hören oder bemerken könnten | Ein hilfreiches Gespräch |
|---|---|
| „Wir dachten, ihr prüft das.“ | Welche Prüfungen gehören zu welchem Team, und wer bestätigt die Abnahme? |
| Mehrere Stakeholder ändern ständig die Prioritäten | Wer kann diese Anfragen bündeln und ihre Reihenfolge festlegen? |
| Inhalte warten auf Freigabe, ohne nächsten Schritt | Wer kann sie freigeben, und wer vertritt diese Person? |
| Nach dem Launch hat die Wartung keinen Verantwortlichen | Welches Team kümmert sich darum, und was umfasst sein Umfang? |
| Eine Automatisierung veröffentlicht etwas Unerwartetes | Welche Aktionen waren erlaubt, und wer kann sie anhalten? |
| Nur eine Person versteht das Deployment | Welches Wissen und welche Zugänge würden einer Kollegin oder einem Kollegen die Übernahme ermöglichen? |
Manchmal ist die Antwort eine klarere Rolle. Manchmal mehr Zeit für eine Person, die die Verantwortung bereits trägt. Hilfreich ist, die Lücke gemeinsam zu erkennen und zu vereinbaren, was sich ändern soll.
Ihr Team sollte nicht raten müssen, welche technischen Entscheidungen die Agentur von Ihnen braucht. Die Agentur sollte nicht raten müssen, welche fachlichen Informationen sie freigeben darf. Klare Grenzen geben beiden Seiten mehr Raum, ihre Arbeit gut zu machen.
Eine Partnerschaft, auf die sich beide Teams verlassen können
Gute Zusammenarbeit macht es leichter, Fragen zu stellen, Bedenken früh anzusprechen und Entscheidungen zu treffen, ohne Arbeit hin und her zu schieben. Klare Verantwortlichkeiten unterstützen diese Beziehung: Sie helfen Menschen zu wissen, wann sie handeln und wann sie um Hilfe bitten sollten.
Wenn Sie Ihre Drupal-Zusammenarbeit leichter steuerbar machen möchten, sprechen wir gern mit Ihnen darüber. Bringen Sie die Punkte mit, die sich unklar anfühlen, ob Veröffentlichung, technische Entscheidungen oder Support nach dem Launch. Wir helfen Ihnen, daraus eine Arbeitsvereinbarung zu machen, die beide Teams verstehen.
