Wie kann eine Organisation die Vorteile von Generalisten bei Großprojekten nutzen?

Die kurze Antwort lautet: „Ihr kommuniziert nicht auf demselben Niveau.“

Um Ihr Beispiel zu verwenden, es ist eine ziemlich faire Wette, dass die Leute, die Excel entwickeln, niemals aufgefordert werden, zu den Gerätetreibern beizutragen.

Damit ein Generalist bei mehreren Projekten nützlich sein kann, ist es wichtig, bei diesen Projekten einigermaßen auf dem Laufenden zu bleiben – die Technologien zu kennen, die Leute zu kennen, die Probleme zu kennen, die Lösungen für frühere Probleme zu kennen usw.

Irgendwann gibt es einfach zu viele Informationen, um Schritt zu halten. Ihr Generalist wird zu viel Breite / nicht genug Tiefe haben, um nützlich zu bleiben.

Der Wechsel zu dedizierten Teams ermöglicht es diesen Teams, sich voll und ganz auf ihr Anliegen zu konzentrieren. Sie opfern Breite, um an Tiefe zu gewinnen (oder zumindest zu bleiben).

Meine Hauptanliegen wären:

Aus organisatorischer Sicht könnte der Wechsel zu dieser Struktur für laufende Projekte unglaublich störend sein. (Ich habe das mindestens zweimal erlebt, und die Kunden waren sehr unzufrieden.) Gibt es einen Gewinn, der diese Unterbrechung ausgleichen könnte? Diese Art von Änderung würde sich auf Fristen auswirken, würde die Fähigkeit beeinträchtigen, das Produkt zu liefern (einige Leute landen zwangsläufig bei Projekten, mit denen sie nicht sehr vertraut sind), weil sie das neue Projekt lernen müssen. Es ist auch unglaublich riskant, da einige Dinge im Durcheinander verloren gehen könnten, wenn die derzeit damit beauftragten Personen zu anderen Projekten wechseln. Was wäre der Plan? Gibt es eine Möglichkeit, eine schrittweise Änderung vorzunehmen?

Wenn es weniger gegenseitige Befruchtung gibt, werden Sie dann in Schwierigkeiten geraten, wenn jemand, der für ein Projekt entscheidend ist, einen anderen Job annimmt? Entwickler neigen dazu, sich zu bewegen. Wenn weniger Leute die Details von Projekten kennen, kann das kostspielig sein. Wenn wir über Projektteams von 5-10 sprechen, ist dies möglicherweise kein Problem, aber wenn die Teams bei einem bestimmten Projekt als 1-2 enden, könnte dies der Fall sein.

Wenn Sie Mitarbeiter in bestimmte Produktlinien einteilen, schränken Sie dann ihre Fähigkeit ein, sich neues Wissen anzueignen (ein Muss für die meisten guten Programmierer) und zwingen damit die Besten, das Unternehmen zu verlassen, um ihre beruflichen Qualifikationen aufrechtzuerhalten? Je mehr Projekte Sie mit älterer Technologie haben, desto schlimmer könnte dies sein.

Wie einfach ist die Übertragung auf andere Projekte? Sobald Sie in einem Projekt Experte sind, werden die Chancen, sich zu bewegen, stark reduziert. Wenn Entwickler also das Gefühl haben, dass Sie ihren Karrierepfaden schaden, werden sie in Scharen gehen und Sie werden viel aktuelles Wissen verlieren. Zumindest brauchen Sie einen Plan, um Transfers zu anderen Projekten zu ermöglichen, und einen Weg, um die „Ich kann ihn nicht aufgeben, weil er der einzige ist, der es weiß …“-Probleme zu überwinden. Karriereentwicklung ist wichtig, je mehr Projektspezialisten es gibt, desto schwieriger ist es, auch aufzusteigen. Sie brauchen einen Plan, um damit umzugehen. Sie könnten erwägen, jedes Jahr 5-10 % der Entwickler zu wechseln und es zur Bedingung zu machen, dass jeder mindestens alle 5 Jahre die Möglichkeit haben muss, die Produktlinie zu wechseln. Dies könnte helfen, die Kreuzbestäubung zu erzwingen, Geben Sie den Leuten die Möglichkeit, neue Arten von Erfahrungen zu sammeln, und halten Sie den Großteil des Teams relativ stabil. Die Hochlaufzeit sollte in den Projektplänen berücksichtigt werden, da Sie wissen, dass Sie jedes Jahr einige neue Entwickler bekommen werden. Es würde auch dazu beitragen, dass Manager sich nicht zu sehr auf eine Person verlassen, da sie wissen, dass sie letztendlich versetzt wird. Sie könnten auch sicherstellen, dass sich die Leute auf neue Stellen bewerben können, ohne die Zustimmung ihres derzeitigen Chefs einholen zu müssen (um das Horten von Leuten zu verhindern).

Ich würde Ihren Chef fragen, was er erwartet, um die möglichen Probleme auszugleichen (ich bin sicher, dass Ihnen in der aktuellen Situation mehr einfällt als mir. Sie können wahrscheinlich auch sehen, was die Vorteile sein könnten.)

Sie müssen auch bedenken, dass Sie möglicherweise Spezialisten haben, die auf jeden Fall funktionsübergreifend bleiben müssen. Oder wollten Sie 7 Business-Intelligence-Spezialisten (1 pro Projekt) anstelle der 2 einstellen, die Sie haben (als Beispiel). Am besten wäre es, eine hybride Organisation zu schaffen, in der einige isoliert sind und andere nicht.

Sie könnten sogar eine Kosten-Nutzen-Analyse durchführen, die die Risiken und Vorteile beider Möglichkeiten quantifiziert, damit er die Auswirkungen sehen kann.

Wenn ein Entwickler 10.000 Codezeilen pro Jahr schreibt und ein 5-köpfiges Team 18 Monate lang an einem Projekt arbeitet, dann kann man erwarten, dass das Projekt 75.000 Codezeilen hat, wenn es in Produktion geht. Wenn es zehn Jahre lang in Produktion bleibt, wird es in dieser Zeit wahrscheinlich auf 250.000 Linien anwachsen. Dies ist ein höchst hypothetischer Fall, der sich entweder auf eine Website oder eine Abonnementsoftware konzentriert – er würde nicht unbedingt auf eingebettete Steuerungen zutreffen.

100.000 Codezeilen geteilt durch 50 sind ungefähr 2000 Seiten, also muss jeder Entwickler, der an einem ausgereiften Projekt beteiligt ist, das Äquivalent von 2000 Seiten Anweisungen im Kopf behalten. Wenn Sie Personen auf mehrere Projekte verteilen, multiplizieren Sie dies mit der Anzahl der Projekte, die sie im Auge behalten sollen.

Dies könnte funktionieren, wenn Sie Leute haben, die in sehr kurzsichtigen Rollen arbeiten – nichts als Datendienste oder bestimmte Arten von zusammenfassenden Berichten oder UI-Konsistenz über mehrere Produkte hinweg. Wenn Sie jedoch möchten, dass einige Personen eine bestimmte Anwendung gründlich verstehen, sollten sie dies in Vollzeit tun. „Funktionsübergreifend“ ist eine ernsthafte Verwässerung des Aufwands.