In meinem ersten Blogeintrag habe ich euch erzählt, was alles schief gegangen ist, als ich vor gut zwei Jahren als Usability Engineer in das Entwicklungsteam unseres Produkts „YAKINDU Traceability“ aufgenommen wurde. Mittlerweile haben wir im Vergleich zu früher eine 180 Grad Drehung gemacht und ich bin schon etwas stolz, wie gut die Zusammenarbeit im Team jetzt funktioniert. Daher möchte ich euch zeigen, wie sich Usability Engineering gut in den Entwicklungsprozess integrieren lässt und wie wir als Team dahin gekommen sind.
Sich gegenseitig beschnuppern und wertschätzen
Wie immer, wenn ein neuer Mitarbeiter zu einem Projekt dazu stößt, muss man sich gegenseitig kennenlernen. Schließlich weiß man noch nicht, was die Person für Fähigkeiten hat und welchen Mehrwert sie dem Projekt bringt. Bei mir gab es damals natürlich noch den Spezialfall, dass der Usability Engineer bis dato eine eher unbekannte Rolle hatte, der Mehrwert also erst einmal vom Team erkannt werden musste. Das hat in der chaotischen Anfangszeit sicherlich noch nicht wirklich gut funktioniert.
Mittlerweile fühle ich mich jedoch wie jedes andere Teammitglied auch, das seinen Beitrag leistet. Wichtig ist mir, dass das Usability Engineering nicht als Sonderstellung gesehen wird. Mein Beitrag ist genauso wichtig wie der aller anderen Teammitglieder.
Auch mal andere Aufgaben übernehmen – Entwicklung eines gemeinsamen Verständnisses
Was sicherlich zu diesem Gefühl beigetragen hat, ist, dass ich im Team auch Aufgaben übernehme, die eigentlich nichts mit Usability Engineering zu tun haben. Beispielsweise haben wir zur Qualitätssicherung am Ende jeden Sprints eine manuelle Testphase, in der das gesamte Team händisch Testfälle ausführt und versucht, Fehler in der Anwendung zu finden. Sowohl am Aufbau der Testfälle, als auch an deren Durchführung bin ich genauso beteiligt, wie meine Entwickler-Kollegen. Das hat für alle Seiten Vorteile: Jeder arbeitet mit dem Produkt und erlebt es – es wird nicht ausschließlich entwickelt, ohne die Funktionen einmal selbst genutzt zu haben. Dadurch fallen sowohl technische Fehler, aber auch Usability-Probleme auf. Immer mal wieder höre ich während dieser Phase Sätze wie: „Hm, das ist aber irgendwie umständlich gelöst“ oder „Die Fehlermeldung ist jetzt aber nicht gerade hilfreich.“ Wir haben dadurch ein gemeinsames Verständnis davon, was funktioniert und was noch verbessert werden kann.
Auch teste ich (sofern möglich) Tickets meiner Teamkollegen, die nichts mit der Benutzeroberfläche zu tun haben. Das hilft mir dabei, das Produkt besser zu verstehen und gleichzeitig kann ich nach rechts und links schauen und auf Dinge aufmerksam machen, die mir zusätzlich auffallen.
Auf der anderen Seite bekomme ich Unterstützung von den Entwicklern beim Einsatz von Usability-Methoden: Beispielsweise hat mich ein Kollege beim Protokollieren der Ergebnisse aus einem Usability-Test unterstützt. So gelangt auch das Bewusstsein und Verständnis über aktuelle Usability-Probleme ins Team. Und vor allem: Wir bekommen ein Teamgefühl, denn alle ziehen am gleichen Strang.
Kapazität im Sprint für Usability-Aktivitäten einplanen
Solche Aktivitäten, wie das Durchführen von Usability-Tests oder der Entwurf neuer Konzepte, werden mittlerweile im Sprint genau eingeplant und mit den Aufgaben der Entwickler abgestimmt. Wir haben für die Planung ein Template entwickelt, in dem wir je nach Rolle (z. B. Entwicklung, Usability Engineering, Build/Infrastruktur) die Kapazitäten abfragen. Wir achten genau darauf, dass jede Rolle im Sprint Aufgaben im angemessenen Umfang zugewiesen bekommt. Dabei wird seitens des Product Owners sichergestellt, dass diese Tätigkeiten auch inhaltlich miteinander einhergehen. Wir organisieren dies über Epics, die sich mit einem konkreten Bereich der Anwendung befassen, und ordnen diesen die inhaltlich relevanten Tickets zu – so auch meine Usability-Aktivitäten. Werden die Tickets aus einem Epic nicht in einem Sprint umgesetzt, werden sie im nächsten umgesetzt. So veralten die erstellten Konzepte nicht wie früher.
Dabei haben wir uns vorgenommen, in jedem Sprint sowohl Tickets für neue Features, Bug-Tickets und Usability-Tickets einzuplanen, sodass das Produkt sowohl aus Funktions-, technischer und Usability-Sicht immer besser wird. Wir wollen so vermeiden, dass Usability-Tickets in der Sackgasse bleiben, in der sie sich vor zwei Jahren noch befanden. Meine Aufgabe ist im Planning dabei ganz klar, die Usability-Fahne hochzuhalten und das Team im Zweifel zu erinnern: Vergesst die Usability-Tickets nicht!
Tickets klein und kompakt halten
Damit diese Usability-Tickets nicht bis zuletzt im Sprint bleiben, da sich niemand – allein wegen des Umfangs – mit ihnen befassen möchte, sind unsere Tickets mittlerweile klein gehalten und befassen sich nur mit bestimmten Ausschnitten eines gesamten Konzeptes. Während die UI-Spezifikation an anderer Stelle verschriftlicht ist, beschreiben die Tickets konkrete Funktionen aus dieser Spezifikation. Das hilft vor allem im Planning dabei, den Aufwand des Tickets besser zu verstehen, zu schätzen und später auch zu testen, ob ein Ticket wirklich zufriedenstellend umgesetzt ist.
Feedback von den Entwicklern einholen oder einfach direkt gemeinsam konzipieren
Um insbesondere die Verständlichkeit der Tickets und Spezifikationen zu erhöhen, haben wir im Prozess etabliert, dass die anderen Teammitglieder die Konzepte, die ich während des Sprints entwerfe, reviewen. Das heißt, wenn ich beispielsweise eine UI-Spezifikation fertig gestellt habe, schreibe ich genauso wie die Entwickler ein „How to test“ in das zugehörige Ticket und ein Entwickler muss das Ticket abnehmen – falls etwas nicht passt, wird das Ticket wieder geöffnet. Dadurch erhalte ich wertvolles Feedback und immer wieder guten Input zur Verbesserung des Konzepts.
Da gute Ideen meist nicht in einem stillen Kämmerlein entstehen, sind wir sogar noch einen Schritt weitergegangen und führen Design Studios mit dem ganzen Team durch, um Konzepte zu entwerfen. Die resultierenden Ideen nehme ich als Grundlage und verfeinere das Konzept mit Hilfe von Prototypen und UI-Spezifikationen. Durch den interdisziplinären Austausch und den Input von jedem Teammitglied sind schon viele tolle Ideen entstanden. Der große Vorteil daran ist: Jeder hat etwas zum Konzept beigetragen und jeder weiß ohne viele Erklärungen, wie es realisiert werden soll.
(Räumliche) Entfernung überwinden
Wir sind also verstärkt dazu übergegangen, wirklich gemeinsam zu arbeiten und uns auszutauschen. Dazu zählt auch mein Umzug in das Entwicklerbüro: An den Tagen, an denen ich für das Projekt tätig bin, sitze ich gemeinsam mit dem Entwicklungsteam in einem Raum. Kommen Fragen auf, werden diese so direkt geklärt. Selbst eine Treppe Entfernung hatte zu einem Kommunikationsverzug geführt. Und: Ich bekomme direkt mit, wenn etwas zu Unstimmigkeit oder Diskussion führt und kann das Ganze klären.
Frühzeitig Feedback geben
Mittlerweile ist auch unsere “Definition of Done” für Tickets, die die Benutzeroberfläche betreffen, so abgewandelt, dass ein Review durch mich notwendig ist, bevor ein Ticket zum Testen freigegeben werden darf. Ist die Arbeit an dem Ticket also hinsichtlich der Oberfläche abgeschlossen (d.h. Tests, Hilfe, Spezifikation etc. können noch ausstehen), schaue ich mir das Zwischenergebnis an und gebe mein Feedback. Da dieses Feedback früh im Sprint gegeben wird, bleibt für den Entwickler genügend Zeit, um dieses noch im selbigen Sprint umzusetzen.
Was ich gelernt habe
Dieses Projekt und auch andere haben mir gezeigt, dass man nicht einfach sagen kann: “Hey, hier habt ihr euren Usability Engineer. Macht das Produkt top!” – insbesondere, wenn im Team noch gar keine Erfahrung mit dem Thema vorliegt. Entwicklung und Usability Engineering müssen sich erst einmal miteinander anfreunden.
Es gibt hier viele Stolpersteine, über die man fallen kann. Wichtig ist, Möglichkeiten zu finden, diese zu umgehen. Ein solcher Prozess ist meist nicht auf Anhieb perfekt. Es braucht Zeit, bis sich alles eingespielt hat. Alle Teammitglieder müssen sich daran gewöhnen, dass es verschiedene Interessen gibt und jedes Interesse seine Berechtigung hat.
Wichtig ist vor allem, als Usability Engineer nicht aufzugeben und Eigenverantwortung zu zeigen: Niemand sagt einem in einem solchen Projekt, was zu tun ist. Man muss sich für das Thema einsetzen, seine Erfahrungen einbringen und mit dem Team Schritt für Schritt verwachsen, so dass im besten Fall irgendwann das Gefühl entsteht: Ohne geht es nicht.
Ich bin froh, dass das bei YAKINDU Traceability dank des tollen Teams mittlerweile genauso läuft!
Kommentare