Hintergrund
Ich arbeite in einem IT-Beratungsunternehmen mit etwa 200 Mitarbeitern. Wie in vielen anderen Unternehmen arbeiten wir an mehreren Projekten, mit kurzen Fristen, mit viel Druck, sowohl von internen Managern als auch von Kunden usw.
Letzte Woche wurde ein Mitarbeiter (B) eines anderen Teams während eines Anrufs über eine Person aus der Test-/QA-Abteilung wütend und sagte in einem wütenden Ton „Sie werden nicht dafür bezahlt, zu denken, sondern Tests durchzuführen“. Der Kern der Sache war, dass der Haupttester des Projekts Jira-Aufgaben mit Hunderten von Kommentaren mit Vorschlägen überschwemmte, „Ich denke das“, „Ich habe darüber nachgedacht“, „Ich schlage diese Entwicklung vor“ usw. Diese unaufgeforderten Kommentare sind oft nur lose mit dem Fehler verbunden. Aufgrund interner Richtlinien können die Fehler nur dann geschlossen werden, wenn alle Kommentare adressiert werden, sodass dieser Tester ein bereits verzögertes Projekt in Geiselhaft nahm und verzögerte.
In dem Anruf waren: B, andere Mitglieder des Entwicklungsteams, der Projektmanager (und direkter Manager von B), ein höherer Manager, der Tester und ein Teil seines Teams und der direkte Manager des Testers: Niemand sagte etwas zu diesem Satz.
Fragen
Wir haben über den Satz zwischen uns diskutiert und die allgemein akzeptierte Meinung ist, dass es unter diesen oder ähnlichen Umständen ein passabler Satz ist, aber es ist vorzuziehen, seine Verwendung einzuschränken. Ich habe auch mit einigen Freunden aus verschiedenen Branchen/Bereichen gesprochen, die stattdessen gesagt haben, dass sie alle davon überzeugt sind, dass das Urteil am Arbeitsplatz nicht akzeptabel ist. Wohingegen Freunde aus der IT unserem Fazit grundsätzlich zustimmen.
Ist das unter Umständen ein akzeptabler Satz? Es ist immer falsch am Arbeitsplatz? Könnte es, wer es sagt, irgendwelchen Konsequenzen aussetzen?
PS: es gibt keine Konsequenzen für B für diesen Satz und auch unaufgeforderte Kommentare des Testers werden gestoppt und alle Fehler werden geschlossen (normalerweise direkt vom Tester-Manager)
Update - 05/12
Vielen Dank an alle, die meine Frage beantwortet haben, ich hatte die Gelegenheit, viele Anregungen und interessante Standpunkte zu lesen.
Ich hatte gestern auch ein kurzes Gespräch mit B und er erklärte, dass der direkte Vorgesetzte des Testers eine E-Mail geschickt hatte, in der er sich für das Verhalten des Testers entschuldigte. Dieser Manager hat auch den Platz des Testers im Projekt eingenommen und alle Bugs sind nun geschlossen und das Produkt freigegeben. Schließlich hat dieser Manager den Tester von einer Position als Test-/QA-Teamleiter zu einer Position als einfacher Integrationstester in einem anderen Projekt versetzt (herabgestuft?).
Ist dies nach Ihrer Erfahrung und Ihrer Erfahrung unter Umständen ein akzeptabler Satz? Es ist immer falsch am Arbeitsplatz?
Wenn jemand sagt „Du wirst nicht dafür bezahlt, zu denken, sondern X zu tun“, solltest du das nicht wörtlich nehmen. In jedem Fall werden Sie dafür bezahlt, zumindest ein wenig nachzudenken, sonst würde ein Roboter Ihre Arbeit erledigen.
Normalerweise wird dieser Ausdruck verwendet, um wiederholte, unproduktive Argumente abzuschneiden und als Anweisung, an die Arbeit zu gehen.
Meiner Erfahrung nach ist es eine dumme Aussage, wenn jemand sie verwendet. Das bedeutet nicht, dass die implizite Begründung („zu viel streiten, zu wenig arbeiten“) falsch ist, sondern dass es normalerweise bessere Wege gibt, es auszudrücken.
In diesem speziellen Fall hat der Tester eindeutig unangemessen Meinungen in Jira-Aufgaben eingebracht, anstatt wie erwartet Fehler zu testen und zu melden. Der Kollege im anderen Team, der die Aussage gemacht hat, war ebenfalls unangemessen.
Das Management sollte allen helfen, ihre Rollen zu verstehen und wie viel persönliche Meinung einbezogen werden sollte. Wenn ich der QA-Leiter wäre, würde ich ein langes Gespräch sowohl mit dem Tester als auch mit dem Kollegen führen. Sie sollten auf dasselbe Ziel hinarbeiten und sich nicht passiv-aggressiv angreifen.
Wenn Sie in der IT tätig sind, werden Sie fürs Nachdenken bezahlt.
Der Satz, den Sie beschreiben, ist vielleicht das Falscheste, was ich in meiner IT-Karriere je gehört habe. Kein IT-Personal wird jemals dafür bezahlt, nicht zu denken, sonst würde seine Arbeit automatisiert.
Es hört sich so an, als ob das eigentliche Problem darin besteht, dass Ihr Kollege einfach nicht die richtigen Kanäle verwendet, um mögliche Verbesserungen zu kommunizieren, und sich dafür entscheidet, sie in Bug-Tracking-bezogene Themen statt in Vorschläge/Verbesserungs-Themen zu stellen.
Einige mögliche alternative Sätze, die Sie verwenden könnten.
Es gibt viele weitere Sätze, die man verwenden kann, um seinen Standpunkt klar zu machen, ohne dass sich der Kollege nicht wertgeschätzt fühlt.
Dies ist aus mehreren Gründen keine produktive Antwort:
Aufgrund dieses Ausbruchs ist es möglich, dass die QA-Person etwas schwerwiegendes Unrecht bemerkt, das außerhalb des Bereichs ihrer beruflichen Pflichten liegt, und sie es nicht meldet, und das gesamte Unternehmen könnte darunter leiden.
Kollege B hat recht damit, dass die QA-Person ihre Aufgaben nicht richtig erfüllt und sich dies auf andere Mitarbeiter und das Unternehmen selbst auswirkt. Kollege B hatte diesen Satz nicht richtig gesagt. Sie müssen sich entschuldigen, und dann muss es eine Art Treffen geben, um zu klären, wie Vorschläge und Kommentare gemacht werden sollten, um sicherzustellen, dass das Projekt vorankommt.
„Du wirst nicht dafür bezahlt, zu denken, sondern X zu tun“ ist am Arbeitsplatz immer falsch?
Vielleicht nicht, aber es ist immer eine rote Fahne. Irgendwo könnte etwas falsch sein, und dieser Fehler sollte angegangen werden.
Wenn dieser Satz gelegentlich „entweicht“, ist das vielleicht kein Weltuntergang, aber wenn er zum Mantra wird, sinkt das „Schiff“ wahrscheinlich. Finden Sie ein gesünderes, stärkeres Schiff.
Natürlich gibt es noch eine andere Seite des Problems - die Fülle an Kommentaren, ihre Qualität und was man beruflich damit macht.
Als erstes müssen die Kommentare objektiv analysiert werden : Sind sie wirklich nützlich, um den Prozess / das Testen / das Produkt zu verbessern?
Als nächstes müssen die Auswirkungen und die Dringlichkeit der Kommentare analysiert werden. Darauf aufbauend erfolgt eine Priorisierung. Anschließend müssen die aus den Kommentaren abgeleiteten Maßnahmen zur Umsetzung im Projekt geplant werden.
Fazit: IT ohne Nachdenken ist ein Rezept für eine Katastrophe . Früher oder später. In gewisser Weise. Die Beispiele sind in unzähligen gedruckten Büchern und im Internet reichlich vorhanden.
„Man wird nicht dafür bezahlt, zu denken, sondern zu testen“
Ein Kommentar wie dieser ist immer inakzeptabel. Problemlösung, kritisches Denken und Synthese sind die Gründe, warum Unternehmen Mitarbeiter einstellen – zu behaupten, dies seien keine wichtigen Beiträge eines Kollegen, ist entwürdigend und respektlos.
Ihr Kollege hat vielleicht versucht, seine Frustration auszudrücken oder Coaching anzubieten, aber dieser spezielle Kommentar war auch nicht produktiv. Es tut mir leid, dass du das erlebt hast.
Das so auszudrücken ist ganz offensichtlich unhöflich. Ein besserer Weg wäre gewesen: „Sie machen Ihren Job nicht. Was Sie tun, verschwendet die Zeit aller und kostet das Unternehmen Geld“. (Es war auch faktisch falsch. QA wird dafür bezahlt, nachzudenken. Richtiges Nachdenken hätte diese JIRAs vermieden, die Zeit und Geld verschwendet haben).
Die Aufgabe der QA besteht jedoch darin, sicherzustellen, dass das Produkt von ausreichender Qualität für den Verkauf / Versand ist. Sie werden JIRAs erstellen, wenn es Probleme gibt, die ein Entwickler beheben muss.
Wenn dieser QA-Mitarbeiter die Entwickler mit rein meinungsbasierten Vorschlägen überschwemmt, ist das kontraproduktiv. Der Entwickler wird und sollte auf keinen Fall eine Änderung aufgrund eines solchen Vorschlags vornehmen. Das sollte an einen Produktmanager gehen, der entscheiden sollte, was getan werden muss, und Aufgaben erstellen sollte, um eine solche Änderung vorzunehmen, oder keine derartigen Aufgaben erstellen sollte.
Es sieht also so aus, als hätte dieser QA-Mitarbeiter die Zeit des Entwicklers verschwendet. Ich erwarte von QA, ein JIRA zu bekommen, wenn etwas nicht so funktioniert, wie es funktionieren soll. Und manchmal, um ein JIRA zu bekommen, wenn etwas so funktioniert, wie es entworfen wurde, aber die Art und Weise, wie es entworfen wurde, nicht gut ist. Ich erwarte nicht, mit Hunderten von JIRAs überschwemmt zu werden, die ich alle ablehnen werde.
Es kann also einen Punkt geben, an dem die Zeitverschwendung von jemandem zu Unhöflichkeit führt. Wie Sie weiter sagten, scheint es funktioniert zu haben. Der QA-Mitarbeiter verstand seine Arbeit nicht, machte seine Arbeit nicht, mit schlimmen Folgen (Verzögerungen) für das Unternehmen, und die Unhöflichkeit führte zu einem Ergebnis – der Grund für die Unhöflichkeit wurde behoben. Irgendjemand, nehme ich an, erklärte ihm seinen Job.
PS. Wenn die QA-Person nicht nur Zeit verschwendet, sondern das ganze Projekt verzögert, indem sie einen Kommentar hinzufügt „Ich denke , dieser Knopf sollte grün statt blau sein“, nachdem ihr wiederholt gesagt wurde, dass sie diesen Unsinn nicht machen soll, dann wird ihr gesagt: „Du wirst nicht dafür bezahlt, nachzudenken “ ist verständlich.
Der Kern der Sache war, dass der Haupttester des Projekts Jira-Aufgaben mit Hunderten von Kommentaren und Vorschlägen überschwemmte
Ich persönlich kann verstehen, wie ärgerlich es wäre, wenn Sie jede Zeile lesen müssten, um herauszufinden, ob es einen Fehler gibt. Außerdem wären dies äußerst unproduktive Kommentare, wenn die Idee bereits an das Unternehmen verkauft ist und die Kommentare erneut vom Unternehmen bewertet werden müssten.
Ich möchte einfach anmerken, dass die Kommentare nicht produktiv sind, da die Idee bereits verkauft ist und das Unternehmen es so will. Ich möchte auch darauf hinweisen, dass das Schreiben von Hunderten von Kommentaren kontraproduktiv wäre, da es schwierig ist, zwischen tatsächlichen Fehlern und bloßen Kommentaren zu unterscheiden.
Ich denke, zu schreien, dass er nicht dafür bezahlt wird, wäre unproduktiv, aber ein verständlicher Ausbruch. Ich würde diese Gelegenheit nutzen, um den Kern der Sache zum Vorschein zu bringen.
Halten Sie die Kommunikationskanäle offen
Ein guter QA-Tester wird tief in das System eintauchen, das Sie entwickeln, und Dinge entdecken, nach denen er nicht ausdrücklich suchen sollte. Sie haben Erfahrung mit der Prüfung von Software und können wertvolle Anregungen geben. Sie wollen diesen Informationskanal wirklich nicht schließen.
... Aber halten Sie sie organisiert
Ihr Unternehmen hat jedoch einen Prozess zum Verfolgen von Fehlern (gut), mit Regeln, dass ein Fehler nicht geschlossen werden kann, bis alle Kommentare bearbeitet wurden (gut), und der Tester Kommentare abseits des Themas eingibt (schlecht). Sie müssen den Tester dazu bringen, seine Eingaben an der richtigen Stelle und nicht an der falschen Stelle zu platzieren. Als Abkürzung können Sie einen Text wie diesen verwenden:
„Kommentar geschlossen, nicht zum Thema.
Sie müssen sicherstellen, dass der entsprechende Ort tatsächlich existiert und funktioniert. Wenn Ihr Tester keinen geeigneten Ort hat, um „das ist mir auch aufgefallen“-Dinge zu melden, auf die die Leute reagieren, dann haben Sie dieses Problem selbst verursacht.
Ich frage mich, ob Ihr aktueller Kommunikationsprozess nur darin besteht, dass Sie bestimmte Fragen stellen (Testfälle)? Wohin soll der Tester gehen, wenn er etwas zu melden hat, das nicht gefragt wurde? Wird dieser Kanal ernst genommen? Das Einfügen von Kommentaren in "Muss alle Kommentare vor dem Schließen behandeln"-Fehlerberichte kann ein Hilferuf sein.
Erklären Sie "geht nicht"
Es ist nicht die Aufgabe der Qualitätssicherung zu entscheiden, welche Funktionen in das Produkt einfließen. Um ein erfolgreiches Produkt herzustellen, müssen Sie auch entscheiden, auf welche Funktionen Sie verzichten möchten . Weil sie nicht benötigt werden oder nicht wertvoll genug sind, um sie im letzten Moment hinzuzufügen und eine Deadline zu riskieren. Sie müssen Ihrem Tester erklären, dass Sie zwar Vorschläge schätzen, dies aber nicht bedeutet, dass Sie sie alle annehmen werden.
Machen Sie einen Unterschied zwischen der Beachtung von Vorschlägen und deren Annahme. Wenn der Tester eine Funktion oder Verbesserung vorschlägt und Sie sich dagegen entscheiden, nehmen Sie dies zur Kenntnis, anstatt den Eindruck zu erwecken, dass Sie den Vorschlag nicht einmal gesehen haben.
Dieser Satz ist nur akzeptabel, wenn Sie versuchen, die Rolle eines Tyrannen zu spielen, und wird normalerweise von einem schlechten Manager verwendet. Normalerweise zeigt es nur an, dass die Person, die es verwendet, entweder mit dem Argument nicht umgehen kann oder anderen Menschen nicht zuhören kann. Die andere Form dieses Satzes ist „weil ich es gesagt habe“. In Ihrem Fall klingt es nach einer einfachen Möglichkeit, andere Personen abzuschneiden. Ich wähle keine Seite im Kampf, aber ich kann es aus beiden Blickwinkeln sehen (als QA oder als Entwickler, da ich Erfahrung in beiden habe). Persönlich habe ich in der von Ihnen beschriebenen Situation herausgefunden, dass es viel produktiver ist, ein separates Ticket für jeden einzelnen Artikel zu eröffnen: Für eine QA, die ein separates Ticket öffnet, kann sichergestellt werden, dass das angesprochene Problem untersucht wird. Als Entwickler ziehe ich das vor, damit das Ticket, an dem ich gerade arbeite, nicht in den Scope Creep-Bereich hineinwächst.
Es gibt jedoch einige seltene Fälle, in denen die Funktion implementiert wurde, wie erwartet funktioniert und auf dem Papier im wirklichen Leben fantastisch aussieht, macht keinen Sinn. Die meisten davon werden normalerweise von einer guten Qualitätssicherung erwischt, und die härtesten, da jeder sein Bestes gegeben hat, aber das Ergebnis entweder null oder negativ ist. Ich halte immer Ausschau nach Hinweisen auf solches Feedback von QA und versuche, es auf ein Reißbrett zu bringen. Normalerweise erscheint ein solches Feedback als nicht relevanter Kommentar im Ticket. In einem solchen Fall würde ich es vorziehen, ein Gespräch mit der Person zu führen, die solche Informationen bereitstellt, um herauszufinden, ob dies der Fall ist oder nicht. Wenn Gespräche mit der Person, die einen solchen Kommentar macht, wirklich in einem solchen Fall enden, sollten Sie so reagieren, andernfalls bitten Sie die Person, ein Ticket zu erstellen, oder erstellen Sie es für sie.
Grundsätzlich ist es produktiver, wenn Sie an einen Punkt kommen, an dem ein Gespräch etwas hitzig wird, einatmen, ausatmen, etwas sagen wie "Ich muss darüber nachdenken und ich werde auf dem Ticket antworten", Ihre Ruhe wiedererlangen, schreiben Sie und wenn Sie sicher sind, dass Sie Recht haben, schreiben Sie Ihre Argumente in das Ticket, warum es jetzt irrelevant/ungültig/egal ist. Dies ist jedoch ein zweischneidiges Schwert, denn wenn die andere Person Recht hatte und Sie nicht, haben Sie das jetzt dokumentiert.
Und denken Sie daran, dass all diese Dinge nicht als Entwickler (dba vs. Backend vs. ui) vs. QA vs. Client vs. wer auch immer betrachtet werden sollten. Die Beziehung sollte so sein devs + QA + client + whoever = great product. Ich war in Umgebungen mit einem starken „Free for All“-Umfeld, wo ich kooperativ agierte und im Gegenzug auch so behandelt wurde.
Tests sind ein gewisser Sonderfall, wenn es um die IT-Arbeit geht. Besonders formale, insbesondere Regressionstests.
Wenn ein Test vordokumentiert wird (was zum Testen getan wird) und die Ergebnisse am Ende auf PASS oder FAIL reduziert werden, sagt das Endergebnis immer noch "X, Y, Z ... wurde durchgeführt, zum Ergebnis von .. .".
X, Y, Z, die getestet werden, können durch eine Vertragsspezifikation mit einem Kunden definiert werden, eine Änderung der Tests kann die Haftung auf sehr unglückliche Weise umverteilen, wenn ein Fehler auftaucht (oder im schlimmsten Fall einen echten Schaden verursacht), der erfasst worden wäre, wenn der Testverfahren wurde genau eingehalten. Die Kehrseite dieser Medaille: Sollte ein Mangel durch vorgeschriebene und vereinbarte Prüfungen nachweislich nicht entdeckt werden, kann das Produkt je nach Vertrag trotzdem als spezifikationsgerecht verkauft und in Rechnung gestellt werden, Mittelfinger als Prämie inklusive.
Aus einer breiteren Perspektive können Arbeiten (nach Spezifikation) bereits beschrieben, angeboten, kalkuliert und VERKAUFT worden sein. Während eine nachträgliche Änderung die Effizienz steigern könnte (bereits berechnet!), erhöht sie auch das Risiko (bereits berechnet!).
Nyos