Wie kann man dem Manager sagen, dass einige Teammitglieder nur kleine Fehler beheben sollen?

Gespräche mit Menschen hängen oft davon ab, ihr Ziel zu verstehen. Es scheint mir, dass, während Ihr Hauptziel derzeit darin besteht, gute Software zu produzieren, Ihr Manager einen Teil des derzeitigen Fachwissens investieren möchte, um den Nachwuchs auszubilden, damit es in Zukunft mehr gute Entwickler gibt.

Wie Sie sehr gut wissen, braucht die Ausbildung jüngerer Kollegen Zeit und die Aufgaben werden von einem Senior allein oft schneller und besser erledigt. Ich denke, Ihr Vorgesetzter weiß das auch, also wird es seine Meinung nicht ändern, ihm das zu sagen.

Während das Training der Junioren wahrscheinlich eines seiner Ziele ist, ist es wahrscheinlich nicht das einzige. Es wird eine Grenze dafür geben, wie viel der aktuellen Produktivität in Schulungen investiert werden kann. Wenn Ihr Team es nicht schafft, seine Mindestziele zu erreichen, können Sie ihn dazu überreden, das Training herunterzufahren, wenn auch wahrscheinlich nicht ganz damit aufzuhören.

Wenn das Problem hingegen darin besteht, dass Sie von vornherein keine jüngeren Kollegen haben möchten, dann haben Sie wahrscheinlich Pech gehabt. Sie müssen herausfinden, warum das Team erweitert wurde und warum auf diese Weise. Ältere Entwickler sind schwer zu finden, also musste das Unternehmen vielleicht unerfahrene nehmen, um sie wachsen zu lassen.

Sie in die Fehlerbehebung zu verbannen, ist wahrscheinlich ein hoffnungsloser Fall. Sie würden aufhören und du würdest an ihrer Stelle auch. Das Unternehmen weiß es und hat weder Zeit noch Geld darauf verwendet, sie zu finden, auszuwählen und einzustellen, nur damit sie ausbrennen. Ich würde mit viel Widerstand rechnen.

Übrigens erfordert das Beheben von Fehlern auch Sorgfalt und Wissen. Wenn Sie glauben, dass neue Entwickler damit umgehen können, warum können sie dann nicht zu einem neuen Feature beitragen?

EDIT: Letzten Absatz verbessert. Vielen Dank an die Kommentatoren für den Hinweis auf unerwünschte Interpretationen dessen, was ich geschrieben habe.

Du nicht.

Der Hauptgrund dafür ist, dass Sie anscheinend nicht glauben, dass einige Leute sich an das Beheben von Fehlern halten sollten, Sie scheinen zu denken, dass nur die qualifiziertesten Leute entwickeln sollten.

Mein Vorgesetzter und ich haben unterschiedliche Erwartungen an gute Entwickler.

Sie können nicht nur 10 Mitarbeiter haben. Sie brauchen 7s-8s, um mit den Dingen Schritt zu halten. Es liegt an Ihnen, wie Sie das vorhandene Talent einsetzen. Wenn Sie zu wählerisch sind, landen Sie bei einem 1-Mann-/Frauengeschäft. Wenn Sie jedoch der Meinung sind, dass die Einstellungen Bonkus sind, müssen Sie diese Bedenken an Ihren Vorgesetzten richten.

Es gibt 3 Entwickler, die ich für fähig halten würde, neue Entwicklungen durchzuführen. Die anderen 11 sind in der Lage, Fehler zu beheben und kleine Verbesserungen vorzunehmen [...] Jedes Mal, wenn ich ein neues Feature starte, versuche ich, die neue Arbeit den leistungsstärksten Leuten zuzuweisen.

Das ist lächerlich. Wie erwarten Sie, dass 3 Entwickler mit der Entwicklung Schritt halten, die von einem 14-köpfigen Team erwartet wird? Es macht keinen Sinn.

Im täglichen Standup werde ich bestimmte Personen fragen, ob die Dinge klar sind, um ihre Bestätigung vor dem Manager zu erhalten. Auch nachdem sie sagen, dass alles "klar" ist. Sie bestehen darauf, sich zu treffen und "Dinge durchzugehen", mein Manager erlaubt es. Er fördert sogar "Peer Programming".

Ein täglicher Standup sollte etwa 15 Minuten dauern. Das ist ungefähr eine Minute pro Entwickler. Ich würde mir Sorgen machen, wenn die Leute in einem Meeting, das für ein bestimmtes Problem bestimmt ist, Dinge nicht durchgehen wollen. Das tägliche Standup sollte verwendet werden, um anzusprechen, was getan wird, was ansteht und welche Probleme vorhanden sind. Es ist nicht der Ort, um die Probleme zu lösen, sondern sie nur anzusprechen.

Unnötig zu erwähnen, dass die Teamdynamik weit aus dem Gleichgewicht geraten ist. 2 Senioren, 1 Mittelstufe, 11 Junioren.

Ich verstehe, dass Sie vielleicht nicht möchten, dass Junioren sofort in die Feature-Entwicklung einsteigen. Das Beheben von Fehlern und das Verständnis der Systeme ist großartig, aber nach ein paar Monaten sollten sie genug Verständnis haben, um neue Funktionen hinzuzufügen. Wenn sie es nicht sind, dann bekommen sie nicht das Coaching, das sie brauchen, oder die Möglichkeiten, sich zu beweisen. Entweder das, oder sie sind einfach unqualifiziert.

Sie bekommen nichts in Bezug auf Features, wenn Sie nur 2-3 Entwickler haben, die an Features arbeiten. Das ist ein riesiger Engpass.

Verwenden Sie die Junioren, die ein gewisses Verständnis des Systems haben. Erlauben Sie ihnen, tatsächlich zu lernen und sich zu beweisen. Sie werden auf diese Weise niemals Senioren. Außerdem können Sie sicher sein, dass die Leute bald anfangen werden zu gehen, wenn sie nur Fehler beheben.

Außerdem, wovor hast du solche Angst? Wenn ein Junior den Code vermasselt, sollte dies durch den Code-Review-Prozess entdeckt werden. Bitten Sie die Seniors, Ihnen dabei zu helfen, diese Juniors zu qualifizierten Softwareentwicklern zu machen.

Er fördert sogar "Peer Programming".

Die Tatsache, dass Sie sich keine Sorgen machen. Ich denke nicht, dass es die ganze Zeit verwendet werden sollte, aber es ist ein erstaunliches Tool, das sogar die erfahrensten Leute in meinem Unternehmen verwendet haben, um Mitarbeiter der unteren und mittleren Ebene in Tagen, die Wochen gedauert hätten, auf den neuesten Stand zu bringen.

Ich bin auch zurückgetreten und sehe zu, wie Leute scheitern [...] Soweit ich weiß, zieht mein Vorgesetzter Leute nicht zur Rechenschaft, wenn sie unterdurchschnittliche Leistungen erbringen.

Es ist leicht, als Entwickler unterdurchschnittliche Leistungen zu erbringen, wenn ihm keine Entwicklungsaufgaben zugewiesen sind. Haben Sie darüber nachgedacht, dass Menschen möglicherweise „unterdurchschnittlich“ sind, weil sie nicht die Ausbildung erhalten, die sie benötigen?

Nehmen wir an, die Junioren bekommen Aufgaben zugeteilt, bei denen sie unterdurchschnittlich sind. Es ist dann Ihre Aufgabe, herauszufinden, wo sie Hilfe bei der Erfüllung ihrer Aufgaben benötigen. Helfen Sie ihnen, das Top-Talent zu werden, das Sie sich so sehr wünschen.

Wie kann ich meinem Vorgesetzten mitteilen, dass bestimmte Personen nicht in der Lage sind, mit neuen Funktionen umzugehen? Er muss sie entweder feuern oder ihnen nur kleine Fehler zum Beheben geben und niedrige Erwartungen haben.

Sie haben uns noch nicht einmal angesprochen, warum sie Ihrer Meinung nach nicht qualifiziert sind. Sind sie nicht in der Lage, weil es nicht Ihrem Senior-Level-Standard entspricht? Wenn das der Fall ist, dann musst du dein Ego loslassen, weil es die Produktion behindert. Sicher, es sollte Standards geben, aber diese Standards werden durch Mentoring und Überprüfung implementiert.

Ich würde Ihre Bedenken verstehen, wenn es ein paar Entwickler gäbe, die einfach unqualifiziert sind und die Sie unbedingt loswerden möchten, aber wenn Sie nur einigen von ihnen die Entwicklung anvertrauen, habe ich das Gefühl, dass Sie ' re das Problem, nicht umgekehrt.

Lassen Sie Ihr Ego los und helfen Sie den Entwicklern bei der Bewältigung ihrer Aufgaben, die aus Wartung und Entwicklung bestehen sollten. Sonst verliert man bald Leute oder sitzt mit Leuten fest, die eigentlich nicht entwicklungsfähig sind.

Es wurde in Kommentaren erwähnt, wie Sie erwarten können, dass Ihre Juniors lernen, wenn Sie ihnen keine Chance geben, ich wiederhole das zehnfach. Sie stellen Ihr Unternehmen auf Abhängigkeiten von Schlüsselpersonen ein, und das ist letztlich auf lange Sicht ein Problem für das Unternehmen. Junior-Entwickler sind billiger und sie können geformt werden, sie können auch viele negative Eigenschaften von denen über ihnen lernen (dh von Ihnen).

Ihr Manager scheint tatsächlich die aufgeklärte Person in dieser Hierarchie zu sein, da er versucht, den Juniors Erfahrung zu vermitteln.

Im täglichen Standup werde ich bestimmte Personen fragen, ob die Dinge klar sind, um ihre Bestätigung vor dem Manager zu erhalten. Auch nachdem sie sagen, dass alles "klar" ist. Sie bestehen darauf, sich zu treffen und "Dinge durchzugehen", mein Manager erlaubt es. Er fördert sogar "Pairprogramming".

Die Junior-Entwickler sind wahrscheinlich nervös und Sie setzen sie in Verlegenheit. Das haben wir alle schon durchgemacht. Ich kann mich erinnern, dass ich damals gesagt habe, dass die Dinge klar waren, als es noch nicht so war. Es brauchte einen Vorgesetzten, um mich hinzusetzen und zu erklären, dass Fragen stellen nichts Schlechtes ist – nicht jeder versteht alles.

Die Tatsache, dass Sie sich darüber beschweren, dass sie sich mit Ihnen treffen, um „Dinge durchzugehen“, ist für mich ein Warnsignal und sicherlich nicht das einzige. Sie sollten diejenigen, die es nicht wissen, ermutigen, zu fragen, als ob sie versuchen würden, Stunden damit zu verbringen, keine Lösung zu finden, die Geld kostet. Sie sollten sie so unterrichten, dass sie sicher sein können, sich zu melden, eine Antwort zu bekommen und sachkundig genug zu sein, um diese Frage nicht noch einmal zu stellen.

Sie sind ein „Leader“, das ist Ihre Rolle, wenn sie immer wieder ähnliche Fragen stellen, müssen Sie vielleicht Ihre Technik überdenken oder überlegen, welche Trainingsmöglichkeiten es gibt, die Sie arrangieren müssen.

Die Zeitspanne dafür beträgt 2 Jahre. Es ist ein sich wiederholender Prozess mit einigen Jungs und ich sehe nicht, dass sie es auf lange Sicht schneiden. Sie wissen nicht, wie man die richtigen Fragen stellt, und ich sehe nicht, dass sie es versuchen, da es keine "echten" Konsequenzen gibt.

Wenn sie damit nicht klarkommen, müssen Sie sich ansehen, welche Lernmöglichkeiten es für sie gibt, welche Schulungen haben Sie sich angesehen?

Wie kann ich meinem Vorgesetzten mitteilen, dass bestimmte Personen nicht in der Lage sind, mit neuen Funktionen umzugehen? Er muss sie entweder feuern oder ihnen nur kleine Fehler zum Beheben geben und niedrige Erwartungen haben.

Junioren wissen nicht, was sie nicht wissen. Ein Leiter soll sie anleiten, damit sie lernen können. Ihr Vorgesetzter sollte die Lernblockade beseitigen.

Ich würde es vorziehen, wenn 3-4 der Junioren nur Fehler beheben und brennen und abstürzen. Verwenden Sie stattdessen dieses Geld, um 1 zusätzlichen älteren Mann einzustellen.

Das ist eine absolut lächerliche Aussage. Sie sollten die Junior-Entwickler fördern, um sie an den Ort zu bringen, an dem Sie sie brauchen.

Soweit ich sehen kann, sind Sie definitiv kein Anführer, Sie sind ein Manager mit einer Ressource. Ich denke, Sie sollten einen Schritt zurücktreten und sehen, ob Sie das Gefühl haben, dass Sie sich zum Wohle von sich selbst, Ihrem Team und letztendlich dem Unternehmen in der richtigen Position befinden - da Ihre kurzfristigen Gewinne dem Unternehmen auf lange Sicht nur schaden können.

Ich habe einen Wechsel in eine andere Division vorgenommen, weil die Situation jetzt meinem kontinuierlichen Wachstum schadet

Ich denke, das ist eine fantastische Idee, da Sie nicht führend sind und dem kontinuierlichen Wachstum Ihrer Nachwuchsentwickler abträglich sind.

Auch die Top-Entwickler befinden sich in ähnlichen Situationen.

Wenn ich ein Senior wäre und die Last der ganzen Arbeit ständig auf meinen Füßen landen würde, anstatt die unteren zu trainieren, dann würde ich sicherlich auch versuchen, zu gehen.

Ich kann Ihnen nicht sagen, wie Sie Ihren Chef davon überzeugen können, aber ich kann Ihnen sagen, dass Ihr Problem anscheinend darin besteht, die Teamhierarchie festzulegen. Sie haben die Hierarchie in Ihrer Frage definiert, aber Sie scheinen sie nicht in Ihrem Arbeitsstream definiert zu haben.

Wenn es zwei Senioren gegen 11 Junioren gibt, sollten diese Senioren vielleicht überhaupt nicht programmieren. Sie sollten sich mehr um das Design der neuen Funktion kümmern, und dann übergeben Sie diese Designs an den Junior, der diese Designs unter der Aufsicht der Seniors implementiert, die Code-Reviews durchführen, während schwierige Teile an die übergeben werden können mittlere Ebene und die Senioren, wenn nötig.

So, wie Sie es einschlagen, haben Sie heute zwei Senioren, einen Mittelklassespieler und elf Junioren, und in fünf Jahren werden Sie auch zwei Senioren, einen Mittelklassespieler und elf Junioren haben.

Der effizienteste Weg, etwas Neues hinzuzufügen: Lassen Sie einen Senior einen Plan entwickeln, erklären Sie ihn zwei Junioren und lassen Sie ihn ihn erstellen. Mit etwas Händchenhalten. Nächstes Mal dasselbe mit weniger Händchenhalten. Und in einem Jahr können sie Dinge alleine machen und den Senior nur noch mit harten Stücken belästigen.

Ich sehe hier zwei Grundprobleme, die Sie kaum anerkannt haben, und viele Beschwerden über die Symptome, die sich aus diesen Problemen ergeben. Darüber hinaus habe ich immer wieder sehr ähnliche Situationen und Stimmungen in der SE-Branche gesehen.

Erstens sind 2 Senioren nicht einmal die Hälfte der Zahl, von der ich erwarten würde, dass sie das Training von 11 Junioren bewältigen kann. Ein einzelner Senior kann im Durchschnitt mit 1 Mid und 2 Juniors umgehen. Ein wirklich guter Teamleiter kann bestenfalls mit 2 Mids und 3 Juniors umgehen, und Ihr persönlicher Code-Output wird dafür dramatisch abnehmen. Allerdings baut man so größere Teams auf. Es spielt keine Rolle, was Ihr Tech-Stack ist, es gibt einfach nicht genug erfahrene Programmierer mit Erfahrung in Ihrem Tech-Stack, und sie werden es nicht sein, bis Sie sie schulen und das Notwendige tun, um sie zu halten.

Als Team ist Ihre durchschnittliche Erfahrung pro Teammitglied viel zu niedrig. Hochkomplizierte Probleme können und sollen Junioren noch nicht zugemutet werden und brauchen Mentoring. Wie jemand anderes bereits sagte, können Sie kein Team von nur 10 Personen erwarten, das gibt es nicht, weil niemand als 10 anfängt und ich noch keine Interviewkriterien finden muss, die in der Lage sind, 10er oder sogar wahrscheinliche zukünftige 10er genau zu identifizieren. Von wem Sie trainiert werden und wie viel Aufwand sie in das Training stecken, ist wichtig und liegt außerhalb der Kontrolle dieser Person. Sie wissen größtenteils noch nicht, was sie lernen müssen oder wie sie produktiver werden können. Das Lesen von zufälligen technischen Artikeln mag wie eine gute Folge des zukünftigen Erfolgs erscheinen, aber die meisten erfolgreichen und produktiven Ingenieure haben es nicht. Es ist eine seltene Eigenschaft, also kannst du'

Zweitens kann ich nur aus der Art und Weise, wie Sie die Dinge beschrieben haben, erkennen, dass Ihre Geschichten zu umfangreich sind. Sie müssen sie in kleinere, handlichere Größen zerlegen lassen. Eine Geschichte, für deren Fertigstellung ein Programmierer auf mittlerem Niveau mehr als 3 Tage benötigt, kann fast immer in kleinere, leichter verständliche Anforderungen unterteilt werden. Ich versuche, die durchschnittliche Geschichte bei etwa 1 Tag Arbeit für einen mittleren Ingenieur zu halten. Scheuen Sie sich nicht davor, Geschichten zu haben, die von der Fertigstellung anderer Geschichten abhängen, bevor sie gestartet werden können. Je mehr Sie die Dinge aufschlüsseln, desto einfacher ist es, alle mit Geschichten zu versorgen, bei denen die Abhängigkeiten bereits abgeschlossen wurden. Feature-Zweige kommen sehr ins Spiel für diesen Zweck nützlich. Darüber hinaus hat die Art und Weise, wie Geschichten geschrieben werden, einen großen Einfluss. Der erfolgreichste Ansatz, den ich'

Wenn Sie sie dazu bringen können, ein besseres Verhältnis von Senior- zu Junior-Level-Mitgliedern anzustreben, wird das einen großen Teil des Problems lindern, aber ich habe gesehen, wie besseres Storywriting ansonsten desorganisierte, unmotivierte Teams vollständig in die Art von hochproduktiven Vermögenswerten verwandelt, von denen das Management schwärmt um. Ihr Worst-Case-Szenario ist, dass Sie sich auf das Mentoring beschränken müssen, bis sie sich verbessern, und sich dann nach ein paar Sprints auf ein neues Paar Junioren konzentrieren müssen, die trainiert werden. Das ist nicht ideal, aber so kommt man auf den Durchschnitt.