Struttura organizzativa ottimale per l'IT?

Uno dei miei datori di lavoro ha usato un tipo molto diverso di struttura organizzativa che sembrava funzionare molto bene e che non ho mai visto usato altrove.

Questo era incentrato sul concetto di ciascun progetto fatto da un team relativamente piccolo e multidisciplinare, riunito solo per la durata del progetto. Un tipico team potrebbe avere più sviluppatori di software generici, un matematico, ingegneri, tecnici di collaudo, ingegneri di server, ecc., Tutti guidati da un singolo project manager.

Una persona verrebbe normalmente coinvolta in più progetti contemporaneamente e quindi parte di più team. I responsabili del progetto si terrebbero in contatto gli uni con gli altri per garantire che le persone non fossero coinvolte in troppi progetti e per garantire che le persone conoscessero le loro particolari priorità. Ogni persona sarebbe quindi responsabile della pianificazione del proprio tempo per assicurarsi di soddisfare i propri impegni di progetto.

Ogni membro del personale aveva il proprio ufficio privato (per la maggior parte) quindi non c'era bisogno di spostarsi fisicamente ogni volta che si entra in una nuova squadra. L'edificio stesso aveva molte sale riunioni / aree comuni per assicurare che i team potessero riunirsi facilmente.

Essere parte di più team diversi ha davvero eliminato le barriere organizzative - le persone trascorrevano la loro settimana media lavorando insieme a un campione rappresentativo dell'intera organizzazione e questo ha comportato il minor numero di "avversari contro di noi" contro di noi che ho esperto.

Era anche un buon modo per garantire che le competenze fossero utilizzate correttamente - il personale poteva essere inserito in un progetto al fine di fornire una particolare abilità o condividere esperienze con estrema facilità e senza bisogno di cambiare una gestione delle persone o una struttura di segnalazione.

L'intero sistema sembrava essere costruito sul modello di business molto specifico dell'organizzazione, alti livelli di motivazione del personale e project manager molto esperti e capaci quindi non sono sicuro di quanto trasferibile, ma ho pensato che valesse la pena condividere comunque .

La legge di Conway recita:

"..organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"

Il corollario di questo è che la migliore struttura organizzativa è la stessa della migliore architettura software.

Non conoscendo le specifiche della tua attività, sto basando quanto segue su alcune generalizzazioni radicali:

L'esperienza indica che lo sviluppo del software è sia costoso che rischioso; e che questo rischio e questa spesa possono essere ridotti (anche con sforzi faticosi) in misura molto limitata.

Da costo e amp; il livello di rischio è (approssimativamente) fisso, è necessario aumentare i rendimenti per ottenere un premio accettabile: rapporto rischio / rischio.

La prima conseguenza ovvia di questo è che le organizzazioni dovrebbero concentrarsi su progetti con un grande profitto. Questo non è sempre realizzabile, poiché le opportunità potrebbero non esistere sul mercato. La seconda conseguenza ovvia di ciò è che i costi di sviluppo dovrebbero essere ammortizzati il più possibile. Ad esempio, distribuendo i costi di sviluppo su più linee di prodotti e amp; progetti. (Ad esempio riutilizzo del codice).

Quindi, torniamo alla legge di Conway: quale struttura organizzativa massimizza il riutilizzo del codice? La risposta ovvia sarebbe quella di allineare le unità organizzative attorno alle librerie e agli ampli; API, con ciascuno sviluppatore responsabile di una o più librerie E uno o più prodotti. Il modo in cui le librerie vengono riutilizzate non è più una decisione puramente tecnica, ma anche un'importante decisione aziendale. Dovrebbe essere una funzione di gestione per garantire che i costi di sviluppo siano ammortizzati in modo efficace per massimizzare il ritorno per sforzo di sviluppo unitario.

Ogni sviluppatore ha quindi la responsabilità per lo sviluppo, il test e l'amp; prestazioni in-service delle funzionalità fornite / supportate dalla sua libreria.

Non riesco a vedere i team di manutenzione separati dai team di sviluppo iniziali che lavorano. In generale, almeno alcuni degli sviluppatori coinvolti nella progettazione e nello sviluppo del core dovrebbero rimanere in manutenzione per un periodo compreso tra sei mesi e un anno (una sorta di pollice succhiato quel periodo in base alla propria esperienza).

Gli sviluppatori di manutenzione devono fare i conti con il problema "da questo punto di progettazione", dove non sono in grado di vedere se una specifica area problematica sia stata creata in questo modo per una buona ragione. È più facile per gli sviluppatori originali correggere errori di progettazione fondamentali.

Se si intende un nuovo sviluppatore di manutenzione, sia gli sviluppatori originali che lo sviluppatore della manutenzione dovrebbero condividere un po 'di tempo per mantenere il sistema. Lo sviluppatore principale controlla che lo sviluppatore della manutenzione non codifichi attorno al suo progetto e lo sviluppatore della manutenzione ha la possibilità di porre domande sui progetti fondamentali e sul ragionamento alla base del codice. Entrambe le parti imparano e condividono la responsabilità.

Gli sviluppatori che hanno dedicato del tempo a mantenere il codice affrettato saranno più concentrati sulla qualità del codice.

I Non ho molta esperienza con i test, ma ho scoperto che funziona meglio se i tester elaborano piani di test insieme agli sviluppatori. I piani di test vengono eseguiti nella fase di test e se tutte le caselle sono state verificate viene dato il via libera.

Un tempo avevamo organizzato team per cliente (o progetto) con alcuni specialisti che supportavano molti clienti. Poi siamo andati alla struttura organizzativa degli sviluppatori di applicazioni e agli sviluppatori di manutenzione e agli sviluppatori di database e i clienti dovevano riunirsi da un pool di persone. Questo fallì miseramente. Ora siamo tornati alla struttura originale e tutti sono molto più felici.

Una cosa che accadde quando avevamo un gruppo di manutenzione di sviluppatori e sviluppatori di applicazioni era che era impossibile passare da una categoria all'altra. Le manutenzioni sono state considerate come aventi meno competenze e quindi non sono qualificate per essere trasformate in sviluppatori di applicazioni.

Nel frattempo gli sviluppatori di applicazioni non avevano idea dei problemi che avevano creato quando avevano un design scadente perché non avevano mai visto i ticket di supporto. Così hanno continuato a ripetere gli stessi errori ripetutamente. Ciò ha ovviamente infastidito gli sviluppatori di manutenzione "meno esperti" che hanno dovuto correggere gli errori degli sviluppatori di applicazioni mentre gli sviluppatori di applicazioni hanno ottenuto tutti i riconoscimenti, inclusi aumenti di stipendio e promozioni.

I project manager erano impegnati in una battaglia continua e dispendiosa in termini di tempo per ottenere risorse per svolgere il proprio lavoro che creava molto odio e malcontento organizzativo. Nessuno poteva dare la priorità al lavoro in modo efficace perché non sapevano di giorno in giorno chi avrebbero avuto la possibilità di fare il lavoro. Ciò ha anche portato via dal momento in cui hanno dovuto gestire effettivamente i loro progetti e alcuni brutti ritardi e overrrun si sono verificati perché non hanno avuto il tempo di vedere cosa stava accadendo a causa del trascorrere troppe ore al giorno combattendo per ottenere persone assegnate al loro alto priorità. I clienti più piccoli erano infastiditi perché perdevano sempre la battaglia delle risorse e le loro alte priorità non venivano soddisfatte. In questo modo potrebbero avere bug critici per gli show-stop che non sono stati corretti.

ITIL e COBIT sarebbe il mio suggerimento per le risposte se vuoi andare in fondo alla tana del coniglio su come organizzare l'IT in un'azienda ad alto livello. Ho visto alcuni ITIL che sembrano una buona idea, ma mi chiedo quanto bene possa essere implementato e l'organizzazione maturata nell'utilizzo del framework.

I migliori schemi organizzativi che abbia mai visto possono essere descritti fondamentalmente come "amebe". Solo un gruppo di ragazzi (e ragazze) con obiettivi comuni che lavorano per arrivare là e ingoiare organicamente ogni cosa sul loro cammino. Potresti avere qualcuno in un ruolo principale su un pezzo specifico, ma quando tutti possiedono tutto possono accadere cose belle.

Sfortunatamente questo tipo di struttura fa esplodere le teste dei PHB e raramente viene visto allo stato selvatico.