Esistono studi di team interfunzionali o di team basati sul dominio (ad esempio, progetti basati su software / meccanici / ecc.)?

8

Lavoro in un'organizzazione che crea molti prodotti di sistemi integrati, ovvero prodotti completi con meccanica / sistema / elettronica / software progettati e realizzati. Al momento la maggior parte delle squadre sono organizzate attorno a progetti in modo trasversale. Il vantaggio di un'organizzazione come questa è che le persone che lavorano a stretto contatto per un obiettivo comune sono vicine.

Gli svantaggi derivano dall'isolamento degli ingegneri dai loro pari. In genere a un progetto viene assegnato un solo ingegnere del software. Ciò significa che i progetti hanno un alto fattore di camion, una condivisione delle conoscenze minima e le migliori pratiche, e lo sviluppo tecnico è limitato.

Quindi la mia domanda è: ci sono studi che mettono a confronto i costi / benefici di questi due approcci?

    
posta mikelong 19.09.2011 - 19:58
fonte

2 risposte

2

Il miglior tipo di struttura del team da utilizzare non è necessariamente uno dei costi-benefici, ma piuttosto sulla cultura organizzativa attualmente in atto, le caratteristiche dei dipendenti e il tipo di progetto condotto. A causa di queste variabili, non c'è modo di affermare che una particolare strategia o approccio sia il migliore, ma ci sono alcuni indicatori generali su come strutturare al meglio una squadra per completare l'attività a portata di mano.

Ci sono molti tipi di squadre e modi per organizza squadre e organizzazioni . Alcune delle forme più comuni sono funzionali, leggere, pesanti e autonome. Di seguito, riassumo una parte di un libro sulla gestione dell'innovazione tecnologica - Gestione strategica dell'innovazione tecnologica di Melissa A. Schilling .

Un team funzionale è interamente non cross-funzionale. Ogni dipendente rimane all'interno del proprio dipartimento. Isolamento totale tra scienza, ingegneria, risorse umane e così via. Un dipendente riporterà a un responsabile funzionale. Sotto questa struttura, le persone che lavorano su un progetto tendono ad essere più impegnate nel proprio dipartimento funzionale piuttosto che nel progetto. Questa struttura è appropriata per ciò che è noto come progetto derivato - sfruttando il lavoro esistente con solo piccole modifiche o miglioramenti e progetti che solo (o principalmente) richiedono un singolo tipo di esperienza.

I team leggeri si verificano quando i membri risiedono nei loro reparti funzionali e riferiscono ai responsabili funzionali. Tuttavia, viene introdotto un project manager. Il project manager supervisionerà le persone che sono necessarie per portare a termine il progetto, ma non le gestirà direttamente. Il ruolo del project manager è di facilitare la comunicazione e assicurare che ogni membro del progetto contribuisca in modo appropriato. Questa struttura è la soluzione migliore per i progetti derivati che non richiedono una grande quantità di coordinamento e comunicazione tra i membri.

I team dei pesi massimi rimuovono le persone richieste dai loro reparti funzionali, tuttavia continuano a riferire a un responsabile funzionale. Un project manager supervisiona le attività del progetto, ma non supervisiona o gestisce direttamente i singoli membri del team. I project manager di solito superano i responsabili funzionali in questo ambiente e sono responsabili della valutazione, del riconoscimento e della guida dei membri del progetto. Questi team hanno un alto grado di comunicazione e collaborazione tra quelli assegnati al progetto e i membri sono anche impegnati per il successo del progetto. Questo formato viene utilizzato su progetti di piattaforma, utilizzati per migliorare i costi, la qualità e le prestazioni di una generazione precedente (ma potrebbe non avere una significativa novità).

I team autonomi rimuovono completamente i membri dai reparti funzionali e li fanno lavorare direttamente sotto un project manager. I project manager qui sono membri dello staff senior e leader dell'organizzazione. A volte, a queste équipe viene data un'immensa libertà di "portare a termine il lavoro" sviluppando le proprie politiche e procedure. Allo stesso tempo, sarebbero ritenuti interamente responsabili dei successi o dei fallimenti del progetto. Questi tipi di team vengono spesso impiegati in progetti innovativi, che introducono una nuova innovazione nei prodotti dell'organizzazione o nella produzione di nuove unità aziendali.

Tuttavia, solo perché un particolare tipo di squadra può essere generalmente valido per un particolare tipo di progetto, è importante anche quale sia la cultura dell'organizzazione. Alcune organizzazioni non possono (o non vogliono) sostenere gruppi autonomi per motivi culturali. Altri "lo hanno sempre fatto" in un certo modo e semplicemente non cambieranno. Importa anche il tipo di persone che fanno parte del team: alcune persone funzionano meglio se sono posizionate e hanno un alto livello di comunicazione e capacità di collaborazione, mentre altre preferiscono il loro spazio per risolvere il problema e rimetterlo in sesto.

I seguenti documenti / libri / documenti sono citati dalla sezione del libro che sto leggendo:

  • S.C. Wheelwright e K.B. Clark, rivoluzionando lo sviluppo del prodotto: salti quantici di velocità, efficienza e qualità (New York: Free Press, 1992).
  • F. Damanpour, "Innovazione organizzativa: una meta-analisi degli effetti di determinanti e moderatori", Academy of Management Journal 34, no. 3 (1991).
  • E.F. McDonough, "Indagine sui fattori che contribuiscono al successo dei team interfunzionali". Journal of Product Innovation Management 17 (2000).
risposta data 28.09.2011 - 01:23
fonte
1

Sebbene sia possibile avere team interfunzionali, ciò non guasta anche lo staff di quei team con più ingegneri part-time. Ad esempio, potresti inserire Bob sul progetto ae sul progetto b e anche mettere Jane sul progetto ae sul progetto b. In questo modo vengono distribuiti, tuttavia, se si dispone di progetti sufficientemente piccoli da essere costruiti con un solo ingegnere del software, anche questo approccio potrebbe presentare delle limitazioni.

Un'altra opzione potrebbe essere quella di mantenere la stessa struttura del team ma organizzare l'ambiente di lavoro attorno alla funzione. Metti insieme tutti i tecnici del software dove possono collaborare in un ambiente aperto. Ciò è in contrasto con il pensiero e talvolta le persone si mettono sulla difensiva quando si abbattono i muri, ma potrebbe essere d'aiuto lavorare su una disposizione di tipo bull-pen.

Anche il concetto di collaborazione è basato su questo. Consulenti e designer indipendenti che altrimenti lavorerebbero in un ufficio a casa, si trasferiscono in una struttura condivisa dove possono alimentarsi reciprocamente.

Potrebbero non esserci molte idee su queste idee, forse è possibile aggiungerle ai team coinvolti come esperimento per ottenere una migliore produttività e soddisfazione nei lavori. Quindi scrivi un white paper sui risultati.

    
risposta data 23.09.2011 - 15:39
fonte

Leggi altre domande sui tag