Gibt es Studien zu funktionsübergreifenden Teams im Vergleich zu domänenbasierten Teams (z. B. projektbasiert im Vergleich zu Software / Mechanik / usw.)?

Ich arbeite in einer Organisation, die viele integrierte Systemprodukte erstellt - dh es handelt sich um komplette Produkte, bei denen Mechanik / System / Elektronik / Software entworfen und hergestellt wird. Derzeit sind die meisten Teams funktionsübergreifend um Projekte herum organisiert. Der Vorteil einer solchen Organisation ist, dass Menschen, die eng zusammenarbeiten, um ein gemeinsames Ziel zu erreichen, nahe beieinander sind.

Die Nachteile ergeben sich aus der Isolation der Ingenieure von ihren Kollegen. In der Regel wird einem Projekt nur ein Softwareentwickler zugewiesen. Dies bedeutet, dass die Projekte einen hohen Lkw-Faktor, minimalen Wissensaustausch und Best Practices aufweisen und die technische Entwicklung begrenzt ist.

Meine Frage lautet also: Gibt es Studien, in denen Kosten und Nutzen dieser beiden Ansätze verglichen werden?

Die beste Art der Teamstruktur ist nicht unbedingt die Kosten-Nutzen-Struktur, sondern die derzeit bestehende Organisationskultur, die Merkmale der Mitarbeiter und die Art des durchgeführten Projekts. Aufgrund dieser Variablen kann man nicht sagen, dass eine bestimmte Strategie oder ein bestimmter Ansatz am besten ist, aber es gibt einige allgemeine Indikatoren dafür, wie Sie ein Team am besten strukturieren können, um die jeweilige Aufgabe zu erledigen.

Es gibt viele Arten von Teams und Möglichkeiten, Teams und Organisationen zu organisieren . Einige der gebräuchlichsten Formen sind funktional, leicht, schwer und autonom. Im Folgenden fasse ich einen Teil eines Buches über das Management technologischer Innovationen zusammen - Melissa A. Schillings strategisches Management technologischer Innovationen .

Ein funktionales Team ist völlig funktionsunfähig. Jeder Mitarbeiter bleibt in seiner eigenen Abteilung. Völlige Isolation zwischen Wissenschaft, Technik, Personal und so weiter. Ein Mitarbeiter berichtet an einen Funktionsmanager. In dieser Struktur fühlen sich Personen, die an einem Projekt arbeiten, eher ihrer funktionalen Abteilung als dem Projekt verpflichtet. Diese Struktur eignet sich für ein sogenanntes Derivatprojekt, bei dem vorhandene Arbeiten mit nur geringfügigen Änderungen oder Verbesserungen und Projekten genutzt werden, für die nur (oder meistens) nur eine einzige Art von Fachwissen erforderlich ist.

Leichte Teams entstehen, wenn Mitglieder in ihren Funktionsabteilungen wohnen und an Funktionsmanager berichten. Es wird jedoch ein Projektmanager eingeführt. Der Projektmanager überwacht die Personen, die für die Durchführung des Projekts benötigt werden, verwaltet sie jedoch nicht direkt. Die Rolle des Projektmanagers besteht darin, die Kommunikation zu erleichtern und sicherzustellen, dass jedes Mitglied des Projekts einen angemessenen Beitrag leistet. Diese Struktur eignet sich am besten für abgeleitete Projekte, bei denen kein hohes Maß an Koordination und Kommunikation zwischen den Mitgliedern erforderlich ist.

Schwergewichtsteams entfernen erforderliche Personen aus ihren Funktionsabteilungen, berichten jedoch weiterhin an einen Funktionsmanager. Ein Projektmanager überwacht die Projektaktivitäten, überwacht oder verwaltet die einzelnen Teammitglieder jedoch nicht direkt. Projektmanager sind in dieser Umgebung in der Regel den Funktionsmanagern überlegen und dafür verantwortlich, die Projektmitglieder zu bewerten, zu belohnen und zu führen. Diese Teams verfügen über ein hohes Maß an Kommunikation und Zusammenarbeit zwischen den Projektmitarbeitern, und die Mitglieder setzen sich auch für den Erfolg des Projekts ein. Dieses Format wird für Plattformprojekte verwendet, mit denen Kosten, Qualität und Leistung einer früheren Generation verbessert werden (die jedoch möglicherweise keine wesentlichen neuen Innovationen aufweisen).

Autonome Teams entfernen Mitglieder vollständig aus den Funktionsabteilungen und lassen sie direkt unter einem Projektmanager arbeiten. Projektmanager sind hier leitende Mitarbeiter und Leiter der Organisation. Manchmal erhalten diese Teams immense Freiheit, "die Arbeit zu erledigen", indem sie ihre eigenen Richtlinien und Verfahren entwickeln. Gleichzeitig würden sie für die Erfolge oder Misserfolge des Projekts voll verantwortlich gemacht. Diese Arten von Teams werden häufig in bahnbrechenden Projekten eingesetzt, die neue Innovationen in die Produkte des Unternehmens einführen oder neue Geschäftsbereiche hervorbringen.

Nur weil ein bestimmter Teamtyp für einen bestimmten Projekttyp im Allgemeinen gut sein kann, ist es auch wichtig, wie die Kultur der Organisation aussieht. Einige Organisationen können (oder werden) autonome Teams aus kulturellen Gründen nicht unterstützen. Andere "haben es immer auf eine bestimmte Weise getan" und werden sich einfach nicht ändern. Es ist auch wichtig, welche Art von Personen im Team sind - einige Personen funktionieren besser, wenn sie zusammengeschlossen sind und ein hohes Maß an Kommunikation und Fähigkeit zur Zusammenarbeit haben, während andere ihren Platz bevorzugen, um das Problem zu lösen und es wieder herauszuwerfen.

Die folgenden Artikel / Bücher / Dokumente werden in dem Abschnitt des Buches zitiert, den ich lese:

• SC Wheelwright und KB Clark, Revolutionierung der Produktentwicklung: Quantensprünge in Geschwindigkeit, Effizienz und Qualität (New York: Free Press, 1992).
• F. Damanpour, "Organisatorische Innovation: Eine Meta-Analyse der Auswirkungen von Determinanten und Moderatoren", Academy of Management Journal 34, No. 3 (1991).
• EF McDonough, "Untersuchung von Faktoren, die zum Erfolg funktionsübergreifender Teams beitragen." Journal of Product Innovation Management 17 (2000).

Sie können zwar funktionsübergreifende Teams haben, aber es schadet auch nicht, diese Teams mit mehreren Teilzeitingenieuren zu besetzen. Sie könnten zum Beispiel Bob auf Projekt a und Projekt b setzen und Jane auch auf Projekt a und Projekt b setzen. Auf diese Weise werden sie jedoch verteilt, wenn Sie Projekte haben, die klein genug sind, um mit nur einem Softwareentwickler erstellt zu werden, kann selbst dieser Ansatz Einschränkungen aufweisen.

Eine andere Möglichkeit könnte darin bestehen, die Teamstruktur beizubehalten, aber die Arbeitsumgebung um die Funktion herum zu organisieren. Stellen Sie alle Softwareentwickler zusammen, wo sie in einer offenen Umgebung zusammenarbeiten können. Dies widerspricht einigen Überlegungen und manchmal werden die Leute defensiv, wenn Sie die Mauern niederreißen, aber es kann hilfreich sein, in einer Bull-Pen-Anordnung zu arbeiten.

Darauf basiert auch das Konzept der Zusammenarbeit. Unabhängige Berater und Designer, die sonst in einem Heimbüro arbeiten würden, beziehen eine gemeinsame Einrichtung, in der sie sich gegenseitig von ihren Stärken profitieren können.

Es gibt möglicherweise nicht viel zu diesen Ideen. Vielleicht können Sie sie den beteiligten Teams als Experiment vorlegen, um eine bessere Produktivität und Zufriedenheit bei den Jobs zu erzielen. Schreiben Sie dann ein Whitepaper über die Ergebnisse.