Soll ich einen Softwareentwickler darüber informieren, dass er seine Testproduktivität verbessern muss?

Wir haben einen Junior-Softwareentwickler eingestellt, der sich in allen erdenklichen Metriken hervorgetan hat – mit Ausnahme der Zeit, die er benötigt, um den von ihm geschriebenen Code manuell zu testen. Wir haben vor Kurzem unser QA-Team entlassen und erwarten nun von den Entwicklern, dass sie ihre eigenen eingehenden Tests durchführen

Hier kommt das Problem: Für eine bestimmte Funktionsentwicklungsaufgabe, für deren Schreiben ein anderer fortgeschrittener/leitender Entwickler 2 Monate benötigen würde, plus Meetings und Hilfe von mir und einigen der anderen leitenden Ingenieure, die die Codebasis geschrieben haben, und 3 Tage zum Testen. Er braucht 1 Monat, um selbstständig absolut schönen und performanten Code zu schreibenmit fast 0 Mängeln und 1-2 Wochen zum Testen. Und er ist erst seit ein paar Monaten bei uns! Das Management hat damit begonnen, seine Leerlaufzeiten zu verfolgen (aufgrund dessen, wie lange er zum Testen braucht) und wir haben festgestellt, dass er während der Testzyklen 50 % der Zeit untätig ist, womit das Management ein großes Problem hat, weil sie der Meinung sind, dass er härter arbeiten sollte und seine Eigenschaften schneller zu testen... trotz der Tatsache, dass er unser leistungsstärkstes Teammitglied ist... auf Junior-Niveau... dass wir auch deutlich unterbezahlen, wenn man bedenkt, welchen Wert er unserem Team bringt.

Ich möchte diesen Mann nicht wirklich verlieren, denn dann bin ich der Verantwortliche, der ihn ersetzt ... und ich halte ihn derzeit für den besten Mitarbeiter in meinem Team. Ich möchte ihm auch nichts sagen, weil wir ihm nicht so viel bezahlen und ich das Gefühl habe, dass er wahrscheinlich auf der Stelle kündigen wird (ich finde ihn ein bisschen hitzköpfig) und sich einen neuen Job suchen, wenn ich bring ihm das vor. Ihn durch jemanden mit gleichen Fähigkeiten zu ersetzen, würde uns 2-3x mehr kosten als das, was wir ihm derzeit zahlen. Und wenn wir jemand anderen einstellen, gehen wir ein großes Risiko ein, dass er den Job nicht erledigen kann und ihn am Ende entlassen muss.

Ich habe dies mit dem Management besprochen und versucht zu argumentieren, dass wir etwas QA zurückbringen sollten, um die Testzeiten zu verkürzen, aber sie möchten ein Treffen mit ihm haben und Dinge eskalieren, die ich absolut nicht tun möchte.

Was soll ich hier tun?

Abgesehen davon, dass das Management ein Arsch ist, können Sie mir erklären, warum es in irgendeiner Weise ein Problem ist, dass ein Entwickler eine Aufgabe erledigt, die Ihrer Schätzung nach 2 Monate in 6 Wochen dauern würde?
@PhilipKendall das Problemmanagement besteht darin, dass sie statt 2-3 Tagen zum Testen (oder besser) 2 Wochen brauchen, und während der Testzeit ist ihr Computer 50 % des Tages im Leerlauf
Ich vermute, es liegt daran, dass er während des langen Testzyklus einen Teil der Zeit untätig ist, und sie denken, dass er dieselben Aufgaben in einem Monat erledigen sollte - er könnte doppelt so schnell sein, wenn seine Tests schneller wären.
@thursdaysgeek Richtig
We recently let our QA team go and have started to expect developers to do their own in-depth testing- Huch! Das ist eine rote Fahne für sich. Entwickler sind keine Tester, das ist eine andere Disziplin. Sie sollten auch niemals für die Qualitätssicherung von Code verantwortlich sein, den sie selbst geschrieben haben. Sie werden dieselben Fehler vermissen, die sie beim Schreiben übersehen haben.
@SethR absolut. An meinem Arbeitsplatz verlassen wir uns absolut auf unsere QA-Mitarbeiter, auch bei flächendeckenden automatisierten Tests. Es gibt eine völlig andere Gedankenmethode von „Ich brauche es, um das zu tun“ bis „Okay, wie mache ich das?“
„Wir haben festgestellt, dass er während der Testzyklen 50 % der Zeit untätig ist.“ Herzlichen Glückwunsch, Sie haben eine verrücktere Unternehmensmetrik für die Produktivität gefunden als geschriebene Codezeilen. Entwickler sind keine Arbeiter am Fließband, Denken ist auch Arbeit ... Sammeln Sie diese Metrik nicht, stufen Sie Mitarbeiter nicht nach dieser Metrik ein und schulen Sie Mitarbeiter definitiv nicht nach dieser Metrik. Meiner bescheidenen Meinung nach.
„Er ist mein bester Angestellter. Er übertrifft alle anderen im Team. Wir zahlen ihm nicht annähernd das, was er wert ist. Alles in allem verwenden wir eine lächerliche Leistungsmetrik, die auf Leerlaufzeiten basiert, und er bleibt zurück. Ich hoffe, ich tue es nicht muss ihn feuern." - Ich habe keine Worte.
Haben Sie eine Theorie dafür, warum er während der Tests 50 % der Zeit untätig ist? Bedenkzeit, Müdigkeit oder Abneigung gegen eine bestimmte Art von Aufgabe, vielleicht sogar nur der Overhead der Unerfahrenheit und der Organisation seiner Gedanken, könnten alle legitime Erklärungen sein. Es wirkt absolut kafkaesk, ihn damit zu konfrontieren, wenn man bereits akzeptiert, dass seine Codequalität sehr hoch ist und er insgesamt ein schneller Arbeiter ist. Es scheint eine bessere Strategie zu sein, ein Gespräch darüber zu eröffnen, was er tut, was ihn so produktiv macht, damit seine guten Praktiken vielleicht verallgemeinert werden können!
Gibt es angesichts dessen, wie gut und produktiv er ist, eine Chance, dass er beim Testen einfach einen viel besseren Job macht als andere Entwickler? Wenn Sie sich Fehler ansehen, die gefunden wurden, nachdem der Code getestet wurde, hat sein Code die Nase vorn?
Das Loslassen unseres QA-Teams – hier liegt das größte Problem: Entwickler wollen unterbewusst keine Probleme in ihrem Code finden. Jeder Fehler, den sie finden, schafft Arbeit für sich selbst. Unsere QA-Jungs haben damit kein Problem. Wenn sie mir zusätzliche Arbeit bereiten, haben sie gute Arbeit geleistet.
Let go of our QA team, tracking his idle times, we considerably underpay him, hope I don't have to fire him [the highest performer]. Das muss eine Trollfrage sein. Es liegt außerhalb meines Verständnisses, dass eine Person oder ein Unternehmen so schlecht im Management und so völlig blind sein kann.
Was heißt hier "leer"?
Wenn Sie glauben, dass eine Funktion, deren Entwicklung 1 bis 2 Monate dauert, in 2 bis 3 Tagen getestet werden kann, irren Sie sich ernsthaft und Sie haben wahrscheinlich gerade jetzt ernsthafte Mängel und andere Qualitätsprobleme in Ihrem Produkt. Dachten Sie, Ihr vorheriges QA-Team würde nichts tun? Ich denke, die 1 bis 2 Wochen, die der Entwickler zum Testen braucht, sind wahrscheinlich eher gering.
Bitte teilen Sie den Namen des Unternehmens mit, damit niemand das Pech haben muss, in den nächsten 2 Jahren, die es dauert, bis das Unternehmen sein Geschäft aufgibt, für diesen Ausbeuterbetrieb zu arbeiten.
"Was soll ich hier machen?" -- geben Sie ihm ein gutes Empfehlungsschreiben, schlagen Sie GTFO so schnell wie möglich vor (zu seinem eigenen Besten) und tun Sie dann selbst dasselbe.
„Ihn durch jemanden mit gleichen Fähigkeiten zu ersetzen, würde uns 2-3x mehr kosten als das, was wir ihm derzeit zahlen.“ -- Haben Sie dieses spezifische Geldproblem in dieser Hinsicht in den Gesprächen mit dem Management angesprochen? Ich würde denken, wenn das nicht dazu führt, dass sie ihren Kurs ändern, dann wird es nichts.

Antworten (5)

Sie haben ein Verwaltungsproblem. Und ob es wahr ist oder nicht, Sie sollten ihnen erklären, dass die Zeit, die er mit dem Testen verbringt, der Grund dafür ist, dass der Code so gut ist , und da er immer noch schneller ist als andere Leute, haben sie zwei Möglichkeiten:

  1. Lassen Sie ihn in Ruhe und hoffen Sie, ihn ein paar Jahre zu behalten, bevor er seinen Wert herausfindet und dorthin geht, wo er anständig bezahlt wird.
  2. Belästigen Sie ihn mit der Zeit, die er mit dem Testen verbringt, was entweder dazu führen wird, dass er nicht so guten Code liefert oder, was wahrscheinlicher ist, dass er es ganz verlässt.

oder sogar 3: Erkennen Sie, dass sie eine sehr gute Sache haben, und stellen Sie sicher, dass Sie die Ressourcen haben, um ihn so lange wie möglich glücklich zu machen, mit guten Arbeitsbedingungen, besserer Bezahlung - was auch immer nötig ist. Dass er dem Unternehmen genug Nutzen bringt, dass sie sich mehr darum kümmern sollten als um die Zeit, in der er sich beim Testen ausruhen lässt. (Und ich möchte darauf hinweisen, dass für einige Leute Ausfallzeiten absolut unerlässlich sind, um eine qualitativ hochwertige Betriebszeit zu haben.)

Lassen Sie mich das wiederholen : Nur weil jemandes Finger sich nicht bewegen, bedeutet das nicht, dass sie untätig sind. Ihr Management scheint zu glauben, dass es etwas Nützliches misst, aber es vernachlässigt die Zeit, die zum Nachdenken, Planen und Aufladen aufgewendet wird – alles gültige und notwendige. Aber da sie eher kurzsichtig zu sein scheinen, ist es besser zu erklären, dass er während des Testens auch mitdenkt und das Produkt besser macht . Das kann wahr sein oder auch nicht, vielleicht lädt er sich auf (was das Produkt besser macht), aber ich bin mir ziemlich sicher, dass Ihr Management dieses Konzept nicht verstehen würde. Vielleicht macht er Blödsinn, was ihn glücklicher macht und somit das Produkt besser macht. Vielleicht könnte er noch effizienter arbeiten, und je besser er beim Testen wird, desto schneller wird er.

Warum schaut das Management nicht auf die anderen Entwickler, die langsamer und weniger produktiv sind als Ihr neuer Junior-Entwickler? Versuchen Sie, sie auf Ihre anderen Entwickler abzulenken. Oder warum nicht die Tests für seine Arbeit machen lassen, da sie so schnell darin sind?

Ich denke, das größte Problem, das sie haben, ist, dass er 50 % der Zeit untätig ist, anstatt zu testen. Ich persönlich habe aufgrund seiner Leistung nichts dagegen, aber das Management / die Vorgesetzten sind der Typ, der erwartet, dass ein Arbeiter vielleicht weniger als 5% des Tages untätig ist - wenn überhaupt. Der Einzelne ist während der Entwicklung auch viel untätig – aber das ist leicht zu rechtfertigen (man muss nachdenken), das Testen hingegen nicht. Zumal vieles davon Regressionstests / das Durchgehen von Checklisten beinhaltet.
@Jeff - Ich bin nicht das Einhorn, das dieser Typ ist, aber wenn ich ohne Ausfallzeiten oder sogar nur mit 5% Ausfallzeiten arbeiten müsste, würde ich lieber schnell brechen. Deshalb bin ich jetzt hier: um meinen Geist aufzufrischen, bevor ich mich in die nächste Ausgabe wühle.
@Jeff - Ich würde dem Management auch mitteilen, dass nur weil sich seine Finger während des Tests nicht bewegen, das nicht bedeutet, dass er untätig ist. Denken (und Ruhen) ist keine sichtbare Arbeit, aber dennoch aktive und produktive Arbeit.
@Jeff, könnte es gerechtfertigt sein, dass er gründlicher ist als andere, dass er tatsächlich mehr kognitive Arbeit auf die Aufgabe anwendet? Oder sogar, dass der Testprozess Routine und Alltäglichkeit ist, oder im Gegenteil, dass er sehr abwechslungsreich ist und er es so oder so als psychisch anstrengender empfindet und langsamer arbeiten muss?
@Jeff Hier ist ein Unterschied zwischen einem QA-Mitarbeiter und einem Entwickler: Der QA-Mitarbeiter findet einen Fehler, und wenn er gut ist, schreiben sie genaue Schritte auf, wie sie ihn reproduzieren können. Der Entwickler, der seinen eigenen Code testet, macht dasselbe, aber dann fängt er an, darüber nachzudenken, was das eigentliche Problem im Code ist, und es möglicherweise zu beheben. Es ist tatsächlich effizienter, aber es sieht so aus, als hätten sie die Tests eingestellt. Tatsächlich haben sie die Tests abgebrochen und das Problem behoben. Dieser Typ testet 20 Stunden, repariert 20 Stunden, und die Idioten da oben halten ihn für faul.

Hier ist einiges los, und nicht viel davon Gutes.

Sie haben einen Junior-Softwareentwickler eingestellt, dem es insgesamt sehr gut zu gehen scheint. Das ist ein guter Anfang. Juniors brauchen jedoch Mentoring, um ihre Fähigkeiten zu erlernen und zu entwickeln. Sie haben also einen Junior-Entwickler genommen, der möglicherweise nicht über viel Wissen und Erfahrung in guten manuellen Testtechniken verfügt, und erwarten von ihm, dass er ein hochkompetenter manueller Tester ohne Mentoring oder Aufsicht durch einen erfahrenen Tester ist.

Auch ohne Zugriff auf erfahrene Tester und Qualitätssicherungstester schreibt Ihr Junior-Entwickler Code mit wenigen Fehlern. Darüber hinaus erledigen sie das gesamte Arbeitspaket aus Entwurf, Entwicklung und Test der Lösung in 5-6 Wochen, wenn Sie davon ausgehen, dass ein anderer Entwickler mit mittlerer oder mittlerer Erfahrung 8 Wochen für die Arbeit benötigen würde. Sie liefern 2-3 Wochen schneller und anscheinend von höherer Qualität, als Sie es von einer älteren Person erwarten würden.

Haben Sie bei der Schätzung Ihren Junior-Ingenieur gefragt, wie lange es dauern würde, die Arbeit zu erledigen? Eine der Grundregeln des Schätzens ist, dass die Menschen, die der Arbeit am nächsten stehen, besser im Schätzen sind. Obwohl sie als Junior möglicherweise eine Anleitung in guten Techniken benötigen, um die Arbeit zu verstehen und einzuschätzen. Ich würde auch fragen, ob es sinnvoll ist, die Entwicklung und das Testen unabhängig zu schätzen, oder ob es sinnvoll ist, den Abschluss des gesamten Arbeitselements zu schätzen.

Dies führt zu "Leerlaufzeit". „Leerlaufzeit“ zu messen, bedeutet in der Wissensarbeit nicht viel. Was bedeutet es, dass sie 50 % der Zeit untätig sind? Wie wird diese Zahl ermittelt? Vielleicht sollten Sie es sich noch einmal überlegen, ob dies etwas bedeutet, zumal die Arbeit schneller als erwartet erledigt wird.

Ich verstehe auch nicht das Zögern, ein Gespräch mit dem Junioringenieur zu führen, um zu verstehen, was los ist. Es muss nicht konfrontativ sein, aber solche Gespräche sollten regelmäßig zwischen jedem Manager oder Teamleiter und seinen direkten Untergebenen oder Teammitgliedern stattfinden. So finden und beheben Sie Probleme.

Ich würde auch empfehlen, Testspezialisten in irgendeiner Form zurückzuholen. Auch wenn ihre Rolle darin besteht, bei der Überwachung zu helfen und den Entwicklern gute Testtechniken beizubringen, anstatt die Leute zu sein, die alle Tests entwerfen und ausführen. Testen ist eine Spezialität und Fähigkeit, die nicht jeder hat. Es kann sich nachteilig auf das Team und die Organisation auswirken, keine Mitarbeiter zu haben, die den lokalen Stand der Technik verbessern und die Ingenieure auf ein höheres Niveau bringen können.

Also zusammenfassend:

  • Überdenken Sie Ihre Einschätzung. Schätzen Sie den Abschluss der Arbeit und versuchen Sie nicht, den iterativen Design-/Entwicklungs-/Testzyklus zu schätzen.
  • Beziehen Sie Ihren Junior-Ingenieur in die Kalkulation mit ein.
  • Überdenken Sie, ob „Leerlaufzeit“ ein wertvolles Maß für Wissensarbeiter ist. Hinweis: ist es nicht.
  • Sprechen Sie mit Ihrem Junior-Ingenieur darüber, ob er alles hat, was er braucht, um effektiv und effizient zu sein. Dazu gehören Mentoring und Coaching zum Aufbau und zur Stärkung schwacher Fähigkeiten.

Das ist wirklich einfach. An der tatsächlichen Leistung dieses jungen Entwicklers ist nichts auszusetzen. Das Problem ist seine Leistung, gemessen an einer ziemlich dummen Leistungsmetrik. Sie erklären ihm also einfach, was er tun muss, um diese Leistungskennzahlen zu umgehen.

Ich hatte einmal das Problem, dass jemand gezählt hat, wie oft Sie Sachen in Perforce eingecheckt haben. Sie verbringen also zwei Wochen damit, ein Feature zu implementieren und es einzuchecken. Ein Einchecken in zwei Wochen, das ist eine unglaublich schlechte Leistung. Sobald Sie informiert sind, überprüfen Sie mindestens viermal am Tag den kleinsten Fortschritt. Das ist eine Leistungssteigerung um den Faktor 40.

Ich habe dies mit dem Management besprochen und versucht zu argumentieren, dass wir etwas QA zurückbringen sollten, um die Testzeiten zu verkürzen, aber sie möchten ein Treffen mit ihm haben und Dinge eskalieren, die ich absolut nicht tun möchte.

Du hast falsch argumentiert.

Wenn das Management möchte, dass Entwickler QA durchführen, und Sie ihre Meinung nicht ändern können, ist das das Ende. Man muss mit dem arbeiten, was man hat.

Stattdessen hätten Sie betonen sollen, dass verschiedene Entwickler unterschiedliche Stärken haben und dass der Entwickler insgesamt großartige Arbeit bei der Bereitstellung von Funktionen leistet.

Es ist erwähnenswert, dass zwei Faktoren eine Rolle spielen. Sie sind zwar etwas langsamer beim Testen, aber das wird durch die Tatsache verschlimmert, dass sie während der Entwicklung schneller arbeiten.

Aber Sie können dies in ein positives umwandeln:

  • Lassen Sie sie an Aufgaben arbeiten, die nicht viele Tests erfordern. Dies maximiert die Aufgabe, in der sie gut sind.
  • Binden Sie sie während ihrer Entwicklungsphase intensiv in Design-Review-Meetings ein. Wenn sie ein guter Entwickler sind, können andere von ihren Stärken profitieren.
  • Lassen Sie alle die Teststrategien der anderen überprüfen. Dies ermöglicht jedem, Methoden zu teilen.
Es ist nicht unbedingt wahr, dass dieser Entwickler "etwas langsamer beim Testen" ist, vielleicht sind sie viel besser als die anderen Entwickler und testen viel mehr und gründlicher als die anderen.

Je nachdem, um welche Art von Test es sich handelt, könnte es gut sein, ihn zu ermutigen, häufiger zwischen dem Schreiben von Code und dem Testen zu wechseln (z. B. eine Woche lang schreiben oder einen kleinen Teil des Features fertigstellen und dann testen). Sie haben erwähnt, dass Sie ihn ein wenig hitzköpfig fanden – vielleicht wäre es in diesem Fall besser, zu versuchen, das Management davon zu überzeugen, dass seine aktuelle Leistung bereits gut ist. (Vor allem, da er ein Junior ist – der offensichtliche Versuch, mehr Arbeit aus einem Junior-Entwickler herauszuquetschen, der bereits bessere Leistungen als seine Senioren erbringt, ohne ihn direkt zu befördern, ist ein todsicherer Weg, ihn aus dem Unternehmen zu vertreiben, und das ist überhaupt nicht das, was Sie wollen. )

Ein großer Teil des Codes kann nicht vernünftig getestet werden und erfordert immer noch viele manuelle Tests und viele Regressionstests. Manchmal werden große Teile des Systems durch eine Funktion geändert, sodass alles erneut getestet werden muss, ähnlich wie bei einer Checkliste.
Ach, das ist schade. Wäre es in diesem Fall möglich, ihn direkt zu fragen, ob es irgendwelche Blocker gibt, auf die er stößt? Ich habe das Gefühl, dass die Formulierung der Frage "Gibt es etwas, das Ihnen im Weg steht" statt "Warum ist Ihre Maschine so viel im Leerlauf?" die Wahrscheinlichkeit einschränken könnte, dass er defensiv wird.
@Jeff Wenn Sie keine Möglichkeit haben, das Testen zu automatisieren, wäre es das Beste, was Sie tun könnten, wenn Sie dies diesem Tester als Problem zuweisen. Es gibt zahlreiche Möglichkeiten zum Testen und viele Tools da draußen. Wenn kein Werkzeug Ihren Anforderungen entspricht, wäre es für das Unternehmen von großem Vorteil, wenn diese Person an der Herstellung eines solchen Werkzeugs arbeitet. Vor vielen Jahren hatte ich ein Gerät, das über eine Tastatur passte und mit dem ich Tastenanschläge steuern konnte. Es gibt viele Möglichkeiten, Tests zu automatisieren.
Soll ich einen Softwareentwickler darüber informieren, dass er seine Testproduktivität verbessern muss?
AntwortenHierDatenschutz-Bestimmungen1y, 0v