Ich werde es am Beispiel des abstrakten Entwicklers Tom beschreiben. Tom bekam einen Job bei Internetmagazinzaden als PHP Middle Developer. Das Unternehmen erstellt Online-Shops von Vorlagen bis hin zu komplexen mit einer Reihe von Integrationen. Das Unternehmen hat die besten Agile, SCRUM, Stand-Ups und Retro. Tom hat 3 Monate gearbeitet und alles läuft gut für ihn, er hat ein paar IMs gestartet, sie funktionieren sogar und die Kunden sind glücklich.
Hier kommt eine neue Aufgabe für die Entwicklung von IM, aber mit der Integration in CRM. Tom beginnt mit der Aufgabe der Integration und irgendwann gelingt es ihm nicht mehr und die Amtszeit erstreckt sich über eine Woche. Gleichzeitig sagt Tom bei der Generalversammlung, dass er "das Problem versteht", in der Hoffnung, dass er bereits einer Lösung nahe ist. Tom wendet sich an den leitenden Entwickler Mike (der nicht sein Mentor ist und nur nicht weit von Tom entfernt sitzt), verweist ihn auf Handbücher und erklärt kurz, was zu tun ist.
Tom geht, um die Tutorials zu lesen und sich mit dem Problem zu befassen. Nach ein paar Tagen kehrt er mit Fragen zur Integration zu Mike zurück und sie klären sie gemeinsam.
Tom geht, um es für ein paar Tage zu klären. Danach kehrt er zu Mike zurück und gibt ihm die endgültige Lösung. Mike überprüft die Zuordnung und weist auf einige kleinere Fehler hin, die Tom bald korrigieren wird.
Es scheint ein funktionierendes Bild zu sein, aber es gibt einige Punkte, die uns zeigen, dass Tom kein mittlerer Entwickler mehr ist, wie wir vorher dachten, sondern Juni.
- Tom hat sich sehr lange (in diesem Fall eine Woche) mit dem Problem befasst und das Problem nicht rechtzeitig signalisiert.
- Ich konnte es mit dem Tutorial selbst nicht herausfinden und anstatt einige unverständliche Momente zu googeln, ging ich zu Mike.
- Tom verbrachte die Zeit eines anderen Entwicklers, anstatt Stand-Ups zu verwenden und dort seine Probleme zu diskutieren.
Manchmal stellen sie bei Interviews für die Position eines Teamleiters die Frage: "Wie teilen Sie Entwickler in Juni, Mitte, Senior ein?" Und meine Antwort lautet ungefähr so:
- , ;
- , ;
- - .
In Toms Fall hat er gerade das Tutorial und die Implementierungsbeschreibung von Mike erhalten, aber er konnte es nicht herausfinden und ging zurück zu Mike. Dies war für mich der erste wichtige "Ruf", dass wir nicht in der Mitte sind. Der zweite wichtige Aufruf war, dass die Fähigkeit, ein Problem zu „signalisieren“, für die Mitte sehr wichtig ist. Wenn er es nicht besitzt, bringt ihn dies in Bezug auf Soft Skills zurück zu den Junioren. Die dritte "Glocke" ist die nachlässige Einstellung zur Zeit eines anderen Entwicklers, der Junioren innewohnt. Manchmal verstehen sie nicht, wie wichtig es ist, den Prozess zu verfolgen und sich an den "freundlichsten" Entwickler zu wenden, anstatt an die Spitze zu gehen und einen Mentor durch ihn zu holen. Dies ist wichtig, weil der Entwickler Mike vielleicht mit einem super verantwortungsbewussten Projekt beschäftigt ist oder seine Aufgabe eine hohe Konzentration erfordert, aber der Programmierer John sitzt buchstäblich am Nebentisch.Wer hat gerade ein Projekt abgeschlossen und noch keine Zeit gehabt, in ein neues einzutauchen.
Betrachten wir einen anderen Fall. Der leitende Entwickler Vasya arbeitet seit langer Zeit im Unternehmen. Vasya hat einen Teamleiter, Petya. Und so kam es, dass Petja ein sehr nachdenklicher Anführer ist und nicht nur eine Aufgabe festlegt, sondern in allen Aspekten mit einem Systemanalytiker zusammenarbeitet und diese erst dann zur Arbeit gibt. Vasya und Petya arbeiten seit 4 Jahren im Unternehmen und dieses Programm ist bereits in der Reihenfolge der Dinge. Gleichzeitig implementiert Vasya Aufgaben perfekt gemäß der schriftlichen technischen Spezifikation, dokumentiert den Code und freut sich, dass bei ihm alles so "nett und gut" ist.
Aber hier ist das Pech, nach einer Weile schließt das Unternehmen und Vasya muss sich einen Job suchen und aus irgendeinem Grund beginnen sie, Vasya während der Interviews nicht als Senior, sondern als Mittler zu qualifizieren. "Wie ist es passiert? Wo bin ich hingefallen? " Fragt er sich.
Alles ist wieder einfach, Vasya verlor die Fähigkeit, die optimale Lösung für das Problem zu finden. In 4 Jahren entspannten der Systemanalytiker und der Leiter des fürsorglichen Teams Vasily so sehr, dass diese Fähigkeit nicht mehr benötigt wurde.
Was ist in diesem Fall zu tun? Wenn Sie dies in einem Unternehmen gefunden haben, sollten Sie den Entwicklern meistens keine Rubel wegnehmen und ihre Gehälter senken (auch wenn indirekt), sondern sich über die Frage wundern, ob dies behoben werden kann. Und wenn die Antwort „Nein“ lautet, ist es besser, sich vom Mitarbeiter „freundlich“ zu verabschieden, da er zu einem bestimmten Zeitpunkt mit der Tatsache unzufrieden sein wird, dass sein Gehalt nicht wächst und der Rest des Teams möglicherweise Probleme damit hat. Wenn die Antwort Ja lautet, benötigen Sie eine sehr durchdachte Arbeit sowohl der Personalschulungsabteilung als auch des Teamleiters. In diesem Fall müssen Sie die Fähigkeiten des Mitarbeiters verbessern und dies so sanft wie möglich tun, um seinen Stolz nicht zu verletzen und ihm die Motivation zu geben, sich zu entwickeln.