Newsgroup: it.lavoro.informatica
Titolo: il capo


 
che in pratica dice che ci sono nove errori "ricorrenti" che fa un 
manager e per i quali i loro dipendenti se ne vanno.
 
l'introduzione dice che quando qualcuno lascia il lavoro, speoo
 
"le persone non lasciano il posto di lavoro, lasciano il loro capo".
 
Mi interessava capire se a qualcuno e' capitato che il proprio
manager commettesse qualcuno di questi errori, al punto
tale da spingerlo a lasciare il lavoro (o meglio a lascire "quel capo").
 
A me, quando ero informatico e' capitato spesso di "lasicare quel capo"
(anzi ogni volta che ho cambiato lavoro e' stato alla fine per questo),
anche se io non ero un dipendente, al limite un collaboratore.
 
Anzi, ho proprio deciso di non cercare piu' lavoro come informatico
proprio per non ritrovarmi tra gli zebedei gente di un certo tipo
(anche se, purtroppo, se ne trova anche fuori dall'informatica, ma in
percentuale decisamente minore, almeno fino ad ora).
 
Per quanto mi riguarda:
 
Punto 1 ("i manager assegnano ai dipendenti troppo lavoro"), non ho 
(quasi) mai considerato il lavoro come "troppo".
 
Punto 2.("il manager non riconosce l'apporto dei dipendenti"),
a me di avere pacche sulla spalla non me ne e' mai fregato una cippa.
 
Punto 3. ("il manager non si preoccupa dei propri dipendenti")
Per quanto mi riguarda, meno il manager meno si interessa del mio lato 
umano e meglio sto.
 
Punto 4.("non onorano i loro impegni"):
questo  e' quello che, a ben vedere,  praticamente mi ha spinto
ad andarmente ogni volta che ho cambiato lavoro.
 
punto 5. "Assumono e promuovono le persone sbagliate".
Mai avuto nulla da dire su assunzioni e promozioni degli altri.
 
punto 6.("non lasciano che le persone seguano le proprie passioni").
finche' mi pagano posso benissimo non seguire le mie passioni. Non 
rendero' 5 volte piu' del normale(come fa chi segue le proprie
passioni, secondo l'articolo), ma questo non mi spinge certo ad andarmene.
 
punto 7. ("non riescono ad enfatizzare le abilita' dei dipendenti").
Non ho nemmeno ben capito cosa voglia dire, se non nella parte in cui 
afferma che tocca al manager "cercare delle aree lavorative
dove il dipendente possa impiegare al meglio le proprie
capacita'". Ma che non lo facciano non mi spinge certo ad andarmene.
 
PS:Questa cosa ("cercare delle aree lavorative
dove il dipendente possa impiegare al meglio le proprie
capacita'") l'ho vista fare solo da un project
manager [all'epoca era PM oggi non so], che guarda caso:
 
a- era una donna (e presumo che lo sia ancora)
b- pur essendo italiana, non aveva studiato in Italia [credo in UK] e, 
essendo stata sposata con un americano, credo avesse vissuto per quelche 
tempo negli Stati Uniti. Ovvero aveva vissuto buona parte della vita 
fuori dall' Italia.
 
 
punto 8. ("non sanno stimolare la creativita' del dipendente")
per quanto mi riguarda se vogliono ingabbiare la mia spinta creativa 
possono farlo senza problemi; non me ne andro' per questo.
 
punto 9.("Non stimolano gli impiegati sul piano intellettuale")
A me se rompi gli zebedei con cose del tipo "dobbiamo fare concorrenza
a Apple" come ho sentito dire nel 2007 da gente che lavorava per 
un'azienda con nemmeno 10 dipendenti, non solo sono fuori dalla mia 
"confort zone", ma ti mando a quel paese senza se e senza ma.
 
Ciao,
Marco


Motivazioni economiche a parte....
 
Fra quelle elencate la n.4 (Non onorano i loro impegni)
e', a mio avviso, ragione PIU' CHE  SUFFICIENTE per licenziarsi.
 
 
ciao
fm
 
 
 

 stavo leggendo questo:
<...>
 
E stai cercando di confutare quanto scritto in quell'articolo, sulla base della tua esperienza personale?
 

 ti mando a quel paese senza se e senza ma.
 
LOL :)
 
-- 
Al3xI98O
«L'importante non è cadere, ma sapersi rialzare»

 tale da spingerlo a lasciare il lavoro (o meglio a lascire "quel capo").
 
Ecco:
 
1. Troppo lavoro
No, mai (sbagliando col senno di poi ma tant'è)
 
2. I manager non riconoscono il prezioso apporto dei dipendenti e non 
premiano il lavoro ben fatto
No, mi aspetto (ingiustamente spesso) solo lo stipendio quindi se 
arriva un "grazie" o altro premio ok, altrimenti non mi sparo
 
3. Non si preoccupano dei loro dipendenti
LOL, no
 
4. Non onorano i loro impegni
Mai successo ma sarebbe un motivo
 
5. Assumono e promuovono le persone sbagliate
Mai successo ma sarebbe un motivo
 
6. Non lasciano che le persone seguano le loro passioni
E' uno dei (non il solo) motivi dei miei due ultimi cambi di lavoro
 
7. Non riescono ad enfatizzare le abilità dei dipendenti
8. Non sanno stimolare la creatività del dipendente
9. Non stimolano gli impiegati sul piano intellettuale
Magari da soli no ma in un ambiente problematico pesano


 punto 9.("Non stimolano gli impiegati sul piano intellettuale")
 
Il combinato disposto di queste quattro rende un lavoro molto pesante per me.
Ciao


No.
 
Ciao,
Marco.

4ndre4 in data mercoledì, 06/01/2016 ha detto:

E' vero che non un un bel rapporto con Marcoxxx, è vero che tende a 
fare statistica con la sua esperienza ed è sempre vero che 1 esperienza 
non può fare statistica...
 
però uno può dire la sua basandosi sulla propria esperienza ovviamente 
senza pensare che tutto funzioni come capita a noi :)


 per evitare che si passasse alle mani ;-(
 
Avevo un cliente così. Un giorno dovevo andare e mi chiama la 
segretaria: "guarda... è meglio che oggi non passi perchè volano cose!"


 a me di avere pacche sulla spalla non me ne e' mai fregato una cippa.
 
Il riconoscimento della qualità del lavoro svolto è sempre stato uno dei 
problemi classici nella professione dell'informatico. 
 
Nessun riconoscimento => motivazione che scende.
 
-- 
Soprano

 però uno può dire la sua 
 
Interessante.

4ndre4 in data giovedì, 07/01/2016 ha detto:

Vero?



 
 
hai detto bene, Soprano, ma sta sicuro che questo è un problema classico
non solo dell'informatica.
In generale, per tutti quei lavori che sono considerati poco è così,
evidentemente per forza di logica: se non fosse così, non sarebbero
considerati poco, mi sembra tautologico.
 
E bada bene che non parlo solo di riconoscimenti economici, ma anche "umani",
del tipo che se io faccio un lavoro magari non esplicitamente richiesto
ma che può giovare in modo significativo, magari il fatto che possa
giovare non se lo caga nessuno, e la gente pensa che ho semplicemente
fatto una cosa inutile.
 
 
ma sai che cazzo ti dico, Soprano?
Che ciò nonostante la mia motivazione non scende, perché io continuerò
lo stesso a fare quel tipo di lavoro che gli altri vedono come una
perdita di tempo.
Anche perché, checché ne dica il resto del mondo, per me non sono affatto
perdite di tempo, perché in genere sono delle utility che mi facilitano
di molto la vita.
 
Magari ci metto mezza giornata a scrivere la mia utility, ma poi, una volta
che l'ho scritta, delle operazioni che sono necessarie e che normalmente
sono  piuttosto lunghe o complicate diventano molto più veloci da fare,
e allora alla fine chi è che ha perso più tempo?
 
Naturalmente tutto questo non toglie che sono sempre disponibile a
condividere il mio "lavoro inutile" con gli altri, nel caso ritenessero
che a loro possa essere utile, e mi rimane la soddisfazione di essere
riuscito a semplificare dei processi complicati.
 
 
 
Ti porto un paio di esempi concreti, in modo da comprendere di cosa
sto parlando, e li scrivo in post separati per evitare di scrivere
post troppo lunghi.


 
 
Primo caso:
diversi mesi fa mi hanno messo a lavorare su un progetto che stava in
una VM linux, che io facevo andare sul mio PC Windows.
Era un progetto molto complicato, composto di decine di sotto-progetti,
e per fare build e deploy del progetto ci volevano diversi passaggi,
non particolarmente complicati ma abbastanza lunghi e noiosi.
 
Ebbene, io ho pensato bene di definire dei files e degli script shell
per automatizzare tali passaggi, in modo che alla fine bastava aprire
il terminale ed eseguire determinati alias per fare build o deploy
dell'applicazione.
 
 
C'ho messo parecchio tempo a mettere in piedi questo meccanismo, ci sono
voluti giorni di lavoro, ma alla fine il risultato l'ho ottenuto, e le
build e i deploy erano molto più veloci da fare.
 
Ma non c'è stato verso di convincere i miei colleghi che lavoravano
allo stesso progetto che io avevo fatto un lavoro
sì lungo, ma che alla fine mi ha semplificato la vita non poco.
 
Loro continuavano a dire che era stata una perdita di tempo.


 
 
secondo caso:
 
Qualche tempo fa ho lavorato su un progetto in cui ricevevo le
specifiche in fogli excel.
Gli excel contenevano dei fogli con la caratteristiche delle tabelle
del db, e noi dovevamo definire delle entity in xml (che corrispondevano
alle tabelle del db) a partire da queste specifiche.
 
Siccome spesso le entity da definire erano molte, e anche piuttosto
lunghe, a un certo punto ho pensato bene di scrivere una classe java
che legge l'excel con le specifiche, e da quello compone il codice
xml che alla fine deve essere prodotto.
 
Questa soluzione richiedeva comunque del lavoro manuale, ma molto
meno rispetto allo scrivere a mano l'xml, dato che le entity con i
campi e le pk (e anche parte della definizione delle fk) venivano appunto definite in automatico.
 
 
Anche qui, ci ho messo una mezza giornata a scrivere la classe, ma
poi non so quanta definizione di xml a mano ho risparmiato...
 
Ho condiviso la mia soluzione al resto del team, ma tutti hanno fatto
come se nulla fosse stato.
 
 
Ma la mia motivazione non è scesa, né nel primo caso né nel secondo,
perché so di avere fatto un lavoro che mi ha semplificato non poco
lo svolgimento delle mie attività, e questo mi basta.
 

 post troppo lunghi.
 
Letto gli esempi... E quindi ne scaturisce una semplice domanda:
ma i tuoi colleghi vengono pagati con gaudio e benemerenza
dall'amministrazione dell'azienda? :-D
 
 
 

 telefoni, poltroncine, lampade e tutto quanto gli capitava sottomano;
 
io ne ho lasciti un paio che non urlavano, ma erano chiaramente affetti
da qualche turba psichiatrica (quale non lo so, non sono uno psichiatra,
ma qualcosa nella loro mente non funzionava). Pero' urlavano e non 
scagliavano niente, anzi erano piu' silenziosi della media, il che 
immagino che renda il loro problema mentale ancora piu' grave 
(sicuramente aggrava
la situazione di quelli che gli stanno intorno, perche' finche il 
problema non si manifesta non ti rendi conto che ce l'ha e il tipo lo 
consideri normale, anzi forse anche dei meno peggio; quindi possono 
passare anni prima che tu te ne accorga. Quello che scaglia le sedie 
invece si vede subito che e' meglio stargli lontano).
 
Ciao,
Marco.
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 "le persone non lasciano il posto di lavoro, lasciano il loro capo".
 
Si può riassumere tutto con il detto:
 
"Il pesce puzza dalla testa"
 
 


Un makefile (o quello che e') per la build di un progetto e' normale
Se un progetto non l'avesse riterrei degli incompetenti i progettisti.
 

 tale da spingerlo a lasciare il lavoro (o meglio a lascire "quel capo").
 
sarebbe anche interessante capire se a qualcuno è capitato di commettere
qualcuno di questi errori, al punto di spingere (o contribuire a spingere)
qualcun altro a lasciare il lavoro.
perché non importa essere dei manager per essere buoni o cattivi capi 
di qualcuno. 
 
io ad esempio ammetto mi sia capitato. non ho la certificazione di essere
stato la causa, ma so di aver commesso errori. 
 
ho letto un po' tutto il thread e mi sembra un convegno di ultime ruote
del carro. dubito fortemente sia così. penso invece sia la tendenza di
tutti a riconoscersi solo nelle situazioni in cui si è al centro del
diritto.
 
peccato, sarebbe un punto di vista diverso diverso dal solito lamentarsi
delle vessazioni e renderebbe la discussione interessante.


 
 
ovviamente io non volevo insinuare una cosa del genere.
Volevo solo sottolineare che spesso succede che quando uno
fa un'attività che non è esplicitamente richiesta, ma può
essere lo stesso utile, gli altri, invece di cogliere l'utilità,
la vedono come una cosa inutile per il semplice fatto che non
è richiesta, e quindi invece di usare il tempo a fare quello che
è esplicitamente richiesto lo hai usato in altro modo.
 
Insomma, guai uscire un attimo dagli schemi, nemmeno per fare qualcosa
che può giovare un domani (non tanto lontano).
Sono convinto che questa mentalità sia abbastanza frequente.
 


 
 
insomma, diciamo che dipende.
Può essere utile se il processo di build/deploy richiede passaggi
un po' complicati, tipo degli script molto lunghi, con delle
variabili.
In questo caso definire per bene il comando in un file e poi
richiamarlo con un semplice alias è molto comodo, e ho visto che
in ambiente linux questa cosa si fa agevolmente.
 
Ma se la build non ha passaggi e non richiede script particolarmente
complicati può anche bastare un semplice documento di istruzioni
che dice come fare.
 


I progetti sono tutti abbastanza complessi da richiedere un make od un 
installer ecludendo gli script ovviamente
 
Anche per un semplice helloworld in C o java ci vogliamo mettere almeno 
un makefile ?
 
O credi che ci prende in mano quel programma sia nella testa dello 
sviluppatore ?
 
 

 Loro continuavano a dire che era stata una perdita di tempo.
 
Il punto è molto semplice per giudicare se è stato o meno una perdita di tempo: in quanto tempo recuperi l'investimento?
Se prima ci mettevi, poniamo, 10 minuti per fare la build ed ora ce ne metti 4, mentre per ottenere questo risultato ci hai investito 2 giorni di lavoro la cosa è parecchio opinabile a meno che tu non facciate 10 build almeno al giorno.
 
Scusa una cosa: ma chi ti ha autorizzato a farlo?
 
Ciao
  Francesco 

 
 
 
 
nessuno.
Come ho detto, era un periodo che avevo tempo a disposizione.
E comunque non è che chiedo l'autorizzazione per fare degli
automatismi, anche perché era tutto nel mio ambiente locale.

 Scusa una cosa: ma chi ti ha autorizzato a farlo?
 
La sua coscienza di bravo sviluppatore?
 

 Sono convinto che questa mentalità sia abbastanza frequente.
 
Ed è disastrosa, aggiungerei.
 
 
 


Hai fatto bene.
 

 come se nulla fosse stato.
 
Questo vuol dire solo una cosa: lavori in mezzo a un branco di imbecilli.
 
 

 che dice come fare.
 
ma dai.


oddio, dopo aver letto alcuni passaggi vorrei vedere la soluzione prima
di giudicare.

 è esplicitamente richiesto lo hai usato in altro modo.
 
in effetti, se ti viene esplicitamente richiesto di fare qualcosa e tu usi
il tempo destinato in altro modo è possibile che qualcuno non la prenda
bene.
te dici: ma io faccio qualcosa che torna utile agli altri. ma se ti hanno
chiesto di fare un'altra cosa sarà che gli sarebbe tornata più utile
quella? ti torna?
 
 

 Scusa una cosa: ma chi ti ha autorizzato a farlo?
 
a proposito di comportamenti del capo che ti inducono ad andartene,
ti posso dire che a me domande come questa facevano imbufalire
non poco (ed ecco un motivo per cui ho sempre preferito  contratti di lavoro
autonomo). Anche al punto di andarmene, se l'atteggiamento di chi
faceva questo tipo di domande era reiterato e portato a conseguenze
estreme
 
 
Se tu chiami un informatico a sviluppare un software, e' lui l'informatico
(cioe' il professionista) e lui sa gli serve un build automatico o no 
e se la sua realizzazione e' una perdita di tempo o meno. Se pensi che non lo
sappia non lo prendere a lavorare da te. E se pensi che abbia perso troppo tempo
a sviluppare l'automazione del build caccialo. Ma non gli rompere gli
zebedei con il fatto che non lo puo' fare se non lo hai autorizzato.
 
Nel mio caso poi, visto che nei contratti di lavoro autonomo c'era scritto 
che il lavoro era "senza vincolo di subordinazione"
ecco che domande come quella  denotava anche una palese violazione degli accordi
contrattuali che avevo all'epoca 
(se sono autonomo non prendo ordini da nessuno, tanto meno da uno con
cui non ho un contratto  [il mio contratto era con
la b.r. fornitrice].
Mi autorizzo da solo, perche' sono in grado di fare quel lavoro 
[spesso a differenza di quelli che vorrebbero autorizzarti]). Se ritieni che
non sia in grado di farlo, chiedi al titolare della b.r che ti mandi un altro
al posto mio.
 
 
Non so se domande del tipo di quella da te fatta siano riconducibili a 
qualcuno dei difetti dell'articolo linkato nel post iniziale, ma 
reiterare comportamenti di questo tipo (pretendere di autorizzare qualcuno
a fare qualcosa quando tu non hai alcuna autorita' per autorizzare nessuno) 
e' stato in un certo senso il motivo principale per cui me ne sono andato
da Ericsson (in realta' la cosa e' arrivata a livelli del tutto folli
con un c****one di dirigente Ericsson che praticamente pretendeva 
di essere lui ad autorizzarmi o meno ad avere un certo tipo di contratto
con la b.r. sua fornitrice [un po' come se mi avesse detto "chi ti ha
autorizzato a firmare un contratto di lavoro autonomo con il mio fornitore?",
tra l'altro non dicendomelo esplicitamente ma mettendo in piedi una
pantomima degna dei film di Fantozzi])
 
 
Ciao,
Marco
 

 contrattuali che avevo all'epoca 
 
eh?
rispettare le specifiche di un progetto mica è subordinazione.
tu avevi facoltà di svolgere le attività commissionate in autonomia, ma
sempre le attività commissionate. mica fare quello che ti pareva.

 quella? ti torna?
 
Mi sembra ovvio che se qualcuno di assegna un tot di tempo per il task A, e tu in quel tot di tempo fai tutt'altro, la tirata d'orecchie te la meriti. Se, invece, tu utilizzi ritagli di tempo, overtime, o tempo personale, per ottimizzare il processo aziendale, la cosa non puo` che essere vista bene. Il problema e` che in molte aziende ci sono persone abituate a routine manuali, e per le quali qualunque cambiamento alle proprie abitudini e` una fatica erculea.

se ha delle idee ben vengano le proposte[...]
 
Mi sembrava che il problema fosse appunto il "ben vengano". Lui le proposte le ha fatte, ma non sono state accettate. Personalmente, non andrei mai a lavorare per un'azienda che non ha un processo di build formale (le domande durante il colloquio servono anche a capire come l'azienda lavora e se ti troverai bene li`), ma se, per qualche motivo, mi rendo conto che un qualunque processo lavorativo ha dei difetti, io mi impegno per proporre la mia soluzione al problema, nel rispetto dell'ecosistema in cui mi trovo a lavorare. A quel punto, di fronte a dei problemi nel modo in cui l'azienda lavora, e a fronte di una soluzione valida per quei problemi, se si fa resistenza, bisogna avere dei motivi piu` che validi.

 Mi sembra ovvio che se qualcuno di assegna un tot di tempo per il task A, e tu in quel tot di tempo fai tutt'altro, la tirata d'orecchie te la meriti. 
 
in questa discussione non sembra tanto ovvio, visto che ha scritto esattamente
questo.

 Mi sembrava che il problema fosse appunto il "ben vengano". Lui le proposte le ha fatte, ma non sono state accettate. 
 
magari non erano accettabili. voglio dire, da una persona che scrive:
 
"Ma se la build non ha passaggi e non richiede script particolarmente
complicati può anche bastare un semplice documento di istruzioni
che dice come fare"
 
posso anche aspettarmi che non sia un portatore di idee rivoluzionarie.

 zebedei con il fatto che non lo puo' fare se non lo hai autorizzato.
 
Sono assolutissimamente e universalmente d'accordo.
 
 


 
Per l'ultima frase, se ho capito bene, il tizio non aveva
scritto una sua soluzione da far
usare obbligatoriamente a tutti gli altri o
che andasse in conflitto con quelle degli altri.
Aveva scritto la sua soluzione che semplificava la vita
*a lui*, senza incidere sul lavoro degli altri(e tra l'altro in assenza
di soluzioni aziendali alternative, mi pare di capire).
E solo lui puo' decidere cosa gli semplifica la vita e cosa gliela complica.
 
Per il resto vedila cosi': sostituiamo per un attimo "informatico" con
"libero professionista".
Se chiami un libero professionista l'obiettivo di
quest'ultimo non puo' essere quello di integrarsi in un team di altri. 
Quello semmai e' un mezzo per raggiungere l'obiettivo.
L'obiettivo del libero professionista  e' portare a termine *quel* 
progetto. Altrimenti non ha senso chiamare un libero professionista.
 
A mio modo di vedere lo stesso discorso dovrebbe valere se prendi
un informatico da una b.r., anche se fosse subordinato(e a maggior 
ragione se e' un libero professionista che viene da te tramite b.r.).
 
Puo' darsi che se chiami un informatico e lo prendi come tuo
subordinato il suo obiettivo principale  debba essere quello di 
prolungare al massimo la vita dell'azienda per cui lavora, per cui la 
realizzazione del progetto in se' puo' forse passare in secondo piano 
rispetto all'integrazione con gli altri.
 
Io pero' mi sono sempre sentito "libero professionista" per cui
facevo fatica a considerare prioritari aspetti diversi dal
portare a termine il progetto, sebbene non abbia mai avuto grossi
problemi con l'integrazione nel team [tranne una volta per la verita']. 
I problemi al limite li ho avuti con i dirigenti.
 
Ciao,
Marco.

 "libero professionista".
 
ma anche no. sostituiamolo invece con "membro di un team", che nel 99,9% dei
casi è la situazione in cui un programmatore lavora. 
 
il resto del discorso sui distinguo contrattuali sono argomenti che in questo
contesto non li trovo ne pertinenti ne interessanti.
 

 questo.
 
Non credo fosse quello il senso. Non credo nessuno sia cosi` stupido (be`, a giudicare dagli interventi in questo ng, effettivamente c'e` da dubitarne) da utilizzare il tempo richiesto per un task, per fare altro. Credo invece lui volesse dire che stesse integrando la sua attivita` con un miglioramento della situazione. Insomma, se uno ti chiede il fix di un bug che blocca il rilascio di una release, e tu rispondi "'sti cazzi del bug, ma guarda che bel sistema di indentazione dei sorgenti ho trovato!" e` ovvio che sei un cazzone. Se, invece, fixi il bug come prima cosa e, in piu`, migliori il sistema, e` diverso.
 

 zebedei con il fatto che non lo puo' fare se non lo hai autorizzato.
 
Te Marco il concetto di lavoro di squadra e gestione delle priorità non sai manco dove abita vero?
 
Ciao
  Francesco


 
 
io non pretendo che il mio lavoro fosse senza macchia, ma a mio avviso
non sarebbe male se l'interlocutore di turno avesse l'umiltà di
evitare di giudicare qualcosa che non ha visto con i suoi occhi.
 
 
Ma ormai sono rassegnato, so che questo qui non posso pretenderlo....


 
 
 
infatti è proprio così.
Meno male che esiste ancora qualcuno che legge quello che scrivo, e non
quello che fa comodo a lui anche se diverso da quello che scrivo.
 
 
Il mio obiettivo, in entrambi i casi, era quello di ridurre la fatica,
nonché di ridurre il lavoro "da asini", cioè il copia e incolla da fare
centinaia di volte, nonché la sequenza di operazioni manuali che non 
finivano più, e che potevano essere automatizzate.
 
Ma è stata una cosa che ho fatto solo per me, senza chiedere niente
a nessuno e senza obbligare nessuno a far nulla, rendendomi solo
disponibile se gli altri pensavano potesse essere utile anche a loro.
 
 
 
Del resto, io la vedo così, non concepisco perché devo fare continuamente
del lavoro asinino quando la programmazione mi dà la possibilità
di scrivere degli algoritmi che fanno parte del lavoro manuale al posto
mio.
Questo detto in generale.

 "le persone non lasciano il posto di lavoro, lasciano il loro capo".
 
Ni, accusare il "capo" è riduttivo.
Ad esempio, alle volte l'ambiente viene reso tossico da una particolare persona che contagia il resto del team, creando un malessere condiviso e non curabile neanche rimuovendo la persona che ha reso tossico l'ambiente. E' vero che il capo dovrebbe rendersi prontamente conto di chi sta intossicando l'ambiente, ma non sempre è possibile, e alle volte succede che la persona "tossica" è fondamentale e non arginabile, e viene agevolata rispetto agli "intossicati" perché ritenuta indispensabile. La cruda realtà è che gente valida può venire sacrificata per accondiscendere gente ritenuta indispensabile. E' un modo di fare cinico, ma purtroppo l'ho visto applicato in più circostanze, ed è devastante su persone che si credono molto più necessari & indispensabili di quanto il capo non li reputi.
 
In realtà basterebbe una buona dose di intelligenza emotiva per evitare situazioni del genere, e i "nove errori ricorrenti" dell'articolo che citi.


 
 
ti spiace essere un po' più chiaro?
Cosa intendi esattamente con "persona che contagia il resto del team",
che crea un malessere così grave da non poter rimediare neanche rimuovendo la persona?
Hai forse esempi pratici presi dalla tua esperienza?
 
Sono curioso.

 Questo detto in generale.
 
Infatti è un compito fondamentale dell'informatica.
 
Informatica: trattamento *automatico* dell'informazione.
 
 

 Hai forse esempi pratici presi dalla tua esperienza?
 
Ne ho quanti ne vuoi. Quello che avevo in mente mentre scrivevo era di un collega di 5-6 anni fa, non nel mio team sebbene sedeva nel nostro open-space, molto preparato ma non aveva voglia di lavorare. Faceva il doppio gioco coi suoi superiori, arrivava a lavoro 5 minuti prima del capo e andava via 5 minuti dopo il capo, e lavorava solo quando il capo era nei paraggi. Era il beniamino del capo: il capo era stato suo docente in università, ed era stato studente modello. A lavoro però faceva poco o nulla, e veniva esaltato per quel poco che faceva, sinché gli altri del gruppo iniziavano a chiedersi se ne valesse la pena impegnarsi (tanto il furbetto riusciva a prendersi i meriti), e si era sparsa una buona dose di indolenza, con un calo di produttività del gruppo, con una conseguente insoddisfazioni delle dirigenze, produttività che era difficile da sanare nel breve periodo, tanto da costringere le dirigenze a ristrutturare tutto il team, e la prima testa che saltò fu proprio quella del capo, seguito da altre persone molto più produttive del furbetto (che comunque andò via subito dopo).
 
Ma ci sono anche tanti altri esempi, lungo descriverli tutti.

 ha scritto:

e quindi C.V.D. si torna sempre all'origine:
 
"Il pesce puzza dalla testa"
 
 

 finivano più, e che potevano essere automatizzate.
 
perdona la curiosità, ma da voi quando fanno i deploy in produzione le
build le fanno in questo modo?
potresti avere vita facile se tu puntassi invece che sulla minor fatica
sulla qualità dei deploy, che da voi devono avere le sembianze di una
partita a dadi.

 "Il pesce puzza dalla testa"
 
Era un esempio di come un singolo individuo puo' mandare a donnine allegre il team. Ovvio che -nel bene e nel male- il capo ha le sue responsabilita'.
Avendo io vissuto la vicenda nel quotidiano da osservatore esterno, ti posso assicurare che il furbetto aveva un'abilita' sovraumana nell'adoperare la lingua li' dove non batte il sole, e aveva logorato il fondoschiena del povero capo sino a deprivarlo di ogni sensibilita' e ad infilargli un travone di dimensioni fantasmagoriche :-)
 
Ma il furbetto era uno scalzacani, infatti non ha fatto molta carriera. Invece mi sono trovato ad assistere a casi in cui ad agire da "intossicatori" erano persone cruciali e indispensabili al team, ai quali veniva perdonato persino il tentare di rubare il lavoro dei colleghi. Un accenno di cazziatone benevolo per salvare la faccia, un'ammiccatina, e amici come prima. Anche qui il capo aveva le sue responsabilita', ma era oggettivamente vincolato a tenersi il TDC, e a doverlo trattare con riguardo. La gente andava via per non avere a che fare col TDC in questione, piu' che col capo.
 


 
ma non è che ci sia uno standard per i deploy, quel progetto in cui
ho fatto tutto quel lavoro di automatizzazione è un progetto molto
complesso, che è stato fatto in un certo modo.
Io non volevo mica cambiare il modo di fare deploy, volevo solo
mettere in piedi un modo per fare in automatico i vari passaggi
che altrimenti erano manuali, allo scopo di risparmiare tempo e fatica
a me stesso.
Tutto qui.
 
Ma se dovevo mettermi a cambiare modo di fare il deploy, campacavallo
in quel contesto, non ne uscivo più...
 

 in quel contesto, non ne uscivo più...
 
non ci pensavo proprio a che tu cambiassi la procedura di deploy. tu hai
parlato della build e io mi chiedevo chi deve fare la build per il deploy
come si comporta, se è vero che per fare una build sono necessarie tutta
una serie di operazioni manuali. lì non è questione di fatica ma di ottenere
una build *sicura* e *riproducibile*. 
 

 qualcun altro a lasciare il lavoro.
 
più che altro sarebbe interessante capire come non commetterne!
Proprio oggi sono incappato quasi per caso in questo bell'articolo: 
http://www.ncbi.nlm.nih.gov/pubmed/26402330
 
Ma c'è tutta una letteratura sull'argomento, basti soltanto andare su coursera e cercare la parola chiave leadership!


 
Cosa c'entra la gestione delle priorita' con quello che si discuteva
lo puoi sapere solo  te.
 
Se non sbaglio tu spesso hai parlato di Ericsson come ambiente da non 
prendere a modello. Io anche.
 
Ma da quanto sopra sembra di capire che anche tu faccia riferimento
alla cosiddetta "teoria dei gruppi", molto di moda in Ericsson qualche
anno fa.
 
Mi ricordi in particolare un tizio
che pretendeva che io arrivassi in azienda alle 10.00 anziche' alle 
8.00-8.30 come facevo allora (e come facevano anche altri),
in ossequio alla suddetta "teoria dei gruppi", "perche' dobbiamo 
lavorare in squadra".
 
Secondo me se  mandi un CV in Ericsson allegando questo post e il 
precedente, hai qualche probabilita' che ti
prendano come dirigente (e non capisco perche' a te non
piaccia quell'ambiente, visto che ragionano
[o almeno ragionavano] esattamente come hai
fatto tu in questo post).
 
Ciao,
Marco.

 tra lavorare in squadra e "rompere le p***e"
 
no sei tu che dagli esempi dimostri di non aver chiaro la differenza.
 
non si stava parlando del capo che entra nel merito dell'editor che usi
ma di uno sviluppatore che avrebbe creato una serie di non meglio precisati
automatismi per migliorare (a detta sua) il processo di build. processo 
che, converrai, in un team deve essere standardizzato, perché l'artefatto
che provi te deve essere uguale a quello che va in produzione, per ovvie
ragioni che non sto a spiegarti per non insultare l'intelligenza.
 
peraltro per quello che è emerso nella discussione nutro molti dubbi che
il nostro amico non abbia semplicemente perso del tempo a causa 
ad uno strumento (maven) che non sa usare. 
 
mettere le mani su questi processi non solo
è cosa da fare in modo coordinato, ma deve essere fatta da quelle persone
che meglio conoscono strumenti e processi: se vedo ad esempio che hai
buttato giornate di lavoro per automatizzare "il copia e incolla da 
ripetere centinaia di volte" perché non sapevi che i filtri di maven facevano
già questo lavoro, per di più non ho chiesto a te di farlo, è ovvio 
che m'incazzo.
 

 lavorare in squadra".
 
Marco come ti ho detto molte volte: non mettere agli altri in bocca parole non dette.
 
La gestione degli orari di presenza è tutt'altra cosa dalla gestione delle priorità.
 
Ciao
  Francesco