Erfolgreiche Web-Projekte durch moderne Arbeitsweisen

Im vergangenen Jahr hat eines unserer Teams, das recht autark arbeitet, einige Anpassungen und Änderungen an ihrer Arbeitsweise vorgenommen, die sich sehr positiv auf die Arbeitsergebnisse und damit auch auf Kundenprojekte auswirken. Mit diesem Blogpost möchten die Kollegen/innen einen kleinen Blick hinter die Kulissen geben:

Unsere Projekte laufen sehr gut, wir halten unsere Budgets ein und arbeiten gerne zusammen – ohne uns aufzuarbeiten. Wir haben eine stabile Rendite, obwohl wir regelmäßig interne Weiterentwicklungen einsteuern. Regelmäßige Kundenbefragungen bescheinigen uns eine hohe Kundenzufriedenheit; alles in allem können wir so arbeiten, wie wir es für sinnvoll und richtig halten.

 

Erfolg ist dabei nur das Ergebnis vereinter Anstrengungen

Es gibt nicht den einen Faktor, der das bewirkt hat – es ist vielmehr das Ergebnis jahrelanger gemeinsamer Arbeit und ein gewisses Maß an strategischer Planung – also sich nicht nur von einem Projekt zum anderen hangeln, sondern sich auch weiterentwickeln.

Es sind viele Köpfe und Hände involviert, wir versuchen dennoch einmal bestimmte Schlüsselfaktoren aufzulisten:

 

a) Team statt Zwist

Den weitaus wichtigsten Anteil am Gesamterfolg hat das Team. Alle zusammen. Wir arbeiten füreinander, nicht gegeneinander. Wir schlagen uns auch mal die Köpfe ein, fokussieren uns aber danach wieder aufs Wesentliche. Und wir arbeiten für die Sache – jeder Einzelne will eine richtig gute Arbeit machen. Wir unterstützen uns gegenseitig (und damit meinen wir nicht nur die Entwickler, wir meinen Vertrieb, POs, Entwicklung und alle sonstigen Beteiligten): Ein Kollege ist überlastet, andere helfen ihm unaufgefordert. Jemand kann etwas nicht und kassiert keine Kritik sondern Unterstützung.

Keiner bei uns im Team könnte seine Arbeit vernünftig machen, wenn er nicht die anderen Teammitglieder hätte, die sich um entsprechende Teile seiner Belange kümmern. Das ist keine Selbstbeweihräucherung, sondern eine harte Tatsache, ohne die keiner der folgenden Faktoren funktionieren würde.

 

b) Cross functional statt Einzelkämpfer

Eine Entscheidung hat neben einem funktionierenden Team sehr hohe Bedeutung: Wir sind cross functional aufgestellt. Dies bedeutet, dass wir unseren kompletten “Value Stream” (=Wertschöpfungskette) bedienen können. Das heißt nicht, dass wir autonom oder eine Firma in der Firma wären. Ein ungewöhnlicher Teil von cross functional stellt hier Marketing und Vertrieb dar: Die Bereichsleitung kümmert sich beispielsweise um unser CMS-Marketing, um Adwords, unsere Website usw. Allerdings wäre das ohne flankierendes, “allgemeines” Marketing, ohne SEO, SEA, UX usw. auch nicht möglich.

Jeder einzelne im Team hat seine Stärken und diese greifen ineinander. Wir haben keine expliziten Frontend-Entwickler, eher T-Shaped Individuals (Top-Frontend-Entwickler, die aber auch mühelos PHP und Angular Code schreiben).

Wichtig ist, dass wir unseren eigenen “Critical Path” (also alles was unserem Ergebnis Wert hinzufügt) unter unserer Kontrolle haben. Dazu gehört auch die Beratung im Vorfeld. Was wir dem Kunden sagen, haben wir im schlimmsten Fall hinterher auch auszubaden (dies führt zwangsläufig zu haltbaren Aussagen ohne den typischen Vertriebs- und Marketing-Sprech).


c) Experimente statt Gesetze

Dies hat eigentlich mit einer großen Schelte angefangen – unsere Entwickler hatten eines Tages beschlossen, dass Product Owner (Projektleiter) nicht mehr beim Schätzen dabei sind. Das ging an mehreren Stellen echt schief, es war recht offensichtlich, weshalb: Nicht weil jemand einen Fehler gemacht hat, sondern weil man ein Experiment als Gesetz verstanden, umgesetzt und nicht weiter bewertet hat.

Eines sollte uns bei unserer Arbeit immer klar sein: Keiner kann uns sagen, welches der richtige Weg ist, wir müssen Dinge ausprobieren, bewerten, justieren usw. – dazu gehören nun einmal Fehler. Die Frage ist nur, über welchen Zeitraum ich Fehler mache ohne sie zu erkennen.

Experimente zu unterbinden wäre fatal – deshalb haben wir ein Experiment-Board entwickelt, bei dem wir klare Experimente für einen Zeitraum definieren und dann in Retrospektiven bewerten. Simpel und effektiv.

 

d) Abholen statt Verkaufen

Eine große Herausforderung war immer die Akquise der richtigen Projekte und Kunden. Hier waren wir von vielen externen Faktoren abhängig – nicht zuletzt vom “Ego” des Kunden. Uns war recht schnell klar, dass wir eine andere Art von Anfragen benötigen und die Kunden anders abholen müssen, weil viele Schwierigkeiten dort beginnen, vor allem wenn man agil arbeiten will.

Wir haben daher in Zusammenarbeit mit unseren Online-Marketing Spezialisten den entsprechenden Bereich auf unserer Website komplett umgebaut um die für uns interessanten Kunden besser abzuholen. Der nächste Schritt war, sehr gezielt AdWords zu schalten, zu messen und zu optimieren. Die Zahl der Anfragen hat massiv zugenommen und viele davon entsprechen genau unseren Wünschen.

 

e) Vertrauen statt Fixkosten

Früher haben wir Anforderungen des Kunden aufgenommen, geschätzt, und manchmal wurde ein Projekt daraus. Heute fahren wir zum Kunden, erklären ihm mehr oder weniger deutlich, dass wir uns nicht darüber unterhalten sollten was er will, sondern was er braucht und darüber, wie wir vorgehen, um das herauszufinden, zu entwickeln und zu messen. Im Anschluss führen wir einen Online-Strategie-Workshop durch und geben eine grobe Kostenschätzung ab, bei der klar ist, dass wir die Kosten nur fixieren können wenn wir den Projektumfang nicht vorher im Detail festlegen. Wir wollen lieber während des Projekts flexibel sein, weil sich das als erfolgreicher erwiesen hat.

Wir fragen zudem nach JEDEM Termin entsprechendes Kunden-Feedback ab, kassieren auch mal Prügel, aber insgesamt finden unsere Kunden genau dieses Vorgehen sinnvoll.

Ein Projekt ist dann erfolgreich, wenn die Website definierte Ziele erreicht – nicht wenn man mit Ach und Krach etwaige Vorgaben (Budget und/oder Zeit) einhält.

 

f) Erfolge statt Niederlagen

Uns wurde erst auf dem Weg so richtig klar, dass Erfolge für ein Team weit wichtiger sind als aus Niederlagen zu lernen. Eines unserer aktuellsten Projekte, welches wir weit unter veranschlagter Kostenindikation fast mühelos live gestellt haben, hat uns die Augen geöffnet: Fehler und Niederlagen helfen nur zu justieren, Erfolge geben Motivation und Ausrichtung und sind viel wichtiger als man gemeinhin glaubt.

Das Team muss es aber für sich als Erfolg empfinden und ihn selbst erarbeitet haben – sich etwas als Erfolg schön zu reden hilft nicht.

 

g) Fakten statt Meinungen

Es ist uns wichtig, sich nicht auf Meinungen zu berufen („der Slider ist aber schöner“), sondern auf Fakten. Das fängt bereits bei der Beschaffung von Fakten an. Wir haben lange unsere “Cycle Time” (Wie lange liegen Tickets in der Entwicklung) jede Woche geprüft und Ausreißer besprochen – wie aus dem Lehrbuch. Irgendwann stellten wir fest, dass uns das weder irgendwas gebracht hat, noch irgendwer sich an die alten Ausreißer erinnert. Also haben wir angefangen, die Cycle Time und die Ausreißer separat zu tracken um dann überhaupt entscheiden zu können, ob wir daraus relevante Fakten gewinnen können oder nur Flickschusterei betreiben.

Unser Motto ist vielmehr, nicht allein aufgrund von Fakten zu handeln. Erst wenn wir hinreichend Fakten haben und wir das Gesamtbild sowie den wirklichen Grund hinter den Fakten erkennen, beginnen wir Lösungen zu erarbeiten und umzusetzen.

 

Fazit: Agil statt Oldschool

Wir haben auch Probleme und wir sind weit weg davon, perfekt zu arbeiten. Hoffentlich werden wir das auch nie. Wichtig ist aber, dass wir uns einen Weg erarbeitet haben, der funktioniert und bei dem wir und auch unsere Kunden zufrieden sind.

Durch die Fähigkeiten jedes Einzelnen und eine stabile technische sowie agile Basis, strenges, transparentes Controlling wichtiger Rahmenbedingungen (Umsatzrendite, Budgeteinhaltung im Projekt) können wir robust-agil arbeiten und nicht versuchen, Projekte auf eine Weise zu bearbeiten, von der wir wissen, dass sie uns nur Niederlagen bringt.

 

 

Kommentar abgeben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.