I maggiori ostacoli al lavoro su un progetto di gruppo [chiuso]

Il mio più grande problema in università era membri del team che facevano poco o nessun lavoro . Alcuni attraverso la pigrizia, altri attraverso l'essere troppo occupati con altri lavori, altri attraverso la manipolazione e sapendo che potevano farla franca. Attraverso prove ed errori, queste erano le strategie che ho trovato per lavorare nel farle partecipare:

• Progetto Gestisci . Quando tutti dividono il lavoro, consegnare ad ogni pezzo una scadenza e accettare di avere aggiornamenti di stato. Assicurati di chiedere se la persona ha bisogno di ulteriore aiuto, presto e spesso. Ciò include anche l'accettazione di dedicare un determinato numero di ore al progetto e il monitoraggio (si spera onestamente) di quanto tempo ogni membro spende.

• Dai loro il "fun bit" . Se non si godranno il lavoro, non lo faranno. Se aiuterà il mio grado scrivendo tutto il boilerplate e la formattazione e la documentazione di output, va bene. Almeno avrò familiarità con il codice quando lo slacker finirà per completare parzialmente la parte divertente e devo intervenire per aiutare.

• Se si riduce a questo, minaccia (e segui) l'arbitrato con il docente / tutor . Documenta le tue ore, sii onesto e condividi una storia coerente con gli altri membri del team (partecipanti). Il più delle volte quando lo scansafatiche ottiene 1 contro 1 con la persona responsabile, ammette la loro pigrizia e negozia un grado inferiore per se stessi, lasciandoti giudicare in base al merito del tuo lavoro.

Alcune delle cose da cercare per evitare il rischio di fallimento sono:

• Il team dovrebbe essere composto da persone che possono comunicare e accettare un leader e sono pronti a lavorare sulle attività assegnate dal leader. Team leader per chiarire ruoli e responsabilità. I membri del team devono accettare o rifiutare e, se accettano, devono impegnarsi.

• Leader deve poter assegnare compiti e seguire.

• La competenza del team nella tecnologia deve essere adeguata. Altrimenti, il team leader deve tenere in considerazione la formazione o ridimensionare lo scopo o le aspettative.

• I requisiti devono essere chiari e le aspettative devono essere ragionevoli, ad es. la GUI di fantasia potrebbe essere ottima ma puoi permetterti? Questa è una chiamata PM. Mirare alla semplicità il più possibile.

• Il team deve disporre di una risorsa esperta per rivolgersi a risolvere la tecnologia. problemi che potrebbero sorgere.

• Il progetto deve essere basato su un progetto, anche su uno semplice di alto livello in cui il database è stabile e lo stile dell'interfaccia utente è determinato. Vuoi evitare enormi cambiamenti a causa dei limiti di tempo.

• Il caposquadra deve misurare i progressi e documentare sforzi, ostacoli, ecc. Questo fa parte del deliverable. Definisci le pietre miliari e riunisci i membri del team e parla faccia a faccia della situazione.

• Il team deve essere disposto a fare un extra di "10 miglia" per raggiungere il successo.

• Il team deve essere motivato.

• Concentrati prima sulle funzionalità principali, consegnalo, quindi lavora sui contenuti. Dare priorità al deliverable. Comprendi in che modo vengono assegnati i contrassegni.

Non importa se l'istruttore non è competente, purché tu abbia altre fonti di conoscenza.

Mi piace rispondere a @jozzas nel complesso, ma credo di poter aggiungere un po '. Le persone sbagliate tendono a finire il lavoro. Le persone intelligenti che sanno cosa sta succedendo tendono a lasciare che gli altri facciano il lavoro. Le persone stupide del gruppo tendono ad amare accumulare la maggior parte del progetto. Tendono anche a maneggiarlo abbastanza male che le persone comuni nel gruppo alzano le mani per la frustrazione e si arrendono. Quindi, il progetto finisce per essere il caso peggiore per quanto riguarda la qualità. A MENO CHE qualcuno passi e gestisca il carico di lavoro ...