Ist es eine gute oder eine schlechte Idee, Entwickler für ein Projekt zu wechseln?

38

Ich arbeite in einem kleinen Team, das mit einem anderen kleinen Team an einem großen neuen Projekt arbeiten wird. Das andere Team arbeitet derzeit an einem Altsystem, an dem es seit Jahren arbeitet.

Der Manager hat entschieden, dass die Entwickler aus meinem Team alle paar Monate wechseln, um die Entwickler zu ersetzen, die am Altsystem arbeiten. Auf diese Weise hat das andere Team die Möglichkeit, an dem neuen Projekt zu arbeiten und das neue System besser zu verstehen.

Ich möchte die Vor- und Nachteile (falls vorhanden) der Rotation der Entwickler aus dem Projekt alle 2-3 Monate kennen.

Ich weiß, dass dies eine ähnliche Frage ist wie "Ist es eine gute oder schlechte Idee, den Hauptentwickler zu wechseln?". , aber diese Frage konzentriert sich auf einen Hauptentwickler. Bei dieser Frage geht es darum, das gesamte Team innerhalb und außerhalb des Projekts zu drehen (der technische Leiter für das neue Projekt kann gedreht werden oder nicht - ich weiß es noch nicht).

Christian P
quelle
2
Bei ProjectManagement StackExchange gibt es dazu eine Frage. Kennen Sie Unternehmen, die Entwickler regelmäßig zwischen verschiedenen Projekten wechseln?
Spoike
2
Ich wollte dies nicht zu einer subjektiven / argumentativen Frage machen, indem ich in der Frage meine persönliche Meinung äußerte. Mein Bauchgefühl ist, dass dies keine gute Idee ist, aber vielleicht gibt es etwas, von dem ich nichts weiß :)
Christian P
1
Welchen Grund gab der Manager an, als Sie ihn fragten, warum? Es ist im besten Interesse eines Unternehmens, Wissen über ein Produkt weiterzugeben, falls Entwickler das Unternehmen verlassen.
Dcaswell
1
Das ist ein Problem. Wenn Ihr Management diesbezüglich noch nicht vollständig transparent ist, ist dies wahrscheinlich ein Zeichen dafür, dass es sich überhaupt keine Gedanken gemacht hat.
Aaronaught
1
Was ich vorschlagen würde, ist, dass Sie das Intital-Team, das das Projekt startet, aus einigen aktuellen Legacy-Entwicklern und einigen aktuellen neuen Projektentwicklern zusammensetzen. Halten Sie sie durch das Projekt. Am Ende unterstützen die Entwickler von Lagacy das neue Produkt und die neuen Entwickler schließen sich einigen anderen Legacy-Entwicklern an, um das nächste Projekt durchzuführen. Auf diese Weise ist das Team während des Projekts (oder der Hauptversion) dasselbe, aber ältere Leute wissen, was sie später unterstützen werden. Neueinstellungen sollten in der Regel mit dem Legacy-Bereich beginnen, es sei denn, sie verfügen über besondere Fähigkeiten, die Ihr Team nicht besitzt und die für das Projekt erforderlich sind.
HLGEM

Antworten:

76

Ich bin überrascht, dass alle denken, das ist so eine gute Sache. Die Autoren von Peopleware (das IMO ist immer noch eines der wenigen Bücher über Software-Projektmanagement, die es wert sind, gelesen zu werden) stimmen überhaupt nicht überein. Fast der gesamte vierte Teil des Buches ist genau diesem Thema gewidmet.

Das Software- Team ist eine unglaublich wichtige Funktionseinheit. Teams müssen sich austoben, um wirklich produktiv zu werden. Es braucht Zeit ( viel Zeit), um sich gegenseitig Respekt zu verschaffen, die Gewohnheiten und Macken sowie Stärken und Schwächen des anderen zu lernen.

Aus persönlicher Erfahrung kann ich sagen, dass ich nach einem Jahr der Arbeit mit bestimmten Leuten gelernt habe, über bestimmte Dinge zu lachen, die mich früher aufgeregt haben. Meine Schätzungen als Teamleiter sind viel besser und es ist nicht allzu schwierig Verteilen Sie die Arbeit, um alle glücklich zu machen. Am Anfang war es nicht so.

Jetzt könnten Sie sagen: "Oh, aber wir trennen nicht das gesamte Team, sondern bewegen nur ein paar Leute." Bedenken Sie jedoch, (a) wie blind unproduktiv ihre Ersetzungen am Anfang sein werden und (b) wie oft Sie sich selbst oder andere Teams sagen werden, ohne überhaupt darüber nachzudenken, "Ich mochte X" oder "Das hätte gefallen" war einfacher, als Y noch da war " , die neuen Mitglieder auf subtile und unbewusste Weise zu beleidigen und innerhalb des bestehenden Teams Spaltungen zu schaffen, sogar Unzufriedenheit unter den" alten "Mitgliedern zu säen.

Die Leute machen das natürlich nicht mit Absicht , aber es passiert fast jedes Mal. Die Leute machen es ohne nachzudenken. Und wenn sie sich dazu zwingen, konzentrieren sie sich am Ende noch mehr auf das Thema und sind frustriert über die erzwungene Stille. Teams und sogar Subteams entwickeln Synergien, die verloren gehen, wenn Sie mit der Struktur herumdrehen. Die Peopleware- Autoren nennen es eine Form von "Teammord".

Das heißt, obwohl das Rotieren von Teammitgliedern eine schreckliche Praxis ist, ist das Rotieren von Teams selbst vollkommen in Ordnung. Gut geführte Software-Unternehmen sollten zwar ein gewisses Konzept von Product Ownership haben, aber es ist für ein Team bei weitem nicht so störend, das gesamte Team in ein anderes Projekt zu verschieben, solange das Team tatsächlich das alte Projekt abschließen oder es zumindest aufbringen kann Ein Level, mit dem sie zufrieden sind.

Wenn Sie Team- Pausen anstelle von Entwickler- Pausen einlegen, erhalten Sie dieselben Vorteile, die Sie von wechselnden Entwicklern erwarten würden (Dokumentation, "Fremdbestäubung" usw.), ohne die schlimmen Nebenwirkungen für jedes Team als Einheit. Für diejenigen, die das Management nicht wirklich verstehen, mag es weniger produktiv erscheinen, aber seien Sie versichert, dass der Produktivitätsverlust durch die Aufteilung des Teams den Produktivitätsverlust durch die Verlagerung des Teams in ein anderes Projekt in den Schatten stellt.

PS In Ihrer Fußnote erwähnen Sie, dass der technische Leiter möglicherweise die einzige Person ist, die nicht gedreht wird. Dies ist so gut wie garantiert, um beide Teams durcheinander zu bringen . Der technische Leiter ist ein Anführer, kein Manager, er oder sie muss den Respekt des Teams verdienen und wird nicht einfach von höheren Führungsebenen autorisiert. Ein ganzes Team unter die Leitung eines neuen Lead zu bringen, mit dem es noch nie zusammengearbeitet hat und der sehr wahrscheinlich unterschiedliche Vorstellungen von Architektur, Benutzerfreundlichkeit, Code-Organisation und Schätzung hat für die Führung, die versucht, Glaubwürdigkeit aufzubauen, und sehr unproduktiv für die Teammitglieder, die beginnen, den Zusammenhalt zu verlieren, wenn sie nicht über ihre alte Führung verfügen. Manchmal Unternehmen habenum dies zu tun, dh wenn der Lead aufgibt oder befördert wird, aber es nach Wahl zu tun, klingt verrückt.

Aaronaught
quelle
2
Nicht ganz anderer Meinung sein - aber es ist nicht ohne Fehler - Teams können und schaffen Imperien. Manchmal ist diese Produktivitätsschwäche nicht immer das wichtigste Ziel einer Krippe, die (wenn überhaupt) mehr auf das Endspiel zielt als andere könnten sein.
Mattnz
4
@mattnz: Was für ein "Endspiel" gibt es für einen Manager außer hoher Produktivität, Mitarbeiterbindung und der Fähigkeit, pünktlich und im Budget zu versenden? Ich spreche hier natürlich von ethischen Managern, die wirklich das Beste für das Unternehmen tun wollen und das Team oder Projekt nicht als Vehikel zur Förderung ihrer persönlichen Karriereziele nutzen. Eine Software-Organisation möchte Imperien - Imperien sind stabil und verdienen Geld - und ja, Imperien können fallen, aber es ist weitaus unwahrscheinlicher, dass sie fallen als ein Kartenhaus.
Aaronaught
2
Rotation ist besser als Leute, die das Unternehmen komplett verlassen
warren
4
@warren: Wenn diese beiden Optionen Ihre einzigen sind, dann ist letzteres fast unvermeidlich.
Aaronaught
3
Ich verstehe diese Antwort überhaupt nicht. Jeder in einem Team sollte professionell sein und gut mit anderen zusammenarbeiten, vorausgesetzt, alle Teammitglieder sind tatsächlich kompetent, was ein anderes Problem darstellt. Rotierende Teammitglieder sind häufig die einzige Wahl für einen Manager, der bei beiden Produkten chronisch unterbesetzt ist oder dessen Abnutzung eine ernsthafte Bedrohung darstellt. Es ist oft sehr schwer, überhaupt ein gutes Talent zu finden. Das Rotieren von Teammitgliedern ist eine Möglichkeit, Wetten gegen das Verlassen der Entwickler abzusichern. Es ist auch gerechter für Entwickler, die an älterer Software arbeiten, wenn sie etwas Neues lernen möchten.
maple_shaft
18

Ich sehe hier selbst keinen großen Nachteil. Die Rotation bringt Ihnen:

  • Fremdbestäubung des institutionellen Wissens - zumindest theoretisch kennt jeder das Legacy-Projekt und das neue.
  • Cross Training - verschiedene Projekte erfordern oft unterschiedliche Dinge. Als Entwickler wachsen Sie viel mehr in hässlichen, alten Projekten als in netten, sauberen Greenfield-Projekten.
  • Grundsätzlich bessere Projekte - nichts anderes als ein neues Team, mit dem Sie die Dokumentation fertigstellen und hässliche Prozesse bereinigen können, mit denen Sie bereit sind zu leben, die Sie aber nicht öffentlich zugeben.
  • Besserer Code - in den meisten Fällen sind mehr Köpfe besser.
  • Wahrscheinlich moralische Verbesserungen - Abwechslung ist das Gewürz des Lebens. Und wer möchte dauerhaft im Bugfixing- / Duct-Taping-Modus des Vorgängerprojekts stecken bleiben? Denken Sie auch daran, dass Ihr "neues" Projekt irgendwann zu einem Vermächtnis wird. Möchten Sie für immer dort hängen bleiben?

Wahrscheinlich ist der einzige Nachteil der Produktivitätsabfall, den Sie durch das Wechseln von Orten erhalten, aber das sollte nur beim ersten Durchgang schlimm schaden. Danach werden beide Seiten an beiden Orten etwas Zeit haben und die hässlichen Teile der Übergabe werden wahrscheinlich besser verstanden und vielleicht gelöst.

Wyatt Barnett
quelle
18
Ich sehe nicht, wie sich meine Moral verbessern würde, wenn ich "herabgestuft" würde, um am Altsystem zu arbeiten.
Telastyn
3
Einige Nachteile sind in der anfänglichen Entwicklungszeit zu sehen und die spezifischen anderen Aufgaben des Legacy-Teams bekommen niedrigere Prioritäten.
Oded
16
@Telastyn Wenn meine alte Firma nicht mehr in der Vergangenheit gearbeitet hätte, würde ich immer noch dort arbeiten. Sicher, es ist schade, gedreht zu werden, aber es ist noch schlimmer, zu wissen, dass Sie niemals gedreht werden, nur weil sie einen älteren Entwickler benötigen.
BeardedO
8
@Telastyn und Christian und andere: Es ist dein Problem, wenn du es als Herabstufung betrachtest. Die Arbeit an Legacy-Systemen ist eine Herausforderung für sich und kann Ihnen eine unglaublich wertvolle Erfahrung bieten, die Sie zu Ihrem Vorteil bei der Entwicklung auf der grünen Wiese einsetzen können. Die Entwicklung auf der grünen Wiese sollte eigentlich viel weniger "kreditwürdig" sein als sie, da es sehr viel einfacher ist, neue Funktionen auf einer vorhandenen Basis zu entwickeln, auch ohne große technische Schulden. Bei Brown Field Development finden Sie die wahren Handwerker. Ja, Sie finden sie auch woanders, aber nicht auf dem Schlachtfeld.
Marjan Venema
8
@MarjanVenema - Es tut mir leid, dass einige Wartungsarbeiten in Cobol meine Karriere nicht voranbringen werden. Sicher, die Arbeit könnte erledigt sein und es könnte sogar eine wertvolle Erfahrung sein - aber wenn mein Manager mich zu dieser Vollzeitstelle versetzt, werde ich meinen Lebenslauf so schnell wie möglich veröffentlichen. Die Tatsache der Angelegenheit ist , dass einige Entwickler werden dies als Degradierung wahrnehmen, unabhängig davon , was es wirklich ist. Diese Wahrnehmung mit dem Wunsch, Pollenflug zu vermeiden, in Einklang zu bringen, ist nicht mein Problem, sondern das des Managers. das ist ihre Aufgabe .
Telastyn
6

Interessanterweise haben wir nach meiner Erfahrung unsere Projekte oft mit genau dieser Absicht begonnen. In der Folge haben wir oft versäumt, auf diese Absicht zu reagieren, weil das neuere Projekt eingeschränkt wurde und wir der Ansicht waren, dass das Cross-Training zu teuer ist.

Ich wünschte immer, wir hätten es geschafft, da ich langfristig glaube, dass es für alle Beteiligten von Vorteil ist - Team, Unternehmen, Kunde und Software. 2/3 Monate klingen lang genug, um das Risiko schwerwiegender negativer Auswirkungen zu begrenzen. Für die beteiligten Entwickler findet kein Kontextwechsel statt, außer zu dem Zeitpunkt, zu dem sie sich dem alternativen Projekt widmen können.

Einige mögliche Vorteile, die nicht erwähnt wurden:

  • Besseres Projektmanagement. Wenn die Projektmanager für beide Projekte an Bord sind, ist es ihr bestes Interesse, hart zu arbeiten, damit Übergangsfristen für beide Projekte nicht schmerzhaft sind. Dies wiederum (abhängig von Ihrem Setup) könnte zu einer engeren Zusammenarbeit zwischen den PMs und den Entwicklungsteams führen.
  • Bessere (proaktive) Dokumentation. Wenn Sie wissen, dass Sie in ein Projekt ein- und aussteigen, liegt dies nicht nur im besten Interesse des Projekts, des Unternehmens und der Praxis im Allgemeinen, sondern jetzt auch im eigenen Interesse der Entwickler, um das Leben zu erleichtern, während sie auf und ab gehen um.
  • Die Moralsache ist eine große Sache. Wenn Ihre Entwickler nicht genug davon haben, an einem Legacy-Projekt festzuhalten, sind sie möglicherweise nicht die Entwickler, die Sie wollen! Wenn dies der Fall ist, werden sie sich in Ihr Unternehmen verliebt fühlen, wenn sie sie vertauschen und andere Entwickler dazu bringen, daran zu arbeiten. Sie könnten nur die Code-Teile aufräumen, von denen sie dachten, dass sie niemand jemals sehen würde. Ältere Systeme werden oft als zweitklassige Projekte angesehen, was häufig zu ihren Lasten geht. Vielleicht helfen Sie auf diese Weise, diese Wahrnehmung zu ändern.
JohnMark13
quelle
Ich denke, dass dies in den meisten Unternehmen der Fall ist. Hohe Ziele, aber die Forderung nach schnellem Turnaround und minimaler sofortiger Kostenvermeidung schließen normalerweise das Cross-Training und die Cross-Development aus, da die Produktivität verloren geht, wenn neue Mitarbeiter für ein Projekt auf den neuesten Stand gebracht werden.
BBlake
2
@BBlake Ja, das ist leider der Fall. Leider, weil es für ein Unternehmen sehr kurzsichtig und ziemlich riskant ist, das Wissen über wichtige Systeme auf eine geringere Anzahl von Personen zu beschränken.
Marjan Venema
1
Leider interessieren sich die meisten Unternehmen, einschließlich der weltweit größten Bank, die ich kürzlich verlassen habe, um anderswo zu arbeiten, mehr für das Endergebnis dieses Projekts oder dieses Wochen- oder Budgetzyklus als für die Vorausplanung der Kosten, die entstehen, wenn ein leitender Entwickler ( wie ich) geht. Da ich kein Budget für Cross-Training für Anwendungen hatte, war ich bestens vertraut. Fügen Sie die Dutzende von Arbeitsstunden hinzu, die damit verschwendet wurden, Produktionsprobleme aufzuspüren, die ich in ein paar Stunden hätte lösen können, weil ich die Systeme kannte. Kurzsichtig, aber das ist der korporative Weg.
BBlake
@Marjan: Ich würde wetten, dass die Kosten, die durch die regelmäßige Durchführung von Cross-Trainings anfallen, weitaus höher sind als die Kosten für die Schulung eines neuen Mitarbeiters, wenn jemand aus dem Unternehmen ausscheidet. Wenn nun ein ganzes Team geht, ist das eine andere Sache.
Dunk
1
@Dunk: Ich weiß nicht, dass es so wäre. Cross Training muss nicht so weit gehen, das Cross Training zu einem Experten auf dem Gebiet zu machen, der nicht direkt von ihm selbst stammt. Es muss nur so weit gehen, dass sichergestellt ist, dass das Unternehmen nicht sofort in Schwierigkeiten gerät und die Gefahr besteht, Kunden zu verlieren, wenn die Feldexperten das Unternehmen verlassen und die Entwicklung in diesem Bereich zum Erliegen kommt. Niemand ist unersetzlich, aber Unternehmen gehen Risiken ein, wenn wichtige Kenntnisse oder Fähigkeiten auf sehr wenige Personen beschränkt sind. Und die Kosten für die Realisierung dieses Risikos können in der Tat sehr, sehr hoch sein.
Marjan Venema
4

Rotation ist eine gute Sache für das Unternehmen und kann auch eine gute Sache für die Entwickler sein.

Es gibt viele gute Gründe und Wyatt hat viele davon in seiner Antwort erwähnt.

Abgesehen davon werden Sie in Ihrer Situation möglicherweise feststellen, dass die Entwickler, die das neuere Projekt in das Legacy-Projekt überführen, möglicherweise nicht glücklich sind. Daher muss klar kommuniziert werden, warum dies geschieht und wie lange es dauert ist für und der Plan geht weiter.

Es kann sinnvoll sein, die Teams nicht zu tauschen, um 1 oder 2 Entwickler zu starten, obwohl dies so aussieht, als würden Leute für eine Herabstufung ausgewählt (was manche Leute vielleicht sehen).

ozz
quelle
Ich mag die Idee, zunächst nur 1-2 Entwickler zu tauschen. Dies wird dazu beitragen, die anfänglichen negativen Auswirkungen auf die Produktivität zu verringern.
SuperM
Sie haben es mit Softwareentwicklern zu tun, nicht mit normalen Leuten. Softwareentwickler neigen dazu, logisch zu sein. Sie können nicht so leicht manipuliert werden wie die breite Öffentlichkeit, indem Ideen wie die oben genannten einbezogen werden. Andere Tricks sind effektiver (z. B. größere Monitore, schnellere Computer), aber keine politischen Schikanen, wie dies mit dieser Idee versucht wird. Für die Mitglieder des neuen Entwicklerteams wird es auf jeden Fall negativ sein. Belohnungsversprechen (siehe oben) sind die einzige Möglichkeit, den schlechten Geschmack zu vertuschen. Natürlich wird es (zunächst) großartig für die Maint-Leute sein, bis sie erkennen, dass sie nicht dazu bereit sind.
Dunk
2

Stimmen Sie mit Aaronaught überein, das ist sehr seltsam zu sehen, wie viele Leute gerade Nachteile nicht sehen. Wenige denken schlecht, dass Sie sehr schnell zeigen können - Code hat keinen Eigentümer und wenn jeder für alles verantwortlich ist, ist das nicht so gut für Qualität . Entwickler sind keine Ressourcen (auch wenn sie von Managern sehr oft so genannt werden), sie sind Menschen und für das Team ist es sehr wichtig, sich gegenseitig zu kennen. Wenn Sie für längere Zeit für ein Projekt arbeiten, werden Sie ein Experte (nicht nur auf dem Gebiet, sondern auch in diesem Gebiet). Sie wissen, woher die meisten Probleme kommen, wer Ihnen die besten Antworten oder vielleicht spezifischere Fachkenntnisse usw. liefert. Wenn Sie neu sind, müssen Sie all diese Überlegungen lernen, damit der Fortschritt verlangsamt wird. Aber natürlich ist es auch gut, andere Praktiken in Ihrer Organisation zu kennen, wie andere Teams bauen und organisieren. Es ist besonders gut, wenn Ihre Projekte in irgendeiner Weise zusammenhängen, z. B. wenn ein Projekt für ein anderes eingegeben wird (nicht direkt erforderlich), um das Gesamtbild besser zu verstehen. Und natürlich ist es gut, Fachwissen zu verbreiten (wenn Sie Zeit haben, sich dieses Wissen anzueignen).

Dainius
quelle
Dieser Beitrag ist ziemlich schwer zu lesen (Textwand). Hätten Sie etwas dagegen bearbeiten sie in eine bessere Form ing?
gnat
2

Ich stimme der Top-Antwort von Aaronaught zu und habe einige Ergänzungen.

  • Die Leute mögen es nicht, herumgeschubst zu werden.
  • In einem hierarchischen Geschäftsumfeld können Personen Verantwortlichkeiten zugewiesen werden, die ihnen später wieder weggenommen werden. Dies kann nur ein Teil des Auftrags sein. Je öfter dies geschieht, desto unwahrscheinlicher ist es jedoch, dass sich diese Personen für irgendetwas verantwortlich fühlen, das ihnen zugewiesen wurde.
  • Ersteres gilt auch für Wartungsarbeiten an Dingen, die die Menschen selbst nicht erstellt haben. Das Aufräumen der Unordnung anderer Leute (oder neutraler formuliert: unvollendete Arbeit) ist für die meisten kreativen Individuen nicht besonders motivierend.
  • Die Philosophie "Ein Programmierer ist ein Programmierer ist ein Programmierer, es handelt sich um anonyme Plug-Ins, die nach Bedarf in Projekte eingefügt werden" lässt keinen Programmierer mehr Wertschätzung oder Interesse für die ihm zugewiesenen Aufgaben empfinden.

Der perfekte Zeitpunkt, um jemanden neu zuzuweisen, ist, wenn er sich langsam langweilt, was er gerade tut. Es gibt nichts mehr zu gewinnen, alles unter Kontrolle, die Arbeit ist erledigt. In diesen Fällen werden sie in der Regel selbst nach anderen Möglichkeiten fragen.

Natürlich ist die Realität hartnäckig und oft gibt es keine andere Wahl, es kann sein, dass jemand anders gebraucht wird, aus welchem ​​Grund auch immer. Dies ist nicht unbedingt schlecht, es kann auch dazu führen, dass sich eine Person wichtig fühlt, und wenn die Person ein großes Problem lösen soll, wird es ihm zugute kommen.

Das bloße Herummischen von Leuten, um Wissen zu verbreiten, erhöht wahrscheinlich den Umsatz. Auf diese Weise wird Wissen verbreitet, aber es wird außerhalb des Unternehmens verbreitet, was wahrscheinlich nicht die Absicht ist.

Martin Maat
quelle
0

TL; DR Machen Sie ein Team und dann ein Team, das zwei Projekte unterstützt.

@Aaronaught wiederzugeben Ich denke, das Mischen von Teams kann problematisch sein, da es einige Zeit dauern kann, sich an neue Praktiken, Prozesse usw. zu gewöhnen. Wenn Sie zu viele Personen wechseln, um schnell zu arbeiten, verliert das Team seine Identität. Dies führt zu mehr Fragen, Verwirrung und Zeitaufwand, um diese Identität auszugleichen.

Auf der anderen Seite, wenn es eine konzertierte Anstrengung gibt, die 2 Teams zu einem Team zusammenzuschließen und 1 Team 2 Projekte unterstützen zu lassen, denke ich, funktioniert das großartig, solange das Team nicht zu groß ist. Ich war Teil zahlreicher Teams, die mehrere Projekte unterstützen. Je näher die beiden Projekte an der Technologie sind, desto einfacher gestaltet sich der Übergang. Meiner Erfahrung nach entstehen die höheren Kosten für den Übergang von einem Projekt zu einem anderen, wenn Sprachen, Client / Server (insbesondere GUI), Industrie (Medizin, Web, Spiel) oder andere ähnliche Bereiche gekreuzt werden. Der Trick besteht darin, dass verschiedene Personen häufig genug an dem Projekt arbeiten, um die Vorteile zu erzielen, aber nicht so oft, dass die Übergangskosten die Vorteile übersteigen.

Dann ist der Nutzen, mehr Leute für ein Projekt zu gewinnen, ebenso bekannt wie die Kosten.

dietbuddha
quelle
1
"Solange das Team nicht zu groß ist" ist hier der Schlüssel, denke ich; Wenn jedes Team 10 Personen hat, ist ein Team von 20 Personen höchstwahrscheinlich zu groß. Auch wenn es eine physische Trennung zwischen den Teams gibt (das OP legt dies nicht fest), wird es nicht als ein einziges Team funktionieren und die Dinge werden unorganisierter. Dies könnte auf jeden Fall funktionieren, hängt jedoch von der Situation (können die Teams effektiv zusammengeführt werden) und den Zielen des Managements ab (die Zusammenführung ist mehr oder weniger dauerhaft, sie wird mehr Ressourcen hinzufügen, aber nicht die gleichen Ziele wie ein Projekt erreichen) Drehung).
Aaronaught
0

Die Rotation von Programmierern ist aus Sicht des Unternehmens und des Entwicklers eine gute Sache.

Aus Unternehmenssicht

  1. Das Management wird die Stärken und Schwächen eines bestimmten Entwicklers kennenlernen, ob er Multitasking beherrscht oder nicht und sich an Veränderungen anpasst.
  2. Wenn ein Entwickler das Unternehmen aus irgendeinem Grund verlässt, verfügt das Unternehmen bereits über ein Backup für die Zukunft.
  3. Es wird die Leistung des Projekts verbessern, da viele Leute daran arbeiten werden. Dasselbe wird von immer mehr Entwicklern getestet. (Testressourcenverschwendung minimiert)
  4. Alle Teammitglieder arbeiten im Team und es wird die Leistung des Projekts steigern und im zukünftigen Management erfahren, welche Art von Team bei der Implementierung eines schwierigen Moduls oder einer schwierigen Aufgabe gebildet werden muss.

Aus Entwicklersicht

  1. Dies wird den Entwickler positiver machen, wenn sein Vertrauen steigt.
  2. Entwickler erhalten von anderen Teammitgliedern immer bessere Ideen und können diese Technik in der zukünftigen Entwicklung verwenden.
  3. Durch bessere Ideen und Vorschläge anderer Teammitglieder erhöht sich die Produktivität der Entwickler.

Nur eine Hauptsache, bedenken Sie, dass,

Programmierer sollten nicht sehr häufig rotieren. Nach einer Entwicklung von 60% bis 70% ist nur eine Verlagerung von Vorteil.

Pragnesh Karia
quelle
3
Ich sehe viele kahle Behauptungen, die hier gemacht werden. Einige von ihnen haben fast nichts mit Rotation zu tun ("Das Management wird die Stärken und Schwächen eines bestimmten Entwicklers kennenlernen"?), Andere sind entweder unbeholfen formuliert oder ergeben einfach keinen Sinn ("alle Teammitglieder arbeiten im Team und es wird die Leistung des Projekts steigern "?). Worauf basieren all diese Punkte? Hast du eine Quelle? Ist es eine persönliche Erfahrung? Wenn ja, welche Erfahrung? Kommt Ihre "Unternehmensperspektive" aus Erfahrung als Manager oder Teamleiter? Haben Sie wirklich gesehen, wie etwas in der Praxis funktioniert?
Aaronaught
1
Die meisten dieser vorgeschlagenen Vorteile scheinen wirklich im Zusammenhang mit der einfachen
Mitgliedschaft
erste "Das Management wird die Stärken und Schwächen eines bestimmten Entwicklers kennenlernen." ist eigentlich das Gegenteil, weil es viel einfacher ist, seine Schwächen zu verbergen, wenn man von einem Ort zum anderen wechselt. Es gibt immer mehr Leute / Software, die schuld sind, warum es spät war, fehlerhaft, nicht erledigt.
Dainius
Es gibt keine Möglichkeit, dass die Projektleistung nicht sehr negativ beeinflusst wird. Warum um alles in der Welt würden Sie glauben, dass die Leistung eines Projekts "verbessert" wird?
Dunk