Un progetto parte quasi sempre dalla stesura di un documento di specifiche chiamato brief.
Il brief dovrebbe contenere tutte le informazioni relative all’azienda e al progetto: tempi, obiettivi prefissi, statistiche, idea, competitor… Dovrebbe facilitare le decisioni aziendali e le spiegazioni ai fornitori. È il frutto di diverse giornate o settimane di lavoro da parte degli uffici marketing e/o tecnici interni all’azienda, richiede diversi incontri con il management per approvazione/assegnazione del budget e altri incontri con i fornitori dei servizi, per spiegare il progetto e chiedere un preventivo di esecuzione.
Ma avete mai provato a riprendere in mano il brief a progetto realizzato e a confrontare l’idea con il progetto finito?
In questo talk smontiamo alcuni miti sul brief e proviamo a capire come CTO, CMO e partner/fornitori possano farlo diventare il vero step 1 del progetto.
È possibile che le aziende coinvolte scrivano il brief insieme, partecipando all’analisi dell’idea e individuando le informazioni davvero utili?
E se fosse il fornitore a guidarvi nella stesura delle soluzioni tecniche?
Se già il brief mettesse l’utente al centro del processo?
Lean prototyping al servizio del designerLuca Scarpa
Slide sul lean prototyping ed esercizi per fa emergere il valore della prototipazione e la facilità di realizzazione di uno strumento per ottenere feedback sprecando poco.
Quanto conosciamo i nostri utenti | Italian Agile Day 2018Emanuele Mantovani
Le slide del mio talk allo IAD 2018 "Quanto conosciamo i nostri utenti"
Generare valore per l’utente finale è un elemento fondamentale per il successo di un software. Ma siamo davvero sicuri di conoscere i nostri utenti? Quali strumenti abbiamo a disposizione per conoscerli e formulare ipotesi corrette e quali metriche possiamo utilizzare per validare e misurare il valore dei nostri prodotti per l’utente finale? Attraverso esempi concreti scopriremo come lo UX Design possa aiutarci a rispondere a queste domande e come possa integrarsi in un contesto agile.
Un progetto parte quasi sempre dalla stesura di un documento di specifiche chiamato brief.
Il brief dovrebbe contenere tutte le informazioni relative all’azienda e al progetto: tempi, obiettivi prefissi, statistiche, idea, competitor… Dovrebbe facilitare le decisioni aziendali e le spiegazioni ai fornitori. È il frutto di diverse giornate o settimane di lavoro da parte degli uffici marketing e/o tecnici interni all’azienda, richiede diversi incontri con il management per approvazione/assegnazione del budget e altri incontri con i fornitori dei servizi, per spiegare il progetto e chiedere un preventivo di esecuzione.
Ma avete mai provato a riprendere in mano il brief a progetto realizzato e a confrontare l’idea con il progetto finito?
In questo talk smontiamo alcuni miti sul brief e proviamo a capire come CTO, CMO e partner/fornitori possano farlo diventare il vero step 1 del progetto.
È possibile che le aziende coinvolte scrivano il brief insieme, partecipando all’analisi dell’idea e individuando le informazioni davvero utili?
E se fosse il fornitore a guidarvi nella stesura delle soluzioni tecniche?
Se già il brief mettesse l’utente al centro del processo?
Right here, right now: come capire e intercettare i momenti cruciali di un’es...Ilaria Mauric
Talk presentato al Web Marketing Festival 2016, a Rimini.
--
Framing, research, codesign, prototype, test sono le 5 fasi del processo di UX design.
In questo talk abbiamo visto come applicarle ai contesti di utilizzo in mobilità.
Abbiamo visto anche i principali tool che ci aiutano a descrivere la complessità di un’esperienza digitale, evidenziare i momenti e le emozioni cruciali e a progettare i flussi della ux.
Questo processo e questi tool ci guidano nel cogliere le opportunità e nel trovare risposte ai bisogni reali, nei luoghi, nei momenti e dai device giusti.
Quo vadis P.O.? Metriche UX per misurare il valore rilasciato.Emanuele Mantovani
In ogni progetto che affrontiamo non abbiamo risposte certe, abbiamo ipotesi da validare il prima possibile con gli utenti. Una serie di strumenti e metriche UX possono aiutare il P.O. e il team a misurare, iterazione dopo iterazione, il valore prodotto per l’utente finale. In questo talk mostro attraverso alcuni esempi come è possibile misurare il valore rilasciato in un progetto Scrum, identificando i pain point che affliggono l’esperienza utente e trovando soluzioni efficaci con tutto il team.
Come ridurre il rischio di fallire un progetto "all fixed" (ambito, tempi e costi) senza cambiare il contratto?
Usando un approccio Agile!
In questo talk parleremo di progetti reali e sfidanti che hanno avuto successo grazie alla stretta collaborazione con il cliente.
Feedback continuo, trasparenza e sviluppo incrementale sono ingredienti alla base di questi risultati.
Sfatiamo il mito "non posso fare agile perchè il cliente e il contratto non me lo permettono"!
Lean prototyping al servizio del designerLuca Scarpa
Slide sul lean prototyping ed esercizi per fa emergere il valore della prototipazione e la facilità di realizzazione di uno strumento per ottenere feedback sprecando poco.
Quanto conosciamo i nostri utenti | Italian Agile Day 2018Emanuele Mantovani
Le slide del mio talk allo IAD 2018 "Quanto conosciamo i nostri utenti"
Generare valore per l’utente finale è un elemento fondamentale per il successo di un software. Ma siamo davvero sicuri di conoscere i nostri utenti? Quali strumenti abbiamo a disposizione per conoscerli e formulare ipotesi corrette e quali metriche possiamo utilizzare per validare e misurare il valore dei nostri prodotti per l’utente finale? Attraverso esempi concreti scopriremo come lo UX Design possa aiutarci a rispondere a queste domande e come possa integrarsi in un contesto agile.
Un progetto parte quasi sempre dalla stesura di un documento di specifiche chiamato brief.
Il brief dovrebbe contenere tutte le informazioni relative all’azienda e al progetto: tempi, obiettivi prefissi, statistiche, idea, competitor… Dovrebbe facilitare le decisioni aziendali e le spiegazioni ai fornitori. È il frutto di diverse giornate o settimane di lavoro da parte degli uffici marketing e/o tecnici interni all’azienda, richiede diversi incontri con il management per approvazione/assegnazione del budget e altri incontri con i fornitori dei servizi, per spiegare il progetto e chiedere un preventivo di esecuzione.
Ma avete mai provato a riprendere in mano il brief a progetto realizzato e a confrontare l’idea con il progetto finito?
In questo talk smontiamo alcuni miti sul brief e proviamo a capire come CTO, CMO e partner/fornitori possano farlo diventare il vero step 1 del progetto.
È possibile che le aziende coinvolte scrivano il brief insieme, partecipando all’analisi dell’idea e individuando le informazioni davvero utili?
E se fosse il fornitore a guidarvi nella stesura delle soluzioni tecniche?
Se già il brief mettesse l’utente al centro del processo?
Right here, right now: come capire e intercettare i momenti cruciali di un’es...Ilaria Mauric
Talk presentato al Web Marketing Festival 2016, a Rimini.
--
Framing, research, codesign, prototype, test sono le 5 fasi del processo di UX design.
In questo talk abbiamo visto come applicarle ai contesti di utilizzo in mobilità.
Abbiamo visto anche i principali tool che ci aiutano a descrivere la complessità di un’esperienza digitale, evidenziare i momenti e le emozioni cruciali e a progettare i flussi della ux.
Questo processo e questi tool ci guidano nel cogliere le opportunità e nel trovare risposte ai bisogni reali, nei luoghi, nei momenti e dai device giusti.
Quo vadis P.O.? Metriche UX per misurare il valore rilasciato.Emanuele Mantovani
In ogni progetto che affrontiamo non abbiamo risposte certe, abbiamo ipotesi da validare il prima possibile con gli utenti. Una serie di strumenti e metriche UX possono aiutare il P.O. e il team a misurare, iterazione dopo iterazione, il valore prodotto per l’utente finale. In questo talk mostro attraverso alcuni esempi come è possibile misurare il valore rilasciato in un progetto Scrum, identificando i pain point che affliggono l’esperienza utente e trovando soluzioni efficaci con tutto il team.
Come ridurre il rischio di fallire un progetto "all fixed" (ambito, tempi e costi) senza cambiare il contratto?
Usando un approccio Agile!
In questo talk parleremo di progetti reali e sfidanti che hanno avuto successo grazie alla stretta collaborazione con il cliente.
Feedback continuo, trasparenza e sviluppo incrementale sono ingredienti alla base di questi risultati.
Sfatiamo il mito "non posso fare agile perchè il cliente e il contratto non me lo permettono"!
Una storia di esperimenti volti a trovare il miglior modo di fare "ux" in ambito Agile. "UX, Scrum e Gilde" affronta la sfida di integrare lo user experience design e Scrum, focalizzando l'attenzione sull'importanza di trovare il giusto equilibrio tra strategia e iterazione.
La presentazione si divide in quattro sezioni principali:
1. Cos'è lo UX design e qual è il suo valore?
2. Lo UX designer e il team.
3. UX e Scrum (in che modo è possibile portare il design a bordo del team Scrum?)
4. Le persone e l'organizzazione.
Tutto quello che non vuoi sapere sulla User experience. Una introduzione per sviluppatori interessati a dialogare con i designer.
Cos'è la User Experience e lo user experience design?
Cosa accomuna developers e designers?
Versione aggiornata con alcuni piccoli miglioramenti alle infografiche, sulla base dei feedback ricevuti durante i talk.
Una storia di esperimenti volti a trovare il miglior modo di fare "ux" in ambito Agile. "UX, Scrum e Gilde" affronta la sfida di integrare lo user experience design e Scrum, focalizzando l'attenzione sull'importanza di trovare il giusto equilibrio tra strategia e iterazione.
La presentazione si divide in quattro sezioni principali:
1. Cos'è lo UX design e qual è il suo valore?
2. Lo UX designer e il team.
3. UX e Scrum (in che modo è possibile portare il design a bordo del team Scrum?)
4. Le persone e l'organizzazione.
Slide aggiornate del workshop di una giornata con il gioco da tavolo Agile the Board Game che spiega in pratica, usando i lego, come funziona Scrum.
Non manca durante la giornata anche l'esercitazione su A3 Reporting, il metodo Lean per apportare continui cambiamenti ai processi eliminando le cause di spreco.
Potete usare le slide per divulgare Agile e Lean, anche a livello commerciale. Ricordatevi solo di rispettare i termini della licenza Creative Common :-)
Commenti e miglioramenti sempre ben accetti!
Come creare un presentazione efficace nei contenuti, nell'attenzione e nella comunicazione utilizzando storytelling, trigger emotivi e cervello rettiliano.
Estratto da "lean presentation design" di Maurizio la Cava
C’è chi sogna che la sua azienda “passi a agile”, chi lo sta facendo e chi lo ha fatto.
In tutti questi casi le aspettative sono alte e il cambiamento forte.
Ma cosa avviene veramente dal “sogno alla realtà”?
A volte il processo di adozione dell’agilità non è così lineare e prevedibile e può dare risultati diversi da quelli attesi.
In questo talk condivideremo la nostra esperienza sul campo, riportando quello che abbiamo visto durante le fasi tipiche delle trasformazioni agili raccontando esperienze di vita vissuta come coach ma anche come PO, SM e sviluppatori.
La centralità della Customer Experience rappresenta uno degli elementi fondamentali per il successo di un'azienda.
Oggi generare valore per i nostri utenti non significa soltanto interrogarsi sui loro bisogni; occorre focalizzarsi sull'intera esperienza che il nostro utente vivrà prima, durante e dopo l'interazione con il prodotto o servizio.
Nell'ambito dello sviluppo agile del software, questa esigenza si traduce, in primo luogo, nella necessità di acquisire una profonda conoscenza dei propri utenti e, in secondo luogo, nell'usare questa conoscenza per generare ipotesi, che andranno implementate e validate iterazione dopo iterazione.
In questo scenario la collaborazione tra il designer e il resto del team diventa fondamentale, a partire dalla generazione delle ipotesi iniziali, che andranno, prima di tutto, validate dal punto di vista della fattibilità tecnologica.
Durante il meetup risponderemo, con una serie di esempi concreti, a quattro principali domande:
1. Cosa significa "generare valore" per l'utente finale oggi?
2. Quali strumenti abbiamo a disposizione per conoscere e formulare le nostre ipotesi?
3. Quali metriche possiamo utilizzare per validare e misurare il valore dei nostri prodotti per gli utenti finali?
4. Come possiamo integrare le competenze dello UX design all'interno dei nostri team Scrum?
Le slide del mio talk di venerdì 16 dicembre allo UX Genova.
Si parla di come aiutare le aziende a risolvere i problemi in modo creativo e collaborativo. Tutto il materiale presentato è di copyright dei rispettivi proprietari.
Questa presentazione era finalizzata alla spiegazione del metodo di progettazione e prototipazione in un lavoro come quello di Cartella Clinica Informatizzata. L'idea da divulgare ai committenti è quella di mettere al centro l'utilizzatore del prodotto, capire le sue necessità, il suo contesto di utilizzo e massimizzare l'efficacia e l'efficienza nella sua esperienza d'uso.
Scrivere software per il business si riduce essenzialmente a due problemi. Capire il vero problema da risolvere, e trovare soluzioni interessanti, senza trasformare la cosa in un percorso ad ostacoli.
Risolvi i tuoi problemi di sviluppo con agilità - di Stefano BrocchiGiuneco S.r.l
Il miglioramento continuo è un fulcro della filosofia Agile. A partire da uno specifico aspetto del processo di sviluppo che vogliamo migliorare, quali sono le tecniche che possiamo mettere in campo per ottenere il meglio? In questa presentazione analizzeremo delle possibili risposte, volte a migliorare il lavoro dello sviluppatore a tutto tondo, spaziando dagli strumenti software ad una collaborazione e comunicazione ottimale.
Sometimes you want to do Domain-Driven Design, but the bad guys are against you. Sometimes you need tobe the bad guy. This is Domain-Driven Design in a bloody brownfield scenario.
Una presentazione in formato "slides" su come pensare in modo "Agile". Documento elaborato nel 2020 da Domenico Aloisi. Tutti i diritti sui contenuti esposti appartengono ai rispettivi proprietari.
Esperienza d'acquisto e architettura dell'informazione: consigli pratici e qu...Ilaria Mauric
Il 29 maggio 2015 sono stata invitata dal gruppo delle GGD di Brescia per parlare di esperienza d'acquisto e architettura delle informazioni, in occasione della #GGDBrescia6, dedicata allo shopping online.
Nel mio intervento ho parlato di come gli utenti si approcciano agli acquisti, di come finiscono nei funnel di un ecommerce e di quali sono gli aspetti da tenere in considerazione quando si progetta l'esperienza digitale.
Perché non facciamo più quello che ci piaceIlaria Mauric
http://www.ilariamauric.it/2012/06/01/agile-ux-barcamp-come-andata/
Le slide che Alessandro Violini di e-xtrategy ed io abbiamo presentato all'Agile UX Barcamp di Firenze (31 maggio 2012).
Abbiamo raccontato la transizione da waterfall ad agile, la nostra esperienza e come siamo cambiati.
Una storia di esperimenti volti a trovare il miglior modo di fare "ux" in ambito Agile. "UX, Scrum e Gilde" affronta la sfida di integrare lo user experience design e Scrum, focalizzando l'attenzione sull'importanza di trovare il giusto equilibrio tra strategia e iterazione.
La presentazione si divide in quattro sezioni principali:
1. Cos'è lo UX design e qual è il suo valore?
2. Lo UX designer e il team.
3. UX e Scrum (in che modo è possibile portare il design a bordo del team Scrum?)
4. Le persone e l'organizzazione.
Tutto quello che non vuoi sapere sulla User experience. Una introduzione per sviluppatori interessati a dialogare con i designer.
Cos'è la User Experience e lo user experience design?
Cosa accomuna developers e designers?
Versione aggiornata con alcuni piccoli miglioramenti alle infografiche, sulla base dei feedback ricevuti durante i talk.
Una storia di esperimenti volti a trovare il miglior modo di fare "ux" in ambito Agile. "UX, Scrum e Gilde" affronta la sfida di integrare lo user experience design e Scrum, focalizzando l'attenzione sull'importanza di trovare il giusto equilibrio tra strategia e iterazione.
La presentazione si divide in quattro sezioni principali:
1. Cos'è lo UX design e qual è il suo valore?
2. Lo UX designer e il team.
3. UX e Scrum (in che modo è possibile portare il design a bordo del team Scrum?)
4. Le persone e l'organizzazione.
Slide aggiornate del workshop di una giornata con il gioco da tavolo Agile the Board Game che spiega in pratica, usando i lego, come funziona Scrum.
Non manca durante la giornata anche l'esercitazione su A3 Reporting, il metodo Lean per apportare continui cambiamenti ai processi eliminando le cause di spreco.
Potete usare le slide per divulgare Agile e Lean, anche a livello commerciale. Ricordatevi solo di rispettare i termini della licenza Creative Common :-)
Commenti e miglioramenti sempre ben accetti!
Come creare un presentazione efficace nei contenuti, nell'attenzione e nella comunicazione utilizzando storytelling, trigger emotivi e cervello rettiliano.
Estratto da "lean presentation design" di Maurizio la Cava
C’è chi sogna che la sua azienda “passi a agile”, chi lo sta facendo e chi lo ha fatto.
In tutti questi casi le aspettative sono alte e il cambiamento forte.
Ma cosa avviene veramente dal “sogno alla realtà”?
A volte il processo di adozione dell’agilità non è così lineare e prevedibile e può dare risultati diversi da quelli attesi.
In questo talk condivideremo la nostra esperienza sul campo, riportando quello che abbiamo visto durante le fasi tipiche delle trasformazioni agili raccontando esperienze di vita vissuta come coach ma anche come PO, SM e sviluppatori.
La centralità della Customer Experience rappresenta uno degli elementi fondamentali per il successo di un'azienda.
Oggi generare valore per i nostri utenti non significa soltanto interrogarsi sui loro bisogni; occorre focalizzarsi sull'intera esperienza che il nostro utente vivrà prima, durante e dopo l'interazione con il prodotto o servizio.
Nell'ambito dello sviluppo agile del software, questa esigenza si traduce, in primo luogo, nella necessità di acquisire una profonda conoscenza dei propri utenti e, in secondo luogo, nell'usare questa conoscenza per generare ipotesi, che andranno implementate e validate iterazione dopo iterazione.
In questo scenario la collaborazione tra il designer e il resto del team diventa fondamentale, a partire dalla generazione delle ipotesi iniziali, che andranno, prima di tutto, validate dal punto di vista della fattibilità tecnologica.
Durante il meetup risponderemo, con una serie di esempi concreti, a quattro principali domande:
1. Cosa significa "generare valore" per l'utente finale oggi?
2. Quali strumenti abbiamo a disposizione per conoscere e formulare le nostre ipotesi?
3. Quali metriche possiamo utilizzare per validare e misurare il valore dei nostri prodotti per gli utenti finali?
4. Come possiamo integrare le competenze dello UX design all'interno dei nostri team Scrum?
Le slide del mio talk di venerdì 16 dicembre allo UX Genova.
Si parla di come aiutare le aziende a risolvere i problemi in modo creativo e collaborativo. Tutto il materiale presentato è di copyright dei rispettivi proprietari.
Questa presentazione era finalizzata alla spiegazione del metodo di progettazione e prototipazione in un lavoro come quello di Cartella Clinica Informatizzata. L'idea da divulgare ai committenti è quella di mettere al centro l'utilizzatore del prodotto, capire le sue necessità, il suo contesto di utilizzo e massimizzare l'efficacia e l'efficienza nella sua esperienza d'uso.
Scrivere software per il business si riduce essenzialmente a due problemi. Capire il vero problema da risolvere, e trovare soluzioni interessanti, senza trasformare la cosa in un percorso ad ostacoli.
Risolvi i tuoi problemi di sviluppo con agilità - di Stefano BrocchiGiuneco S.r.l
Il miglioramento continuo è un fulcro della filosofia Agile. A partire da uno specifico aspetto del processo di sviluppo che vogliamo migliorare, quali sono le tecniche che possiamo mettere in campo per ottenere il meglio? In questa presentazione analizzeremo delle possibili risposte, volte a migliorare il lavoro dello sviluppatore a tutto tondo, spaziando dagli strumenti software ad una collaborazione e comunicazione ottimale.
Sometimes you want to do Domain-Driven Design, but the bad guys are against you. Sometimes you need tobe the bad guy. This is Domain-Driven Design in a bloody brownfield scenario.
Una presentazione in formato "slides" su come pensare in modo "Agile". Documento elaborato nel 2020 da Domenico Aloisi. Tutti i diritti sui contenuti esposti appartengono ai rispettivi proprietari.
Esperienza d'acquisto e architettura dell'informazione: consigli pratici e qu...Ilaria Mauric
Il 29 maggio 2015 sono stata invitata dal gruppo delle GGD di Brescia per parlare di esperienza d'acquisto e architettura delle informazioni, in occasione della #GGDBrescia6, dedicata allo shopping online.
Nel mio intervento ho parlato di come gli utenti si approcciano agli acquisti, di come finiscono nei funnel di un ecommerce e di quali sono gli aspetti da tenere in considerazione quando si progetta l'esperienza digitale.
Perché non facciamo più quello che ci piaceIlaria Mauric
http://www.ilariamauric.it/2012/06/01/agile-ux-barcamp-come-andata/
Le slide che Alessandro Violini di e-xtrategy ed io abbiamo presentato all'Agile UX Barcamp di Firenze (31 maggio 2012).
Abbiamo raccontato la transizione da waterfall ad agile, la nostra esperienza e come siamo cambiati.
Slide della mia presentazione al 2° WordPress Meetup Bari del 18 giugno 2016.
— Articolo sulla presentazione: https://nicolalosito.it/2016/06/23/introduzione-wordpress-multisite/
— Pagina dell'evento: http://wpbari.it/2016/06/11/meetup-bari-18-giugno-2016/
Agile and Design: creating and implementing products (in Italy) is possibleIlaria Mauric
The wiseman says: "A company specialized in IT consultancy cannot make products."
If you decide to break this taboo, the road is only one: understanding how that product can be realized and working hard to make it.
This is the story of Indyco, a tool born merging an agile dev team and a lean design team. Teams that didn't know each other before. And they made Indyco real in 6 months.
We will share the simple but powerful principles that lead us up to the go-live.
Now we are measuring and collecting data for next step.
These slides have been presented at Better Software 2014.
Perché non facciamo più quello che ci piace - Italian Agile Day 2012Ilaria Mauric
Presentate all'Italian Agile Day 2012, le slide mostrano l'evoluzione del metodo di lavoro di e-xtrategy dal 2008 al 2012, da quando cioè ha deciso di abbracciare le metodologie agili. L'intervento pone un focus particolare sulle criticità legate alla progettazione della user experience e sul cambio di percezione sul valore del lavoro offerto.
Monthly.Info: dall'idea al design dell'interfaccia mobile, step by step. Vers...Ilaria Mauric
Le slide che hanno accompagnato il mio intervento al Whymca di Milano (21 maggio 2010). Dopo l'intervento ho ricevuto diversi suggerimenti che approfondirò nel mio blog.
Intranet tra lavoro superficiale e profondo - Webinar - 16 - [IntranetManagem...Giacomo Mason
Non ho tempo per guardare la intranet!
Quante volte ci siamo sentiti dire questa frase nelle interviste ai dipendenti? Spesso, infatti, le intranet sono viste dai nostri colleghi più come un disturbo che come una risorsa a disposizione.
E sono in buona compagnia: anche una chat su Teams o un messaggio su Whatsapp possono costituire altrettante distrazioni inopportune se ci sollecitano nel momento sbagliato.
Ma qual è il momento giusto? Per capire come le intranet ci possono aiutare e in quali fasi delle nostre attività dobbiamo fare un passo indietro e distinguere, nella nostra giornata lavorativa, tra attività “superficiali” e “profonde”, nei tre ambiti dell’informazione, dell’azione e della relazione.
In questo webinar proporremo un framework che vi aiuterà a capire meglio come posizionare correttamente la vostra proposta intranet all’interno del quotidiano dei colleghi, a seconda del loro ruolo in azienda.
Argomenti del webinar
- Lavoro superficiale e lavoro profondo
- Informazione, azione, relazione
- Intranet, digital workplace e i loro impatti sui diversi ambiti
- Un framework evolutivo per il progetto
Noi conosciamo Kanban e Scrum come metodologie di gestione Agile. Lo Scrumban unisce le migliori caratteristiche di entrambi i metodi, combinando la natura prescrittiva dello Scrum e la capacità di miglioramento dei processi del Kanban, consentendo ai team di avvicinarsi allo sviluppo Agile e di migliorare costantemente i loro processi
Nell’organizzazione per processi diventano di primaria importanza le relazioni. Sono il modo con cui le persone stanno insieme, realizzano progetti, fanno l’organizzazione, costruiscono la conoscenza comune, soddisfano efficacemente le loro esigenze e quelle aziendali
Create in uno "spike", ben lontane dall'essere un prodotto informativo, sono una scaletta, una base di partenza per una versione migliorata di prossimo rilascio
Agile è entrato nel gergo comune di molte aziende che hanno a che fare con progetti IT. Questa è una buona cosa: il termine è conosciuto e accettato come una buona prassi, le persone sono ben disposte ad adottare metodi e pratiche che consentono di migliorare la gestione del ciclo di vita di un prodotto software e sono favorevoli al cambiamento.
Quando però si parte veramente mi sono trovato in diverse situazioni dove Agile si limitava alla parte “persone” e “organizzazione” ma non entrava nel merito di come si sviluppa il codice!
La provocazione “Stop Meeting, Start Coding” vuol ridurre all’essenziale i momenti di confronto e concentrarsi a scrivere buon codice, insieme!
In questo talk presenterò alcune buone pratiche di coding che favoriscono anche l’efficacia organizzativa.
Francesco Liguori, Giuliano Liguori | Il Project Manager ai tempi dell'IAPMexpo
L'avvento dell'Intelligenza Artificiale Generativa sta ridefinendo il ruolo del Project Manager. In questa presentazione esploreremo le competenze necessarie al Project Manager 5.0 per gestire progetti complessi integrando efficacemente l'Intelligenza Artificiale. Vedremo come un approccio umano-centrico, che ponga le persone al centro arricchito dalle potenzialità dell'AI, consenta di ottenere risultati migliori. Presenteremo metodologie innovative che uniscono il pensiero analitico umano con la potenza computazionale delle macchine per una gestione di progetto aumentata. L'obiettivo è ispirare una nuova generazione di Project Manager pronti ad affrontare le sfide del futuro.
"Da grande voglio fare il SEO" di Nereo Sciutto al Convegno Gt 2007Nereo Sciutto
La mia presentazione al ConvegnoGT di Firenze in cui ho parlato di formazione dei SEO e delle differenze fra operare in-house o all'interno di una agenzia.
Spunti di riflessione sull'opportunità di superare i silos dipartimentali, passando dalla gestione a compartimenti stagni alla gestione osmotica dei contenuti.
Le slide illustrano modelli e strumenti gestionali osmotici per comunicare ad attrito zero, in modo fluido e biunivoco, fra aree aziendali, azienda e partner, azienda e clienti, sfruttando le potenzialità del web 2.0 in fase di marketing, vendita, formazione e assistenza.
Prima di scendere a un livello di dettaglio maggiore, le slide evidenziano alcune tendenze generali:
- Le aziende sono propense ad adottare modelli e strumenti (knowledge base e community) per esplicitare, raccogliere, formalizzare e trasmettere sapere, all'interno dell'impresa, nonché a monte e a valle della catena della fornitura
- Si sta diffondendo l'idea di gestire 1 sorgente del contenuto e usarla per realizzare molti output (sistemi di CCMS, Component Content Management, e di automazione editoriale su carta, web, mobile e app);
- La consumerizzazione delle applicazioni business e l'ingresso dei nativi digitali nel mercato del lavoro richiedono lo sviluppo di sistemi più improntati alla visualità, all'interattività e alla socialità
- L'innovazione è sempre più guidata anche dai fruitori del prodotto / servizio, sotto forma di feedback espliciti e/o di dati raccolti automaticamente dai sistemi di monitoraggio inclusi nel prodotto (IoT, internet of things, internet delle cose) / servizio
- Sistemi esperti sono chiamati a fornire in modo proattivo, personalizzato e contestuale contenuti in grado di supportare decisioni e azioni, compensando anche il tendenziale decremento del livello di esperienza e competenza registrato da alcune funzioni aziendali
- I destinatari di dati e contenuti non sono solo persone, ma anche software, a sé stanti o incorporati all'interno di smart object.
5. Perché questo talk
• difficoltà ricorrenti
• brief lacunosi
• brief per proge i digitali
stru urati come brief creativi
• incomprensioni
• time consuming
6. Obie ivi
• far diventare il brief un documento
autorevole per tu i i team coinvolti
nel proge o
• consegna di valore fin dal brief
• disegnare un perimetro per
lavorare in concerto
7. Pagine
min 5
max 100
Ricevuto
via mail, a volte
anticipato per tel
Formato
doc, pdf, ppt
Possibilità di discuterlo
con riunione di
approfondimento
59. brief e briefing
To brief dall’inglese, si traduce in italiano con
“dare informazioni”.
Dunque, si definisce briefing un breve incontro in
cui vengono impartite sintetiche informazioni e
dire ive in merito a un proge o o a un piano
d’azione.
Sovente, nel corso del briefing viene reda o un
documento (brief), che riporta le informazioni e le
linee guida per la lavorazione del proge o.
[...]
Fonte: Sapere.it di De Agostini
68. Che cos’è un brief
Come nasce un brief (parte 1)
Interviste
Come nasce un brief (parte 2)
Cosa manca?
Ripartire da qui
69. Che cos’è un brief
Come nasce un brief (parte 1)
Interviste
Come nasce un brief (parte 2)
Cosa manca?
Ripartire da qui
70. Breve intro
Domande aperte per capire se il problema era
sentito anche dagli altri.
5 Commi enti (CMO, CTO)
10 Partner / Fornitori (design, sviluppo)
Partecipa anche tu su bit.ly/1hzDKbr
blog.gnvparters.com
72. Da chi nascono le idee contenute in un brief?
Dall’Editore o da proposte fa e
dal team di lavoro vagliate
comunque da lui.
Dalle redazioni,
dal webmarketing.
Dalla proprietà o dai
sistemi informativi.
Dai responsabili di prodo o
o di mercato.
Necessità imposte dal
mercato o dal customer care.
Commi ente
Sono idee nostre.
74. Su cosa si basa l’idea contenuta in un brief
Informazioni, obie ivi,
richieste.
Definizione obie ivi, kpi,
budget e tempi.
Best practices, o imizzazione
e automatismo dei flussi di
lavoro
Esigenze del momento,
aspe ative sul proge o,
obie ivi da raggiungere,
stare al passo coi tempi.
Commi ente
80. Che informazioni ti aspe i di trovare in un brief?
Principali a ori.
Vincoli tecnologici.
Tempistiche.
Epic stories.
Business model.
Budget.
Partner / Fornitore
82. Le informazioni che ricevi sono quelle che ti servono?
Non sempre.
Alcune.
Ma sono più interessanti
quelle che il cliente non dice.
Cose che per lui sono ovvie
o implicite, o a cui ha fa o
il callo senza accorgersene.
Nel 99% dei casi no.
Partner / Fornitore
83. Cosa ti
aspe i dal
partner o
fornitore
quando gli
hai mandato
un brief?
Cosa si
aspe a da te
il Cliente
dopo averti
mandato un
brief?
84. Cosa ti aspe i / cosa si aspe a dopo averlo mandato?
Domande per la definizione
del proge o e per evitare
fraintendimenti su
obie ivi e percorsi da
intraprendere.
Commi ente
Partner / Fornitore
85. Cosa ti aspe i / cosa si aspe a dopo averlo mandato?
Una prima ipotesi
proge uale, con un
orizzonte economico
identificato.
Commi ente
Partner / Fornitore
86. Cosa ti aspe i / cosa si aspe a dopo averlo mandato?
Economics
e tempistiche.
Commi ente
Partner / Fornitore
87. Cosa ti aspe i / cosa si aspe a dopo averlo mandato?
Un preventivo
a corpo
e dei tempi.
Commi ente
Partner / Fornitore
88. Cosa ti aspe i / cosa si aspe a dopo averlo mandato?
Un preventivo
a corpo
e dei tempi.
Commi ente
Partner / Fornitore
93. Quanto tempo
trascorre in
media dall’invio
del brief al
partner /
fornitore
all’avvio el
proge o?
Quanto tempo
trascorre in
media dalla
ricezione del
brief all’avvio
del proge o?
94. Quanto tempo trascorre dall’invio al partner/fornitore al kickoff?
2 se imane.
Non meno di un mese.
Mesi e mesi.
Commi ente
Partner / Fornitore
95. Quanto tempo trascorre dall’invio al partner/fornitore al kickoff?
2 se imane.
2 se imane.
Non meno di un mese.
Non meno di un mese.
Mesi e mesi.
Mesi e mesi.
Commi ente
Partner / Fornitore
100. Quali sono i problemi ricorrenti in un proge o nato da un brief?
Cambiamenti
acce ati mal volentieri.
Mancanza di de aglio.
Analisi poco approfondita.
Commi ente
Partner / Fornitore
101. Quali sono i problemi ricorrenti in un proge o nato da un brief?
Cambiamenti
acce ati mal volentieri.
Mancanza di de aglio.
Analisi poco approfondita.
Commi ente
Rigidità.
Informazioni inutili
o incomplete.
Partner / Fornitore
103. Quali sono i vantaggi ricorrenti in un proge o nato da un brief?
Concordare a priori
obie ivi e KPI.
Condivisione del proge o.
Punti di vista molteplici.
Commi ente
Partner / Fornitore
104. Quali sono i vantaggi ricorrenti in un proge o nato da un brief?
Concordare a priori
obie ivi e KPI.
Esistono?
Condivisione del proge o.
Punti di vista molteplici.
Commi ente
Partner / Fornitore
105. Quali sono i vantaggi ricorrenti in un proge o nato da un brief?
Concordare a priori
obie ivi e KPI.
Condivisione del proge o.
Punti di vista molteplici.
Commi ente
Abbiamo l’occasione
di trovare i giusti
interlocutori e far loro
le giuste domande.
Partner / Fornitore
106. Che cos’è un brief
Come nasce un brief (parte 1)
Interviste
Come nasce un brief (parte 2)
Cosa manca?
Ripartire da qui
107. Che cos’è un brief
Come nasce un brief (parte 1)
Interviste
Come nasce un brief (parte 2)
Cosa manca?
Ripartire da qui
108. Idea di proge o
tempo sconosciuto
CTO
CMO
Azienda
o Ente
Utenti
CEO
Tech / Digital /
Web unit
Responsabile di
proge o
Redazioni
Customer Care
Comunicazione
109. Idea di proge o
tempo sconosciuto
CTO
CMO
Azienda
o Ente
Utenti
CEO
Tech / Digital /
Web unit
Responsabile di
proge o
Redazioni
Customer Care
Comunicazione
110. Scri ura del brief
1 se • 1 mese
CTO
CMO
Azienda
o Ente
Proge o
CEO
Tech / Digital /
Web unit
Responsabile di
proge o
Redazioni
Customer Care
Comunicazione
Utenti
111. Scri ura del brief
1 se • 1 mese
CTO
CMO
Azienda
o Ente
Proge o
CEO
Tech / Digital /
Web unit
Responsabile di
proge o
Redazioni
Customer Care
Comunicazione
Uffici tecnici
Uffici contabili
Copy
Uffici legali
…
Utenti
112. CEO valuta il brief prodo o
1 se • 1 mese
CTO
CMO
Azienda
o Ente
Proge o
CEO
Tech / Digital /
Web unit
Responsabile di
proge o
Redazioni
Customer Care
Comunicazione
Uffici tecnici
Uffici contabili
Copy
Uffici legali
…
Utenti
113. Partner / fornitori selezionati analizzano il brief
1 g • 5 gg
CTO
Partner
Fornitore
CMO
Azienda
o Ente
Partner
Fornitore
CEO
Tech / Digital /
Web unit
Proge o
Partner
Fornitore
Responsabile di
proge o
Redazioni
Customer Care
Comunicazione
Uffici tecnici
Uffici contabili
Copy
Uffici legali
…
Utenti
114. Scelta del partner / fornitore
1 se • 1 mese
CTO
CMO
Azienda
o Ente
Partner
Fornitore
CEO
Proge o
Tech / Digital /
Web unit
Responsabile di
proge o
Redazioni
Customer Care
Comunicazione
Uffici tecnici
Uffici contabili
Copy
Uffici legali
…
Utenti
115. Approfondimenti con partner / fornitore scelto
1 se • 1 mese
CTO
Team UX
CMO
Azienda
o Ente
Partner
Fornitore
CEO
Tech / Digital /
Web unit
Proge o
Team dev
Responsabile di
proge o
Redazioni
Customer Care
Comunicazione
Uffici tecnici
Uffici contabili
Copy
Uffici legali
…
Utenti
116. Approvazione e kickoff
1 mese • 8 mesi
CTO
Team UX
CMO
Azienda
o Ente
Partner
Fornitore
CEO
Tech / Digital /
Web unit
Proge o
Team dev
Responsabile di
proge o
Redazioni
Customer Care
Comunicazione
Uffici tecnici
Uffici contabili
Copy
Uffici legali
…
Utenti
123. Il Cliente si aspe a che
i designer si occupino
della grafica e gli
sviluppatori dello
sviluppo.
124. Il Cliente è tendenzialmente
o imista sui tempi di lavoro
che affida all’esterno.
125. Il partner / fornitore
è tendenzialmente
guardingo sul proge o
in generale e sui tempi
di realizzazione.
126. Che cos’è un brief
Come nasce un brief (parte 1)
Interviste
Come nasce un brief (parte 2)
Cosa manca?
Ripartire da qui
127. Che cos’è un brief
Come nasce un brief (parte 1)
Interviste
Come nasce un brief (parte 2)
Cosa manca?
Ripartire da qui
128. Il brief (o l’idea)
non è stato verificato
con le persone
a cui è rivolto.
Utenti
129. Il brief (o l’idea)
non è stato verificato
con le persone
che coinvolge.
Uffici tecnici
Uffici contabili
Copy
Uffici legali
…
130. Quasi sempre,
i partner / fornitori
che lavoreranno sul
brief non conoscono
il dominio
e sul documento
non se ne parla.
131. Quasi sempre,
i partner / fornitori
temono che durante il
proge o emergano
aspe i che lo
porteranno a un bagno
di sangue.
132. Quali sono i problemi ricorrenti in un proge o nato da un brief?
Cambiamenti
acce ati mal volentieri.
Mancanza di de aglio.
Analisi poco approfondita.
Commi ente
Rigidità.
Informazioni inutili
o incomplete.
Partner / Fornitore
133.
134. Non sono previste
a ività di verifica
neanche post proge o.
Riscontrato sopra u o su proge i di servizio, non di prodo o.
135. Che cos’è un brief
Come nasce un brief (parte 1)
Interviste
Come nasce un brief (parte 2)
Cosa manca?
Ripartire da qui
136. Che cos’è un brief
Come nasce un brief (parte 1)
Interviste
Come nasce un brief (parte 2)
Cosa manca?
Ripartire da qui
141. Dichiarare la strategia di business
•
•
•
•
•
•
•
obie ivi di business e bmc
benchmark e competitor
vincoli stru urali o tecnici
a ori ed epic stories
kpi e metriche
priorità, tempi, budget
product owner e interlocutori
142. “Puliamo” il linguaggio
•
•
•
•
•
•
•
obie ivi di business e bmc
benchmark e competitor
vincoli stru urali o tecnici
a ori ed epic stories
kpi e metriche
priorità, tempi, budget
product owner e interlocutori
143. Definire un obie ivo
S
specifico
M
misurabile
A
acce abile
R
rilevante
T
tempificato / tracciabile
226. A ori
Sono singole
persone o gruppi
di persone che
hanno bisogno
di usare
il servizio
o prodo o
digitale.
Sistema
spedizione
Customer
care
Anonimo
Admin
Proge o
Registrato
Sistema
fa urazione
Magazzino
227. Epic story
Una epic story
rappresenta un
bisogno di uno
degli a ori del
sistema che potrà
essere descri o in
user stories più
de agliate.
229. Verifica e sostenibilità degli obie ivi
• partire dai dati reali
• verificare le idee con gli a ori che dovranno
realizzarla, possibilmente prima di
prome erle al CEO
• priorità e rilasci non per feature, ma per
obie ivi e metriche.
231. Ridefinire i ruoli
Il partner / fornitore non è
“quello che fa la grafica”,
“quello che fa il sito”,
“quello che scrive codice”.
L’utente non è un’entità che genera
impression e statistiche.
236. Buone pratiche del partner / fornitore
• chiedere perché
(Ask Why, why, why, why and why!)
• guarire dalla sindrome del “Me l’avete
chiesto voi”
• individuare interlocutori e product owner
• chiarire chi fa cosa
h p://zurb.com/manifesto
237. Buone pratiche del partner / fornitore
• rilasci basati sulle priorità
• basta dire che per tu o ci vuole minimo
un anno
• misurare
• rinunciare al proprio ego: non è per voi
ma per il Cliente e per chi beneficerà del
proge o
242. Vantaggi
•
•
•
•
•
meno spreco
meno dispersione delle informazioni
riduzione del rischio
le riunioni sono già operative
team multidisciplinare perme e di
orientare le scelte consapevolmente
243. #1
#2
#3
#4
#5
Definire il dominio
Dichiarare la strategia di business
Verifica e sostenibilità degli obie ivi
Ridefinire i ruoli
Condividere la design vision
Ringraziamenti
Rispondi al questionario!
•
Mabel Morri (www.mabelmorri.it) per le
illustrazioni
•
Lia, Marco, Alessandro, Stefano, Sergio
Aiutaci a capire come scrivere meglio un
brief per far partire un proge o col piede
giusto:
•
Francesco, Michele, Lorenzo, Ma eo,
Daniele, Alessandro, Daniel, Alberto,
Michele, Lorenzo
•
Nicolò, Luca, e Fabio di GNVPartners
bit.ly/1hzDKbr
Be er So ware 2013 • Firenze, 12 novembre 2013
@mariannacerato,