Il lato oscuro della forza - L'eterna lotta tra progettisti e team di sviluppo

Il lato oscuro della forza.L’eterna lotta tra progettisti e team di sviluppo

Roma 20 febbraio 2014

Alessio Ricco

Il lato oscuro della forza - Roma , 20 febbraio 2014

Di cosa parleremo esattamente ?

Vedremo alcune situazioni che sono “a rischio” nei rapporti tra designer, project manager e team di sviluppo !▪ Motivi per cui si generano incomprensioni !▪ Situazioni di polarizzazione

▪ Pregiudizi nei confronti degli sviluppatori


Come lo racconteremo ?

Da un punto di vista assolutamente di parte: il coder !▪ Come pensa ▪ Cosa è importante per lui ▪ Come si sente percepito in ufficio ▪ Come percepisce i suoi colleghi


A chi è rivolto questo webinar ?

A chi, almeno una volta ha sentito dire…

!▪ “Abbiamo le idee, ma loro sono un freno a mano, non

riusciamo a realizzarle nei tempi desiderati”

▪ “Ma che ci vuole a farlo? è una stupidaggine”

▪ “Il software da usare lo decidiamo noi, quelli dell’IT vogliono sempre avere l’ultima parola”


A chi è rivolto questo webinar ?

e soprattutto… !▪ “Ragazzi mi raccomando, siamo nelle vostre mani,

Buonanotte!”


Sospensione della incredulità

Per vedere le cose con i suoi occhi, occorre che sia lui, oggi, il nostro eroe.


Il lato oscuro della forzaMario Rossi - Sviluppatore

SEEING

SAYING

DOINGFEELING

HEARING



SEEING

SAYING

DOINGFEELING

HEARING

sta in un open space rumoroso, ma non sono i suoi colleghi a parlare ad alta voce

se possibile ascolta musica nelle cuffie mentre lavora

“è meglio non coinvolgere il reparto ICT perchè è troppo lento, ci blocca le attività, non è agile nelle decisioni”

viene interrotto da colleghi che chiedono qualunque cosa



SEEING

SAYING

DOINGFEELING

HEARING

vede il monitor

vede la sua scrivania disordinata e piena di junk food e cartacce



SEEING

SAYING

DOINGFEELING

HEARING

parla un linguaggio incomprensibile

parla di telefilm e cose pop molto di nicchia

ride o impreca da solo

RTFM!

LOL!



SEEING

SAYING

DOINGFEELING

HEARING

scrive una applicazione strategica per la società oppure installa driver e antivirus ai colleghi. oppure entrambe le cose. chatta con i colleghi. !



SEEING

SAYING

DOINGFEELING

HEARING

si sente frustrato. potrebbe fare di più ma all’azienda questo non interessa e lo impiegano male



SEEING

SAYING

DOINGFEELING

HEARING

vede il monitor

parla un linguaggio incomprensibile

parla di telefilm e cose pop molto di nicchia

sta in un open space rumoroso, ma non sono i suoi colleghi a parlare ad alta voce

se possibile ascolta musica nelle cuffie mentre lavora

ride o impreca da solo

vede la sua scrivania disordinata e piena di junk food e cartacce

scrive una applicazione strategica per la società oppure installa driver e antivirus ai colleghi. oppure entrambe le cose. chatta con i colleghi. !

si sente frustrato. potrebbe fare di più ma all’azienda questo non interessa e lo impiegano male

“è meglio non coinvolgere il reparto ICT perchè è troppo lento, ci blocca le attività, non è agile nelle decisioni”

viene interrotto da colleghi che chiedono qualunque cosa RTFM!

LOL!


Chi è uno sviluppatore ?

E’ tante cose, ma soprattutto ci interessa sapere che: !▪ E’ un problem solver

▪ E’ abituato a ragionare in modo logico utilizzando linguaggi formali e non ambigui

▪ Fa un lavoro creativo (anche se spesso non viene riconosciuto come tale)


Quali sono alcune delle cose importanti per uno sviluppatore ?

!▪ Riutilizzare il codice

(rendere il codice un bene aziendale, meno debug)

▪ Progettare classi, oggetti, basi di dati che siano versatili, documentati, espandibili(sono i suoi strumenti di lavoro)

▪ Impegnare il proprio tempo in cose creative (Il computer deve fare cose ripetitive, non chi lo programma)

▪ Concentrarsi su un problema alla volta

▪ e poi…


Quali sono alcune delle cose importanti per uno sviluppatore ?

… e poi… TEMPO! !▪ Tempo per il testing

▪ Tempo per il debugging

▪ Tempo per il refactoring

▪ Tempo per l’autoformazione


Cosa succede invece ?

!▪ Il testing non viene fatto

“come si deve” “io non devo testare il tuo codice” “abbiamo fatto i test,è pieno di errori, non possiamo pubblicarlo domani”



!▪ Il debug non è considerato

nella timeline del progetto“se devi fare il debug significa che hai lavorato male”



!▪ Il codice non viene mai riutilizzato perché nessuno sa che è

un risparmio di tempo“il team dei creativi deve essere libero di esprimersi e voi dovete fare quello che vi dicono di fare”



!▪ Continue interruzioni email, telefonate, colleghi che hanno problemi informatici di basso livello, ecc.. interruzioni che spesso non hanno filtro, non vengono considerate ‘attività lavorativa’ e soprattutto tolgono la concentrazione, il focus sui task



Non sempre è chiaro quale siano i compiti di uno sviluppatore

▪ Web Writer“Io non devo conoscere l’html, quella è una cosa da programmatori”

▪ HTML-ista “io non devo conoscere Javascript, quella è una cosa da programmatori”

▪ ACCOUNT “io non so fare i grafici su Excel, lo chiedo al programmatore”

▪ HELPDESK“Il cliente mi dice che non capisce come scrivere un post su wordpress, ci potete pensare voi?”


Forse c’è un equivoco

Organi di staff e organi di line

Gli organi di staff affiancano le line, cioè gli organi operativi veri e propri. Le line si avvalgono, nella loro attività direttiva, dello studio e della collaborazione di organi di staff, ovvero di specialisti che operano ad ogni livello nell’ambito della struttura organizzativa e il cui compito principale è quello di fornire servizi ai dipartimenti funzionali.Gli organi di staff sono, dunque, organi ausiliari la cui finalità è quella di favorire il raggiungimento degli obiettivi dell’impresa.


IT Team: staff o line ?

▪ I team IT sono spesso sia STAFF che LINE

▪ Spesso sono organi di staff degli organi di staff

▪ Spesso non è chiaro chi fa da STAFF al team IT Queste ambiguità spesso sono presenti in aziende piccole dove la versatilità rischia di sconfinare nella confusione


Avete mai visto….?

Un agente di vendita controllare se le gomme di tutte le automobili della flotta aziendale sono gonfie? !è difficile.. ma forse avete mai visto… !Un project manager andare a casa del suo capo a installare l’ADSL ? Un graphic designer andare a togliere i virus dal PC della segretaria di direzione ? !Uno sviluppatore essere in ritardo con la consegna e lavorare la notte ?


Perché gli sviluppatori sono così importanti nelle funzioni di staff?

Perché hanno una conoscenza a 360° di funzioni che interessano ormai quasi tutti gli ambiti di qualsiasi reparto di qualsiasi azienda.Perché sono dei problem solver e spesso questa loro “peculiarità” viene impiegata nel modo sbagliato.Per esempio: un IT risolve in 10 minuti una cosa che per altri suoi colleghi richiederebbe ore.Il problema è che un IT che risolve 6 problemi perde un’ora del suo tempo che talvolta è difficile giustificare (e spesso richiede un “fuori orario”).Spesso i suoi colleghi non sono responsabilizzati a gestire e prendersi cura dei propri strumenti di lavoro.


Burnout

La sindrome da burnout (o più semplicemente burnout) è l'esito patologico di un processo stressogeno che colpisce le persone che esercitano professioni d'aiuto, qualora queste non rispondano in maniera adeguata ai carichi eccessivi di stress che il loro lavoro li porta ad assumere.

Maslach e Leiter (2000) hanno perfezionato le componenti della sindrome attraverso tre dimensioni: - deterioramento dell'impegno nei confronti del lavoro - deterioramento delle emozioni originariamente associate al lavoro - un problema di adattamento tra persona ed il lavoro, a causa delle eccessive richieste di quest'ultimo. (http://it.wikipedia.org/wiki/Sindrome_da_burnout)

http://it.wikipedia.org/wiki/Sindrome_da_burnout


Verso la deadline

Gli sviluppatori spesso preferiscono lavorare quando possono sentirsi concentrati e tranquilli !

▪ Dopo l’orario di lavoro

▪ Il sabato

▪ Ad agosto !!!Questo è ovviamente un male e porta facilmente al burnout.


La compressione della Timeline

Il Team di sviluppo deve consegnare il prodotto entro la data prevista

▪ Spesso la data prevista è una deadline non contrattabile

▪ Potrebbero esserci stati ritardi nell’avvio dello sviluppo per cause non dipendenti dal team IT (lo sviluppo spesso sta alla fine di una filiera che coinvolge management, progettisti, reparto comunicazione, reparto creativo)

▪ Il progetto richiede più giornate di sviluppo di quelle a disposizione sul calendario

▪ Se questa situazione si verifica troppe volte durante l’anno, esiste un problema di cui l’azienda dovrebbe prendersi carico.


Cosa pensa il team di sviluppo ?

Molto spesso, le altre componenti aziendali che hanno partecipato al progetto (e hanno prodotto i ritardi) non sono responsabilizzate sul risultato di chi viene dopo di loro nel processo di produzione.

Molto spesso il project manager non partecipa alle nottate di sviluppo.



“Se abbiamo poco tempo, come faremo a testare il software ?”

“Come facciamo a evitare i bug se dobbiamo sviluppare anche la notte ?”

“Che succederà se falliamo la deadline ?”

“Perché dobbiamo fare sempre noi le notti ?”



“Ci hanno abbandonato”

vittimismo

Risultato: Perdita di fiducia nell’azienda, nel prodotto, nei propri superiori…


Il peccato originale

L’azienda spesso ignora il fatto che molte delle Best Practices tipiche dei team di sviluppo portano innovazione e crescita !▪ “Perché devo usare un sistema di ticketing quando posso fare il

forward di una email agli sviluppatori ?”

▪ “Perché fai il refactoring? Non potevi scriverlo meglio fin da subito?”

▪ “Io non ti devo testare il software, sei tu che lo devi fare bene”

▪ “Che ci fate in due davanti al computer?”

▪ “A che ci serve una libreria di css/html/codice ? sbrigatevi a terminare il progetto”


Parliamo dei suoi difetti (solo alcuni però)

Molti di questi difetti vengono spesso usati in azienda contro di loro !▪ Lo sviluppatore potrebbe voler dimostrare ad ogni costo che

è in grado di risolvere qualsiasi problema (inutile supereroe)



Molti di questi difetti vengono spesso usati in azienda contro di loro ▪ Lo sviluppatore potrebbe voler dimostrare a tutti che lui è

più bravo del suo collega (sviluppatore anche lui) o del consulente (competizione nel team)



Molti di questi difetti vengono spesso usati in azienda contro di loro

▪ Lo sviluppatore potrebbe illudersi che il suo datore di lavoro sia un mecenate e lui un artista (perdita della vision)



Molti di questi difetti vengono spesso usati in azienda contro di loro !▪ Lo sviluppatore potrebbe credere di essere migliore dei suoi

colleghi, possibilmente tutti (delirio di onnipotenza)


Il senso di colpa

La frustrazione del problem solver è il BUG !▪ In azienda il bug è vissuto con senso di colpa

▪ Il più delle volte, i bug sono inevitabili nel processo di sviluppo, quindi

occorre un atteggiamento “maturo”

▪ Molti dei bug dipendono anche dal fatto che il tempo per il debug o una figura professionale adeguata (Debug Engineer) spesso sono sottostimati o non contemplati

▪ Anche altri settori aziendali fanno errori, ma nella produzione del software spesso sono macroscopici, altrove possono essere nascosti, o considerati meno importanti

▪ Non è nemmeno accettabile che il Team IT minimizzi o nasconda i bug gravi.


It’s a feature, not a bug

Spesso occorre che Sviluppatore, Designer e Project manager concordino su cosa è un bug e… !▪ Una feature richiesta e poi diventata obsoleta

(“il software non va bene, devi togliere questa funzione”)

▪ Una feature documentata in modo ambiguo(“quando seleziono ‘tutte le qualifiche’ devo mostrare le righe dove “qualifiche” vale null?”)

▪ Una feature introdotta dallo sviluppatore (“l’ho fatto così perché nessuno mi ha detto come farlo”)

▪ Una feature non detta “lo davo per scontato…”


It’s a bug, not a feature

Spesso occorre che Sviluppatore, Designer e Project manager concordino su cosa è una feature e… !▪ Una modifica che provoca delle contraddizioni logiche

nell’architettura del software

▪ Una modifica che non tiene conto di alcuni vincoli progettuali

▪ Una modifica che mette a rischio il raggiungimento della milestone

▪ Una modifica che trasforma un prodotto in una versione “custom” (il team è attrezzato per fare la manutenzione di N versioni custom dello stesso codice sorgente?)

▪ Una cosa che nessuno userà mai ma richiede tempo per essere sviluppata


Vogliamo problemi, non soluzioni

Altra situazione a rischio è quando lo sviluppatore non è incaricato di risolvere un problema ma è incaricato di eseguire una soluzione spesso pensata da personale non IT (per esempio un account)


Vogliamo problemi, non soluzioni

Altra situazione a rischio è quando lo sviluppatore non è incaricato di risolvere un problema ma è incaricato di eseguire una soluzione spesso pensata da personale non IT (per esempio un account) !Esempio: “Ho parlato con il cliente e ti ho disegnato le maschere”

“Devi farmi una applicazione che ogni volta che premo un tasto si collega su quel sito, fa il parsing della pagina ed estrae le notizie. Una volta estratte le notizie le ripulisce dai corsivi e dai grassetti e me le archivia su una pennetta usb” Questa situazione è rischiosa perché lo sviluppatore non sta parlando con un vero designer e soprattutto si sente sottovalutato (da qualcuno che evidentemente non conosce i feed RSS) e quindi sottoimpiegato.


Come fare allora?

Visione di gruppo: !• Evitare il più possibile i “compartimenti stagni”Avere ruoli e responsabilità chiare e ben definite per reparto e per singolo !

• Che ruoli e responsabilità siano chiari e noti a tutti gli attori !

• Rendere noti e partecipi tutti gli attori della vision aziendale


Come fare allora?

Dentro l’azienda: !Coinvolgere gli sviluppatori in tutte le fasi del processo !se ci sono problemi “linguistici” utilizzare un “mediatore culturale”, cioè una figura che possa rapportarsi sia con personale IT che con personale non IT, che sappia illustrare con semplicità eventuali “criticità” tecnologiche del progetto, comprendere le esigenze del cliente e riportarle al Team IT avendo l’autorevolezza per potersi confrontare con gli sviluppatori.


Come fare allora?

Fuori dall’azienda:Coinvolgerli con moderazione negli incontri con il cliente(Lo sviluppatore va allineato con venditori, project manager, account, etc per evitare situazioni spiacevoli e fraintendimenti) Esempio:Di fronte al cliente viene chiesto allo sviluppatore se una certa feature può essere realizzata e lo sviluppatore dice “no”.


Come fare allora?

Sviluppatori vs Progettisti

Il progettista non sempre può permettersi di progettare pensando che il tempo a disposizione degli sviluppatori sia infinito. A volte il team IT può dare dei suggerimenti che permettano di riutilizzare il codice Il graphic designer può interpellare il team di sviluppo per sapere con quanta fedeltà il templare grafico può essere riprodotto

Lo sviluppatore puo’ aiutare i designer a documentare meglio il loro lavoro


Come fare allora?

Esempi:

Il mockup è perfetto ma i testi con il Lorem Ipsum non tengono conto che nel caso reale i contenuti potrebbero avere lunghezze diverse che “rompono” l’interfaccia.Il mockup della form non tiene conto di eventuali interdipendenze tra i campi, eventuali validatori, tooltip, tipi di campo, database con tabelle di lookup preesistenti e di cui occorre tenere traccia. Il progettista non ha tenuto conto del fatto che una dropdown in una particolare potrebbe contenere fino a 10000 voci e il team di sviluppo aveva già un componente per gestire questo tipo di casi


Come fare allora?

Creare manuali, documentazione, guidelines, librerie che siano patrimonio comune di tutti i reparti coinvolti nella progettazione e nella produzione del software


Come fare allora?

• Aumentare la comunicazione interdipartimentale !

• Evitare di creare competizione e rivalità tra reparti

• Team building, co-design, facilitazione, hackaton interni

• Non mortificare il bisogno di innovazione (impedirlo a chi si occupa di tecnologia non ha senso)

• Cultura del cambiamento


Soprattutto

• Ogni azienda viene modellata dal suo management, dalla sua vision, dalla sua cultura.

• Se l’IT non è parte della cultura aziendale avrà sempre ruoli marginali

• Se l’azienda opera online, necessita di strumenti IT, ha dei centri EDP deve risolvere al più presto questa contraddizione. come ?

• Figure intermedie che abbiamo autorevolezza presso i team IT


Soprattutto “Avere fede nella forza del lavoro di gruppo”


Disclaimer & Credits

Star WarsImages included in or linked from this page are copyright Lucasfilm Ltd. and are used here under Fair Useage terms of copyright law.

Geek & Poke licensed under a Creative Commons Attribution-NoDerivs 2.0 Licensehttp://geek-and-poke.com/

Alessio Ricco@alessioricco http://www.linkedin.com/in/alessioricco

http://geek-and-poke.com/

http://www.linkedin.com/in/alessioricco


…e sopratutto

NON E’ STATO MALTRATTATO ALCUNO SVILUPPATORE PER LA REALIZZAZIONE DI QUESTE

SLIDES

Il lato oscuro della forza - L'eterna lotta tra progettisti e team di sviluppo

Leadership & Management