Progettazione funzionale: dove il business incontra il software
Un’introduzione alla progettazione funzionale
Lo scopo della progettazione funzionale è definire i requisiti da implementare con una soluzione software. Indipendentemente dalla forma assunta, le specifiche funzionali sono intese a registrare quello che il software deve fare per supportare un utente business. Spesso, i progetti funzionali sono rivisti e approvati sia da stakeholder commerciali che tecnici. Gli utenti business confermano che, sì, questo è esattamente ciò che vogliono che il sistema faccia. Gli utenti tecnici confermano che, sì, questi requisiti sono fattibili, implementabili e testabili. Per saperne di più sulle sfumature della progettazione funzionale e sull’approccio unico di Engineering Industries eXcellence, il nostro team marketing ha incontrato uno dei nostri massimi guru tecnici ed esperti di progettazione funzionale per una buona sessione vecchio stile di domande e risposte faccia a faccia.
Incontro con il nostro esperto: Guillermo Padron
ZB: CIAO GUILLERMO! GRAZIE PER AVER ACCETTATO DI RACCONTARCI UN PO’ DI TE E DI CIÒ CHE FAI.
GP: Piacere mio, iniziamo!
ZB: INNANZITUTTO, DIMMI QUALCOSA DI TE E DEL TUO BACKGROUND. C’È QUALCOSA CHE LA MAGGIOR PARTE DELLE PERSONE NON SANNO DI TE?
GP: I miei genitori sono immigrati negli Stati Uniti da Cuba nel 1979 durante il periodo di Fidel Castro. Cuba aveva un accordo con il governo degli Stati Uniti per permettere l’emigrazione verso gli States e Castro l’ha usato come opportunità per sbarazzarsi degli indesiderabili, prigionieri di stato, dissidenti politici del regime comunista, per darvi un’idea. All’epoca, mio padre era un prigioniero politico. A lui e a mia mamma fu detto che sarebbero stati portati su un gommone in Florida e così fecero. Riuscirono alla fine ad arrivare a New York e si stabilirono nel New Jersey. Nacqui lì nel 1991.
ZB: CHE STORIA INCREDIBILE, G! NO SO BENE COME PROSEGUIRE DA QUI, MA CONSIDERANDO CHE SEI UNO DEGLI ESPERTI TECNICI DI MAGGIOR TALENTO NEL NOSTRO TEAM USA, MI CHIEDO COM’ERI DA BAMBINO. SEI NATO PER LAVORARE IN QUESTO SETTORE?
GP: Magari non nato, ma sicuramente “allevato” per questo. Alle elementari, ero molto appassionato di matematica e scienze. Mi piacevano ed ero abbastanza bravo in queste materie. Erano concrete, e per me era molto più semplice comprendere con un esempio quale fosse la risposta a un problema. Era così che funzionava la mia mente. Frequentavo inoltre una scuola dove quelle materie venivano enfatizzate, perché vivevo in una zona in cui le opportunità formative non erano sempre le migliori, perciò gli insegnanti incoraggiavano gli allievi a intraprendere studi pratici e commerciali. Così alle superiori, mi rivolsi a Omar, mio fratello maggiore, per un’ispirazione. Stava iniziando l’università alla facoltà di informatica e volevo seguire le sue orme.
ZB: QUAL È IL TUO PRIMO RICORDO DELLA TECNOLOGIA?
GP: Quando ero più giovane, mio fratello ed io andavamo a trovare mio padre in ufficio. Alla fine della giornata, se eravamo stati bravi e quando tutti avevano lasciato l’ufficio, ci permetteva di giocare ad alcuni giochi sul computer. Era fantastico! Quando iniziai le superiori, i PC iniziavano a diventare molto più comuni nelle case e potemmo prenderne uno anche noi. Così, quando lo ebbi a portata di mano, ne fui davvero affascinato. Entrai nel mondo dei videogiochi e da allora non ne sono più uscito!
ZB: OK, DACCI UN PO’ DI INFORMAZIONI SUI TUOI STUDI, GIUSTO PER PUNTUALIZZARE.
GP: Ho frequentato la Rutgers University e mi sono laureato con una doppia specializzazione in Informatica e Matematica. In realtà non avevo affrontato il linguaggio di programmazione prima dell’università, però mi interessava. Così, mi dilettai parecchio durante gli studi....vari corsi di programmazione, sistemi operativi, linguaggi. Non fu facile per me. Ricordo ancora i momenti di frustrazione o lucidità, cercando di capire perché il codice che stavo scrivendo non funzionasse o perché il mio progetto non desse i risultati sperati. Ma non è possibile imparare a diventare un buon problem-solver se non si hanno tanti problemi da risolvere.
ZB: BEN DETTO. HAI UN LATO CREATIVO?
GP: Certo! Mi è sempre piaciuto scrivere, i giochi, la musica - la creatività è il motore centrale di tutto questo. Inizialmente mi addentrai nella programmazione perché volevo creare un videogioco. Sebbene non avessi una mente puramente creativa, la progettazione dei videogiochi richiede un buon mix di conoscenze tecnico-matematiche per garantire che il sistema funzioni correttamente e ingegno per poter creare un mondo unico, coinvolgente e immersivo in cui qualcuno desideri giocare.
ZB: LA PROGETTAZIONE DI VIDEOGIOCHI, DICI? MA ALLORA COME SEI FINITO IN ENGINEERING USA?
GP: A quanto pare, il mondo dei videogiochi è un settore altamente competitivo e di grandi sfide in cui entrare e certamente non accetta neolaureati privi di esperienza. Un giorno spero ancora di vivere il mio sogno dei videogiochi, ma sapevo che non era il mio trampolino di lancio. Volevo imparare, crescere come professionista e ampliare le mie competenze tecniche ed Engineering mi dava l’opportunità di fare tutte e 3 le cose.
ZB: SÌ! CHE COSA FAI IN ENGINEERING USA?
GP: Sono in Engineering Industries eXcellence da poco più di 5 anni. All’inizio ho avuto a che fare con molti ambiti di competenza diversi nella nostra azienda. Tecnologie PLM, MES, SPC. Progetti per la formazione sul software di produzione, convalida della soluzione, integrazione di sistemi. Clienti nel settore degli alimenti e bevande, dispositivi medici, petrolio e gas, energia, produzione chimica. Sono molto grato di questa varietà di esperienze, perché mi ha aiutato a sviluppare una comprensione approfondita dei processi sia di produzione che di implementazione delle soluzioni. Questo è stato cruciale per il mio successo come esperto di progettazione funzionale.
Progettazione funzionale presso Engineering Industries eXcellence
ZB: OH SÌ, LA BUONA VECCHIA PROGETTAZIONE FUNZIONALE. MI RIDICI CHE COS’È?
GP: Progettazione funzionale significa prendere un requisito business, ossia ciò che il cliente in definitiva vuole che il software faccia, e tradurlo in specifiche tecniche che gli sviluppatori possano capire in base al sistema con cui stanno lavorando. La progettazione funzionale è il momento del vero allineamento tra business e IT e come esperto di progettazione funzionale sono responsabile di assicurare che niente vada perso nel passaggio.
ZB: PENSO DI CAPIRE…
GP: Ad esempio, supponiamo che il cliente voglia un programma dove inserire 2 numeri e il computer fornirà una somma. L’esperto di progettazione funzionale prenderà tale requisito business e e lo trasformerà in una serie di casi d’uso, o specifiche funzionali, che gli sviluppatori possono seguire per conseguire l’obiettivo finale. Dunque:
- Questa è l’interfaccia che dovresti avere;
- Dovresti avere due campi;
- Hai bisogno di questo pulsante per cliccare invia;
- Quando l’utente finale clicca, dovrebbe succedere questo.
Ovviamente, quando forniamo una soluzione IT di produzione avanzata queste specifiche sono molto più complesse e complete.
ZB: COME FUNZIONA IL PROCESSO DI PROGETTAZIONE FUNZIONALE? ABBIAMO UN APPROCCIO SPECIFICO IN ENGINEERING USA?
GP: Le tempistiche e la portata di ogni progetto sono diverse, ma in generale, seguiamo una metodologia agile in Engineering Industries eXcellence. Questo è un approccio basato sullo sprint e vale sia per la progettazione funzionale che per gli aspetti di sviluppo software del nostro processo. Uno sprint copre una fetta dei requisiti di business tratti da un lungo elenco. Fondamentalmente diciamo “Per questo sprint, che durerà x, ci concentreremo su x requisiti e li faremo funzionare”. Il vantaggio del metodo agile è che permette una rapida prototipizzazione. Quanto più brevi sono gli sprint, meno lavoro effettui per ogni sprint, tanto più spesso il cliente può vedere l’avanzamento e dare un feedback. Al contrario, l’approccio a cascata rende più difficile e dispendioso in termini di tempo apportare le modifiche. È molto più facile modificare un progetto dopo uno sprint più breve che cambiare qualcosa dopo 8 mesi di sviluppo, specialmente se il cliente ha avuto la possibilità di osservare o usare il prodotto. Ogni prodotto cambia in un modo o in un altro, una volta che il cliente riesce ad avere una migliore visione dell’obiettivo finale.
ZB: MA SE LO SVILUPPO AGILE NON AVESSE SVANTAGGI, SAREBBE L’UNICO METODO DISPONIBILE. QUALI SONO GLI ASPETTI NEGATIVI?
GP: I progetti complessi con un numero elevato di requisiti non sono sempre facilmente separabili in sprint. Il lato negativo del metodo agile è che spesso richiede di disaccoppiare alcune fasi dei progetti che non dovrebbero essere disaccoppiate, tutto per mantenere uno sprint di dimensioni ragionevoli. Ad esempio, potresti avere un gruppo di funzionalità che sono tutte correlate alla programmazione degli ordini o alla gestione delle scorte o altro, ma quel gruppo è troppo grande per essere gestito in un singolo sprint, quindi devi suddividerlo. Di conseguenza vi è il rischio che ciò che accade nel secondo sprint possa influenzare negativamente quello che è stato fatto nel primo, richiedendo più tempo per le correzioni e i nuovi test. Vi è anche molta pressione perché gli sprint agili iniziali forniscano qualcosa che possa passare molto precocemente in fase di sviluppo. Talvolta, questo significa trascorrere meno tempo su framework e strumenti organizzativi, il che può finire per rallentare lo sviluppo lungo la linea. È qui che le nostre relazioni con gli strumenti esistenti e le partnership con altre aziende diventano preziose. Esse forniscono molto del framework preesistente, quindi possiamo passare direttamente a soddisfare le esigenze dei clienti. Ma il più delle volte, i vantaggi del metodo agile e di avere un feedback dai clienti con la maggior frequenza possibile durante un programma superano gli aspetti negativi e portano alla consegna di una soluzione finale migliore e più efficace. E quindi rimaniamo fedeli a questa.
ZB: COSA RENDE UN PROGETTISTA FUNZIONALE UN VALIDO ESPERTO?
GP: L’esperto di progettazione funzionale è un collegamento critico tra il cliente che acquista la tecnologia e il team di sviluppo che costruisce il software. Quale mediatore principale tra il business e il software, hai molto controllo sulla buona riuscita della struttura di una soluzione. Dato questo potere, devi considerare entrambi i lati in ogni fase del lavoro. Devi considerare non solo come un progetto si presenterà visivamente per l’utente finale, ma anche come (e se) può essere sviluppato, testato e supportato. Talvolta quello che va bene per un lato non va bene per l’altro. Inoltre, devi sempre cercare di capire che cosa darà i risultati migliori a lungo termine per la progettazione. Puoi progettare qualcosa con facilità se non hai vincoli e semplicemente caricare un numero infinito di requisiti sul team di sviluppo. Ma devi assicurarti che i tuoi sviluppatori abbiano abbastanza tempo nel loro sprint per programmare quello che tu progetti. Al tempo stesso, devi considerare come quel progetto verrà testato. Se progetti eccessivamente ogni aspetto di un requisito, si verrà a creare uno scenario molto impegnativo da supportare per la validazione. Cerchi di capire quanto del progetto sia esplicito e vincolante, quanto debba essere aggiunto per buone pratiche di programmazione e quanta tolleranza vuoi dare al progetto per assicurarti che tutte le esigenze del business siano soddisfatte. Si tratta di trovare il giusto equilibrio.
ZB: COSA TI CONTRADDISTINGUE COME ESPERTO DI PROGETTAZIONE FUNZIONALE, GUILLERMO?
GP: Nei miei 5 anni alla Engineering Industries eXcellence, sono stato coinvolto in tutti i diversi aspetti di un progetto IT. Ho trascorso molto tempo sul lato della consulenza IT, molto tempo con il software e molto tempo con operatori dell’area produttiva. Ho visto in prima persona come i miei progetti si propagano in quello che succede a livello di base. Questo mi ha permesso di avere una prospettiva unica dietro il quadro generale di un programma. So che gli utenti lo utilizzeranno nel loro lavoro quotidiano e non voglio rendere più difficile il loro lavoro. Capisco questo impatto e lo prendo come una seria responsabilità.
ZB: UN’ULTIMA DOMANDA PER TE, POI TI LASCIO TORNARE ALLE TUE IMPORTANTI MANSIONI. CHE COSA TI PIACE DI PIÙ DI QUELLO CHE FAI?
GP: La progettazione funzionale mi ha dato l’opportunità di imparare contemporaneamente tantissimo delle esigenze dell'industria e della natura dei progetti di sviluppo di software. Mi piace il mio ruolo perché mi permette di comunicare con tutti gli attori coinvolti dai miei progetti, i vertici, gli utenti finali e i miei team di sviluppo e convalida, e di avere un loro feedback. I miei progetti influenzano quello che fanno e il livello di facilità o difficoltà del loro lavoro. Questa interazione mi aiuta a capire dove i miei progetti funzionano e dove stanno fallendo. Questo è stato un fattore chiave dietro la mia crescita come esperto e il continuo miglioramento del lavoro che produco.
