it-swarm.com.de

So verwalten Sie einen Entwickler mit schlechten Kommunikationsfähigkeiten

Ich leite ein kleines Entwicklerteam für eine Anwendung, die sich in der Mitte ihres Lebenszyklus befindet, in einem großen Unternehmen. Dies bedeutet leider, dass die Programmieraufgaben üblicherweise zu 30/70 auf "andere technische Arbeiten" aufgeteilt werden. Diese Arbeit beinhaltet:

  • Arbeiten mit DBA/Unix/Network/Loadbalancer-Teams bei verschiedenen Aufgaben
  • Auftragserteilung und Verwaltung von Hardware- oder Infrastrukturaufträgen in verschiedenen Regionen
  • Ausführen von Tests, die noch nicht auf CI migriert wurden
  • Analyse
  • Unterstützung/Untersuchung

Es ist fair zu sagen, dass die Entwickler alle lieber programmieren würden, als diese alltäglicheren Aufgaben zu erledigen, also versuche ich, die lustigen Programmierjobs gleichmäßig im Team zu verteilen.

Der größte Teil des Teams wurde eingestellt, weil sie, obwohl sie möglicherweise nicht über die Elite-Programmierkenntnisse verfügen, um ihre eigene Compiler-/Game-Engine/Hochfrequenz-Handelssysteme usw. zu schreiben, gute Kommunikatoren sind, die "Dinge erledigen können" und mit anderen Teams zusammenarbeiten und navigieren hier etwas durch die komplexe Bürokratie. Sie sind gute Entwickler, aber auch gute technische Mitarbeiter.

Ein Mitglied des Teams verfügt jedoch wahrscheinlich über überdurchschnittliche Codierungsfähigkeiten, aber überdurchschnittliche Kommunikationsfähigkeiten. Traditionell gab ihm der vorherige Entwicklungsmanager eher die Programmieraufgaben als die oben aufgeführten alltäglicheren Aufgaben. Ich bin jedoch nicht der Meinung, dass dies dem Rest des Teams gerecht wird, das die Fähigkeit bewiesen hat, ein umfassendes Know-how zu entwickeln, das in einer IT-Abteilung für große Unternehmen häufig benötigt wird.

Was soll ich in dieser Situation tun? Wenn ich ihm weiterhin mehr Programmierarbeit gebe, weiß ich, dass dies schneller erledigt wird (und umgekehrt würde ich erwarten, dass er die andere Arbeit langsamer erledigt). Aber es widerspricht meinen Grundsätzen und fördert die Idee, dass Sie sich eine "bequeme Nische" schaffen können, indem Sie einfach schlecht mit den Aufgaben umgehen, die Sie nicht mögen.

Ich möchte klarstellen, dass ich nicht versuche, dieses Problem aufgrund eines Grolls anzugehen, oder dass ich, wie erwähnt, einen "Chip auf meiner Schulter" habe. Ich suche Ratschläge, wie man ein rundes Team führt, das glücklich und motiviert ist. Wenn man die Vielfalt der Antworten auf diese Frage betrachtet, scheint es viele unterschiedliche Meinungen darüber zu geben, wie dies erreicht werden kann.

52
djcredo

Es hört sich so an, als würden Sie sich zu viel Mühe geben, um gut gerundet zu sein Einzelpersonen und nicht genug Mühe, um eine gut gerundete Team zu haben.

Es ist nichts Falsches daran, in etwas gut zu sein - wahrscheinlich wurde er deshalb eingestellt! Sie sollten dankbar sein, jemanden zu haben, der von Anfang an gut programmieren kann.

Du hast gesagt:

... es widerspricht meinen Grundsätzen und fördert die Idee, dass Sie sich eine "komfortable Nische" schaffen können, indem Sie einfach schlecht bei den Aufgaben sind, die Sie nicht mögen.

Wenn er ein mittelmäßiger Programmierer wäre, würde ich zustimmen. Aber das hast du nicht gesagt. Sie sagten, er sei ein guter Programmierer. Er ist nicht schlecht in den anderen Aufgaben, um aus ihnen herauszukommen - er hat seine Bemühungen lediglich darauf konzentriert, ein besserer Programmierer zu werden. Daran ist nichts auszusetzen.

Als Manager ist es nicht Ihre Aufgabe, dafür zu sorgen, dass alle "rund" sind. Es ist Ihre Aufgabe, dafür zu sorgen, dass s *** erledigt wird. Und das machst du nicht. Tatsächlich treffen Sie Entscheidungen, die Stoppen Dinge nicht erledigen.

Welches Problem Sie auch haben, Sie müssen es überwinden - Sie machen Ihr Team weniger produktiv.

77
riwalk

Sie bekommen hier in den anderen Antworten etwas Hitze für Ihre Entscheidung, etwas gegen diesen Kerl zu tun, aber ich verstehe voll und ganz, was Sie sagen. Wenn die anderen Teammitglieder "alle lieber programmieren würden, als diese alltäglicheren Aufgaben zu erledigen", werden sie sich darüber ärgern, dass Sie Belohnung für die schlechte Leistung des armen Kommunikators, indem Sie ihm gerecht geben die Aufgaben, die jeder will.

Stellen Sie sich vor, Sie sind einer der "guten Kommunikatoren" im Team, deren Fähigkeiten mit denen des betreffenden Entwicklers vergleichbar sind. Sie bearbeiten Anrufe, arbeiten mit anderen Nicht-IT-Mitarbeitern zusammen, die kaum eine Maus von einer Tastatur kennen, schreiben Pläne für die Benutzerabmeldung auf und vieles mehr, weil Ihr Chef dies vorschreibt. Der mürrische Entwickler kann sich in der Zwischenzeit, weil er "schlechte Kommunikationsfähigkeiten" hat, den ganzen Tag in seinem Würfel zurücklehnen und die Benutzer ignorieren, die nur an den "lustigen" Sachen arbeiten.

Jetzt hast du gesagt, dass der mürrische Entwickler "überdurchschnittliche" Fähigkeiten hat, aber du hast nicht gesagt, dass er der Beste ist. Dies bedeutet, dass vielleicht 1/3 Ihres Teams, die guten Kommunikator-Entwickler, die über die Fähigkeiten des mürrischen Entwicklers oder höher verfügen, alle sauer sind.

Lohnt es sich, etwas Produktivität von Ihrem BEST PERFORMING STAFF zu verlieren, weil sie sich über den mürrischen Entwickler ärgern? Du musst dich entscheiden.

Wenn Sie den Kerl nicht feuern möchten, schlage ich vor, dass Sie einen der folgenden Ansätze wählen:

1) Mentor ihn, um ein besserer Kommunikator zu sein. Nur Sie können sagen, ob dies machbar ist. Es könnte hilfreich sein, nur seine Hand zu halten. Einige Menschen haben nur Angst vor formellen Geschäftsinteraktionen und drücken dies aus, indem sie sauer sind, wenn sie dazu aufgefordert werden.

2) Anreize für die "gute Kommunikation" schaffen entweder mit Geld oder anderen Vorteilen. Machen Sie deutlich, dass Sie gute Kommunikatoren wirklich schätzen und Ihre Entwickler dann nicht so verärgert sind, aber die Belohnung muss real und sinnvoll sein. "Mittagessen mit dem Bezirksleiter" wird es nicht schneiden. Ein "Star Player/Kudos/Attaboy" -Preis wird auch nicht nur ein Stück Papier sein. Es muss zusätzliches Geld, zusätzlicher Urlaub, eine gewisse Gleitzeit, eine ernsthafte Anerkennung bei höheren Unternehmen sein, die Gehaltserhöhungen kontrollieren usw.

39
Graham

Zuallererst bedeutet es schlechte Managementfähigkeiten., Ihren Teammitgliedern die Schuld zu geben

Ich meine, wenn er wirklich schlechte Kommunikationsfähigkeiten hat, tut mir sein soziales Leben sehr leid, aber bei der Arbeit ist dies nicht so sehr sein Problem wie es ist deine. Und seien wir ehrlich, er könnte tatsächlich nur gelangweilt durch Ihre langweilige Arbeitsumgebung sein oder private Probleme haben, die seine Leistung beeinflussen, oder heimlich planen, Sie alle zu töten.

Die Kommunikation dauert mindestens zwei, und schließlich könnten Sie derjenige mit den Fähigkeiten schlechter Menschen sein. Ungeachtet dessen, dass der Rest der Teammitglieder ziemlich gut miteinander auskommt, könnten sie alle (auch ohne es zu wissen) einen Kommunikationsmangel kompensieren, den Sie haben, und ihn selig ignorieren.

Und wie auch immer, gehen Sie nicht im Internet herum und fragen Sie nach Leuten, die drei Schreibtische von Ihnen entfernt sitzen. Gehen Sie zum Jungen und fragen Sie ihn, ob wirklich etwas nicht stimmt und ob es geklärt werden kann. (oder etwas Langweiliges, das optimiert oder verbessert werden kann)

Vielleicht hasst er nur seine Schreibtischposition (steht er vor den Toiletten?) Und das macht ihn schlecht gelaunt.

Hinweis: Hören Sie auf die Antwort, als wäre er ein empfindungsfähiger Mensch, keine menschliche Ressource.

(zB: versuche erkläre ihm ausführlich die Notwendigkeit bestimmter Praktiken und die Bedeutung bestimmter Entscheidungen, einige Leute graben Details, da sie ihnen das Gefühl geben, einen Kapitän zu haben, der das tut fährt das Schiff nicht in die Klippen)

9
ZJR

Menschen sind unterschiedlich. Als Manager müssen Sie die Menschen anders (aber fair!) Behandeln, um das Beste aus Ihrem Team herauszuholen.

Das heißt, es ist wahrscheinlich gut für Entwickler mit schlechten Soft Skills, daran zu arbeiten. Ich würde herausfinden, welche nicht-codierende Sache der Entwickler mag (oder tun möchte), die mehr von diesen Soft Skills beinhaltet. Lassen Sie sie sich auf diese Aufgabe ein, und im Idealfall verbessern sie die Soft Skills als Nebeneffekt.

Die Leute sind oft nicht schlecht in etwas, um von der Arbeit wegzukommen; Sie sind schlecht darin, weil sie es nicht genießen oder eine Begabung dafür haben. Sie können dem letzteren nicht helfen, also arbeiten Sie am ersteren.

8
Telastyn

30/70 split kann sein, wo all Ihre Probleme beginnen. Ich habe noch nie Entwickler gesehen, die mit einer solchen Trennung zufrieden waren.

Ich habe gesehen, dass Entwickler sich mit 10, 15% anderer Arbeit ​​wohl fühlen (und war selbst glücklich, weil es Spaß macht, wenn die Dosis stimmt), aber 30% sind zu viel. Ich würde eher denken, dass andere Teammitglieder es vorziehen, ihre Meinung nicht zu äußern, als dass es nur einen gibt, der "30% andere Arbeit" nicht mag.

Ich denke auch, dass es wichtig ist, Ihre "Produktivitätsmathematik" an realistischere Zahlen anzupassen. Es wird sich aufgrund unvermeidlicher Verluste bei "Kontextwechseln" niemals zu 100% summieren.

  • 30 + 70, die beim Umschalten zwischen Programmierung und andere Arbeit ​​bis zu 100% Produktivität summieren, wird im wirklichen Leben niemals passieren; es ist wahrscheinlicher über 20 + 50 oder sogar 20 + 40. Kontextwechsel sind für Softwareentwickler besonders schmerzhaft. Wenn Sie interessiert sind, lesen Sie in diesem Artikel nach, warum dies so ist: WACHEN SIE DEN PROGRAMMER NICHT AUF!
    Programmierer, die ihre Produktivität schätzen, wären natürlich über solche Verluste unglücklich.

Was Ausführen von Tests Teil des Jobs betrifft, haben Sie darüber nachgedacht, ihn an Tester weiterzugeben? Die Tatsache, dass Programmierer können es tun (ich denke, jeder erfahrene Programmierer sollte dazu in der Lage sein), bedeutet nicht, dass sie sollten. Tester können es auch, und sie machen es besser, und sie werden keine Produktivitätsverluste bei "Kontextwechseln" erleiden.

Ein weiterer Punkt, an dem ich mich frage, wie Sie QS-Ressourcen nutzen, ist Ihre Erwähnung von Support/Investigation. Professionelle Tester, mit denen ich früher zusammengearbeitet habe, neigen dazu, in solchen Dingen "zuerst zu sagen".

  • Als Ex-Tester verstehe ich sie ziemlich gut - Produktionsprobleme waren für mich (als Tester) eine unschätzbare Datenquelle, um mehr über die Testabdeckung zu erfahren ("Wurde dieses Problem durch meine Tests ordnungsgemäß abgedeckt?") Und für Fehlerpriorisierung ("Okay, es wurde durch Tests abgedeckt und vor der Veröffentlichung gemeldet, aber habe ich damals die entsprechende Priorität/Schwere festgelegt?").

Für einen guten Tester ist es recht einfach herauszufinden, wann die Untersuchung des Supportproblems an Entwickler weitergeleitet werden muss, und dies kommt nicht sehr oft vor. Gründe, Entwickler damit zu überladen, entgehen mir einfach. Wie ich bereits geschrieben habe, sind sie sicher können das tun (ich würde allgemein erwarten, dass leitende Entwickler wissen, wie man alles macht, was die Qualitätssicherung macht), aber das bedeutet nicht, dass sie sollten.

6
gnat

Ich habe 2 Dinge dazu zu sagen

  1. Haben Sie einen Codierer oder Softwareentwickler? rekrutiert?
    Wenn Sie einen Softwareentwickler in Betracht ziehen, sind alle Dinge, die Sie erwähnt haben, Teil der Softwareentwicklung. Sie können diese nur ignorieren, wenn Sie nur für eine bestimmte Aufgabe eingestellt haben. IMO 50% der gesamten Softwareentwicklung ist Codierung, alles ist Design, Analyse, Test, Dokumentation usw.

  2. Niemand wird perfekt geboren.
    Es kann einfach nicht sein, dass man eine Person findet, die in allem gut ist. Sie müssen sie zum Kämpfen bringen und sie dazu bringen, Dinge zu lernen.

Als Manager muss man das Beste aus ihnen herausholen, aber auf lange Sicht könnten Probleme auftreten. Weisen Sie ihnen leichte Aufgaben zu, damit sie sie in den Griff bekommen. Holen Sie ihnen das Gefühl raus, dass ich bin nicht gut darin/ich kann es mir nicht leisten, dies zu tun. Behandeln Sie vor allem alle gleich, um die effizienteste Leistung Ihres Teams zu erzielen.

4
Shirish11

Wenn jeder Ihrer Mitarbeiter den gleichen Titel/die gleiche Stellenbeschreibung hat und die Stellenbeschreibung alles enthält, was Sie aufgelistet haben, muss dieser Programmierer diese anderen Fähigkeiten schärfen, indem er mehr dieser anderen Nicht-Programmierer-Aufgaben erhält. Ebenso werden Ihre anderen Mitarbeiter ihre Programmierkenntnisse nicht verbessern, wenn sie ständig an nicht programmierenden Aufgaben arbeiten müssen (verwenden oder verlieren).

Aber ich denke immer noch, dass Ihre Hauptpriorität wahrscheinlich darin bestehen sollte, Ihre Fristen einzuhalten (was Sie möglicherweise noch tun können, während Sie die Arbeit gleichmäßig verteilen).

EDIT : Wenn Sie ein kleines Team haben, ist es wahrscheinlich sinnvoll, dass alle Mitglieder mehrere Hüte tragen können. Wenn Sie ein Team haben, das groß genug ist, ist es wahrscheinlich sinnvoll, Gruppen zu haben, die sich auf verschiedene Bereiche spezialisiert haben. Aus Ihrem Beitrag geht hervor, dass Sie kein Team haben, das groß genug ist, um Gruppen von Spezialisten zu haben.

4
programmer

Aus Ihrem ursprünglichen Beitrag geht nicht hervor, was genau an den Kommunikationsfähigkeiten dieses Entwicklers fehlt. Ein mangelndes Interesse an Besprechungen oder Planungs-/Koordinierungsarbeiten (zum Beispiel) weist nicht unbedingt auf schlechte Kommunikationsfähigkeiten hin. Vielleicht hat der Entwickler einfach das Gefühl, dass diese Art von Arbeit Managerarbeit ist und seine Produktivität als Entwickler beeinträchtigt? Oder hat er vielleicht das Gefühl, dass es zu viel organisatorischen Aufwand gibt und dies eine Form des Protests gegen das ist, was er für insgesamt verschwendete Zeit hält? Schließlich ist das gegenteilige Problem, bei dem die Leute den ganzen Tag reden und nie etwas erledigen, auch im Büro ziemlich häufig.

Es ist wichtig, dass Sie mit diesem Entwickler nicht konfrontativ sprechen und herausfinden , warum er die nicht programmierenden Aufgaben vermeidet. Es ist wahrscheinlich kein einziger Grund, er kann so viele verschiedene Gründe haben, wie es verschiedene Arten von Aufgaben gibt. Stellen Sie sicher, dass er versteht, dass der Zweck des Gesprächs darin besteht, dass Sie lernen, wie Sie die Teamproduktivität und die Arbeitszufriedenheit für alle Teammitglieder effektiv verbessern können (Sie möchten ihn nicht erreichen). Dies ist eine Zeit, in der Sie zuhören und nicht streiten oder versuchen, seine Bedenken mit ruckartigen Reaktionen auszuräumen. Sie sollten sich wahrscheinlich auch mit den anderen Teammitgliedern treffen. Vielleicht können sie diesen Typen die schwere Entwicklerarbeit machen lassen, während sie sich auf die gesprächigere Seite des Berufs konzentrieren.

Denken Sie nach diesem Meeting einige Zeit über die Gespräche nach, die Sie geführt haben, und versuchen Sie, die Perspektive dieses Mitarbeiters offen zu betrachten. Vielleicht waren Ihre anfänglichen Gefühle richtig und ihm fehlen einige wichtige Fähigkeiten, die Sie ihm zur Entwicklung bringen sollten. Oder vielleicht hat er Ihre Annahmen in Frage gestellt. Vielleicht können Sie mit anderen Teams zusammenarbeiten, um einige Prozesse zu formalisieren und den Bedarf an redundanter Kommunikation zu verringern. Vielleicht ziehen andere Teams nicht ihr Gewicht und Sie müssen sich freundlich mit ihrem Management unterhalten. Es gibt viele Möglichkeiten, die Sie möglicherweise nicht in Betracht ziehen.

Führen Sie schließlich und vor allem ein Folgegespräch mit Einzelpersonen oder gegebenenfalls eine Teambesprechung. Wenn Sie echte organisatorische Probleme festgestellt haben, auf die Sie Einfluss haben, informieren Sie Ihre Mitarbeiter über die Maßnahmen, die Sie zur Verbesserung ihrer Arbeitssituation ergreifen werden. Wenn Sie immer noch glauben, dass der einzelne Mitarbeiter im Unrecht ist, setzen Sie sich zu ihm und erklären Sie, welche Änderungen Sie von ihm benötigen und warum. Entwickler neigen dazu, gut auf logische/praktische Erklärungen zu reagieren. "Es ist nicht fair gegenüber Ihren Kollegen, Ihnen die ganze lustige Arbeit zu geben. Wir möchten, dass Sie alle reine Entwickler sind, aber das ist nicht die Realität der Situation, also müssen wir die Last der beschissenen Arbeit teilen."

Natürlich, wenn dieser Typ nur ein mürrischer Idiot ist, sich weigert, Ihnen zu sagen, warum er unglücklich ist, nicht auf die Vernunft reagiert und von seinen Kollegen nicht gut respektiert wird ... nun ... es ist Zeit für den Leistungsverbesserungsplan.

4
skelly

Sie versuchen zwar, ein Team zu leiten und möchten alle motiviert halten (Fairness hilft), aber opfern Sie das Projekt, indem Sie nicht über die beste Programmiererprogrammierung verfügen? Ich meine, das ist der Punkt, nicht wahr?.

Haben Sie keine Angst davor, Ihren besten Entwickler zu wenig zu nutzen und/oder zu riskieren? Ihre Aufgabe ist es, diese Art von Pflichten von allen zu entlasten.

Gleich behandelt zu werden bedeutet nicht, dass Sie alle gleich behandeln. Wenn die anderen die Nicht-Programmieraufgaben abbauen wollen, um mehr Programmieraufgaben zu erhalten, laufen sie dann nicht Gefahr, in beiden Bereichen gut zu sein?

EDIT : Abgesehen von Ihren persönlichen Gefühlen haben Sie kein Problem identifiziert. Irgendwann behindert der Mangel an Kommunikation einen Programmierer. Andere werden Ressentiments zeigen und ihre Arbeit kann leiden. Bisher scheinen Sie der einzige zu sein, der ein Problem hat. Es sei denn, Sie teilen noch etwas nicht?

EDIT 2 Irgendwann wird jeder um einen besonderen Gefallen bitten. Diese Person kommuniziert weniger und codiert mehr (was sie auf jeden Fall tun sollte). Jemand anderes möchte etwas später hereinkommen. Ein anderer muss eine Besprechung überspringen, um eine Frist einzuhalten. Eine Grafikperson bekommt einen größeren Monitor. Wenn Sie zu viel Wert darauf legen, Punkte zu sammeln, vergessen Sie, was wichtig ist.

2
JeffO

Ich bin ein mürrischer Linux-Administrator, der viel Skripting macht, und es wurde festgestellt, dass ich schlechte Kommunikationsfähigkeiten habe. Ich höre mich sehr nach deinem Typ an. Tatsächlich ist dies der einzige Bereich, auf den ich mich in Leistungsbeurteilungen einlasse. Auf der anderen Seite führe ich mein Team kontinuierlich in Sachen Innovation und Problemlösung und habe den Weg zu der neuen Plattform geschaffen, die wir einführen, und meinem Team viel Zeit und meinem Unternehmen viel Zeit gespart viel Geld, indem ich ich selbst sein darf.

Mein ehemaliger Chef wurde von seiner Familie/Frau UND der Geschäftsleitung unseres Unternehmens gebeten, seine Position zu verlassen ... gleichzeitig. Er arbeitete unermüdlich daran, die Verantwortung fair auszugleichen, und übernahm selbst viel Last. Wenn es während einer Interaktion mit jemandem außerhalb der Abteilung ein Kommunikationsmissverständnis gab, das auf ihn zurückkam, war er schnell dabei, es zu bestrafen. Er war schlecht darin, "nach oben zu managen", daher war unser Team das letzte, das Ressourcen erhielt, bis es zu einem Notfall kam, und dann überbezahlte das Unternehmen die Anbieter mit raffinierten Verkaufsgesprächen für nicht getestete Hardware, ohne das Team zu konsultieren, das diese Tools verwenden würde. In dem Bestreben, ein "ausgewogenes" Team zu bilden, verwaltete er unsere Aufgabenlisten im Mikromanagement und versuchte, Aufgaben auszugleichen, damit die Teammitglieder ihre Fähigkeiten in Bereichen verbessern konnten, in denen sie nicht großartig waren, was zu einer Menge fehlerhaftem Code führte schlecht strukturierte Implementierungen. Während anderen Personen als dem Autor speziell Support-Aufgaben für diesen fehlerhaften Code zugewiesen wurden, damit sie "lernen" konnten, verursachten die schlecht strukturierten Implementierungen, der Code und die Tests viel schlechtes Wohlwollen zwischen den Teammitgliedern und tatsächlich erhöht Vorkommen des "Schuldspiels", das ein schneller Weg zu einem giftigen Teamzustand ist.

Mein jetziger Chef ist eine ruhige, gesammelte Person, die aus der Junior-Administratorrolle gekommen ist und sich hochgearbeitet hat. Er trifft gute Entscheidungen und verlässt sich stark auf Teammitglieder, um ihre eigenen Prioritäten zu setzen. Er ist ein ausgezeichneter Kommunikator und reagiert ruhig und gemeinsam mit seinem Vorgesetzten auf Kommunikationsprobleme, Ideen oder Bedürfnisse meines Teams. Er "arbeitet unermüdlich nach oben". Er nimmt nur langsam größere architektonische Änderungen vor und berät sich gründlich mit dem gesamten Team, bevor er Änderungen an unserer Umgebung vornimmt. Er kann sich auf die Besonderheiten unserer Teammitglieder verlassen.

Unter dem neuen Manager ist unsere Ausfallzeit auf fast Null gesunken (was auch den Prozentsatz der Zeit, die wir für Supportaufgaben aufwenden, von ungefähr 40% auf ungefähr 10% gesenkt hat), die Zufriedenheit unseres Teams ist durch das Dach gegangen, und wir sind es auf dem richtigen Weg, von einem „Break the Bank für neue Hardware alle drei bis fünf Jahre“ zu einem kontinuierlichen Akquisitionsplan überzugehen, der dem Unternehmen über fünf Jahre hinweg eine coole Million pro Jahr einsparen soll. Dieser Plan war ein Basisprogramm, das unter dem vorherigen Manager niemals zustande gekommen wäre, sondern vom neuen Manager aktiv in die Geschäftsleitung gedrängt wurde und davon abhing, eine Menge Synergien in den Fähigkeiten des Teams zu finden. Der CIO hat uns informell mitgeteilt, dass wir jetzt das einzige Team im Unternehmen sind, das wirklich "ihre Scheiße zusammen hat" und dass er unser Arbeitsumfeld so wenig wie möglich stören und so viele Ressourcen in Problembereiche mischen wird dass wir uns als möglich identifizieren. Dies hat sich bewahrheitet und die "Kosten" für unseren Support noch weiter gesenkt, obwohl dies die Arbeitsbelastung einiger anderer Teams gestört hat - aber es hat auch die "Kosten" für den Support dieser Teams gesenkt.

Schauen Sie, der Ort, an dem Entwickler ihre Fähigkeiten verbessern können, ist in der Schule oder in ihrer Freizeit. Der Ort, an dem sie Dinge produzieren können, liegt in der Zeit Ihres Unternehmens. Der beste Weg, Dinge zu produzieren, besteht darin, das zu produzieren, was sie am besten wissen. Wenn ein Entwickler in Bereichen arbeitet, in denen er sich nicht wohl fühlt, sollte er einen zweiten Entwickler hinzuziehen, der spezialisiert ist und als Team arbeitet, oder der spezialisierte Entwickler sollte den Code schreiben und Dokumentation und Diagramme erstellen. Leiten Sie Supportaufgaben an die Personen weiter, die den Code geschrieben haben. Ja, dies erhöht den sogenannten "Busfaktor" - die Wahrscheinlichkeit, dass Ihre Abteilung einen Geschwindigkeitsschub erleidet, wenn der Spezialist von einem Bus angefahren wird. (Oder entlassen oder Jobs gewechselt oder ...) Die Wahrheit ist, dass Ihr Produktivitätsverlust aufgrund dieser Angst um Größenordnungen höher ist als der tatsächliche Verlust, wenn ein "Busereignis" auftritt. Was im Allgemeinen während eines "Busereignisses" passiert, ist, dass der Erbe der Arbeit des Spezialisten sie nach seinem eigenen Bild neu erstellt, damit er sie am effektivsten unterstützen kann, im Allgemeinen eine Reihe von Problemen löst und die für die Unterstützung aufgewendete Zeit noch weiter verkürzt, und das Leben geht weiter auf.

Weisen Sie Dinge Personen zu, die sie am besten können. Lassen Sie sie ihre Arbeit unterstützen und dokumentieren. Fördern Sie ihre Kreativität und ermöglichen Sie ihnen, sich ohne Ablenkungen oder Mikromanagement zu konzentrieren. Alles andere ist Management-School-BS, was leider so klingt, als würde Ihr Unternehmen darin schwimmen. Das bedeutet nicht, dass Ihr Team auch darin schwimmen muss.

Aus Sicht eines Unternehmens fördert ein guter Manager die Werte des Unternehmens, während er Aufgaben gemäß diesen Werten ausführt. Aus Sicht eines IT-Mitarbeiters lässt ein guter Manager das Team so schnell und sauber wie möglich das tun, was richtig ist, und wirkt als Kotbarriere gegen die Geschäftsleitung, die Werte, die sie in Wochenend-MBA-Kursen gelernt haben, in die Kehlen der Untergebenen drückt. Sie sind ein Firmenmann, und das ist möglicherweise nicht das Beste für Ihr Team. Diejenigen mit "guten" Kommunikationsfähigkeiten sind einfach zu höflich, um es zu sagen.

2
Karl Katzke
  • Stellen Sie sicher, dass der Mitarbeiter weiß, wie wichtig Kommunikationsfähigkeiten für seine Stellenbeschreibung sind. Arbeiten Sie mit ihm/ihr zusammen, um sich zu verbessern.
  • Bestehen Sie nicht darauf, dass sie bei solchen Aufgaben so gut sind wie die anderen Teammitglieder.
  • Weisen Sie Aufgaben nach den Prinzipien zu, an die Sie glauben. Finden Sie ein Gleichgewicht zwischen effizienter Zuordnung von Aufgaben zu Fähigkeiten und Fairness/Spaß.

Dies sind nur zusammenfassende Ideen. Hoffentlich stiehlt jemand diese Punkte und faltet sie in eine der anderen Antworten. ;-);

0
Chris Quenelle

Leistung ist alles. Gib ihm die Programmieraufgaben. Sprechen Sie mit dem Rest der Abteilung darüber. Optional können Sie jemanden dazu bringen, Com-Aufgaben zu erledigen, oder jemanden nur für Com-Aufgaben beauftragen. Denken Sie nicht an die Programmierung, Spaß zu haben. Alles ist "Spaß" von Ihrem POV.

Wenn Sie dies nicht tun, schaffen Sie eine Situation, die extrem schwer zu handhaben und weniger effektiv ist, als es sein könnte.

0
Lodewijk

Was für eine großartige Frage, darüber sollten alle Teamleiter, Vorgesetzten und Manager von Technikfreaks nachdenken. Ich mag Ihren Ansatz, jeder sollte eine "lustige" Aufgabe bekommen. Ein Team, das verschiedene Aufgaben übernehmen kann und übergreifend trainiert ist, verhindert, dass das Peterbilt-Prinzip das unabdingbare Teammitglied verwüstet, das Team verlässt oder sogar nach Luft schnappt . ein Urlaub'.

Nun, wie in vielen Beiträgen hervorgehoben, ist die Arbeit nicht fair und sollte es auch nicht sein. Manager werden daran gemessen, wie viel wertvolle Arbeit geleistet wird.

  • Manager ordnen Aufgaben basierend auf ihren Fähigkeiten Einzelpersonen zu.
  • Gute Manager passen Aufgaben an, die auf Fähigkeiten, Wachstum, Interesse und Produktivitätssteigerung des Teams basieren.
  • Großartige Manager bringen ihr Team dazu, dies mit ein wenig Hilfe und Anleitung zu tun. Dh ohne dass der Manager den ganzen Tag damit verbringt.

Sprechen Sie mit Ihrem guten Programmierer und fragen Sie ihn, ob er etwas lernen möchte. Welche anderen Aufgaben würde er annehmen ... selbst was für ihn am wenigsten zu beanstanden ist. Kann er anderen Teammitgliedern bei ihrer Programmierung helfen ... sie betreuen? Ja, ich weiß, dass Kommunikation ein Problem ist, also sollte er vielleicht daran arbeiten.

Eine andere Möglichkeit, dies zu verpacken, besteht darin, eine Liste mit Aufgaben zu erstellen und jeden Mitarbeiter etwas auswählen zu lassen. Lassen Sie Ihren guten Programmierer zuerst auswählen. Wenn Sie ihn im Voraus warnen und ihm die Aufgabenliste noch besser zeigen.

Wenn Sie Widerstand bekommen, was Sie fast immer mit Veränderungen tun, finden Sie ein Verkaufsargument, etwas, das für ihn von Wert ist, warum wird er davon profitieren? Zuletzt können Sie ihm einfach sagen, dass er es für das Team tun soll.

Erwarten Sie auch, dass Fehler und eine geringere Produktivität auftreten. Dies ist ein Zeichen dafür, dass die Menschen lernen. Dieses Projekt mag leiden, aber das nächste wird besser sein.

Abschließend ist es Ihre Aufgabe, dafür zu sorgen, dass die Dinge erledigt werden, aber auch Ihre Mitarbeiter zu vergrößern und sie noch besser in den Prozess einzubeziehen. Einige mögen sagen, dass der beste Weg, um sicherzustellen, dass Dinge erledigt werden, ein Team ist, das weiß, was erledigt werden muss und die Ergebnisse besitzt.

Bearbeiten: Oh und versuchen Sie es weiter, die obigen Ratschläge stammen aus jahrelangen Fehlern, aber ich wusste immer, dass ich meinem Team helfen wollte, zu wachsen, und ich wusste, dass Produktivität König ist, also habe ich immer wieder neue Dinge ausprobiert, als der letzte Versuch fehlschlug.

0
MarcLawrence

Die beste Antwort wurde bereits akzeptiert, aber ich bin überrascht, dass niemand darauf hingewiesen hat, dass "Aufgabenzuweisung" nicht das einzige ist, mit dem der Manager arbeiten kann. Ein "überdurchschnittlicher Programmierer" mit "überdurchschnittlichen Kommunikationsfähigkeiten" sollte (bei sonst gleichen Bedingungen) ein höher bezahlter/erfahrener Entwickler sein als jemand mit ähnlichen Programmierkenntnissen und schwachen Kommunikationsfähigkeiten. Dies kann dazu beitragen, jegliche wahrgenommene "Bevorzugung" des Teams auszugleichen. (In einigen Organisationen kann es für das Unternehmen aufgrund der Art der geleisteten Arbeit viel mehr wert sein, überdurchschnittliche Fähigkeiten in "Anforderungsanalyse" und unterdurchschnittliche Fähigkeiten in anderen Bereichen zu haben. Als Manager müssen Sie entscheiden, wie Sie damit umgehen .)

Eine andere Sache, auf die Sie achten sollten: Wenn Sie der betreffenden Person nur Programmieraufgaben geben, führt dies langfristig zu einer Isolation. Stellen Sie sicher, dass Sie ihnen weiterhin einige der anderen Aufgaben geben (aber diejenigen, die sie gut erledigen können, richten Sie sie nicht für negatives Feedback ein !!), damit sie für die anderen Abteilungen/Teams sichtbar sind und für sie sichtbar sind.

Schließlich ... melden Sie sich bei den anderen Teammitgliedern, wenn sie in regelmäßigen Abständen any Ungleichheit in den Teamzuweisungen feststellen. Dies mag Ihnen ein großes Anliegen sein, aber # 15 auf der Liste aller anderen.

0
Al Biglan