Mission Statement

I am a Jack of all trades in technology and I believe in the power of prototyping to evaluate business models.

My mission is to solve hard technical or conceptual problems. Therefore I either build and operate stuff very efficient by myself or work together with startups and entrepreneurs, tackling their technical challenges.

If you are interested in my services, hire me! If it is not urgent, then you are welcome to just follow / friend me at Facebook, Twitter or LinkedIn because I post quiet some content on those topics.

Prozesse in der Kreativwirtschaft: Ein großes Missverständnis

Die puristische, reine Lehre nach einem immer gleichen agilen Prozess erscheint mir inzwischen schon fast wie der heilige Gral. Unereichbar und vor allem ein frommer Wunsch. Eine immerwährende gute Ausrede für den Entwickler – “Agil wäre das nicht passiert!” – und trotzdem im Alltag schwer umzusetzen.

Auf der anderen Seite sind Marketing-Abteilungen, die von Kampagnen pixelgenaue Designs abnehmen wollen, weil sie das seit 5 Jahren schon so machen. Feedback zur wirklichen User Experience, welches über “Logo muss größer” und “dies muss noch etwas roter” hinausgeht, kommt dann oft erst, wenn zum ersten mal getestet wird. Und dann fängt man nochmal von vorne an.

Ein Dienstleister muss nicht jedem Kunden einen  Prozess aus dem Lehrbuch aufdrücken.

Anstatt von einem perfekten Prozess zu träumen, den der nie implementiert werden kann, sollte das was an agilen Methoden und responsiven Prozessen auf dem Markt ist, als Toolset begriffen werden.

Wie aus jedem guten Werkzeugkasten kann sich dieser und jener Tools bedienen werden, wenn sie Sinn ergeben. Es gibt für mich kein richtig oder falsch, solange es funktioniert und alle zufrieden sind. Dafür müssen aber auch alle beteiligten – inkl. Entwickler schon früh genug in die Prozessgestaltung mit einbezogen werden.

Von welchen Tools spreche ich?

Nun, es gibt eine ganze Menge an Tools im Digitalen: Eine Obermenge an abstrakten Methoden / Prozesse zerlegt sich in einzelne Tools. Um nur mal ein paar zu nennen:

Einsatz abhängig von der Zielstellung

Anhand von 3 üblichen Cases möchte ich mal zeigen, wie die diversen Toolsets in unterschiedlichen Reihenfolgen angewendet werden können. Your mileage may vary.

Case 1: Produktentwicklung

Wenn ein Startup gegründet wird oder ein Service designed wird, ist das Business-Ziel oft (einigermaßen) klar, aber noch nicht der Weg da hin. Da eignet sich dann ein Scrum aus dem Lehrbuch schon relativ gut. Die maximale Nutzung und Zufriedenheit des Teams ohne unnötigen Overhead. Darüber machen sich genügend Menschen Gedanken – hier soll es mehr um die Dienstleister-Seite gehen. (Links zu Scrum Blogposts)

Case 2: Homepage-Relaunch

Bei einem klassischen Homepage Relaunch für ein mittelständisches Unternehmen oder eine Organisation, welches keine digitalen Produkte vertreibt, wird ja oft das Rad nicht neu erfunden. Es existieren bereits viele Inhalte und Informationen, welche neu strukturiert und gegebenenfalls aktualisiert werden müssen. Die UX Herausforderungen sind punktuell – größere Änderungen an der UX sogar kontraproduktiv und vielleicht gar nicht erwartet. (Siehe All Websites Look The Same http://www.novolume.co.uk/blog/all-websites-look-the-same/). Bei diese Aufgabenstellung kann ein Prozess beispielsweise wie folgt aussehen:

Case 3: Kampagnen

Bei Kampagnen verhält es sich genau umgekehrt. Hier wird das optische Rad oft nicht neu erfunden, sondern nur auf ein Highlight übertragen, welches allerdings meist eine ziemliche Herausforderung in der UX mit sich bringt – man will ja überraschen.

Macht einfach eine pragmatische Projektplanung..

Vergesst nicht: Der Kunde ist der Experte für das Produkt oder sein Unternehmen. Ihr seid die Experten für das digitale. Sprecht seine Sprache und drückt ihm keine Begriffe auf, die er nicht versteht oder die ihm Angst machen. Überfallt ihn nicht, wie von einem anderen Planeten.

Also redet nicht von Sprints, sondern macht einfach eine grobe Projektplanung, macht ihm klar was er bis wann feedbacken muss und aktualisiert diese regelmäßig.

Sagt ihm ruhig, dass die Planung speziell für ihn und sein Projekt so ist und das ihr das nächste mal wieder schaut, was die beste Art ist, dass Projekt zu planen.

.. und beherzigt dabei diese Dinge

Aus allen Tools und Werten, die das agilen Projektmanagement und der responsive Webdesign Prozess zur Verfügung stellt habe ich folgende Dinge als essentiell erkannt:

  1. Immer ein lauffähiges Produkt haben. Änderungen sollten immer so nah am tatsächlichen Produkt gemacht werden, wie möglich. Also keine kompletten Screens designen, die weggeworfen werden, sondern so früh wie möglich die Styles auf die Plattform bringen und über konkrete Dinge sprechen. Das versteht auch ein Kunde.
  2. Weiter ist ein Mechanismus wichtig, um ständig reflektieren zu können, ob man auf dem richtigen Weg ist. Aber den müsst ihr nicht Retrospektive nennen, sondern könnt ihn einfach auf die Agenda des “Jour Fix” setzen.
  3. Experimentieren und Erfahrungen sammeln. Nutzt die Methodne und deren Tools, die es gibt! Bevor ihr zusammenstellen könnt, was für das jeweilige Projekt am besten ist, müsst ihr auch Erfahrungen damit gemacht haben. Also macht gezielt Experimente, wenn es sich anbietet.

Die Ironie der agilen Methoden

Die Ironie an der Sache ist ja, dass wenn man sich zu 100% an eine “agile Methode” hält, man ja schon eigentlich nicht mehr agil ist. Die Arbeit wird nur von einer anderen Methode diktiert. Ein Appell zum Nachdenken.

Weiterführende Lektüre gibt es bei Andy Hunt, Autor des Alltime-Klassikers The Pragmatic Programmer, – vergesst auch nicht, den zweiten Teil seines Posts zu lesen.

(Das auf dem Bild oben ist übrigens ein Artbot, gesehen auf der Makerfaire.)

08.10.2015


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.