Newsgroup: it.lavoro.informatica
Titolo: Project designermanagerleader

Non è uno sproloquio. E' che mi trovo nella situazione, e mi ci troverò sempre di più, di dover da un lato disegnare applicazioni software, dall'altro di doverne gestire la realizzazione in qualità di gestore di un gruppo di sviluppo (da cui la sbrodolata nel soggetto). Mentre per il primo aspetto me la cavicchio abbastanza, dato che più o meno quello faccio di mestiere, per quanto riguarda la seconda parte sono scarsino assai; negli ultimi 10 anni, infatti, ho praticamente lavorato da solo, eventualmente coordinandomi con altri professionisti nel caso in cui il progetto che si stava realizzando lo necessitasse.
 
Come dicevo, sto affrontando la nuova situazione di gestire un gruppo. La cosa, capiamoci, è molto stimolante, ma contro di me giocano quel che dicevo, ossia l'abitudine di lavorare da solo, e l'età (inutile che mi nasconda, a 48 anni non ho più la testa ne l'elasticità che avevo a 20).
 
Per cui mi è venuto in mente di chiedere qualche opinione da coloro che già svolgono questo tipo di incarico: secondo voi, teorie di gestione a parte ma proprio dal lato pratico, quali sono le cose da fare e, soprattutto, da NON fare nella gestione di un gruppo che sta realizzando un progetto software?
 
-- 
Ciao!
Luca

 Per cui mi è venuto in mente di chiedere qualche opinione da coloro che già svolgono questo tipo di incarico: secondo voi, teorie di gestione a parte ma proprio dal lato pratico, quali sono le cose da fare e, soprattutto, da NON fare nella gestione di un gruppo che sta realizzando un progetto software?
 
cose imho da fare:
- avere sempre chiaro la timeline e condividerla con chiarezza con
tutti
- assegnare task per obiettivi e responsabilizzare al raggiungimento
degli stessi
- fissare incontri a cadenza periodica in cui si discutono problemi di
tutti e proposte
 
cose imho da evitare:
- non lasciare spazio all'inventiva: nel senso, si ascolta tutti ma
poi si fa come dico io
- non mollare mai nessuno da solo in difficoltà. a volte capitano task
rognosi e la tentazione è quella di farci lavorare quello più "tosto"
finché non ci leva le gambe, in quei casi affianca da subito un'altra
persona anche se non è d'accordo (i programmatori tendono ad essere
inguaribili ottimisti sulle loro capacità di sopportazione).
 

 Per cui mi è venuto in mente di chiedere qualche opinione da coloro che già svolgono questo tipo di incarico: secondo voi, teorie di gestione a parte ma proprio dal lato pratico, quali sono le cose da fare e, soprattutto, da NON fare nella gestione di un gruppo che sta realizzando un progetto software?
 
Tutto ciò è dal vivo o in remoto? Citavamo proprio l'altro giorno
http://www.joelonsoftware.com/articles/fog0000000043.html
 

>soprattutto, da NON fare nella gestione di un gruppo che sta realizzando un progetto software?
 
- non dare mai la colpa agli altri, ne davanti ne dietro, la colpa è
tua i meriti dei programmatori.
 
- se qualcuno non è preparato come dovrebbe (troppo junior/incapace),
chiedi che venga tolto da gruppo oppure calcola correttamente il suo
apporto nel piano di lavoro e sii molto chiaro con il committente se
non è d'accordo. Altrimenti si creano spiacevoli situazioni in primis
verso lui.
 
- sta a te utilizzare le persone nel modo giusto, nel distribuire e
preparare le attività in modo che le persone le svolgano e siano
produttive in base alle loro caratteristiche.
 
- E sopratutto non usare mai le regex per il parsing di flat file
 
 

 - E sopratutto non usare mai le regex per il parsing di flat file
 
e neanche le bolle in array
 
M.


e bloccare ili sempre nelle ore di lavoro.

 e neanche le bolle in array
 
e mi raccomando mai fare i test. i veri programmatori non scrivono bug
e quelli degli altri li fulminano con un'occhiata mentre leggono i
commenti del codice.
 
 

 Per cui mi č venuto in mente di chiedere qualche opinione da coloro che gią
svolgono questo tipo di incarico: secondo voi, teorie di gestione a parte ma
proprio dal lato pratico, quali sono le cose da fare e, soprattutto, da NON
fare nella gestione di un gruppo che sta realizzando un progetto software?
 
Rispondo alla seconda domanda (cosa non fare), la cui risposta e' molto
facile (sara' che a me hanno mandato gente mediamente in gamba): 
 
- punto fondamentale: non ROMPERE GLI ZIMBELLI a quelli che lavorano o
almeno ci provano seriamente, specialmente non rompere con cose
assolutamente inutili (tipo "questo non si fa perche' l'altro e' OOP e
questo no" o peggio [molto molto peggio] con cose del tipo: "non devi
arrivare prima delle 10.00 perche' gli altri non arrivano prima delle
10.00 e bisogna "lavorare in gruppo" [o peggio: non devi arrivare prima
delle 10.00 perche' io non arrivo prima delle 10.00]. Anche "non devi
arrivare dopo le 8.30 perche' gli altri arrivano prima delle 8.30" e' da
evitare assolutamente, a meno che non hai modo di constatare  che il tizio
interessato arriva alle 12.00 e se ne va alle 14.00 dopo aver fatto una
pausa pranzo dalle 12.30 alle 13.30).
 
- Non far pesare l'esperienza, a meno che non siano loro a chiederti le
cose (leggasi: delegare al massimo tutto quello che e' delegabile e, a
meno che non si abbia motivo fondato per fare il contrario, tendere a
fidarsi di quello che fanno gli altri, che di solito non sono dei
coglioni, ma spesso ne sanno piu' dei "vecchi". Questo anche quando gli
altri mettono le righe bolla in un array, a meno che il software poi per
qualche motivo non funzioni).
 
- Personalmente aggiungerei: non frantumare gli zebedei con false promesse
 o peggio, frasi che preannunciano genericamente "buone cose" (del tipo
"se il progetto va bene e' meglio per tutti"), specialmente nel caso in
cui si sappia (come in genere si sa) che se il progetto va bene tu ne
avrai dei benefici (magari un altro progetto) mentre gli altri se ne
andranno a casa comunque: massima chiarezza fin da subito aiuta molto. 
 
 
 
Il "cosa fare" e' un po' piu' difficile.
Se possibile, far scegliere alle persone quando e come lavorare,
responsabilizzare premiando quando fanno bene (possibilmente non solo con
una pacca sulla spalla) e comunque cercare di far capire ad ognuno quale
e' il suo compito. 
 
 
 
Ciao,
Marco.
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 


Impressioni sul gruppo? Tutta gente nuova, gente che conosci, un mix?
 

 Per cui mi è venuto in mente di chiedere qualche opinione da coloro che già svolgono questo tipo di incarico: secondo voi, teorie di gestione a parte ma proprio dal lato pratico, quali sono le cose da fare e, soprattutto, da NON fare nella gestione di un gruppo che sta realizzando un progetto software?
 
Ricorda che la gestione del progetto verso il cliente è tua, pertanto
devi essere abile a compensare eventuali carenze o criticità di
realizzazione (sforamenti nei tempi, bug, improvvisi cambi dei
requisiti). Più bravo sei nel fare questo, meno importante è la
maggiore o minore bravura dei tuoi collaboratori. E di conseguenza più
vivi tranquillo :-)
In questo senso devi organizzare strumenti e procedure di lavoro in
maniera che l'errore del singolo abbia il minimo impatto possibile sul
progetto.
Come pure è importante l'affiatamento, inutile avere vicino geni
dell'informatica con cui sei sempre in attrito. Meglio un onesto
lavoratore con cui ti capisci al volo. Ed anche se non sei tu a
sceglierli direttamente, puoi sempre fare in modo di far capire a chi
sceglie che è meglio cambiare scelta (e ricadiamo tra le capacità
personali che deve avere un buon capo progetto).


Tre post e il thread è in vacca!
 
Che dire, sono orgoglione di voi!! 
 
:-D
 
--
Ciao!
Luca

 ...
 
Mamma mia, in che ambienti orridi hai lavorato fino ad adesso!!
E io mi lamentavo...
 
-- 
Ciao!
Luca


Mancano info: cos'è il "gruppo"? Un insieme di persone o un "luogo di 
lavoro"? Entrambi?
 
Attrezzati con strumenti per gestione progetti, che facciano gestione 
degli obiettivi, delle risorse, planning, gestione delle deadline ecc. 
Dai uno sguardo a "Trello" di Joel Spolsky (
http://www.trello.com
 e 
http://www.joelonsoftware.com/items/2011/09/13.html
), un ottimo 
strumento per group development, IMHO. Dovrai fare delle riunioni 
periodiche, dove esaminerete i risultati (test) e vi confronterete con i 
problemi.
Il progetto dovrà avere degli obiettivi e dei limiti, nonché delle 
direttive "di massima" sul "come" andrà implementato (ma questo lo sai).
I programmatori tendono ad essere anarchici, e se non li gestisci con 
pugno di ferro in guanto di velluto rischi di trovarti parti di progetto 
fatte con tecnologie differenti che mal si integrano.
Lasciamo le righe bolla in array se non sono un rischio, ma se il 
programmatore è "de coccio", meglio dare subito ordini precisi...
Attenzione a scegliere gli elementi del gruppo, se sarà compito tuo: 
devono conoscere molto bene le tecnologie che TU farai adottare (perché 
sei tu il responsabile del progetto, e se va in vacca è causa tua).
Se i programmatori hanno delle perplessità sul tuo design, chiedi di 
motivare, e se hanno ragione correggi.
Tieni sempre sotto controllo la situazione, specie quando affidi dei 
task "a scatola chiusa" a qualcuno. Le riunioni periodiche servono per 
discutere dei problemi e verificare se qualcuno è in difficoltà, ma 
soprattutto a vedere come avanza il progetto.
 
Nelle riunioni eviterei di assumere il ruolo di evangelist, piuttosto 
vedo meglio il motivatore, ed eviterei riunioni il venerdi pomeriggio 
alle 16 od il lunedi mattina alle 8.30.
Fatti dare un feedback da tutti, nessuno escluso: se ci sono perplessità 
devono emergere nelle riunioni ed essere risolte al termine della stessa.
Attenzione alle "mine vaganti": il signor SoTuttoIo, l'ingegner 
IochoTreLauree, TizioCheEAmicoDiSempronio, ecc.

menegot...@gmail.com
 ha scritto:

E pensa che le cose peggiori non le ho scritte.


gestione di un gruppo che sta realizzando un progetto software?
 
Cose da fare (o che almeno io ho trovato utili in passato): 
- partire da un progetto su carta opportunamente modularizzato;
- assegnare a ciascuno una parte e vincolarli al raggiungimento di task
specifici per tempi obiettivi;
- aggiornare frequentemente lo stato avanzamento lavori;
- riunirsi almeno un pomeriggio a settimana (di solito il venerdi' che la gente
'e piu' scarica) e affroantre argomenti di interesse comune, confrontarsi.  

 'e piu' scarica) e affroantre argomenti di interesse comune, confrontarsi.  
 
Pessima idea: alcuni (esterni) potrebbero aver la necessità di levare le
tende per tornare al proprio loculo; il venerdì pomeriggio si è così
scazzati che la produttività e l'efficienza neuronale raggiungono
livelli così bassi da rendere quasi nociva ogni azione che preveda il
prendere decisioni. Il venerdì pomeriggio è meglio usarlo per scrivere
la documentazione :-)
Per la riunione, meglio il lunedì...
 
M.

Per la riunione, meglio il lunedě...
manco morto (io ODIO i  lunedi' ;-P) la semplice idea di dover parlare al mondo
di lunedi' la trovo insopportabile.


Si, vabbe', ma scusa, delle enne domande a qualcuna potresti anche 
rispondere eh?
 

 rispondere eh?
 
N domande? Io ne vedo sostanzialmente quattro:
- gruppo locale o distribuito;
- gruppo nuovo o esistente;
- gruppo preparato o da far crescere;
- ho voce in capitolo nella selezione.
 
E rispondo veloce: locale, costruendo, quindi da far crescere anche come gruppo, si, ho voce in capitolo.
 
-- 
Ciao!
Luca


Thx.
Buona selezione allora.