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
Perché sono qui?
Perché sono qui?
Perché sono qui? UNIMORE Prof.ssa L. Leonardi Ing. F. Di Marco Lorenzo Della Sciucca
Mi presento
Mi Presento A livello personale
Mi Presento A livello professionale
Obiettivo del Seminario
Obiettivo del Seminario
Obiettivo del Seminario 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
Obiettivo del Seminario 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».
Contesto Aziendale
Contesto Aziendale Corporate Presidente e AD Giorgio Moretti Vicepresidente Claudio Cricelli Amministrazione Finanza e Controllo Riccardo Donati Risorse Umane Sistema Gestione Qualità Sistema Informativo Filippo Di Marco Comunicazione Istituzionale Elisabetta Natali Infrastrutture Acquisti Giorgio Redaelli Coordinamento Sviluppo Offerta PierLuigi Banfi Ricerca e Progetti Speciali Riccardo Fontanelli Mercato Sanità Privata Mercato Cure Primarie Mercato Sanità Pubblica Mercato Sanità Privata Gianfranco Capra Mercato Cure Primarie Adriano Bossini DG Millennium Coordinamento Commerciale Sanità Pubblica Antonio Redaelli Mercati Internazionali Marketing & Sales Mercati Internazionali Sara Mintrone Coordinamento Produzione Amela Popovac Coordinamento Delivery Giorgio Fenino
Contesto Aziendale Corporate Presidente e AD Giorgio Moretti Vicepresidente Claudio Cricelli Qui sotto stanno i Product Manager Coordinamento Sviluppo Offerta PierLuigi Banfi Amministrazione Finanza e Controllo Riccardo Donati Comunicazione Istituzionale Elisabetta Natali Risorse Umane Sistema Gestione Qualità Sistema Informativo Filippo Di Marco Infrastrutture Acquisti Giorgio Redaelli Ricerca e Progetti Speciali Riccardo Fontanelli Mercato Sanità Privata Mercato Cure Primarie Mercato Sanità Pubblica Mercato Sanità Privata Gianfranco Capra Mercato Cure Primarie Adriano Bossini DG Millennium Coordinamento Commerciale Sanità Pubblica Antonio Redaelli Mercati Internazionali Marketing & Sales Mercati Internazionali Sara Mintrone Coordinamento Produzione Amela Popovac Qui sotto stanno i Project Manager Coordinamento Delivery Giorgio Fenino
Contesto Aziendale 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
Contesto Aziendale 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
Contesto Aziendale 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
Contesto Aziendale 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
Contesto Aziendale «Non abbiamo avuto belle esperienze con i 110 e lode perché tendono ad essere dei perfezionisti, non particolarmente umili, che non rispettano le scadenze»
Contesto Aziendale 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 Gestire il Contesto Aziendale, a volte, è un LAVORO di per se.
Gestione Progetti Tematiche Generali
Gestione Progetti Tematiche Generali Struttura Commerciali Sviluppatori Cliente
Gestione Progetti Tematiche Generali
Gestione Progetti Teoria vs Pratica
Gestione Progetti Teoria VS Pratica 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 Fase 1 - Concepire e Definire il Progetto Siete soli, come questo Cactus.
Gestione Progetti Teoria VS Pratica Fase 1 - Concepire e Definire il Progetto 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
Gestione Progetti Teoria VS Pratica Fase 1 - Concepire e Definire il Progetto 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à
Gestione Progetti Teoria VS Pratica Fase 2 Programmazione del Progetto 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
Gestione Progetti Teoria VS Pratica Fase 2 Programmazione del Progetto 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!
Gestione Progetti Teoria VS Pratica Fase 3 Definizione, dimensionamento e gestione Team
Gestione Progetti Teoria VS Pratica Fase 4 Attuazione del Progetto Monitoraggio -> OK! Azioni Correttive -> OK! Comunicazione ->
Gestione Progetti Teoria VS Pratica 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
Gestione Progetti Teoria VS Pratica Comunicare con il cliente
Gestione Progetti Teoria VS Pratica Comunicare con i colleghi
Gestione Progetti Teoria VS Pratica 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
Gestione Progetti Teoria VS Pratica Fase 4 Attuazione del Progetto Monitoraggio -> OK! Azioni Correttive -> OK! Comunicazione -> OK! Negoziazione -> OK! Varianti di progetto -> OK! Conclusione -> OK!
Gestione Progetti Teoria VS Pratica Alcuni esempi (a voce, non mi azzardo a scrivere di questi episodi!)
Ingegneria del Software Fase di Analisi
Ingegneria Software Fase di Analisi 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 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).
Ingegneria Software Fase di Analisi 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
Ingegneria Software Fase di Analisi
Ingegneria Software Fase di Analisi
Ingegneria Software Fase di Analisi
Ingegneria Software Fase di Analisi
Ingegneria Software Fase di Analisi
Ingegneria Software Fase di Analisi 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 Consiglio / BPMN Poster: http://www.bpmb.de/images/bpmn2_0_poster_it.pdf Consiglio / TUTORIAL: http://www.bpmn.org/documents/introduction_to_bpmn.pdf Consiglio / BOOK:
Ingegneria del Software Produzione
Ingegneria Software Produzione 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 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
Ingegneria Software Produzione 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
Ingegneria Software Produzione Consiglio / TALK (http://confreaks.net/videos/282-lsrc2010-real-software-engineering)
Ingegneria Software Produzione (l ho portata con me, se volete guardarla dura 1 ora potremmo guardarne i primi 15 minuti..!)
Domande?
Grazie dell attenzione in bocca al Lupo!