DA STUDENTE A PROJECT

(1)

DA STUDENTE A PROJECT MANAGER: MANUALE DI

SOPRAVVIVENZA

Seminario di approfondimento per il corso

«Laboratorio di Ingegneria Informatica»

Lorenzo Della Sciucca

Dedalus S.p.a.

Facoltà di Ingegneria, Modena 18 Novembre 2010

(2)

Perché sono qui?

(3)

Perché sono qui?

(4)

UNIMORE

Prof.ssa L. Leonardi Ing. F. Di Marco

Lorenzo

Della Sciucca

Perché sono qui?

(5)

Mi presento

(6)

A livello personale

Mi Presento

(7)

A livello professionale

Mi Presento

(8)

Obiettivo del Seminario

(9)

Obiettivo del Seminario

(10)

L’obiettivo del seminario è condividere con voi la mia esperienza lavorativa in una azienda di discreta

dimensione (>500), per quanto riguarda:

1. Il Contesto Aziendale

2. Gestione Progetti:

• Tematiche Generali

• Teoria VS Pratica

3. Alcune osservazioni sull’Ingegneria del Software:

• Fase di Analisi

• Produzione

Nessuna «ricetta magica» o «verità», solamente

«consigli» basati sulla mia esperienza e sul buon senso

(11)

PREMESSE

• Nella mia esperienza, Gestione Progetti e Gestione Clienti sono attività in stretta correlazione;

• Non lavoro nel ramo della «Produzione», ma mi limito ad Analisi/Progettazione, con qualche contaminazione di

Marketing;

• La mia azienda produce GESTIONALI, non produciamo Tool o «Tecnologia».

(12)

Contesto Aziendale

(13)

Presidente e AD Giorgio Moretti Vicepresidente Claudio Cricelli

Infrastrutture Acquisti Giorgio Redaelli Risorse Umane Sistema Gestione Qualità

Sistema Informativo Filippo Di Marco

Comunicazione Istituzionale Elisabetta Natali Amministrazione Finanza

e Controllo Riccardo Donati

Coordinamento Sviluppo Offerta

PierLuigi Banfi

Ricerca e Progetti Speciali Riccardo Fontanelli

Mercato Sanità Privata Mercato Cure Primarie Mercato Sanità Pubblica

Mercato Cure Primarie Adriano Bossini DG Millennium Mercato Sanità Privata

Gianfranco Capra

Corporate

Mercati Internazionali

Marketing & Sales Mercati Internazionali

Sara Mintrone

Coordinamento Produzione Amela Popovac Coordinamento Commerciale

Sanità Pubblica Antonio Redaelli

Coordinamento Delivery Giorgio Fenino

Contesto Aziendale

(14)

Presidente e AD Giorgio Moretti Vicepresidente Claudio Cricelli

Infrastrutture Acquisti Giorgio Redaelli Risorse Umane Sistema Gestione Qualità

Sistema Informativo Filippo Di Marco

Comunicazione Istituzionale Elisabetta Natali Amministrazione Finanza

e Controllo Riccardo Donati

Coordinamento Sviluppo Offerta

PierLuigi Banfi

Ricerca e Progetti Speciali Riccardo Fontanelli

Mercato Sanità Privata Mercato Cure Primarie Mercato Sanità Pubblica

Mercato Cure Primarie Adriano Bossini DG Millennium Mercato Sanità Privata

Gianfranco Capra

Corporate

Mercati Internazionali

Marketing & Sales Mercati Internazionali

Sara Mintrone

Coordinamento Produzione Amela Popovac Coordinamento Commerciale

Sanità Pubblica Antonio Redaelli

Coordinamento Delivery Giorgio Fenino

Qui sotto stanno i Product Manager

Qui sotto stanno i Project Manager

(15)

• Le attività più complesse implicano il coinvolgimento di numerose figure dell’organigramma

-> conoscere bene l’organizzazione ed imparare a muoversi

• L’Organigramma non è scritto nella pietra

-> nel bene e nel male, prestate un orecchio (non la bocca!) alle «chiacchere» di palazzo

(16)

MANSIONARIO: Product Manager

• Definizione offerta e supporto alle vendite

• Rapporti con Opinion Leader

• Gestione di Pool Utenti / Comitati scientifici

• Piano marketing

• Produzione documentazione

• Proposizione listini

• Produzione contenuti marketing (no immagine)

• Pubblicità (proposta presenza advertising e redazionale su media specializzati)

• Convegni (proposta partecipazione a convegni )

• Presenza a Convegni

• Pre sales

• Formazione struttura commerciale

• Presentazioni e dimostrazioni

• Sopralluoghi

• Produzione offerte non standard

• Produzione documentazione di gara

• Governo attività per la preventivazione, con garanzia tempi risposta

• Gestione di Progetti complessi e/o strategici

• Sviluppo offerta

• Gestione budget manutenzione evolutiva

• Analisi funzionale nuovi moduli

• Analisi funzionale modifiche prodotti a listino

• Concezione ed analisi nuovi prodotti

(17)

MANSIONARIO: Project Manager

• Allocati direttamente su aree di mercato o su clienti

• Gestiscono, se non remunerati, solo progettualità complesse e/o Clienti con circa 1.000.000 Euro di fatturato annuo

• Le loro attività devono essere remunerate dai clienti

• L’azione del responsabile è primariamente di analisi dei bisogni ed allocazione dei Project Manager a clienti/aree di mercato

(18)

•

Vi ritroverete sicuramente a seguire diversi

prodotti oppure diversi clienti e quindi ad avere tanti fronti aperti contemporaneamente che

avanzano a velocità diverse:

• Sul lavoro bisogna essere assolutamente MultiTasking

• Nonostante tutto, bisogna rispettare le scadenze

• Soluzioni come OUTLOOK diventeranno il vostro pane quotidiano:

• Gestione delle Attività

• Calendario

(19)

«Non abbiamo avuto belle esperienze con i 110 e lode perché tendono ad essere dei

perfezionisti, non particolarmente umili, che non rispettano le scadenze»

(20)

• Nessuno insegna niente, se non è costretto o non gli torna utile

-> imparare ad arrangiarsi

• Cercate di mantenere buoni rapporti con tutti i colleghi (che se lo meritano)

-> il rapporto personale è alla base di tutto, ed un buon clima aiuta a lavorare meglio

• Confrontarsi è importante, bisogna anche imparare a

«farsi valere»:

-> ma cercate un conflitto costruttivo Contesto Aziendale

(21)

Gestire il Contesto Aziendale, a volte, è un LAVORO di per se.

(22)

Gestione Progetti – Tematiche Generali

(23)

Commerciali

Cliente

Struttura

Sviluppatori Gestione Progetti – Tematiche Generali

(24)

Gestione Progetti – Tematiche Generali

(25)

Gestione Progetti – Teoria vs Pratica

(26)

Ripercorriamo le macro-fasi individuate dal Seminario dell’Ing.

Ghedini:

1. Concepire e Definire il Progetto

2. Programmazione del Progetto

3. Definizione, dimensionamento e gestione Team

4. Attuazione del Progetto

Gestione Progetti – Teoria VS Pratica

(27)

Fase 1 - Concepire e Definire il Progetto

Siete soli,

come questo Cactus.

(28)

Con il Cliente:

• Ricordate che nella fase di Analisi è fondamentale, prima ancora di parlare del problema, partire da una precisa Contestualizzazione dell’esistente, il cosiddetto «As Is». I diagrammi sono meglio delle parole.

• Non potete fidarvi ciecamente di quello che vi dice il cliente, si dimentica un sacco di cose.

• Il cliente conosce bene i propri problemi, ma

spesso chiede soluzioni sbagliate. D’altronde non cerca un mero esecutore, ma un consulente…

(29)

Con i Colleghi:

• A livello interno, la fase di Analisi è affidata a voi, e spesso sarete soli. Procuratevi

l’aiuto che vi serve, ricordando che non tutti lavorano al meglio se non hanno

responsabilità…

(30)

• Scomporre il progetto in Fasi e Sub-Unità -> …

• Evidenziate quali Fasi permettono di passare dalla

situazione attuale («As Is») al risultato finale («To Be»).

• Ribadisco: i diagrammi sono meglio delle parole Fase 2 – Programmazione del Progetto

(31)

• Scomporre il progetto in Fasi e Sub-Unità -> OK!

• Milestones -> OK!

• Diagrammi di Gantt -> solo ad ALTO livello

• Gestire le Risorse -> non potete

• Matrice delle Responsabilità -> OK!

Fase 2 – Programmazione del Progetto Gestione Progetti – Teoria VS Pratica

(32)

Fase 3 – Definizione, dimensionamento e gestione Team Gestione Progetti – Teoria VS Pratica

(33)

Fase 4 – Attuazione del Progetto

• Monitoraggio -> OK!

• Azioni Correttive -> OK!

• Comunicazione -> …

(34)

La comunicazione è fondamentale:

1. Comunicare in maniera corretta e costante con il cliente

2. Comunicare in maniera corretta e costante con i colleghi

… la documentazione non è un mezzo di comunicazione efficace, è lento e costoso, va utilizzata solo per…

documentare

(35)

Comunicare con il cliente

(36)

Comunicare con i colleghi

(37)

La Posta Elettronica è uno strumento

fondamentale, bisogna imparare ad usarlo al meglio:

1. Avanzamenti di Stato e Comunicazioni

«ufficiose»

2. Domande con risposte complesse, per forza di cose non immediate (rimane traccia scritta, ad entrambi)

3. Tutela:

• «Ma mi aveva detto che…» Non ti tutela per niente

• «Ecco la mail in cui affermava che…» Va molto meglio

(38)

Fase 4 – Attuazione del Progetto

• Monitoraggio -> OK!

• Azioni Correttive -> OK!

• Comunicazione -> OK!

• Negoziazione -> OK!

• Varianti di progetto -> OK!

• Conclusione -> OK!

(39)

• Alcuni esempi…

(a voce, non mi azzardo a scrivere di questi episodi!) Gestione Progetti – Teoria VS Pratica

(40)

Ingegneria del Software – Fase di

Analisi

(41)

Cosa intendo per Fase di Analisi?

• Contestualizzazione (As Is);

• Raccolta dei requisiti / Intervista per capire il problema;

• Formalizzazione dei requisiti e dei casi d’uso;

• Definizione dei requisiti funzionali;

• Architettura (To Be).

Ingegneria Software – Fase di Analisi

(42)

La mia esperienza mi insegna che gli strumenti di analisi forniti da UML non funzionano.

Triste, ma vero.

Troppa carta, manca un quadro complessivo, troppo vicini al livello «tecnico» (di cui non mi occupo).

(43)

Noi ci occupiamo di GESTIONALI, quindi il nostro obiettivo è fornire uno strumento informatico che consenta di gestire in maniera efficace ed efficiente un PROCESSO di lavoro.

La chiave di tutto è il PROCESSO. Il Flusso.

UML non consente di disegnare in maniera adeguata il PROCESSO.

I Manutentori di UML (OMG) lo hanno capito, e da anni lavorano a qualcosa di nuovo

(44)

(45)

(46)

(47)

(48)

(49)

Applicabile a vari livelli:

1. Il «processo» (come viene organizzato il lavoro)

2. La rappresentazione dell’architettura applicativa, con le interazioni fra i diversi attori interni ed esterni

all’architettura

3. Progettazione di logiche di orchestrazione che

diventano direttamente eseguibili dagli orchestratori Ingegneria Software – Fase di Analisi

(50)

Consiglio / BOOK:

Consiglio / TUTORIAL:

http://www.bpmn.org/Documents/Introduction_to_BPMN.pdf

Consiglio / BPMN Poster:

http://www.bpmb.de/images/BPMN2_0_Poster_IT.pdf

(51)

Ingegneria del Software – Produzione

(52)

L’esperienza di altri mi insegna che gli strumenti di

programmazione e produzione tipici dell’Ingegneria del Software, non funzionano.

Triste, ma vero.

Il modello definito è troppo «accademico» e poco

«empirico». L’ingegneria, di per sé, ha una discreta componente empirica.

Ingegneria Software – Produzione

(53)

Consiglio a tutti di cominciare a documentarsi sulla metodologia di sviluppo AGILE.

(Non la conosco bene, mi limito a mettervi la pulce nell’orecchio)

I principi fondamentali:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan Ingegneria Software – Produzione

(54)

(55)

Esistono molte «tecniche» di sviluppo AGILE, più o meno condivisibili, ma i principi ispiratori rimangono gli stessi:

• Poca documentazione;

• Forte coinvolgimento del Cliente / Utente;

• Il Codice è il Modello. Utilizzo di Mock Object per avere fin da subito un quadro completo;

• Rilasci frequenti, un set di funzionalità per volta;

• Testing continuo grazie a tecniche di Testing Automation

• Se ci pensate, la maggior parte delle Web Application Google Style segue questi principi

(56)

Consiglio / TALK

(http://confreaks.net/videos/282-lsrc2010-real-software-engineering)

(57)

(l’ho portata con me, se volete guardarla… dura 1 ora…

potremmo guardarne i primi 15 minuti..!) Ingegneria Software – Produzione

(58)

Domande?

(59)

Grazie dell’attenzione…

… in bocca al Lupo!