Ich bin Software-Entwickler und führe derzeit glücklich mein Team von einem ... mir.
Das Problem ist, dass meine Verantwortlichkeiten und die Menge an Arbeit zu explodieren beginnen und ich befürchte, dass es bald unüberschaubar wird und dass die Qualität der Arbeit darunter leidet. Ich glaube fest daran, dass ich dafür ein Team aufbauen könnte.
Ich nehme an, die Frage ist, wie würden Sie Ihren Direktoren zeigen, dass Sie Ihrer Meinung nach Ihre Arbeit effektiv erledigen und die besten Produkte liefern können, mit denen Ihr Team wachsen muss?
Sie bitten uns, davon auszugehen, dass es eine gute Idee ist, mehr Arbeitskräfte hinzuzufügen. Aus Gründen, die ich weiter unten beschreibe, bin ich der festen Überzeugung, dass die Vergrößerung eines Teams als Reaktion auf eine „explodierende“ Arbeitsbelastung oft das erste Anzeichen von Problemen ist. Wenn ich an Ihrer Stelle wäre, würde ich versuchen, mit meinem Vorgesetzten darüber zu sprechen, warum die Arbeit so explodiert – und zu versuchen, einige klare Softwarespezifikationen, Anwendungsfälle, Tests und Feature-Planungen auszuarbeiten, die den Arbeitsbereich abdecken sollten das sollte in deiner Verantwortung liegen. Wenn Sie mit Ihrem Chef zusammenarbeiten können, um das ungeplante Wachstum des Projekts einzuschränken und zu begrenzen, wird das eingeschränkte Produkt in der Regel erheblich besser sein.
Ich stelle es mir gerne wie eine Stadt vor, die einige Bäume entlang des Bürgersteigs der Main Street pflanzt. Sie können den Baum unkontrolliert wachsen lassen, in diesem Fall könnte er ein paar Bürgersteige knacken und Sie müssen eine Menge Leute einstellen, um die Nebenwirkungen des Wachstums aufrechtzuerhalten. Oder Sie können den jungen Baum an einen Pfosten binden und sein Wachstum mit einem strengen und rücksichtslos starren Entwicklungsplan lenken – und Sie erhalten hübsche, gerade Bäume mit einem geringeren Risiko für Bürgersteigbrüche.
Genauer gesagt, wird es in einigen viel zitierten Büchern über bewährte Softwareverfahren wie The Mythical Man-Month und Peopleware oft als Trugschluss bezeichnet, dass das Hinzufügen von mehr Arbeitskraft zu einem Softwareprojekt zu guten Ergebnissen führt.
Offensichtlich gibt es Kapazitätsgrenzen dafür, was eine einzelne Person tun kann. Aber herauszufinden, wann und wie das Team erweitert werden kann, ist nicht trivial – und ein Team zu erweitern, nur weil ein Entwickler (oder eine Gruppe) „das Gefühl hat“, dass die Arbeit nicht mehr gewartet werden kann, ist nicht immer eine gute Idee.
Ohne einen architektonischen Plan darüber, wie die Arbeit in Zukunft voraussichtlich wachsen und sich verändern wird, verursacht es normalerweise Probleme, mehr Köche in die Küche zu werfen. Zum einen sind die anfänglichen Kosten für eine neue Person normalerweise viel höher als budgetiert. Hier meine ich in Bezug auf die Aufnahme und Ausbildung neuer Leute. Und selbst nachdem die Person hochgefahren ist und beginnt, einen positiven Nettoproduktivitätseffekt hinzuzufügen (Monate später), haben Sie dann einen zusätzlichen Kommunikationskanal, der die Gesamtproduktivität aller verringert – und Sie haben zusätzlichen Verwaltungsaufwand.
Da es im Allgemeinen N*(N-1)/2 bidirektionale Verbindungen zwischen N Personen gibt, bedeutet dies, dass der Kommunikationsaufwand mit dem Quadrat der Teamgröße wächst. Oft wächst die Verwaltungsbürokratie mit der gleichen Geschwindigkeit oder schneller. Schnell verschärfen sich die ursprünglichen Argumente über fehlende Arbeitsstunden in einer Rückkopplungsschleife, wobei das Hinzufügen von Personen zur Minderung des Arbeitsdrucks also genug neuen Arbeitsdruck verursacht, als der Grenzwert eines neuen Teammitglieds zu niedrig (oder sogar negativ!) es zu tun.
Viele Leute denken naiv, dass dies nur passiert, wenn Sie über Projekte im NASA-Maßstab mit Hunderten von Ingenieuren sprechen. Aber tatsächlich kann es in einem Team mit nur 2-5 Personen passieren. Es hängt alles von der Infrastruktur, den Entwicklungsanforderungen und dem Architekturplan ab, was die Softwarerollen erreichen müssen.
Ich würde sagen, die beiden Bücher zu lesen, die oben in dieser Antwort erwähnt werden. Denken Sie darüber nach, wie Sie einen Angriffsplan für das Projekt, wie Sie es jetzt sehen, „architektieren“ könnten, und achten Sie dabei darauf, so viele verschiedene (möglicherweise unvorhergesehene) Richtungen des zukünftigen Wachstums wie möglich zu berücksichtigen. Lesen Sie mehr über Planungsfehler . Und versuchen Sie dann, all das zu einem umsetzbaren Plan für den Aufbau eines Teams zusammenzufassen.
Tully2003
Mike