Umgang mit schlechten Nachrichten

Vor ein paar Wochen ist mir etwas klar geworden. Als agiler Tester ist es wirklich schwer, Fehler zu kommunizieren! Tester sind dafür bekannt, dass sie schlechte Nachrichten überbringen, aber es ist nicht einfach, dies richtig zu tun. Vor allem, wenn Sie in einem Scrum-Team sind und es richtig heiß hergeht, weil überall Fehler oder Probleme herumfliegen.

Stellen Sie sich vor, Sie verkaufen Ihr Haus und ein potenzieller Käufer kommt innerhalb einer Stunde, um Ihre Immobilie zu besichtigen. Ihr Haus ist ein einziges Durcheinander und Sie müssen es dringend aufräumen. Sie fangen sofort an und arbeiten hart, um die Arbeit zu erledigen. Sie saugen jede Ecke ab und polieren jede Vase auf dem Tisch. Qualität ohne Kompromisse geht Ihnen nicht aus dem Kopf. Dann kommt Ihr Immobilienmakler herein und sieht sich die Wohnung an. Sie hören ihn murmeln, während er Ihr Haus untersucht. Sie haben Ihr Bestes gegeben und dann sagt er Ihnen, was Sie falsch gemacht haben. Er erzählt Ihnen, dass der potenzielle Käufer sich sehr für Feng Shui interessiert und dass er der Meinung ist, dass die Wohnung überhaupt nicht ausgewogen aussieht. Das ist irgendwie frustrierend, nicht wahr? Woher sollten Sie das wissen? Überlegen Sie, wie Sie auf Ihren Makler reagieren würden.   Manche Menschen vermeiden es ganz und gar, schlechte Nachrichten zu sehen oder zu überbringen. Sie schieben sie so lange wie möglich hinaus und weichen ihnen manchmal aus. Wenn Sie wirklich erfolgreich und kompetent in dem sein wollen, was Sie tun, sollten Sie keine Angst davor haben, schlechte Nachrichten zu erhalten und zu überbringen. Echte Gewinner versuchen sogar, sie so schnell wie möglich zu erkennen. Gewinner stellen sich den Herausforderungen und nehmen sie an. In traditionellen Wasserfallprojekten arbeiten die Tester zusammen und testen das Produkt. Aber es ist keine Herausforderung, Fehler über Excel-Tabellen oder andere elektronische Tools zu kommunizieren. Es gibt keine Rückmeldung und zeigt keine Emotionen. Es ist auch nicht schwer, sie mit Ihren Testkollegen zu kommunizieren. Sie sind alle auf der gleichen "Test"-Seite. Und das ist meiner Meinung nach eine ganz schlechte Praxis. In der Softwareentwicklung sollte es keine Seiten geben. Wir entwickeln Software gemeinsam. Wir sind alle daran beteiligt, das Leben der Menschen zu verändern. Ich habe einige Tester kennengelernt, denen die Fehler oder Bugs im Produkt wirklich egal waren. Sie zeigten keinerlei Engagement für das Produkt. Einige dieser Tester waren sogar froh darüber, einen Fehler gefunden zu haben, und freuten sich darüber, zeigen zu können, wie er behoben wurde. Das ist schlecht... Es gibt viele Möglichkeiten, mit schlechten Nachrichten umzugehen. Aber das Wichtigste ist, dass wir aufhören sollten, schlechte Nachrichten zu meiden. Vielleicht ist das eine Selbstverständlichkeit, aber hören Sie auf, Ausreden zu finden! Zwingen Sie sich, diese Gewohnheit abzulegen. Ja, es ist schmerzhaft, dieses flaue Gefühl im Magen, wenn Sie herausfinden, dass die Dinge nicht so laufen, wie sie sollten. Und ja, es ist schwierig, diesen Schmerz in Ihren Prozess einzubeziehen. Aber in dieser Situation ist er absolut notwendig. Bringen Sie die schlechte Nachricht. Suchen Sie sie heraus. Spekulieren Sie über ihre möglichen Quellen. Garbage In, Garbage Out Wenn Sie einem Entwickler ein Problem mitteilen wollen, versuchen Sie zu verstehen, dass die Möglichkeit besteht, dass die benötigte Funktionalität nicht gut erklärt oder verstanden wird. Garbage In, Garbage Out... Die Entwickler haben bereits mit dem Schreiben von Code zu kämpfen. Machen Sie niemanden dafür verantwortlich, dass er nicht jede Kleinigkeit weiß. Vermitteln Sie Ihre Erkenntnisse auch anhand eines konkreten Beispiels. Abstraktes verwirrt die Situation noch mehr. Zeigen Sie also die Schritte, mit denen Sie das Problem reproduzieren können (oder schreiben Sie sie auf). Jeder ist verantwortlich Stellen Sie sicher, dass Sie nicht der Einzige sind, der schlechte Nachrichten oder Probleme meldet. Testen sollte eine Teamleistung sein. Jeder sollte an den Tests beteiligt sein, um einen besseren Einblick in das Produkt zu erhalten. Die Automatisierung Ihrer Tests ist hilfreich, aber versuchen Sie, sie gemeinsam mit dem gesamten Team zu entwickeln, damit alle daran beteiligt sind, die Tests richtig durchzuführen. Wenn etwas Schlimmes passiert, ist das ganze Team, einschließlich des Testers, dafür verantwortlich, dass dies nicht im Voraus bekannt ist. Es sind nicht die Symptome des Problems, die behandelt werden müssen, sondern die Ursache Wenn Sie einen Fehler von Ihrem Teamkollegen erhalten. Beheben Sie ihn nicht sofort. Versuchen Sie herauszufinden, woher der Fehler kommt und warum er erst so spät aufgetreten ist. In den meisten Fällen liegt es an einer offensichtlichen Annahme, die Sie während Ihrer Arbeit gemacht haben. Stellen Sie sicher, dass Sie alle Annahmen überprüfen und mit Ihren Teamkollegen besprechen. Helfen Sie den Entwicklern beim Testen Wiederkehrende Probleme sollten vermieden werden. Aber wenn es doch passiert, sollten Sie nicht zu negativ reagieren, wenn Sie dieses Problem (erneut) kommunizieren. Wenn Sie sehen, dass ein Problem nach einer Fehlerbehebung wieder auftritt, versuchen Sie, den Entwicklern bei der Erstellung eines automatisierten (Unit-)Tests zu helfen. Erklären Sie Ihrem Teamkollegen, warum es wichtig ist, dafür zu sorgen, dass dieses Problem nicht wieder auftritt. Überwindung schlechter Nachrichten Eines der Dinge, die mir bei der Arbeit mit "erfolgreichen" Scrum-Teams aufgefallen sind, ist, dass sie alle schlechten Nachrichten / Probleme überwunden haben. Nennen Sie sie agil oder nicht, es ist mir egal. Das Team (einschließlich der Tester, Entwickler, Business-Analysten usw.) wusste, dass ihnen eine Vielzahl von Hindernissen in den Weg gelegt werden würde. Das Ignorieren von Fehlern war inakzeptabel. Sie versuchten, so viel wie möglich über das Problem zu wissen und eine Strategie zu formulieren, um die Situation zu "besiegen". Die Übermittlung schlechter Nachrichten führte dazu, dass sie keine Ressourcen mehr für weniger wichtige Bemühungen verschwendeten. Sie wollten lieber früher als später von Problemen erfahren, die wichtigen Benutzern im Weg standen.