tassonomia dei modelli di risorse del progetto software

Question

tassonomia dei modelli di risorse del progetto software

#1 da (2 voti)
#2 da (-4 voti)

1

Mi piacerebbe capire l'impatto di diversi modelli di risorse per progetti software . Innanzitutto, vorrei identificare i diversi approcci di risorse che vengono utilizzati per i progetti di risorse software. Ecco alcuni modelli a cui posso pensare basandomi sulle mie esperienze:

Risorse centrate sul prodotto
Pool di risorse pianificate
Raggruppamento di risorse caotiche

Modello 1 - ha risorse focalizzate sul prodotto. In questo modello il team di progetto è dedicato a un prodotto (ad esempio un servizio SOA). In questo modello, il prodotto è il concetto centrale e il team rimane e cresce con il prodotto. Questo modello promuove l'apprendimento continuo per il team nel dominio del prodotto e facilita il rapido sviluppo di nuove funzionalità perché il team di progetto è profondamente informato sul prodotto. Questo modello sembra essere molto efficace per l'evoluzione dei prodotti esistenti nelle aziende centrate sul prodotto.

Modello 2 : estrae risorse da un pool di risorse all'avvio di nuovi progetti. Questo modello sembra essere più adatto quando si sviluppano nuovi prodotti da zero. In questo modello i membri del team devono acquisire le conoscenze di dominio richieste prima di iniziare il progetto. Il modello non sembra efficace per le aziende basate sul prodotto, poiché la conoscenza del dominio del prodotto viene persa quando le risorse si sciolgono dopo il completamento del progetto. Questo modello è tipico nelle organizzazioni di consulenza.

Modello 3 - è in realtà un'estensione del Modello 2. Nel Modello 3, le risorse vengono sostituite con altre risorse a metà progetto. Pertanto, il modello tratta le risorse come materie prime in cui si prevede che i nuovi membri del team di progetto acquisiscano le stesse conoscenze della risorsa che hanno sostituito. Questo modello trae la maggior parte della conoscenza del dominio ed è caratterizzato da un basso livello di morale e bassa produttività. Questo modello si trova di solito in organizzazioni che sono costantemente in lotta antincendio.

Domanda : esiste una tassonomia dei modelli di risorse software che posso utilizzare piuttosto che crearne di nuovi?

project-management domain-driven-design resources project-structure

posta Chris Snow 23.11.2013 - 11:51

fonte

2 risposte

-4

Il modello 1 è l'organizzazione divisionale, il modello 2 l'organizzazione a matrice. Il modello 3 sarebbe un'organizzazione basata su una matrice debole. Nota per tipo funzionale di organizzazioni IT non è la soluzione migliore quando ogni lavoro è diverso e sono progetti.

risposta data 25.11.2013 - 14:34

fonte

Leggi altre domande sui tag project-management domain-driven-design resources project-structure

Utilizzo della finestra mobile come RAM temporanea Dovremmo sempre ASCIUGARE? Qualche esempio di caso limite di quando non farlo? [chiuso]

score 2 · Accepted Answer

Non sono sicuro che ci sia una tassonomia per i team, ma ci sono diversi modi di guardare i team e come sono organizzati e strutturati.

Innanzitutto, ci sono alcune dimensioni di cui puoi parlare: formalizzazione, standardizzazione e centralizzazione. La formalizzazione è il livello al quale regole, procedure e documenti scritti guidano il comportamento di individui e gruppi. La standardizzazione è il livello in cui le attività vengono eseguite in modo coerente all'interno dell'organizzazione. La centralizzazione è il livello al quale la capacità di prendere decisioni è mantenuta ai livelli più alti dell'organizzazione.

Questi tre fattori di discussione di un'organizzazione portano anche al concetto di strutture meccanicistiche e organiche. Le organizzazioni meccanicistiche hanno alti gradi di standardizzazione e formalizzazione, spesso (ma non necessariamente) con un alto grado di centralizzazione. Il risultato finale è una prestazione coerente, ripetibile e affidabile. L'altra estremità dello spettro è costituita da strutture organiche, che offrono ai dipendenti di livello più basso maggiore libertà di condurre il proprio lavoro come meglio ritengono opportuno, il che spesso porta a una maggiore innovazione a costo di coerenza e ripetibilità in tutta l'organizzazione.

Ci sono anche modi per guardare la struttura di segnalazione di una squadra. Quattro punti di vista sono la struttura funzionale del team, una struttura di squadra leggera, una struttura di squadra pesante e una struttura di squadra autonoma.

In una struttura di team funzionale, tutti lavorano nei loro reparti funzionali e non c'è integrazione interfunzionale. In una struttura di squadra leggera, tutti lavorano all'interno di un reparto funzionale e i manager funzionali hanno autorità sugli individui mentre un project manager coordina i ruoli funzionali rispetto a un singolo progetto. Nell'ambito di una squadra di pesi massimi, i project manager hanno autorità sugli individui forniti da un gruppo funzionale, ma ritorneranno al loro gruppo funzionale dopo che il loro ruolo nel progetto è stato completato. In un team autonomo, il project manager ha un controllo a lungo termine sulle risorse fornite dai gruppi funzionali.

Gestione strategica dell'innovazione tecnologica di Melissa A. Schilling ha alcuni capitoli dedicati ai diversi modi di organizzare i team , con particolare attenzione allo sviluppo del prodotto e all'innovazione sul posto di lavoro. Non è univoco per il software, ma può essere un punto di partenza rilevante attraverso le sue citazioni.