Ich leite ein kleines Teilprojekt in meinem Unternehmen, und ich habe noch nie zuvor in meiner Karriere ein Projekt geleitet, und dieses Miniprojekt soll laut meinem Vorgesetzten eine Führungsübung sein.
Ich habe eine Aufgabenaufschlüsselung vorgenommen und sie zugewiesen. Eine dieser Aufgaben war die Form
Entwickeln Sie eine Funktion/API mit Signatur
Output functionName(Input1,Input2), die Funktion sollte TaskX ausführen
Wo TaskX ziemlich ausführlich beschrieben wurde. Es war ziemlich klar und direkt und auch ziemlich eigenständig.
Ich bekam jedoch eine ziemlich große Klasse geliefert, bei der die angeforderte API im Wesentlichen eine Member-Funktion einer Klasse war, die Klasse hatte auch Datenmember, die für die Funktion selbst nicht wirklich nützlich sind (zum Beispiel hat sie einen völlig nutzlosen Viewer für die Funktion). Ich habe den Code überprüft und versucht zu erklären, wie ich es gemacht hätte, einschließlich Codeschnipsel (die ungefähr 20/30 Codezeilen waren), dies beinhaltete auch den Hauptteil der Funktion.
Aus irgendeinem mir nicht ganz ersichtlichen Grund bekomme ich immer wieder eine große Klasse geliefert, deren Feature und Implementierung ich nicht für ganz richtig halte, aber darum geht es nicht. Der Punkt ist, dass ich, wenn ich diese Member-Funktion verwenden wollte, ein ziemlich großes Objekt instanziieren musste, was nicht viel Sinn macht.
Für mich ist das Ziel der Aufgabe also nicht erreicht, und ich habe versucht, genau zu sagen, was ich will und warum, aber irgendwie bekomme ich immer noch Widerstand. Denken Sie auch daran, wie kurz die Funktion war, ich hatte erwartet, dass dies in höchstens drei Tagen erledigt sein würde (und das war eine Überschätzung, da die Funktion am Ende in Bezug auf den Code wirklich kurz war), aber es ist jetzt zwei Wochen her . Der Grund dafür, dass es so lange dauert, ist, dass ich zusammen mit dem eigentlichen Kern der Aufgabe eine ganze Klasse, wie beschrieben, und ein paar Skripte und ein IDE-Projekt bekomme, die ich ehrlich gesagt nicht brauche. Das einzige, was ich physisch brauchen würde, sind ein oder zwei Quelldateien.
Ich habe bereits mit meinem Vorgesetzten darüber gesprochen und im Wesentlichen habe ich aus diesem Gespräch nur herausgefunden, dass der Ingenieur, mit dem ich derzeit zusammenarbeite, dazu neigt, Dinge zu übertreiben. Meine Frage hier ist also, wie kann ich in Zukunft mit dieser Situation am besten umgehen?
Das einzige, woran ich persönlich dachte, war, mich neben ihn zu setzen und zu versuchen, ihn durch die Aufgaben zu führen, die ich ihm zugewiesen habe, aber oft driften diese Gespräche zu Dingen ab, die nicht direkt mit der Aufgabe zusammenhängen (das liegt wahrscheinlich daran, dass ich zu verfügbar bin Erklärungen geben und das schadet mehr als es nützt).
Irgendein Rat?
(Hinweis: Das Projekt ist sehr klein, es sind etwa drei Ingenieure beteiligt, mich eingeschlossen).
Update : Trotz meines Code-Reviews wurde ich also wieder mit aufgeblähtem Code versorgt. Die Technik, die ich angewendet habe, um das zu klären, war also eine Art Mischung aus ein paar Antworten, die ich von hier erhalten habe.
Zunächst einmal habe ich ausdrücklich gefragt, warum ich angesichts der Aufgabe so viel Code bekommen habe. Ich wurde begründet (ob ich zugestimmt habe oder nicht, ist eigentlich egal), aber am Ende haben wir geklärt, was für die Aufgabe notwendig ist, also habe ich am Ende die 20 Zeilen bekommen, die ich für notwendig hielt. Damit war die aktuelle Aufgabe erledigt.
Als Übung für ihn habe ich jedoch beauftragt, mir eine Form von Design/Pseudocode zu geben, dessen Implementierung es ermöglichen würde, das Ziel der nächsten Aufgabe zu erreichen. Deshalb hatten wir ein Treffen, wo wir darüber gesprochen haben. Die Diskussion neigte manchmal dazu, zu anderen Details abzudriften (nützlich zu verstehen, aber aus Codierungssicht nicht wichtig), ich denke, dieses Mal gelang es mir jedoch, die meiste Zeit auf dem Laufenden zu bleiben. Am Ende dieses Treffens stellte ich die explizite Frage "Wie viele Codezeilen brauchen Sie Ihrer Meinung nach, um dies zu implementieren?" er erklärte mir, was er seiner Meinung nach zu tun hatte, und dieses Mal klang es ungefähr richtig, ich habe auch viele Male betont, dass der minimale Code erforderlich ist, und ich denke, ich wurde dieses Mal verstanden.
Das einzige, woran ich persönlich dachte, war, mich neben ihn zu setzen und zu versuchen, ihn durch die Aufgaben zu führen, die ich ihm zugewiesen hatte
Das scheint mir eine gute Idee zu sein. Es folgt grundsätzlich dem Prinzip „Lead by Example“ .
Die Idee ist natürlich, dass Ihr Team irgendwann in der Lage sein wird, Dinge alleine zu erledigen, ohne dass Sie neben ihnen sitzen müssen, aber in diesem Fall scheint es hilfreich zu sein, dies einmal mit dieser Person zu tun.
Versuchen Sie, mit ihnen klarzukommen, und versuchen Sie, eine der Aufgaben zu erledigen, die Sie ihnen zugewiesen haben. Teilen Sie ihnen Ihren Denkprozess mit, fragen Sie sie, was sie denken und argumentieren, geben Sie Feedback, Vorschläge und Korrekturen, aber lassen Sie sie das Codieren übernehmen.
Lassen Sie sie danach die restlichen Aufgaben alleine erledigen und sehen Sie, wie sie das jetzt geschafft haben. Vielleicht neigt diese Person dazu, die Dinge zu verkomplizieren, und was sie braucht, ist ein wenig Anleitung, um ihre Verhaltensweisen zu verstehen und zu ändern.
aber oft driften diese Gespräche zu Dingen ab, die nicht unbedingt mit der Aufgabe zu tun haben (das liegt wahrscheinlich daran, dass ich zu bereitwillig Erklärungen gebe und das mehr schadet als nützt).
Ich würde dies nicht als Gespräch einrahmen ; vielleicht ist das dein fehler und warum weicht das ab.
Dies sollte mehr in Richtung Paarprogrammierung gehen (aber lassen Sie sie auch hier das Codieren machen und vermeiden Sie es, so viel wie möglich selbst zu programmieren).
Wenn Sie das Gefühl haben, dass diese Person anfängt, abzuweichen oder auf Details einzugehen, die nicht benötigt werden, bringen Sie die Übung höflich wieder auf den richtigen Weg und konzentrieren Sie sich wieder auf die anstehende Aufgabe.
Stellen Sie Ihrem Ingenieur eine Herausforderung: Produzieren Sie den minimalen Code, um die Anforderungen zu erfüllen. Diese Version muss nicht releasereif sein, sondern lediglich eine korrekte Umsetzung der Anforderungen.
Wenn dies erledigt ist, besprechen Sie mit dem Techniker, was noch benötigt wird, um es für die Veröffentlichung vorzubereiten. Was ist der Nutzen und die Kosten von allem, was hinzugefügt werden könnte?
Das klingt sehr nach Verschleierung . Verschleierung ist eine Praxis, die normalerweise von Entwicklern angewendet wird, die nicht gut in ihrem Job sind, wobei sie ihre Arbeitsplatzsicherheit gewährleisten, indem sie ihren Code so schwer wie möglich machen, um ihn zu verstehen und damit zu arbeiten, so dass sie die einzigen sind, die wissen, wie er funktioniert. Wenn sie gefeuert werden, muss das Unternehmen daher die gesamte Arbeit, die sie geleistet haben, verwerfen und von Grund auf neu machen, weil niemand versteht, was getan wurde. Daher glauben sie, dass sie weniger wahrscheinlich entlassen werden, weil die Gemeinkosten für ihren Ersatz zu hoch sind.
Folgendes tun Sie: Wenn Sie glauben, dass ein Projekt in 3 Tagen erledigt werden kann, dann setzen Sie eine Frist von 3 Tagen. Das ist ein KPI, den Ihr Entwickler erfüllen muss; Wenn sie die Aufgabe nicht in 3 Tagen erledigen können, dann ist das ein Streik gegen sie, den Sie bei ihrer nächsten Leistungsbeurteilung verwenden können. Wenn sie glauben, dass 3 Tage nicht ausreichen, können sie zu Ihnen kommen und die Frist aushandeln, und zu diesem Zeitpunkt können Sie die Anforderungen mit ihnen klären und ihnen klar machen, dass der Auftrag, den sie bekommen, nicht so groß ist, wie sie denken es ist, und wenn sie dann immer noch versuchen, etwas wirklich Großes zu liefern, können Sie ihnen sagen, dass ihr Code nicht den Spezifikationen entspricht.
Das Wichtigste, was man mit einem Entwickler tun sollte, der verschleiert, ist, seinen Code nicht zusammenzuführen . Das Verschleierungsschema schlägt fehl, wenn verhindert wird, dass ihr Code in Produktion geht. Stellen Sie sicher, dass nur sauberer Code in die Produktion geht, damit Sie nicht mit einer Menge technischer Schulden stecken bleiben, wenn dieser Entwickler das Unternehmen verlässt.
Als Einschränkung zu all dem oben Gesagten : Viele Sprachen haben "Best Practices", die sehr nach Code-Verschleierung aussehen, z. B. Schnittstellendefinitionen, viel Konfigurationsaufwand und so weiter. Stellen Sie sicher, dass Sie die Einschränkungen verstehen, unter denen der Entwickler arbeitet; es ist möglich, dass er guten, sauberen Code liefert, der den Standards der Sprachen/Frameworks entspricht, mit denen er arbeitet, und Sie sagen ihm, er soll schlechten, abgedroschenen Code schreiben, der schwer zu warten ist, und er versucht, Ihnen nett zu sagen, dass Sie es sind ein Idiot und du hörst nicht zu. Denken Sie bei allem, was Sie tun, daran.
Wenn Sie die Autorität haben, versuchen Sie beim Umgang mit diesem Entwickler, engere Fristen einzuführen und spezifische Ausgabeanforderungen hinzuzufügen.
Bis zu dem Punkt, an dem Sie ihm eine dedizierte Code-Editor-Datei senden, je nach verwendeter Sprache (z. B. *.cs) mit Struktur und "Code hier einfügen" im Kontext
Auf diese Weise wäre es für ihn schwieriger, seine Arbeit aufzublähen und zu verschleiern.
Aber wenn Sie als Ergebnis eine inakzeptable Arbeit erhalten würden, hätten Sie etwas, mit dem Sie sich an Ihren Vorgesetzten wenden können, um Rat / Bestätigung einer für diesen Entwickler erforderlichen Maßnahme zu erhalten
IMHO ist der Umgang mit allen Arten von Untergebenen auch Teil des Hineinwachsens in eine Führungsrolle, in der Ihre Aufgabe nicht darin besteht, die Arbeit zu erledigen, sondern Aufgaben zu verteilen und erhaltene Ergebnisse in ein Endprodukt zu integrieren
Bernhard Döbler
Helena
Benutzer8469759
Benutzer8469759
Daniel R. Collins
Benutzer8469759
Benutzer8469759