Karl Lagerfeld’s design specifications

Original Sketch by Karl Lagerfeld - Special Collections FIT

Se siete sviluppatori di software, la prossima volta che vi arriva sul tavolo un documento di design specifications di, diciamo, difficile interpretazione e non immediata comprensione prima di dare inizio alle vostre “geek lamentations” e infastidire i colleghi business analyst e solution architect riflettete sul fatto che le povere (si fa per dire) sarte che lavorano per i grandi stilisti di moda come Karl Lagerfeld, per esempio, si devono basare su roba come quella qui a fianco per realizzare gli abiti concepiti nella mente dell’Artista.

Bellissimi, splendidi schizzi ma pur sempre schizzi e guai a sbagliare le proporzioni, l’ampiezza del bavero, la lunghezza della manica.

Comunque Karl è un genio è il suo sito internet è uno dei più originali che abbia mai visto.

Poveraccio il web developer…

BABOK v2.0

Il 31 Marzo 2009 è stata rilasciata la BABOK (Business Analysis Book Of Knowledge) v2.0. I membri della IIBA la possono scaricare gratuitamente dal sito dell’associazione mentre i non iscritti possono acquistarla per 29.95 USD.

L’esame per la certificazione CBAP (Certified Business Analyst Professional) continuerà a essere basato sulla BABOK v1.6 fino al 31 Luglio 2009, dopodiché seguirà la versione 2.0.

La presentazione SlideShare qui sotto vi spiega quali sono i passaggi necessari per candidarsi all’esame CBAP.

La forma e il contenuto

Dato che mi piacciono le definizioni operative dirò che a mio parere lo scopo primario per cui qualunque tipo di scritto viene creato è di essere letto.

E dunque chi scrive, dovrebbe sforzarsi il più possibile di rimuovere ogni ostacolo incontrato dal lettore nell’accedere al contenuto.

Quando un contenuto arido, ostico, asettico è già di per sé un ostacolo alla lettura occorre agire sulla forma.

I signori di Infomap hanno alcuni brillanti consigli da darvi per presentare in forma quasi gradevole e invitante il vostro prossimo arido, ostico e asettico documento tecnico.

Guardate che differenza fa presentare un tema piuttosto indigesto come la conformità alle prescrizioni della Food&Drug Administration prima e dopo la cura Infomap: FDA Compliance.

Altri esempi sono disponibili sul sito Infomap qui insieme a un’interessantissima demo sull’importanza della forma e del formato quando si scrivono documenti tecnici (e non solo).

Project Premortem Analysis

In questo articolo del 1989 (“Back to the Future: Temporal Perspective in the Explanation of Events”)  Mitchell, Russo e Pennington riportano i risultati di una ricerca secondo la quale immaginare che un evento sia già accaduto consente di incrementare del 30% la capacità di prevederne future conseguenze.

Su questa scoperta si basa l’idea dell’analisi pre-mortem, un metodo per aiutare la valutazione dei rischi in un progetto, descritto in questo articolo pubblicato nel numero di Settembre 2007 della Harvard Business Review.

A differenza di una tipica sessione di risk assessment nella quale i convenuti si chiedono che cosa potrebbe andare storto, nell’analisi pre-mortem l’assunto è che il paziente è morto e l’obiettivo è spiegare che cosa è andato storto.

Il compito dei membri del team è generare un insieme di ragioni plausibili per il fallimento del progetto.

Una sessione premortem tipica si potrebbe svolgere in questo modo: dopo aver ragguagliato il team circa il piano di progetto, il facilitatore  informa che il progetto è fallito. Nei minuti seguenti, ciascun componente del team indipendentemente dagli altri elenca una lista di ragioni che spieghino il fallimento.

Nella fase di revisione, il facilitatore chiede a ciascun membro del team, a cominciare dal project manager, di elencare una ragione differente sino a che non siano state registrate tutte le opinioni.

Una volta raccolti tutti i contributi, il project manager passa in rassegna la lista e riflette su come rafforzare il piano di progetto.

Anche quest’ultima fase può essere svolta coinvolgendo il team e utilizzando tecniche quali per esempio il brainstorming.

Business Analysis Certification Program: Facilitation Skills

IIBA® is a registered trademark owned by International Institute of Business Analysis.

Ho dato ieri il secondo esame della serie, quello relativo al corso denominato “Facilitation Skills for Business Analyst” (superato con un bel 45/45, punteggio in cui non speravo, data l’abbondanza di domande situazionali e deduttive).

E poiché mi sono iscritto all’IIBA® sono ora autorizzato a utilizzarne il logo.

Questo secondo corso della serie di quattro (ho parlato qui del primo “Business Analysis Fundamentals”) verte principalmente sulla Knowledge Area denominata “Requirements Communication” e mira a sviluppare nel Business Analyst le capacità di facilitazione di tutte le dinamiche del processo di sviluppo del prodotto (Product Life Cycle) che si articolano nelle altre 5 aree di conoscenza della BABOK^®.

Si trattano quindi argomenti come:

• fondamenti del processo di comunicazione, ciò che lo ostacola, ciò che lo facilita
• lo sviluppo di un requirements communication plan
• le tre principali categorie in cui cadono le tecniche di raccolta dei requisiti (Requirements Elicitation), ovvero: mirate (targeted elicitation come interviste, job shadowing, survey), di gruppo (group elicitation ossia brainstorming, workshop, focus group, sessioni di prototipizzazione), fisiche (physical elicitation ovvero analisi documentale, reverse engineering e analisi delle interfacce)
• best practices nella conduzione di meeting
• principi di negoziazione e mediazione

Un aspetto fondamentale nella preparazione di un requirements communication plan è la conduzione della cosiddetta “stakeholder analysis” o “analisi dei portatori di interesse”. Ricordo che uno stakeholder è definito come un individuo o categoria di individui che ha un interesse in un’attività economica, organizzazione d’impresa o progetto e ha modo di influenzarli positivamente o negativamente. Esempi tipici sono gli utenti finali, i clienti, i vari livelli di management, gli appartenenti all’organizzazione IT, gli sponsor del progetto, i “subject matter expert” (SME) o “esperti in materia”, ecc.

Nella nostra organizzazione siamo soliti riconoscerne un ristretto sottoinsieme che spesso e volentieri comprende solo il project manager presso il cliente (ossia la controparte del nostro PM) e gli utenti finali.

La stakeholder analysis si articola in una serie di passaggi che mirano a identificare tutti i portatori di interesse rilevanti ai fini della conduzione del progetto:

1. Identificare tutti i possibili stakeholder
2. Tracciare le rispettive attitudini nei confronti del progetto
3. Selezionare gli stakeholder chiave (key stakeholders)
4. Analizzare le fonti di preoccupazione degli stakeholder
5. Identificarne i fattori di successo
6. Sviluppare strategie di comunicazione con i key stakeholders
7. Documentare il tutto nel Requirements Communication Plan

A tal fine risultano particolarmente utili alcuni strumenti tramite i quali rappresentare in forma graficai passaggi chiave della stakeholder analysis.

Per quanto riguarda la rappresentazione delle attitudini degli stakeholder nei confronti del progetto, si può utilizzare la Stakeholder Attitude Chart:

Nome, Posizione	100% contrario	Moderatam. contrario	Neutrale	Moderat. a favore	100% a favore
Mario Rossi, Finance			Ο→	→	→χ
Piero Bianchi, Marketing	Ο →	→	→χ

Il simbolo “Ο” indica la posizione in cui attualmente si trova lo stakeholder mentre “χ” indica dove abbiamo necessità che si sposti per assicurare il successo del progetto.

La selezione degli stakeholder chiave avviene attraverso una matrice 2×2 nella quale i portatori di interesse vengono posizionati sulla base della loro influenza/potere/autorità (ordinate) e del loro livello di attenzione/preoccupazione nei confronti del progetto (ascisse).

Ne risultano quattro quadranti associati alle combinazioni: elevata influenza / scarsa preoccupazione, scarsa influenza / elevata preoccupazione, scarsa influenza/scarsa preoccupazione, elevata influenza / elevata preoccupazione: gli individui o le categorie che ricadono in quest’ultimo quadrante sono i key stakeholders.

L’analisi delle fonti di preoccupazione si può effettuare tramite una tabella come quella riportata qui sotto che consente di identificare l’impatto del progetto su diverse aree di interesse e sui relativi stakeholders.

In questa fase, per ciascuna area di interesse sulla quale il progetto ha impatto significativo, è necessario abbozzare una strategia di risposta o mitigazione del rischio corrispondente.

Aree di Preoccupazione	Modesto impatto	Moderato impatto	Elevato impatto	Stakeholder interessati
Struttura organizzativa			X	Mario Rossi, Giorgio Verdi
Misura delle performance			X	Piero Bianchi
Competenze acquisite		X		Piero Bianchi

Infine, nella cosiddetta Stakeholder Solution Matrix è possibile combinare le informazioni raccolte nei passaggi precedenti e schematizzare possibili strategie per il comportamento da tenere con ciascuno degli stakeholders:

Stakeholder	Preoccupazioni	Fattori di successo	Come influenzarlo	Chi può influenzarlo
Mario Rossi,Finance	Inadeguatezza ai nuovi compiti	Training	Illustrazione del programma di training e crescita professionale	Responsabile formazione

Business Analyst Certification Program

IIBA® is a registered trademark owned by International Institute of Business Analysis.

Ho iniziato un paio di mesi fa il percorso di certificazione per Business Analyst offerto dall’ International Institute for Learning: Business Analyst Certification Program (BACP).

Il corso verte sul contenuto del Business Analysis Body of Knowledge (BABOK^® v1.6, sta per uscire la v2.0), l’equivalente della PMBOK dei project manager. Tuttavia la certificazione BACP non è equivalente alla certificazione Project Manager Professional  e per diventare un business analyst professionista occorre acquisire la certificazione CBAP^® (Certified Business Analyst Professional) fornita dall’International Institute for Business Analysis (IIBA^®) (sorta di equivalente del Project Management Institute) attraverso un esame simile a quello richiesto per i PMP.

La spina dorsale del percorso di apprendimento è costituita dalle 6 Knowledge Areas della BABOK^®:

• Enterprise Analysis (EA)
• Requirements Planning and Management (RP&M)
• Requirements Elicitation (RE)
• Requirements Analysis and Documentation (RA&D)
• Requirements Communication (RC)
• Solution Assessment and Validation (SA&V)

La versione mind map delle knowledge areas e dei relativi task la trovate qui: BABOK^® Knowledge Areas

Il programma BACP si articola in 4 corsi:

• Business Analysis Fundamentals: 12 ore (se siete già PMP, dà diritto a 12 PDU)
• Facilitation Skills: 18 ore (18 PDU)
• Writing and Managing Requirements Documents: 12 ore (12 PDU)
• Business Processes Modeling:18 ore (12 PDU)

I corsi si seguono online attraverso il meccanismo delle virtual classroom che devo riconoscere essere piuttosto efficace.

Ogni corso è seguito da un esame della durata di un’ora da effettuarsi online entro trenta giorni dal completamento del corso corrispondente: 30 domande sul contenuto del corso, della BABOK^® e su situazioni da analizzare.

Ho superato il primo esame due settimane fa (punteggio 28/30).

Il Business Analyst non coincide esattamente con il ruolo di Solution Architect, presente nella nostra organizzazione, che si fa carico di trasformare i requisiti in una soluzione software nell’ambito di un progetto. Il BA è invece la figura preposta a far emergere, documentare, mantenere, verificare e validare i requisiti ed è più coinvolto nel Product Life Cycle (PdLC) più che nel Project Life Cycle (PLC).

Tuttavia, le conoscenze, tecniche e best practices del ruolo del BA sono un prezioso strumento anche per una figura di Solution Architect come la nostra. Sullo sviluppo di queste pratiche penso che baserò gli obiettivi del team per l’anno prossimo. Salvo cataclismi…

Bazzicando il sito dell’International Institute for Business Analysis mi sono imbattuto nel blog del loro istituto, molto interessante per gli addetti ai lavori.

Lo trovate qui: http://blog.theiiba.org/