Implementierungsphase == doof

Von | 1. April 2014

Vorweg: Dies ist kein Aprilscherz! Muß man heute ja dazu sagen.

Neulich hatte jemand auf Google+ in einem Kommentar angemerkt, die Implementierungsphase sei der Schlüssel zum Erfolg. Quasi so als „wie wir ja alle wissen“ Eröffnung für eine Argumentationskette.

Bei mir ist da allerdings die Kette direkt runtergefallen, denn: Ich halte das für Unsinn.

Ich will jetzt gar nicht so weit gehen und sagen, daß es idealerweise gar keine Implementierungsphase geben sollte, sondern ein ständiges Hinzufügen, Entfernen und Ändern der Implementierung, denn mir ist auch klar, daß nicht jeder personell so gut aufgestellt ist, daß alle Beteiligten mit so einer Umgebung klarkommen.

Nein, ich möchte vom ganz normalen „Kunden XY“ ausgehen, bei dem ein kleines Team im Marketing nebenbei noch Analyse macht, während die Implementierung bei einem ganz normalen Entwicklerteam liegt, das ansonsten mit Webanalyse rein gar nichts am Hut hat, im schlimmsten Fall also eher widerwillig ist.

Auch in so einer Situation ist die Implementierungsphase in der Regel überbewertet. Und gerade in einer solchen Situation sollte man alle Beteiligten umstimmen.

Zement

Mein großes Problem mit der Überbewertung der Implementierungsphase (und ich betone das jetzt jedesmal) ist der Grundgedanke, daß es da eine Phase gäbe. Denn wenn es eine Phase gibt, dann gibt es auch ein Ende dieser Phase, und am Ende dieser Phase ist per Definition alles fertig. Komplett. Perfekt.

Wenn ich jetzt gerade meine Entwicklerpersonamütze auf dem Kopf gehabt hätte, würde ich auf dem Boden liegen und Tränen lachen. Jeder, der auch nur ansatzweise jemals mit Softwareentwicklung zu tun hatte weiß, daß am Ende einer Phase alles mögliche passiert ist, aber „fertig“ oder gar „perfekt“ steht da eigentlich nie.

Mit meinem Marketinghut auf dem Kopf bin ich desillusioniert, denn ich habe das schon erlebt. Trotzdem hoffe ich immer wieder, daß so ein Projekt vielleicht eines Tages doch einmal wirklich fertig sein wird wenn die Phase vorbei ist.

Hier liegt das eigentliche Problem: das Ende der Phase ist nicht dann erreicht, wenn das Ziel perfekt umgesetzt wurde!

Stattdessen hängt das Ende der Phase (jeder Phase in unserer Welt!) davon ab, wie es am Anfang definiert wurde. KPIs. Deliverables. Man-hours. Go-live-date. Vertrag mit Entwicklerteam abgelaufen. Jemand geht in den Urlaub. Fiskaljahr.

Für die KPIs und Deliverables könnte man sich ja noch glatt erwärmen, die sind aber meist vor der Phase festgelegt worden und daher nicht in der Lage, flexibel auf Änderungen zu reagieren. Und selbst wenn diese Flexibilität möglich ist, dann läuft man wahrscheinlich wieder in andere Limits rein, siehe den Rest der Liste.

All das ist suboptimal und führt nicht zu einer guten Lösung. Darüber werden in der Softwarebranche seit Jahrzehnten Bücher geschrieben.

Agile

Der Trend zur Zeit geht zur agilen Softwareentwicklung (Stichworte z.B.: „Kanban„, „Scrum“ oder „Extreme Programming„). Ein Grundgedanke ist, daß „responding to change“ wichtiger ist als „following a plan“.

Und wenn man das konsequent weiterdenkt: „Klare inhaltliche Vorgaben (Pflichtenheft) sind schwerlich möglich, da die Anforderungen per Definition erst zur Projektlaufzeit entwickelt werden.“

Warum führe ich das hier an?

Weil agile beansprucht, genau das Problem der Implementierungsphase zu lösen. Das Ziel aller agilen Schulen ist, daß die Situation in der die Phase vorbei ist aber niemand glücklich eben gar nicht eintritt.

Und davon sollten wir uns in der Webanalyse ruhig mal ein paar Scheiben abschneiden.

Symbiose

Für einen Marketer, der nebenbei noch Webanalyse betreibt und vielleicht erstmal gar nicht sagen kann was genau er benötigt, ist es schwierig bis unmöglich, ein gutes Pflichtenheft anzufertigen. Er kann aber lernen und dann auch artikulieren, was ihm noch fehlt. Dafür braucht es Zeit und Erfahrung!

Wo besser könnte man diese Erfahrung machen, als bei der Umsetzung kleiner Projekte? „Erstmal klein anfangen“ ist eine der wirklich guten Strategien, wenn man etwas lernen will!

Jetzt kommt natürlich der Einwand „unser Entwicklerteam hat auch noch andere Stakeholder“. Dahinter steckt die Annahme, daß agile automatisch mehr Zeit seitens der Entwickler benötigt. Genau das ist aber eben nicht der Fall!

Beispiel Webanalyse: Wer eine komplexe Implementierung in einem Rutsch (in einer Phase) machen will, der muß dem Entwicklungsteam ziemlich ausführlich und detailliert erklären, was es tun soll. Das Team plant dann entsprechend seine Ressourcen und macht sich an die Arbeit. Schon alleine die Planungsphase nimmt hier viel Zeit in Anspruch!

So eine Implementierung für Webanalyse (und nicht nur SiteCatalyst Reports & Analytics) ist zwar nicht übermäßig schwierig, für einen unbedarften Entwickler gibt es aber doch eine Handvoll Konzepte zu erlernen. Daß das in der veranschlagten Zeit klappt und zwar ohne Mißverständnisse, halte ich für eine optimistische Annahme, vor allem wenn Planung und eigentliche Umsetzung zeitlich getrennt nacheinander stattfinden.

Für beide Seiten ist es einfacher und langfristig besser, sich in kleinen Schritten an das Thema heranzutasten, also z.B. zunächst nur Kampagnentracking zu implementieren oder was auch immer für’s Marketing wichtig ist.

Marketing sammelt dadurch Erfahrungen im Umgang mit den Daten oder lernt einfach erstmal, wie dieses „Webanalyse“ eigentlich funktioniert. Und Development muß nicht gleich ein vergleichsweise großes Projekt stemmen, sondern kann klein anfangen, sozusagen mit einem Testlauf.

Win-win.

Überspitzt gesagt läßt sicher der oben unterstellte Widerwille der Entwickler dadurch zähmen, daß man dem Team nicht so viel aufbürdet. Ein kleiner Gefallen tut sich leichter als ein großer.

Ja, ich weiß, wir reden hier nicht von Gefallen sondern von der eigentlichen Aufgabe des Entwicklungsteams, aber: Man zeige mir ein Entwicklerteam, das nicht überlastet ist. Und man zeige mir ein überlastetes Team, das nicht wenigstens teilweise „Priorität nach Person“ macht. Insofern sind „kleine Gefallen“ einfach eine Realität.

Meine These: Je kleiner die Schritte, desto größer der Erfolg auf lange Sicht.

Und agile ist der Extremfall, hier ist jeder Schritt genau eine Story, ein use case. Sehr erstrebenswert!

5 Gedanken zu „Implementierungsphase == doof

  1. Bijan

    Hi Jan,
    da hast Du Dich an ein eigentlich leichtes (aus meiner und vermutlich auch Deiner Sicht) aber schweres (aus Sicht der noch Analytics-Implementierungs-Unwissenden) Thema gewagt.

    Ich würde sagen ja-komma-aber, denn so ganz ohne requirenments-analysis und preparation würde die ‚implementierungsphase-schauen-wir-mal-was-wie-geht‘ kommt man dennoch nicht aus. Ich würde aufgrund meiner Erfahung sagen: die Mischung macht’s und wenn man diesen Umstand und diese Erfahrung den Entwicklern, Stakeholdern und Merketeers verständlich machen konnte, hat man eigentlich einen guten Weg eingeschlagen und schon sehr viel erreicht 😉

    Gruß
    Bijan

    Antworten
  2. Gerhard Klassen (@gerhardklassen)

    Guten Morgen Herr Exner,

    vielen Dank für diesen Artikel.
    Während ich meinen Espresso am Morgen genieße und den Text lese, musste ich schmunzeln und an meine Erfahrung denken:

    Sie bestätigen auch meine These, dass man mit kleinen Schritten am Ende größeren Erfolg verzeichnet. Nehmen wir bspw. die Implementierung von Adobe Analytics. Mit zahlreichen Prop- und Evar-Variablen und unendlich vielen Events schafft man es ja kaum eine glatte Implementierung am Anfang eines neuen Projektes hinzubekommen.

    Vor allem im E-Commerce (größere Onlineshops) werden beinahe schon wöchentlich neue Projekte angeschoben, die auf ihre Art und Weise gemessen werden möchten. Das heißt, es wird regelmäßig etwas implementiert.

    Ich bin zwar in meiner persönlichen Erfahrung (Gott sei Dank) nicht mit unwilligen Entwicklern konfrontiert worden, sondern eher mit „Stakeholdern“ unterschiedlicher Hierarchie-Ebenen, die der Weiterentwicklung leider noch nicht die richtige Priorität beimessen. Mit Weiterentwicklungen meine ich bestehende Implementierungen zu überarbeiten, um bspw. Variablen sparen zu können oder nicht mehr benötigte Variablen oder Events aus dem Code zu nehmen etc.

    Daraus folgt für mich, dass
    a) die neuen Projekte eher eine Implementierungskopie im Sinne der Variablen von ähnlichen Projekten sind und
    b) man es dadurch schwer hat, überhaupt die Weiterentwicklung der Implementierungen voranzutreiben.

    Grenzenlos ist die Freude, wenn obere Implementierungskopien ohne Rücksprache eingebaut werden, um Zeit zu sparen und meinem Team Freudensprünge zu bereiten.

    Die Schlussfolgerung ist für mich, dass erst das Bewusstsein für den Wert der Webanalyse (am besten in € oder $) in der Geschäftsführung geschaffen werden muss. Und anschließend das Bewusstsein für eine agile Implementierung. Dadurch schaffe ich mir die Verhandlungsbasis für spätere Diskussionen, wenn Weiterentwicklungen von Implementierungen benötigt werden, um den genannten Wertbeitrag zum Unternehmen beitragen zu können.

    Viele Grüße
    Gerhard Klassen

    Antworten
  3. Pingback: Mindestens Zwei! | Webanalyse auf Deutsch

  4. Pingback: Ein Tagesausflug in’s Action Land | Webanalyse auf Deutsch

  5. Pingback: Checkliste – Vom Bedarf zum Code | Webanalyse auf Deutsch

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.