Ein separates Team unterstützt Live-Drupal-Websites

In den letzten sechs Monaten haben wir daran gearbeitet, ein organisiertes und strukturiertes Support-Team bei Droptica aufzubauen. Ich kann nun mit Freude sagen, dass unser Drupal-Support erstklassig ist. In diesem Beitrag werde ich ein wenig darauf eingehen, warum wir ein separates Support-Team geschaffen haben. 

Droptica begann als typisches Softwareentwicklungsunternehmen, mit einer Gruppe von Drupal-Entwicklern, die an den anstehenden Aufgaben arbeiteten. Dies konnte eine neue Website für einen Kunden oder ein neues Feature für eine bestehende Website sein. Wie die meisten kleineren Drupal-Agenturen haben wir uns so gut wie möglich selbst verwaltet: Wir erledigten das, was am wichtigsten oder dringendsten war. Dies funktionierte jedoch nur bis zu einem gewissen Punkt.

Wachstum und Veränderungen

Viele Veränderungen haben sowohl auf dem Drupal-Markt als auch bei Droptica in den letzten zwei Jahren stattgefunden.

Drupal-Projekte sind gewachsen. Drupal bewegt sich definitiv in Richtung des Unternehmensmarktes und größerer Implementierungen. Während vor drei Jahren ein typisches Drupal-Projekt in unserem Unternehmen ein bis zwei Entwickler benötigte, um es über einige Monate hinweg zu liefern, arbeiten wir jetzt an Projekten, die sogar 5-6 Entwickler in Vollzeit über längere Zeiträume erfordern. Die von uns erstellten Websites sind wirklich massiv, komplex und erfordern viel Aufmerksamkeit.

Die Erwartungen an Qualität und Zuverlässigkeit sind ebenfalls gestiegen, da wir begonnen haben, größere Kunden zu bedienen. Wenn Websites viel mehr Traffic haben und Fehler oft schwerwiegende Konsequenzen mit sich bringen, wird Exzellenz in der Ausführung zu einer erwarteten Anforderung. Gut organisierte Prozesse sind unerlässlich, um die erwarteten Standards jederzeit aufrechtzuerhalten.

Droptica ist gewachsen. Wir haben uns in den letzten Jahr um 30 % und in den letzten zwei Jahren um 100 % vergrößert. Wir bedienen jetzt mehr Kunden und unterstützen viel mehr Websites als je zuvor. Das ist super aufregend. Es ermöglicht uns, noch mehr und schneller zu lernen und wirklich spannende Dinge zu tun, bringt aber auch Schwierigkeiten mit sich:

1. Wenn Drupal ein Sicherheitsupdate veröffentlicht, müssen wir über 100 Websites so schnell wie möglich aktualisieren.
2. Es gibt keine einzelne Person mehr im Unternehmen, die „alle Projekte kennt“ – es sind einfach zu viele.

All dies hat uns gezwungen, noch besser organisiert zu sein als zuvor.

Wir haben SCRUM eingeführt

Wir haben agile Ansätze schon viel früher genutzt, aber 2018 war das Jahr, in dem wir wirklich voll auf agile Methoden umgestiegen sind. Wir können nun mit Sicherheit sagen, dass wir ein agiles Unternehmen sind. Wir verwenden die SCRUM-Methodik in allen Projekten, die wir liefern. Die Mehrheit unserer internen Funktionen und Projekte wird ebenfalls in SCRUM durchgeführt.

SCRUM ist großartig. Bei größeren Projekten und größeren Teams ermöglicht es uns, hohe Qualität, Organisation und Geschwindigkeit in den Projekten aufrechtzuerhalten. Unsere Kunden schätzen die Vorhersagbarkeit und die große Kontrolle, die sie über den Entwicklungsprozess haben. Wir haben über die Vorteile der Arbeit mit SCRUM geschrieben und unsere Erfahrungen über Kommunikation in einem Scrum-Team geteilt.

SCRUM funktioniert nicht für Support

Ich kann SCRUM nicht genug loben. Trotzdem funktioniert SCRUM trotz aller Qualitäten nicht gut für den Support.

1. Supportanfragen kommen oft in letzter Minute und können nicht auf den 'nächsten Sprint' warten (z.B. 3 Wochen).
2. Das Volumen der Supportanfragen ist unvorhersehbar.
3. Oft nimmt das Debugging mehr Zeit in Anspruch als das Beheben, was Schätzungen wirklich schwierig macht.

SCRUM-Teams können nicht nebenbei Support leisten

Ein Team, das an der Bereitstellung eines Projekts in SCRUM arbeitet, kann nicht gleichzeitig andere Websites unterstützen. Sprints in SCRUM sind relativ kurz (typischerweise 2 Wochen) und zugewiesene Aufgaben sollten innerhalb des Sprints abgeschlossen werden. Wenn ein Team eine bestimmte Geschwindigkeit (Umfang der Arbeit, die sie in einem Sprint liefern können) hat, wird die Hinzufügung zusätzlicher Supportaufgaben dazu führen, dass der Sprint nicht geliefert wird. Dies wird zu unerfüllten Erwartungen und zur Unfähigkeit, Liefertermine von Projekten vorherzusagen, führen.

Alternativ könnte das Team in der Planung etwas freie Zeit für eventuell auftretende Support-Tickets lassen. Unsere Tests zeigen jedoch, dass dies kein funktionierender Mechanismus ist. Das Team muss viel zu oft den Kontext wechseln, und das Projekt beginnt zu leiden.

Die einzige Situation, in der wir sehen, dass Entwicklungsteams erfolgreich Support leisten, ist, wenn sie eine Live-Version des Projekts unterstützen, an dem sie gerade arbeiten. Dies funktioniert jedoch offensichtlich nur in Szenarien, in denen ein Entwicklungsteam noch an einem Projekt arbeitet. Ein Projekt, das abgeschlossen ist und kein vollständiges Team mehr benötigt, muss anders verwaltet werden.

Das Drupal Support-Team betritt die Bühne

Nach vielen Versuchen und Irrtümern mit verschiedenen Ansätzen haben wir entschieden, dass die beste Lösung die Schaffung eines dedizierten Drupal-Support-Teams ist. Das Support-Team kümmert sich um alle Websites, die kein aktives Entwicklungsteam haben. Das bedeutet, alle Websites, die weniger als einen Vollzeit-Entwickler an Arbeit erfordern.

Wenn eine unterstützte Website plötzlich ein größeres Feature oder mehr Arbeit erfordert, stellen wir ein Entwicklungsteam zusammen, das vorübergehend übernimmt. Sobald die Arbeit abgeschlossen ist, wird die Website zurück an den Support übergeben.

Wir haben in den letzten 6 Monaten mit diesem Ansatz experimentiert und er hat sich als der zuverlässigste erwiesen. Tatsächlich ist er so großartig, dass wir begonnen haben, Support als separaten Service anzubieten.

Schauen Sie sich unser Drupal Support-Angebot an.