So legen Sie richtig ausgerichtete KPIs für Ingenieure und QA-Mitarbeiter fest

Einleitung

Ich richte gerne KPIs für meine Engineering-/QA-Teams ein. Ich verwende dies, um die Leistung zu bewerten und bei der Bestimmung des Bonus/der Gehaltserhöhung in jedem Quartal zu helfen.

Dies ist ein KPI, den ich für meine Ingenieure festgelegt habe:

  • % der Aufgaben, die die QA ohne Fehler bestanden haben

    • dh je nach QA-Ablauf (pro Problem oder pro Sprint) sehen wir, wie viele Fehler für alle Probleme gemeldet wurden, die von 1. dem Techniker, der das Problem behoben hat, 2. dem anderen Techniker, der es überprüft hat, gemeldet wurden.
      • dh in einem bestimmten Sprint hat Ingenieur X 20 Probleme gelöst, die von Ingenieur Y überprüft wurden. Angenommen, die QA erledigt ihre Arbeit auf Sprintbasis und die QA hat 5 Fehler in diesen 20 Problemen gefunden, die Aufgaben, die die QA ohne Fehlerprozentsatz bestanden haben ist 75%

  • % der Aufgaben, die nach der Bereitstellung ordnungsgemäß funktioniert haben Dieselbe Idee wie oben, aber diese wird für Code behandelt, der tatsächlich live veröffentlicht und von Benutzern verwendet wird

Dies ist ein KPI, den ich für meine QA-Mitarbeiter habe:

  • Anzahl der gefundenen Fehler pro Problem
    • dh je mehr Bugs ein QA-Personal in einem Issue findet, desto besser.

Problem

Die KPIs für die Ingenieure und das QA-Personal wirken widersprüchlich, oder anders gesagt: Sie wirken wie ein Nullsummenspiel. Was natürlich nicht gut für die Moral der Mitarbeiter ist und Rivalität/Ressentiments hervorrufen würde.

Wie kann ich dies ändern, damit sowohl Ingenieure als auch QA-Mitarbeiter über KPIs verfügen, die sie dazu bringen, zusammen statt gegeneinander zu arbeiten?

Update: ein konkreter Fall

Dies ist eine Antwort auf die Antwort von novigt unten sowie in Bezug auf diesen Kommentar zu einem verwandten Beitrag:

Sind die Tester vor einem Build beteiligt? Das heißt, sind sie an der Entwicklung der Anforderungen oder Anwendungsfälle oder Benutzergeschichten, der Überprüfung der Designdokumentation oder der Teilnahme an Codeüberprüfungen beteiligt? ...

Ich dachte mir, dass die richtige und solide Dokumentation von Szenarien ein großer Teil der Bewertung von QA-Personal ist (denken Sie daran, dass ich hier von nicht-technischem QA spreche, das einfach Black-Box-Tests durchführt und keine automatisierten Tests usw. durchführen kann).

Ich stimme zu, dass eine Metrik, die die Gesamtzahl der Fehler berechnet, falsch ist, und ich stimme der Metrik für Vorfälle in der Produktion zu .

Lassen Sie mich meine neue Metrik anhand eines Beispiels erläutern:

Geben Sie hier die Bildbeschreibung ein

Angenommen, ich habe einen einzelnen Anmeldebildschirm (Passwort vergessen/Erinnerung an mich usw., der Kürze halber nicht enthalten), den ich erstellen und bereitstellen möchte. Unter Verwendung der Gherkin-Syntax schreibt der QA-Ingenieur die folgenden Szenarien:

Szenario 1: Happy-Path-Login-
given Benutzer gibt korrekten Benutzernamen/pwd ein
whenBenutzer klickt auf Login-
thenBenutzer sollte zum Dashboard geleitet werden

Szenario 2: Anmeldefehler
given Benutzer gibt falschen Benutzernamen/Kennwort ein
whenBenutzer klickt auf Anmeldefehlermeldung
thenzeigt: falscher Benutzername/Kennwort

Diese Dokumentation wird den Ingenieuren (zusammen mit den Entwürfen) im ersten Sprint übergeben , die sie entwickeln, einem Peer-Review unterziehen, sie zum Testen an die Qualitätssicherung zurücksenden und dann in Version 0.0.01 der App bereitgestellt wird.

Einmal auf Prod passiert der folgende Fehler

givenDer Benutzer gibt den richtigen Benutzernamen/pwd ein.
andDer Server ist ausgefallen. Der whenBenutzer klickt auf die Anmeldung. Der
then
erwartete
Benutzer sollte eine Fehlermeldung erhalten: Der Dienst ist derzeit nicht verfügbar .
Tatsächlich
dreht sich ein Spinner für immer

Hier sind die KPIs/Metriken, die wir für dieses Szenario erfassen:

  • Anzahl Szenarien: 2
  • Anzahl der Vorfälle in der Produktion: 1

Metriken als Momentaufnahme geben nicht das ganze Bild wieder, also machen wir weiter:

Im zweiten Sprint aktualisiert das QA-Personal die Dokumentation mit Szenario 3:

Szenario 3: Anmeldung verarbeiten, wenn Server ausgefallen ist
given Benutzer gibt korrekten Benutzernamen/pwd ein
andServer ist ausgefallen
whenBenutzer klickt auf Anmeldung
thenBenutzer sollte eine Fehlermeldung erhalten: Der Dienst ist derzeit nicht verfügbar

Die Ingenieure beheben diesen Fehler und stellen ihn in Version 0.0.02 bereit . In der Version tritt dieser Fehler auf:

givenDer Benutzer gibt den richtigen Benutzernamen/pwd ein.
andDer Benutzer ist nicht mit dem Internet verbunden . Der whenBenutzer klickt auf die Anmeldung. Der
then
erwartete
Benutzer sollte eine Fehlermeldung erhalten: Der Benutzer ist offline .
Tatsächlich
dreht sich ein Spinner für immer

Hier sind die KPIs/Metriken, die wir für dieses Szenario erfassen:

  • Anzahl Szenarien: 3

  • Anzahl der Vorfälle in der Produktion: 1

  • Steigerungsrate der Szenarien: 33%

  • Abnahmerate der Zwischenfälle in der Produktion: 0 %

Daher verwenden wir die letzten beiden KPIs (Zunahme der Szenarien und Abnahme der Vorfälle in der Produktion) zusammen, um die Leistung einer QA-Person zu bewerten. Die abschließende Bewertung sollte beide KPIs (zusätzlich zu anderen Metriken, die an anderer Stelle besprochen werden können) verwenden, um einen Ingenieur zu bewerten. Auf diese Weise ist die Zunahme von Useless-Case-Szenarien allein nicht positiv, und auch eine Zunahme von Zwischenfällen in der Produktion ohne eine entsprechende Zunahme von Szenarien sollte für den Ingenieur ein Warnsignal sein. Ich weiß, dass man dies auch erreichen kann, indem man umfassende Unit-Tests mit einer Codeabdeckung von >95% usw. durchführt, aber nehmen wir an, wir sind noch nicht so weit.

Gibt es ein Problem damit?

"Sobald auf prod, tritt folgender Fehler auf" Dies ist kein Fehler . Ein Bug ist eine Abweichung von der Spezifikation. Das war von Anfang an nie in der Spezifikation. Wenn Sie dies als Fehler bezeichnen, werden Ihre Ingenieure sehr unglücklich sein. Ein Fehler ist ein Fehler, den ich als Ingenieur gemacht habe, etwas, das nicht wie angegeben funktioniert. Etwas, das nicht in der Spezifikation enthalten ist, ist eine Feature-Anfrage und sollte niemals jemand anderem als dem, der die Spezifikation schreibt, vorgeworfen werden.
@nvoigt fair genug, ich werde es nicht einen Fehler nennen, ich werde es Spezifikationsfehler nennen .
Wer trifft das Urteil, dass die QA das hätte spezifizieren sollen? Und wenn diese Person weiß, was hätte spezifiziert werden sollen, warum hat sie es dann nicht gleich getan, anstatt die armen QA-Jungs raten zu lassen?
Es ist die Aufgabe der QA sicherzustellen, dass die Dokumentation alle möglichen Anwendungsfälle abdeckt. Das bedeutet nicht, dass alle diese Anwendungsfälle in Version 0.0.01 implementiert werden, aber wir müssen zumindest wissen, dass sie existieren (sie können in einer späteren Version gemäß dem Lean-Modell durchgeführt werden). Außerdem geht es hier nicht um alles oder nichts. Ich sage nicht, dass die QA auf dem Parkplatz verprügelt wird , wenn ein Spezifikationsfehler auftritt . Ich sage, dass dies Metriken sind, die wir als Ergänzung in ihrer Bewertung verwenden können ...
.. D. h. wenn ich einen Mitarbeiter bewerte, schaue ich mir mehrere Dinge an, einschließlich ihrer KPIs. Sie machen eine absolute Aussage, dass alle Metriken/KPI's schlecht sind? Lassen Sie mich versuchen, die Dinge mehr aus Ihrer Perspektive zu sehen. Angenommen, Sie haben Wissensarbeiter, die Ihnen unterstellt sind, wie bewerten Sie deren Leistung (ohne jegliche Metrik)? Und wie können Sie diese Einschätzung untermauern? Wie können Sie diesen Prozess skalieren?
Nun, wenn Ihre QA Ihre Spezifikationen schreibt, hoffe ich, dass Sie sie verdammt gut bezahlen, denn das liegt weit über der Gehaltsstufe normaler QA-Arbeit. Es wäre die Aufgabe eines Business Analyst oder Product Owner, je nachdem, wie agil Sie sein möchten. Wie auch immer, nein, ich habe keine KPIs und ich kann nur auf der Grundlage meines Verständnisses des technischen Teils und meines Bauchgefühls urteilen. Ich sage nicht, dass das großartig ist. Es übertrifft einfach die Metriken, die ich bisher gesehen habe. Ich hätte gerne transparente KPIs, aber alles, was ich weiß, kann leicht von Wissensarbeitern gespielt werden. Am Ende zählt die Lieferung eines fehlerfreien Produkts.
.. aber wir wissen, dass es im wirklichen Leben kein fehlerfreies Produkt gibt?
wie auch immer.. du hast mir schon so viel zu denken gegeben.. ich muss ein paar bücher lesen und mehr recherchieren, ich fühle mich definitiv nicht so stark mit all dem wie ich es tat.. danke für all deine infos :)
Gern geschehen. Ich mag die Tatsache, dass du darüber nachdenkst. Es gibt zu viele Leute da draußen, die das nicht tun (und ich habe ihre Metriken gesehen ...).
Kurze Frage @nvoigt: Was halten Sie von der Idee, Metriken zu verwenden, um Prozesse in der Organisation zu verbessern, anstatt Einzelpersonen zu bestrafen/belohnen? Dh datengetriebene Prozessverbesserung

Antworten (1)

Als Ingenieur übernehme ich jetzt also eine einzelne Aufgabe, grüble 4 Wochen lang darüber nach, stelle sicher, dass sie überhaupt keine Fehler enthält, und ich bin der beste Arbeiter, den Sie je hatten. Obwohl ich für eine so einfache Aufgabe 4 Wochen gebraucht habe.

Auf der anderen Seite haben Sie die QA, die stark darauf angewiesen ist, einen beschissenen Ingenieur zuzuweisen. Je beschissener der Ingenieur, desto mehr Belohnungen erhält die QA. Was passiert, wenn ich ein Produkt von einem guten Ingenieur testen muss? Wird mir ein Plan zur Leistungsverbesserung auferlegt, weil ich nicht genügend Fehler gefunden habe?

Ihre Metriken sind willkürlich und weniger als nützlich. Ihre Leute sind keine Arbeiterdrohnen, sie nutzen ihre Intelligenz, um ihre Arbeit zu erledigen. Beleidigen Sie sie also nicht mit Metriken, die leicht gespielt werden können.

Beginnen Sie zumindest mit dem, was wirklich zählt: Vorfällen in der Produktion . Fehler, die sowohl Ingenieuren als auch QA entgangen sind. Versuchen Sie, diese zu minimieren, und Sie werden sehen, dass Ingenieure und QA eigentlich ein Team sind, das auf dasselbe Endziel hinarbeitet.

Es ist jedoch fraglich, ob es sich für Geheimdienstmitarbeiter lohnt, Metriken zu haben. Noch hat niemand die richtigen gefunden und die falschen können leicht nach hinten losgehen. Wenn Sie irgendetwas auf Ihren KPIs (wie Lob oder Gehalt) basieren, seien Sie darauf vorbereitet, dass die Leute schlau genug sein werden, Sie bei jedem von ihnen auszutricksen. Dann stecken Sie mit Leuten fest, die ihre Arbeit gemacht haben, aber nach den Metriken durchschnittlich aussehen, und Leuten, die das System gespielt haben, anstatt gute Arbeit zu leisten, aber auf Ihrem System großartig aussehen.

Ihr Punkt ist gut getroffen, dass der anfängliche KPI nicht nützlich ist. Ich habe meine Frage mit einer anderen Metrik aktualisiert, die hoffentlich Ihre Punkte anspricht. Bitte werfen Sie einen Blick darauf. Außerdem: Es ist fraglich, ob es sich für Geheimdienstmitarbeiter lohnt, Metriken zu haben. Bisher hat noch niemand die richtigen gefunden. Können Sie bitte eine Studie oder Statistik (oder sogar einen Meinungsartikel) nennen, die diesen Punkt unterstützt?
@abbood Nein, ich kann etwas nicht sichern, was nicht existiert. Ich habe noch nie KPIs gesehen, die für Wissensarbeiter gut funktionierten, noch habe ich von ihnen gehört. Wenn Sie welche finden, lassen Sie es mich wissen, ich würde mich freuen, sie zu haben.
@abbood Joel hat (hatte, aber mir sind keine Änderungen bekannt) eine ähnliche Einstellung zu KPIs für Wissensarbeiter .
@nvoigt Wie bewertet BA die Lösung anhand von KPI? Eigentlich habe ich nur wenige Empfehlungen zu geschäftlichen und technologischen Aspekten und versuche, die Lösung zu bewerten, aber es fällt mir wirklich schwer, den KPI zu identifizieren. Können Sie mir mindestens 2-3 KPIs für den Start geben oder mir eine Vorstellung davon geben, wie die KPIs aussehen sollten?
So legen Sie richtig ausgerichtete KPIs für Ingenieure und QA-Mitarbeiter fest
AntwortenHierDatenschutz-Bestimmungen1y, 0v