Wie kann man die Aufgabe eines Praktikanten übernehmen, ohne dass er sich geschlagen fühlt?

Hintergrund: Ich war ein Jahr Praktikant an meinem jetzigen Arbeitsplatz, bis ich im Mai in Vollzeit eingestellt wurde. Ich bin Programmierer und entwickle hauptsächlich mobile Apps, aber auch einige Web-Apps. Seitdem haben wir mehrere Praktikanten eingestellt, von denen zwei unter meinem Kommando stehen. Der Grund dafür ist, dass mein Chef möchte, dass ich lerne zu delegieren und zu festigen, was ich gelernt habe, indem ich es einer anderen Person beibringe.

Der Kontext ist also, dass ich meinem Praktikanten eine wichtige, aber kleine Aufgabe gegeben habe. Er sollte etwas in dem Projekt programmieren, an dem ich arbeite. Entweder hat er die Aufgabe falsch verstanden oder ich habe es nicht gut genug erklärt, aber er hat es falsch gemacht. Seine Arbeit ist bisher unvollständig, aber ich kann aus dem, was er geschrieben hat, entnehmen, dass es nicht funktionieren wird und dass er die Aufgabe falsch interpretiert hat (oder nicht gut genug erklärt wurde) und die Art und Weise, wie er die falsche Aufgabe erledigt hat, nicht gut ist. Zu seiner Verteidigung, er ist im zweiten Studienjahr und ich bin graduiert, also habe ich ein paar Jahre Ausbildung und ein ganzes Jahr Berufserfahrung vor ihm. Ich möchte seinen Code verwerfen, meinen eigenen schreiben und ihm erklären, wie und warum ich ihn auf diese Weise codiert habe, aber ich möchte nicht, dass er sich wegen des Scheiterns dumm oder niedergeschlagen fühlt. Der Grund, warum ich mir Sorgen mache, dass er sich dumm fühlt, ist, weil ich keine Ahnung habe, wie er beabsichtigte, dass es funktioniert, und weil es sich für mich wie eine dumme Art anfühlt, aber ich bin mir der Tatsache bewusst, dass ich auch dummes Zeug geschrieben habe während meines Praktikums und ich schreibe immer noch dummes Zeug im Vergleich zu vielen vielen anderen Leuten. Trotzdem ist er gescheitert. Wir alle scheitern irgendwann.

Also, wie übernehme ich seine Aufgabe und erkläre ihm, wie man es richtig macht, ohne dass er sich wegen des Scheiterns niedergeschlagen fühlt?

Hast du testgetriebene Entwicklung ausprobiert? Wenn er anhand einer Reihe von Tests codieren kann, besteht nur eine sehr geringe Wahrscheinlichkeit, dass er die Aufgabe falsch kommuniziert.
@StevenGubkin - wer schreibt den Test? Wenn er es selbst macht, schreibt er nur falsche Tests.
@Davor Eine gängige Methode besteht darin, dass Entwickler Komponententests schreiben, der Produkteigentümer / Chef / Kunde jedoch Akzeptanztests schreibt. Der Code muss diese passieren, um als „erledigt“ zu gelten.
@Angew - Ja, das hört sich gut an. Ich dachte nur an Unit-Tests.
„Ich möchte seinen Code verwerfen, meinen eigenen schreiben und ihm erklären, wie und warum ich ihn so codiert habe“ : der denkbar schlechteste Weg für ihn, das Codieren zu lernen, und für Sie, das Delegieren zu lernen. Bitte vermeiden.
Wenn Sie mit weniger qualifizierten Personen arbeiten, ist es am besten, die Feedback-Schleife zu verkürzen. Überprüfen Sie ihre Arbeit oft und stellen Sie sicher, dass sie auf dem richtigen Weg sind. Am Ende des Tages sind Sie für ihre Arbeit verantwortlich. Wenn sie das Falsche programmieren, wird es Sie nur verlangsamen.
@FreeAsInBeer Das werde ich berücksichtigen. Wir werden daran arbeiten, den Code zu überprüfen, bevor sie zur Tür hinausgehen.
@coredump dafür ist es definitiv zu spät. Er sagte mir, er verstehe, dass wir unter Zeitdruck stünden und ich wollte ihm eine neue Methode beibringen. Wir setzten uns hin und gingen meinen Weg, es zu tun, und seinen Weg durch. Ich erklärte, warum er nicht gut war (weil er Dinge fest programmiert hatte, wenn wir wollten, dass unser Code robuster und flexibler war), ich brachte ihm Techniken bei, wie man Daten festhält, und erklärte, wann und wo er auf dem richtigen Weg war und hatte die richtige Idee, brauchte aber etwas mehr. Ich weiß nicht, ob es die BESTE Entscheidung war, aber ich glaube nicht, dass es die falsche war.
@TomSterkenburg Ich bin froh, dass es gut gelaufen ist, du scheinst einen guten Ansatz gewählt zu haben. Ich war besorgt, dass Sie anfangen würden, den Praktikanten zu bevormunden und ihn zu manipulieren (ja, ich bin eher pessimistisch). Schön, dass es bei dir funktioniert hat.
@coredump Ich verstehe deine Bedenken, ich hätte sie auch. FreeAsInBeer schlug kleinere Feedbackschleifen vor, also habe ich seinen Code heute für eine andere Aufgabe überprüft, bevor er ging. Es war definitiv eine großartige Idee, ich konnte auf kleine Fehler in seinem Gesamtdesign hinweisen (keine Verwendung von Gettern, unnötige Änderung globaler Variablen) und sicherstellen, dass er wusste, warum wir es anders machen wollten. Das klingt ein bisschen nach Mikromanagement, aber ich denke, diese Art ist gerechtfertigt, weil ein Teil meiner Arbeit darin besteht, ihn zu unterrichten, weil er erst ein College-Student im 2. Jahr ist. Ich denke, es lief gut, danke an alle für die Hilfe!
Du behandelst Menschen, als wärst du für sie verantwortlich. Gut für dich. Ich würde dir ein Bier spendieren, wenn ich könnte.

Antworten (7)

Fragen Sie ihn am besten danach: „Mal sehen, was Sie für Feature X gemacht haben. Was war Ihr Gesamtplan? Wie haben Sie Input gesammelt, verarbeitet, Output produziert? Warum haben Sie ABC auf diese Weise gemacht?“. Als Vorgesetzter muss das nicht anklagend sein. Es erstellt einen Dialog, in dem Sie sehen können, was ihr Plan ist, und Sie können sie nach ihrer Lösung für Hindernisse fragen, auf die sie stoßen werden.

Vielleicht haben sie eine brillante Lösung, die Sie nicht sehen können, vielleicht erkennen sie das bevorstehende Hindernis nicht. Du kannst es nicht wissen, bis du mit ihnen sprichst.

Wenn sie für den gegebenen Zeitrahmen keine zufriedenstellende Lösung haben, muss es nicht hart sein. „Unser Zeitrahmen ist eng, also werde ich das selbst übernehmen. Es war ein guter Versuch, ich habe einen ähnlichen Fehler gemacht, als ich ein Praktikant war. Bitte (geben Sie eine andere Aufgabe an).“

Letztendlich habe ich diese Antwort gewählt, weil sie eher der Frage und meinem Zeitrahmen entsprach. Er ist an 2 Tagen in der Woche da und möchte seinen letzten Tag dieser Woche lieber mit einer anderen Aufgabe verbringen. Beim Coden ist es oft ratsam, von vorne zu beginnen, anstatt mit einem kaputten System zu arbeiten, und ich denke, dies ist einer dieser Fälle. Besser er beginnt eine neue Aufgabe neu, nachdem ich erklärt habe, wie und warum ich seine aktuelle Aufgabe verschrottet habe, als dass wir Zeit damit verschwenden, seinen aktuellen Code so zu verwalten, wie ich es eigentlich gemeint habe. Wir werden auf jeden Fall an der Kommunikation arbeiten.
@TomSterkenburg Beachten Sie, dass das Delegieren von Arbeit auch mit der Freigabe der Kontrolle einhergeht. Der einzige Punkt ist, dass der Code tatsächlich das tun muss, was er tun soll (Fehlkommunikation ist wahrscheinlich ein Fehler Ihrerseits, aber keine Sorge, das richtige Delegieren ist eine ziemlich komplexe Fähigkeit, es braucht Zeit, um es zu lernen). Das Hinzufügen zusätzlicher Einschränkungen ist ebenfalls in Ordnung, aber Sie müssen die Grenze zwischen „einer wichtigen Einschränkung“ und „ich würde es nicht so machen“ erkennen. Andernfalls ist Delegation nur Zeitverschwendung.
@TomSterkenburg Sie haben angegeben, dass Sie erst seit Mai Vollzeit-Entwickler sind. Ich denke, es ist noch zu früh in Ihrer Karriere, um allgemeine Verallgemeinerungen vorzunehmen wie „Beim Coden ist es oft ratsam, von vorne anzufangen, anstatt mit einem kaputten System zu arbeiten …“ Was Sie feststellen werden, ist, dass Sie oft nicht arbeiten werden B. in Greenfield-Projekten, sondern arbeiten mit alten Systemen und altem Code, der vielleicht sogar kaputt ist. Sie werden den alten Code nicht einfach über Bord werfen und von Grund auf neu schreiben.
@Moss Aber meistens wäre es noch besser gewesen, es aufzugeben ;-) Nur weil man die meiste Zeit mit einem schrecklichen Altsystem arbeiten muss, heißt das nicht, dass es gut oder klug ist ... Es ist manchmal notwendig
@Falco Die meiste Zeit wäre es noch besser, es fallen zu lassen? Recht. Versuchen Sie, dies einem Unternehmen mit einem großen, komplexen und etablierten System mit vielen Benutzern zu sagen, die darauf angewiesen sind. Wenn es Ihr Lieblingsprojekt ist, an dem Sie zu Hause gearbeitet haben, in Ordnung. Wenn es um tatsächliche Unternehmen und Budgets und Finanzen und Reputation geht, ist das keine leichte Sache. Außerdem könnte die Entscheidung, es zu tun , katastrophal sein .
Probieren Sie Pair Programming aus. Sie müssen es immer noch richtig machen, und er lernt Schritt für Schritt, während Sie es tun.
@Moss Wie auch immer, wir arbeiten nicht mit einem Legacy-System, wir arbeiten mit Code, der vor 3 Tagen geschrieben wurde. Vielleicht nicht „oft“, vielleicht wäre ein besseres Wort „manchmal“, aber lassen Sie uns nicht in der Semantik aufhängen. Ich glaube nicht, dass irgendjemand widersprechen würde, dass man manchmal von vorne anfangen muss. Das gilt auch für viele Dinge im Leben. Diesmal vielleicht nicht, aber dafür ist es sowieso zu spät

Mit einem Wort ... nicht. (Ja, okay, das ist eine Kontraktion.)

Sie haben angegeben, dass Sie diese Praktikanten beaufsichtigen, weil Ihr Chef möchte, dass Sie das Delegieren lernen. Dahinter steckt mehr als nur „Hier ist etwas Arbeit, mach das“. Wenn Sie jetzt die Arbeit des Praktikanten übernehmen, haben Sie, wie mir scheint, nicht das gelernt, was Ihr Chef Ihnen beibringen wollte.

Sie haben zugegeben, dass es Kommunikationsprobleme gab. Um Delegieren zu lernen, müssen Sie lernen, effektiver zu kommunizieren. Der Kommunikationszyklus umfasst Erzählen, Zuhören, Feedback und Korrigieren/Nacherzählen; In diesem letzten Teil beginnt der Zyklus von neuem und wird so lange fortgesetzt, wie es erforderlich ist. Es scheint, dass Sie bisher versucht haben, nur die ersten beiden Teile zu verwenden. Sie benötigen jedoch die zweiten beiden Teile, um eine genaue Kommunikation sicherzustellen.

Mein Vorschlag ist, zurück zum Praktikanten zu gehen und ihn wissen zu lassen, dass Sie beide sich falsch verständigt haben. Überprüfen Sie, was das Projekt sein soll, und stellen Sie sicher, dass der Praktikant ein gutes Verständnis davon hat; lass ihn nicht einfach "Ja, ich verstehe" sagen. Bitten Sie ihn, (in seinen eigenen Worten) zu wiederholen, was er tun soll, und gegebenenfalls Korrekturen vorzunehmen. Bitten Sie ihn dann, einen Plan zu erstellen und diesen durchzugehen, bevor er mit dem Programmieren beginnt. Bleiben Sie auch aufgeschlossen; sein Ansatz ist nicht unbedingt falsch, nur weil es nicht das ist, was Sie getan hätten; Natürlich ist es möglich, dass sein Ansatz nicht funktioniert, aber es ist Ihre Aufgabe, ihn zu einer funktionierenden Lösung zu führen, nicht es selbst zu tun.

Das einzige, was ich dieser Antwort hinzufügen möchte, ist: Delegieren Sie wichtige Aufgaben in Zukunft nicht mehr an Praktikanten. Praktikanten sollten nur an Dingen arbeiten, die keine große Sache sind, wenn sie nicht funktionieren.
Außerdem denke ich, dass Sie sich mit weniger Praktikanten befassen sollten (einer für ältere Mitarbeiter sollte mehr als genug sein), um sie richtig betreuen und in der Lage sein zu können, selbstständig zu arbeiten.
@NotMe Ich würde diesem Gefühl nicht zustimmen, zumindest in Bezug darauf, wie mein Arbeitsplatz mit Praktikanten umgeht. Sie werden bezahlt und sie sind hier, um wertvolle Erfahrungen zu sammeln. Ich versuche sicherzustellen, dass sie sie bekommen. Es gibt wirklich keine Aufgabe, die ich ihnen geben könnte, die nicht wichtig ist
@TomSterkenburg, es hört sich so an, als ob Ihre Unternehmenskultur dazu neigt, Praktikanten etwas mehr Verantwortung als sonst zu übertragen (ich befinde mich derzeit in einem ähnlichen Umfeld). Ein solches Umfeld akzeptiert wahrscheinlich die Tatsache, dass die interne Arbeit möglicherweise nicht erfolgreich ist, und versteht das Risiko, das dies für Projekte haben könnte. Ich denke, der Projektverantwortliche sollte Einfluss darauf haben, ob Sie Ihren Praktikanten coachen, um die Aufgabe wieder auf Kurs zu bringen, oder sie für ihn übernehmen. Ich habe nicht als Antwort gepostet, da dies keine Ratschläge zu Ihrer eigentlichen Frage gibt. :)
@blaughw richtig. Nun, in diesem Fall bin ich der Projektmanager. Es ist kein riesiges Projekt, aber ich leite im Grunde das Ganze, einschließlich der Kundeninteraktion und all dem. Ich beschloss, seinen Code und meinen neuen Code durchzugehen und zu sehen, was er vorhatte
@TomSterkenburg Wenn Sie wirklich möchten, dass sie lernen, können Sie sie bitten, ihren Code neu zu schreiben - diesmal gemäß Ihren Standards. Ich habe nie von Leuten gelernt, die Code für mich geschrieben haben, ich habe von Leuten gelernt, die mir gesagt haben, in welche Richtung ich gehen soll (verwenden Sie eine Liste, um sie zu durchlaufen, verwenden Sie Technik-x usw.). Erzählen Sie auch keine Fallstricke wie "hier nach null suchen". Das sind die wertvollsten. Außerdem sagten Sie, Sie hätten Kundenkontakt. Beziehen Sie, wenn möglich, die Praktikanten in diesen Teil ein. Solche Momente habe ich immer genossen.
@EdwinLambregts Guter Rat, aber ob sie mit Kunden interagieren oder nicht, liegt leider nicht in meiner Hand. Sie sind nur dazu berechtigt, so viel zu tun. Nur Vollzeitmitarbeiter interagieren direkt mit Kunden, obwohl sie protokollierte Fehler vom Kunden sehen können
Dies. Wenn der Praktikant die Aufgabe nicht verstanden hat und Sie keinen zweiten Versuch unternehmen, sie besser zu kommunizieren, warum fühlen Sie sich dann nicht besiegt? Praktikanten erledigen die Dinge langsamer als erfahrene Mitarbeiter, aber Sie sollten trotzdem möglichst alle Phasen der Aufgabe durchlaufen, und „Schrott und neu anfangen“ ist eine Phase jeder Aufgabe, in der der erste Versuch völlig nutzlos ist.

Niemals den Code einfach wegwerfen und für jemand anderen neu schreiben. Wenn die Person für Sie arbeitet, setzen Sie sich hin und erklären Sie, was falsch war und was genau Sie wollen, und zwingen Sie sie dann, das Umschreiben zu machen, bis sie es richtig gemacht hat.

Andernfalls erledigen Sie sowohl Ihre als auch die Ihrer Arbeit, und sie bleiben nicht kompetent. Viele Leute sind frustriert, wenn das passiert, weil sie nicht sehen, warum es umgeschrieben wurde, und einfach davon ausgehen, dass alles, was sie tun, umgeschrieben wird, weil Joe ein Kontrollfreak ist, nicht weil er Probleme hat.

Sie werden nicht besser, wenn Sie dies tun, und es erweist ihnen einen großen Bärendienst. Es bedeutet auch, dass Sie nicht richtig delegieren und dass Sie überwältigt sein werden und sie glücklich weiterrollen und denken, dass sie großartig sind und Sie ein Idiot sind. Es ist schwieriger, jemanden zu trainieren, als umzuschreiben. Aber wenn man sich die Zeit ein paar Mal genommen hat. dann werden Sie eine Verbesserung erzielen, weil nur sehr wenige Menschen gerne ihre Arbeit wiederholen müssen.

Nun kann es sein, dass Sie sich mit dieser Person zusammensetzen und ein Pairing-Programm durchführen müssen, wenn sie wirklich sehr wenig Wissen hat. Aber in diesem speziellen Fall lassen Sie sie eine Lösung finden und stoppen den Praktikanten einfach, wenn er anfängt, in die falsche Richtung zu gehen. Sie stellen immer wieder Fragen wie „Warum haben Sie sich für diese Methode entschieden? Haben Sie schon einmal über eine Bibliothek nachgedacht?

Und denken Sie daran, dass dies nicht nur die Schuld des Praktikanten ist. Wenn Sie nicht klar waren, wonach Sie fragten, und wenn Sie sie nicht jeden Tag überprüften und sich Zwischenstücke ihres Codes ansahen, dann waren Sie genauso schuld wie der Praktikant. Machen Sie dies also nicht zu einer Schuldzuweisung, sondern zu einer produktiven, konstruktiven Kritik.

Kurz gesagt, setzen Sie sich mit dem Praktikanten zusammen und lassen Sie ihn/sie zusehen, wie Sie das Projekt codieren, ihm/ihr erklären, warum Sie das Projekt so codieren, wie Sie es tun, und dem Praktikanten dabei gute Codierungspraktiken beibringen. Anstatt über das Versagen des Praktikanten nachzudenken, können Sie daraus eine Unterrichtserfahrung machen. Scheitern ist wirklich eine der besten Möglichkeiten, um zu lernen, was nicht funktioniert, und obwohl Sie nicht unhöflich sein sollten, den Praktikanten mit seinem schlechten Code über den Kopf zu schlagen, müssen Sie veranschaulichen, warum sein Code nicht funktioniert, und warum der beste Plan an dieser Stelle ist, von vorne zu beginnen.

Ob sich der Praktikant niedergeschlagen fühlt oder nicht, liegt an diesem Praktikanten. Sie müssen ohnehin lernen können, mit Misserfolgen umzugehen, wenn sie es noch nicht getan haben. Wenn Sie jedoch richtig mit der Situation umgehen, sollte der Praktikant zumindest etwas gelernt haben. In dieser Situation ist das viel wichtiger, als sich Sorgen zu machen, dass sie sich beleidigt oder gedemütigt fühlen.

Ich würde definitiv mit ihm programmieren, wenn er heute verfügbar wäre, aber es gibt Zeitbeschränkungen und ich muss es leider heute erledigen.
Wenn es ein Zeitproblem ist, ist dies eine weitere Erinnerung an dich selbst, sicherzustellen, dass er die Zeiterwartungen kennt. Ich nehme an, du arbeitest länger und er ist schon gegangen? In diesem Fall gibt es nicht viel zu tun, dann tun Sie es selbst. Er wird die Gelegenheit verlieren, Sie beim Programmieren zu sehen.
@TomSterkenburg: Wenn der Abgabetermin heute ist und der Praktikant die Aufgabe nicht erledigt hat und heute nicht im Büro ist, dann klingt es so, als hätten Sie dem Praktikanten nicht genug Zeit gegeben, um die Aufgabe zu erledigen, und/oder Sie haben es getan den Fehler des Praktikanten nicht früh genug erkennen, damit er sich davon erholen kann. Das gehört natürlich alles zur Ausbildung dazu, man muss Praktikanten Zeit lassen, langsam zu sein. Diese Dinge passieren.
Unter keinen Umständen sollte die Aufgabe codiert werden. Sie sollten ihn die Aufgabe codieren lassen, während Sie zuschauen und verbale Anweisungen geben. Er wird nie besser, wenn Sie seine Arbeit wiederholen.

Erwägen Sie Pair Programming mit dem Praktikanten. Entweder gehen Pair-Programme durch ihren falschen Code und versuchen, ihn zu beheben, oder gehen durch ihren Code, erklären seine Fehler und diskutieren und Pair-Programmierung neuen, besseren Codes. Pair Programming ist das beste Lernwerkzeug, Wissenstransfer, Code-Review, QA, alles in einem!

Manchmal müssen Sie aus Zeitgründen einfach ihre Sachen verschrotten und die Arbeit erledigen. Habe das schon einmal gemacht, und es war mit einem Senior-Entwickler. Man merkte, dass sie sich leicht niedergeschlagen fühlten, aber sie wussten, dass wir unsere Arbeit erledigen mussten.

Wenn es die Zeit erlaubt, nutzen Sie die Chance, gemeinsam zu lernen. Sie werden lernen, wie man besser programmiert, Sie werden erfahren, wo die Fehlkommunikation passiert ist. Sie werden viel besser lernen, Aufgaben zu erklären und Geschichten zu schreiben, wenn Sie sehen, wie andere die Anfrage interpretiert haben.

Paarprogrammierung ist großartig, aber wenn Sie es tun, muss der Praktikant die Person sein, die tatsächlich die Tastatur bedient.
Voll und ganz einverstanden @HLGEM

Ich möchte seinen Code verwerfen, meinen eigenen schreiben und ihm erklären, wie und warum ich ihn so codiert habe

Ja! Tu es!

Äh, vielleicht.

Ich habe die sehr vernünftigen Einwände gegen diesen Ansatz gelesen. Jetzt, wo ich gerade ein Fass voll Benzin in dieses Feuer gekippt habe, weiß ich, dass ich einiges erklären muss. Meine kurze Zusammenfassung ist, dass dieser Ansatz das Potenzial hat, sehr nützlich zu sein.

Ein viel zitiertes Beispiel ist die Schulung der US-Regierung zur Erkennung von Falschgeld. Den Menschen wurde diese Fähigkeit beigebracht, indem sie sich sehr gut mit dem vertraut machten, was richtig ist, anstatt zu studieren, was falsch ist. Wenn der von Ihrem Kollegen erstellte Code ausreichend düster ist, besteht die beste Option möglicherweise darin, das Unbrauchbare zu eliminieren und zu demonstrieren, was gut ist, und zu diskutieren, was gut ist, und sicherzustellen, dass er das tun kann, was gut ist.

Also, trotz der Einwände, die andere Leute vorgebracht haben, würde ich vorschlagen, dass Ihr Plan Verdienst haben könnte und vielleicht sogar der beste Plan ist. Es kann jedoch auch nicht sein. Als meine Karriere die Rolle eines College-Lehrers übernahm, konnte ich die Qualität der Arbeit sehen, die eine Gruppe von Studenten erstellte. Ich habe auch gesehen, wie effektiv die Leute einige Dinge lernten und andere Dinge nicht. Ich begann wirklich zu sehen, wie unterschiedliche Lehrstile für verschiedene Menschen effektiv sind.

Ich habe auch gelernt, dass erfolgreiches Delegieren bedeutet, jemandem eine Aufgabe zu übertragen, die er erfolgreich erledigen kann, und dazu gehört auch, sein Qualifikationsniveau zu bestimmen. Ein typisches Beispiel: Manche Menschen zögern, Entscheidungen zu treffen, aber sie wissen, wie Dinge getan werden sollten. Sie könnten sie fragen: "Nun, was sollte Ihrer Meinung nach getan werden?" Indem Sie sie dazu anregen, die erforderlichen Maßnahmen zu ergreifen, können Sie dazu führen, dass sie beginnen, die Macht zu erkennen, die sie nutzen könnten, und möglicherweise gedeihen. Wenn Sie jedoch einer Person, die gerade einer Organisation beigetreten ist, die gleiche Frage stellen und diese Person nicht genügend Details kennt, um eine vernünftige Entscheidungsgrundlage zu haben, kann eine identische Anstachelung nur verheerende Auswirkungen haben.

Wenn Sie versuchen, jemanden zu schulen, stellen Sie sicher, dass Sie (früh im Prozess) Fragen stellen, um das Verständnis zu überprüfen und festzustellen, welcher Ansatz hilfreich ist und welcher nicht. Konzentrieren Sie sich darauf, ihnen die Struktur zu geben, die sie brauchen, mit klar definierten gewünschten Ergebnissen und vielleicht sogar klar definierten Ansätzen, und überlassen Sie ihnen dann die Aufgabe, das von Ihnen festgelegte, einfach zu erreichende Ziel zu erreichen. Was die Bereitstellung von Beispielen (von Ihnen und von ihm erstellt) und die Bereitstellung von Anweisungen betrifft, so wird die Nützlichkeit eines bestimmten Ansatzes von Person zu Person unterschiedlich sein.

In Zukunft müssen Sie Praktikanten wissen lassen, dass sie eine kritische Aufgabe übernehmen, aber wenn Sie ihre Arbeit bis zu einem bestimmten Zeitpunkt nicht genehmigen können, wird sie von jemand anderem erledigt. Das ist fair, offen und ehrlich. Das bedeutet nicht, dass sie es nicht ernst nehmen sollten, weil Sie ihnen eine gute Empfehlung geben möchten. Praktikanten sollten nicht mit geschäftskritischem Druck belastet werden.

Versuchen Sie, eine Art Nachbesprechung durchzuführen, damit Sie nachvollziehen können, wo Sie bei der Erklärung dieses Problems gegenüber dem Praktikanten gescheitert sind oder welche Annahmen Sie hinsichtlich seines Qualifikationsniveaus getroffen haben. Es gibt keinen Grund, dies nicht auch für Sie und Ihr Unternehmen zu einer Lernerfahrung zu machen.

Da Sie das nicht getan haben, würde ich mit dieser Erklärung beginnen und mich dafür entschuldigen, dass ich dies nicht gleich gesagt habe. Ich vermute, der Praktikant wird es verstehen. Halten Sie sie über Ihre Herangehensweise auf dem Laufenden. Nehmen Sie sich die Zeit, so viel wie möglich zu erklären. Wenn möglich, nicht alles wiederholen. Hoffentlich gibt es dort einen einlösbaren Code.

Geben Sie dem Praktikanten so schnell wie möglich etwas zu. Lassen Sie sie wieder auf das Pferd steigen, nachdem sie heruntergefallen sind. Vielleicht können sie dieses Projekt mit Ihren neuesten Vorschlägen umschreiben.

Ich denke nur, wenn man es ruhig und professionell angeht, wird sich der Praktikant nicht zu sehr verprügeln. Es ist wichtig, dass sie verstehen, dass Sie ihre Fähigkeiten erweitern möchten, und es sollte ein realistisches Maß an Misserfolg geben, aber keinen totalen Misserfolg. Manchmal läuft einem einfach die Zeit davon.

Wie kann man die Aufgabe eines Praktikanten übernehmen, ohne dass er sich geschlagen fühlt?
AntwortenHierDatenschutz-Bestimmungen1y, 0v