Ich leite ein mittelgroßes Team von Entwicklern, deren Fähigkeiten, Alter und Zeit im Unternehmen stark variieren. Einige der Jüngsten im Team gelten als kompetent, während einige der Ältesten (altersmäßig) von einem großen Teil des Teams übertroffen werden. Außerdem haben wir neue Leute mit weniger als 2 Monaten im Projekt, während andere seit mehr als 3 Jahren dabei sind.
Das Problem, das ich habe, ist, dass wir ein neues Projekt anstehen, in das sich jeder einbringen möchte, aber alle sind mit den dafür erforderlichen Fähigkeiten nicht vertraut, und ich muss mein Team zumindest in den ersten paar Monaten in zwei Teile aufteilen: einige von ihnen bleiben im aktuellen Projekt, während andere am "coolen" Projekt arbeiten.
Langfristig habe ich bereits klargestellt, dass jeder seine Zeit für das neue Projekt bekommt, indem er Rotationen plant, aber jeder ist bestrebt, zuerst dort einzusteigen.
Ich habe diesbezüglich einige Bedenken:
Ich habe daran gedacht, kleine Quizes zu machen, damit ich herausfinden kann, wer am besten in Form ist oder zumindest das meiste Wissen hat, das für das "coole" Projekt benötigt wird (was mir irgendwie einige Rechtfertigungen für meine Handlungen gibt), aber ich denke auch, dass ich es tun sollte Gehen Sie mit denen, von denen ich glaube, dass sie den Job richtig machen können (im Grunde eine Ahnung, die mich dazu veranlasst hätte, diejenigen auszuwählen, mit denen ich bereits gearbeitet habe, was die neuen Leute praktisch aus dem Spiel bringt).
Jeder Rat wäre sehr willkommen.
Erfahrung ist ein schwacher Indikator für zukünftigen Erfolg (Hunter & Hunter, 1984). Fühlen Sie sich also frei, die Zeit im Stuhl zu entfernen, da es Ihnen nicht schaden wird. Das Alter ist ein Nullindikator für den Erfolg (gleiche Studie), also entfernen Sie das definitiv aus der Gleichung. Ihr bester Prädiktor ist die kognitive Fähigkeit, kritisch zu denken und zu analysieren. Da alle Ihre Entwickler über die grundlegenden Fähigkeiten und Kenntnisse verfügen, nehmen Sie diejenigen, die ihre Fähigkeit zur Analyse gezeigt haben, diejenigen, die Intelligenz vor allen anderen gezeigt haben.
Entwickeln Sie ein strukturiertes Interview, eine Reihe von Fragen, die jedem Kandidaten vorgelegt werden und die seine Fähigkeit zum Denken, zum Stellen der richtigen Fragen, zum Theoretisieren und zum Abstrahieren aufzeigen. Wählen Sie diejenigen aus, die am besten abgeschnitten haben.
Entfernen Sie in allen Fällen Ihr Bauchgefühl. Sie sind wie der Rest von uns voreingenommen und wahrscheinlich wird Ihr Bauchgefühl wenig bis gar keinen Einfluss auf zukünftigen Erfolg haben. Ich weiß, das liest sich sehr kontraintuitiv; Wir verlassen uns alle darauf und auf unsere Erfahrung, und deshalb ist unser Auswahlverfahren ungefähr 50/50 in Bezug auf den Erfolg. Das ist ein Münzwurf und Sie können kein Geschäft mit einer Münze führen.
Einige Punkte von meiner Seite, um die bereits geäußerten Ideen zu ergänzen:
Versprechen Sie nichts, was Sie nicht einhalten können, oder machen Sie deutlich, dass dies Ihre Absicht ist und Änderungen unterliegen kann. Auch wenn dies im Umgang mit reifen Erwachsenen sehr einfach erscheinen mag, kann es überraschend sein, wie jemand demotiviert werden kann, wenn diese Art von Erwartungen nicht erfüllt werden.
Berücksichtigen Sie nicht nur die Anforderungen Ihres neuen Projekts, sondern auch, wie Sie sicherstellen können, dass das alte Projekt reibungslos endet.
Wenn Ihre Gruppe neu in der Technologie oder Branche ist, sollten Sie damit beginnen, die Leute hinzuzuziehen, die bessere Selbstlerner/Selbststarter sind, und werden auf jeden Fall einige Senioren einbeziehen, die den Prozess leiten könnten. Dies kann dem Projekt helfen, einige schnelle Erfolge zu erzielen, die Ihnen helfen, vor Ihrem Management oder Kunden etwas Glaubwürdigkeit zu gewinnen. Auch diese Starter werden anderen helfen, leicht an Bord zu kommen.
Wenn es darum geht, Ihre Entscheidungen zu erklären, tun Sie es wie gewohnt, sonst werden Sie befragt. Generell bevorzuge ich mehr Offenheit, die das Thema zulässt, aber man muss seinem Stil treu bleiben.
Vermeiden Sie es, den Auftrag in eine Preis-/Strafsache umzuwandeln, Sie haben andere wichtige Gründe, um in diesem Fall die Entscheidung zu treffen, und das beste Motivationsszenario ist möglicherweise nicht das beste Geschäftsszenario. Wie Corleone sagte: "It's only business"
Ich habe in der Vergangenheit einige Experimente durchgeführt und es schien, dass diese Teams erfolgreich waren, in denen die Mitglieder zuvor zusammenarbeiten konnten . Dieses Setup war viel besser als das Setup, als das Team-Setup auf den erforderlichen Fähigkeiten basierte.
Mein Vorschlag wäre, Teams basierend auf den bestehenden "kleinen Gruppen" einzurichten. Menschen mit dem gleichen Verständnis lernen mehr und schneller . Es wird einige Stürme geben , aber es wird nicht sehr weh tun. Der häufigste Fehler, den ich heute sehe, ist, dass die Linienmanager nach Entwicklern mit den erforderlichen Fähigkeiten suchen - sie wie Ressourcen behandeln -, um ein Projekt zu starten, und die Ideen der Teamdynamik ignorieren. Ihr Argument ist, dass Menschen schneller lernen, zusammenzuarbeiten, als etwas Neues zu lernen. Ich sehe dieses Argument unter besonderen Umständen als gültig an, aber ich unterstütze es nicht.
Was ist der beste Weg, um die Moral für diejenigen aufrechtzuerhalten, die nicht in das coole Projekt aufgenommen werden?
Mein Problem bei diesem Teil ist, dass das alte Projekt als nicht cool gilt. Wenn ich Sie wäre, habe ich an diesem Thema gearbeitet und herausgefunden, warum das alte Projekt nicht cool ist und wie man es cool macht. Normalerweise halten die alten, nicht coolen Projekte ein Unternehmen am Leben , also kann man dieses Argument vielleicht nutzen, um die Teamtrennung zu verkaufen .
Zusammenfassend: Versuchen Sie, die kleinen Gruppen in Ihrem aktuellen Team durch persönliche oder kleine Gruppengespräche zu finden und herauszufinden, was an dem alten Projekt cool ist, und verkaufen Sie diese Idee. Ihr könnte jemand sein, der es lieben wird. Sprich mit ihnen und finde es heraus.
Wenn die vorhandenen Fähigkeiten der Menschen wirklich keine Vorteile bieten, müssen Sie sich andere Faktoren ansehen. Sie brauchen eine gute Mischung aus soliden Entwicklern und klügeren Entwicklern, um den Erfolg sicherzustellen, zumal dies außerhalb der Komfortzone aller liegt.
Ich würde mir zuerst Ihre erfahreneren (unternehmensbezogenen) Entwickler ansehen und diejenigen auswählen, die zu Ihren produktiveren und fleißigeren Entwicklern gehören. Das sollte man gewissermaßen als Belohnung sehen, wenn wirklich alle daran arbeiten wollen.
Sobald Sie eine Kerngruppe haben, würde ich mir Ihre erfahrenen (erfahrungsmäßigen) Entwickler ansehen und mindestens einen (je nach Größe des Projekts vielleicht zwei) auswählen, um die Dinge in Gang zu bringen. Auch hier gilt: Da dies außerhalb des Fachwissens aller liegt, müssen Sie Personen auswählen, auf die Sie sich verlassen konnten. Diese erfahreneren Entwickler sollten Ihnen helfen, Projektrisiken zu identifizieren, auch wenn dies nicht in ihrem Steuerhaus liegt. Und Sie brauchen Leute, die nach Risiken Ausschau halten (technologische, zeitliche und andere), weil dies ein brandneues Projekt ist, das eine Technologie verwendet, mit der Sie keine Erfahrung haben.
Was die Rechtfertigung betrifft, kann nicht jeder an dem neuen Projekt arbeiten. Die Entwickler wissen, wer die besseren und fleißigeren Entwickler in der Gruppe sind, und die Leute, die sich weniger anstrengen, können sich nicht wirklich darüber beklagen, vom Projektstart ausgeschlossen zu werden. Gute Leute haben die Möglichkeit, dich zu verlassen. Gib ihnen keinen Grund. Dann brauchen Sie einige erfahrene Leute, die Ihnen helfen, Projektrisiken zu mindern. Auch hier gilt: Wenn Sie diejenigen auswählen, die sich in der Vergangenheit bewährt haben, können die anderen nicht wirklich argumentieren.
Du bist der Manager. Du kannst nicht jedermanns Kumpel sein. Manchmal muss man unpopuläre Entscheidungen treffen. Versuchen Sie, nüchtern wie Mr. Spock zu sein, wenn Sie Ihre Argumentation darlegen. Und vielleicht möchten Sie die schlechten Nachrichten einzeln oder in kleinen Gruppen verkünden, wenn Sie sich wirklich Sorgen um die Reaktionen machen. Das gibt den Leuten die Möglichkeit, sich (an dir) Luft zu machen, ohne eine riesige Welle der Negativität zu erzeugen. Treffen Sie Ihre Entscheidung und teilen Sie diese schnellstmöglich allen (einzeln oder in Kleingruppen) mit. Es sind schlechte Nachrichten. Holen Sie es heraus und bringen Sie es schnell hinter sich, damit die Gerüchteküche keine Zeit hat, sich zu drehen.
Möglicherweise können Sie einige davon als Chance nutzen, neue Teile des Systems für die Leute zu lernen/zu verwalten, die auf der alten Software bleiben. Aber das wird dich nicht sehr weit bringen, also überverkaufe es nicht.
Warum verwenden Sie keinen rotierenden Führungsstuhl, bis Sie besser beurteilen können, wer am besten geeignet ist, Aspekte des Projekts zu leiten? Der Ansatz könnte ähnlich funktionieren, als ob alle 2 (oder n) Wochen die Rollen und das Team rotieren (Junior Dev, DBA, Lead Dev, Architect usw.).
Zum Auftakt könnten Sie alle dazu bringen, anonym abzustimmen, welches Team und welche Rolle ihrer Meinung nach ein anderes Teammitglied haben sollte (natürlich kann der Wähler nicht für sich selbst stimmen).
Vorteile des Ansatzes
Nachteile des Ansatzes
Andreas klar