Immer wieder hört man, wie wichtig es ist, Usability Engineering in die Entwicklung zu integrieren. Aber wie ist es überhaupt, als Usability Engineer neu in ein Team zu kommen, das bisher kaum etwas mit Usability am Hut hatte? Genau diese Situation hatte ich, als ich vor zwei Jahren in das Entwicklungsteam von YAKINDU Traceability aufgenommen wurde.
Mittlerweile bin ich wirklich stolz, wie toll sich die Zusammenarbeit entwickelt hat. Wir sind als Team zusammengewachsen und haben es in den vergangenen Monaten geschafft, Usability als festen Bestandteil in der Produktentwicklung zu verankern. Zu Beginn sah die Situation jedoch noch anders aus.
Damit ihr nicht über die gleichen Stolpersteine stürzt, beschreibe ich in diesem Blogeintrag, welche Schwierigkeiten der Einstieg in ein neues Team mit sich bringen kann. Oder wisst ihr das schon aus eigener Erfahrung? Dann lest direkt meinen nächsten Blogeintrag und findet heraus, wie Usability Engineering erfolgreich eingeführt werden kann.
Hochmotiviert ins Projekt
Vor gut zwei Jahren fiel die Entscheidung, dass ich als Usability Engineer die Entwicklung unseres Produktes „YAKINDU Traceability“ begleiten sollte. Meine Mission: die Usability des Produktes auf Vordermann zu bringen. Ich hab mich damals sehr darüber gefreut, die Chance zu bekommen, kontinuierlich an der Entwicklung eines Produktes beteiligt zu sein – den Usability-Engineering-Prozess also wirklich auszuleben.
Außerdem trat ich die Nachfolge einer damalige Kollegin an, die das Projekt bereits zuvor als Usability Engineer begleitet hatte. Der Grundstein für eine gute Produktentwicklung war also bereits gelegt – das Team wusste, was Usability Engineering bedeutet, ein gefestigter Prozess bestand, Usability Methoden wurden eingesetzt – dachte ich zumindest.
Willkommen auf dem Boden der Tatsachen
Ich kam also hochmotiviert in das Team und erwartete, nach einer kurzen Übergabe, direkt starten zu können. Ich schaute mir zunächst an, was für Usability-Methoden und Ergebnisse bereits existierten.
Eine Anforderungserhebung hatte stattgefunden, das wusste ich – an den Interviews war ich selbst beteiligt gewesen. Auch gab es Personas, die im Projektbüro an der Wand hingen. Und ich fand mehrere Usability-Reviews, die Probleme aufdeckten und Verbesserungsvorschläge aufzeigten. Das sah erstmal gut aus, oder?
Natürlich war es toll, dass diese Vorarbeit geleistet wurde. Das Problem daran war nur: Die Ergebnisse steckten in einer Sackgasse fest. Sie lagen zwar vor, fanden aber ihren Weg in die Entwicklung nicht. Kurz gesagt: Niemand schenkte ihnen Beachtung.
Wenn Tickets zu groß werden...
Warum? Ich lernte schnell, dass etwas nur seinen Weg in die Entwicklung fand, wenn es über JIRA lief, ein Tool für die Verwaltung von Tickets. Da das Projekt agil aufgestellt war, wurde im Sprintplanning einkalkuliert, was im nächsten Sprint erledigt werden sollte.
Ich suchte also in JIRA nach Usability-Tickets, wurde fündig und… wurde von diesen beinahe erschlagen. Nicht hinsichtlich ihrer Anzahl, sondern hinsichtlich ihres Umfangs.
So bestand ein Ticket quasi aus einem ganzen Konzept – man könnte sagen, jedes Ticket glich eher einem riesigen Epic. Das machte eine Schätzung und eine kontrollierte Umsetzung unmöglich.
Kein Wunder, dass um diese Tickets ein großer Bogen gemacht wurde – sie waren einfach nicht handhabbar. Ein großes Problem hatte ich damit zumindest schon mal identifiziert.
Wenn man im Sprintplanning nichts zu tun hat
Aber es gab noch weitere Probleme: Als Teammitglied erwartete ich, konkrete Aufgaben für den nächsten Sprint zu bekommen. Also saß ich erwartungsfroh im Sprintplanning und wartete und wartete… bis sich am Ende alle verabschiedeten, da alle verfügbaren Kapazitäten verplant waren.
Ich hatte allerdings keine Aufgabe zugewiesen bekommen. Also fragte ich nach, wie meine Vorgängerin das gehandhabt hatte und bekam die Antwort, sie hätte sich eigene Aufgaben herausgesucht. Also dachte ich mir: Mach ich das auch erstmal so.
Wenn Konzepte veralten
Dieses Vorgehen war allerdings nicht zielführend. Die Konzepte, an denen ich arbeitete und die ich spezifizierte, versanken ebenfalls im Datengrab. Warum? Weil sie thematisch nicht in den Sprint passten und andere Features wichtiger waren.
Meine Konzepte wurden also immer wieder nach hinten verschoben. Das führte natürlich dazu, dass auch meine Konzepte veralteten und sich anstauten. So hatte ich zwar im Sprint etwas zu tun, umgesetzt wurden meine Ideen allerdings nicht. Es fehlte ganz klar die Abstimmung zwischen den anstehenden Aufgaben der Entwickler und meinen Usability-Tätigkeiten.
Wenn Tickets länger dauern, als geplant
Mit den Problemen hörte es damit aber nicht auf: Wenn es dann endlich soweit war, dass eines meiner Konzepte angegangen werden sollte, dauerte die Umsetzung meist viel länger als ursprünglich eingeplant.
Das hatte eine klare Ursache: Während der Prozess für ein „Entwicklungsticket“ so aussieht, dass es erst umgesetzt und dann von einer zweiten Personen getestet wird, war das mit meinen Usability-Tickets nicht der Fall. Die Ergebnisse wurden (zunächst!) einfach so hingenommen und das Ticket geschlossen.
Das Review fand dadurch quasi verspätet im nächsten Sprint statt, wenn der Entwickler das Ticket umsetzen wollte. Das Ergebnis waren endlose Diskussionen: Könnte man nicht dieses und jenes ändern, warum ist das so, was meint ihr? Die Anforderungen an das Ticket wurden also wieder verschoben.
Und das Problematischste dabei: Ich saß nicht im Projekt- sondern im Usability-Büro eine Etage weiter oben und bekam die Diskussionen erst mit, wenn ein Entwickler nach oben gestiefelt kam und mich zur Klärung dazu holte. Dadurch wurde jede Menge sinnlose Zeit vertan.
Wenn UI-Tickets zu spät gereviewt werden
Nachdem dann alles geklärt war – zumindest vermeintlich – und sich der Entwickler an die Arbeit gemacht hatte, gab es irgendwann für mich das Signal, das Ticket testen zu können. Dies war meist kurz vor Code Freeze der Fall, da neben den Änderungen an der Benutzeroberfläche natürlich auch noch Tests, Hilfe und Spezifikation zu schreiben waren.
Was passierte dadurch? Ich testete das Ticket und musste es in vielen Fällen wieder öffnen, da bestimmte Dinge nicht richtig umgesetzt waren. Da das Sprintende kurz bevor stand, kam es zu Zeitdruck. Was tat man also: Die Änderungen wurden in ein neues Ticket verschoben und… reihten sich in die Sackgasse ein. Priorität für den neuen Sprint hatten ja schon wieder neue Features.
Ein langer Weg… aber es hat sich gelohnt
Ihr merkt selbst: Die Liste der Probleme im Projekt war lang. Ein Glück, dass wir im Projekt agil arbeiten und in den regelmäßig stattfindenden Retrospektiven solche Probleme ansprechen.
Was ich beschrieben habe, war der Stand vor gut zwei Jahren. Gemeinsam im Team entwickelten wir über die Zeit hinweg einen Prozess, um UNSERE Mission – die Usability des Produkts voranzutreiben – zu erfüllen. Und das klappt mittlerweile wirklich gut!
Ihr fragt euch, wie wir es jetzt richtig machen? Das verrate ich euch in meinem nächsten Blogeintrag.
Kommentare