Il censimento dei web project manager 2008

Sono da poco usciti i risultati del sondaggio svolto dalla webzine A List Apart che per il secondo anno cerca di descrivere nel dettaglio le professioni di chi lavora con il web.

L’anno scorso ho isolato dal sondaggio i tratti salienti della professione del web project manager ed è quindi interessante confrontare alcune delle ipotesi emerse con i risultati del 2008.

Molte le conferme. Il web project manager:

  • segue un percorso formativo che nasce nella maggioranza dei casi dalla programmazione;
  • lavora solitamente per realtà di piccole dimensioni;
  • ha prevalentemente un’età compresa tra i 30 e i 40 anni;
  • lavora in azienda piuttosto che come libero professionista.

Vediamo nel dettaglio quello che è emerso. Alcune domande del sondaggio sono state riformulate rispetto al 2007 e un confronto diretto è pertanto solo indicativo.

In azienda o come libero professionista

Job title by workplace (2008)

Iniziamo da un dato che non è stato analizzato lo scorso anno: la percentuale di web project manager che lavorano in azienda rispetto ai liberi professionisti. Tra le diverse professioni web, il web project manager si trova più comunemente a lavorare in azienda piuttosto che esercitare la libera professione.

Il dato non stupisce e ne ho già parlato a proposito di una domanda nelle FAQ (Il web project manager è un consulente esterno all’azienda o un collaboratore interno?): il ruolo di coordinamento e gestione dei progetti del web project manager, le frequenti interazioni con il gruppo di lavoro e i clienti richiedono la sua costante presenza in azienda.

Esistono comunque casi in cui il web project manager è libero professionista; lavora per uno o più periodi di tempo (solitamente semestri) per aiutare le aziende con cui collabora a migliorare la gestione progetti.

Percentuale di web project manager

Job title (2007)

Job title (2008)

Tra i due anni non si apprezzano significative differenze relativamente alla percentuale di web project manager paragonata alle altre professioni.

Impressionante la percentuale che non ricade in nessuna delle numerose categorie indicate, più di un quarto. Sarebbe interessante capire quale sia la professione svolta.

Distribuzione dei web project manager per tipo di organizzazione

Job title distribution by organization type (2007)

Job title distribution by organization type (2008)

Il grafico indica la percentuale di web project manager impiegata nei diversi settori organizzativi. Rispetto allo scorso anno sono cambiate e sono state accorpate alcune categorie.

È possibile notare come la percentuale più alta di impiego (8.4%) sia presso piccole realtà. Una conferma dell’indicazione emersa lo scorso anno: il web project manager si trova a lavorare soprattutto per startup, realtà in cui rilasci frequenti e timing serrati richiedono la presenza di una figura che garantisca il raggiungimento degli obiettivi.

Distribuzione dei web project manager per gruppo di età

Job title distribution by age group (2007)

Job title distribution by age group (2008)

Confermato il trend per quanto riguarda l’età. Non si nasce web project manager (o non si dovrebbe), ma lo si diventa dopo aver maturato una certa esperienza, a partire dai 30/35 anni.

Distribuzione per sesso

Gender distribution by job title (2007)

Gender distribution by job title (2008)
Piccolo incremento per quanto riguarda il ruolo delle donne nel web project management, aumento confermato in quasi tutte le altre professioni, segno forse della maggiore visibilità data quest’anno al sondaggio.

Percentuale di lavoratori con retribuzione superiore a 100.000 dollari

Percentage of job title holders who earns salary of 1000k (2007)

Percentage of job title holders who earns salary of 1000k (2008)

Nessuna variazione di rilievo. Il grafico, come evidenziato l’anno scorso,  è comunque difficilmente rapportabile alla realtà italiana.

Rilevanza dell’istruzione per lo svolgimento del proprio lavoro

Perceived relevance of education by job title (2007)

Perceived relevance of education by job title (2008)

Cambia la percezione dell’importanza data agli studi.

Il fatto che un po’ tutte le professioni abbiano visto aumentare il dato si può forse giustificare dall’aver meglio espresso la domanda rispetto allo scorso anno. In generale, comunque, poco più del 50% dei rispondenti ha indicato come rilevante il proprio piano di studi nei confronti della professione, suggerendo che sotto questo punto di vista c’è ancora molto da fare.

Soddisfazione per il proprio lavoro

Job satisfaction by job title (2007)

Job satisfaction by job title (2008)

Le percentuali aumentano di molto rispetto all’anno scorso: forse anche in questo caso la domanda era stata mal posta nel 2007.

In percentuale però la soddisfazione dei web project manager, se paragonata alle altre professioni, aumenta in proporzione minore, tanto che dal primo posto si passa a metà classifica.

Impegnativo trarre una conclusione vista la variabilità in così poco tempo. Probabilmente il ruolo del web project manager, in alcuni contesti, non trova lo spazio che merita.

Ma forse è anche tempo che il project management maturi da disciplina che relega tutte e sole le responsabilità al project manager a vera e propria fonte di leadership e visione (di questo parlerò in parte nel mio intervento a Firenze il prossimo mese)

La percentuale di web project manager che scrive in un blog

Prelevance of blogging by job title (2007)

Prelevance of blogging by job title (2008)

Il web project manager è fanalino di coda quando si parla di scrivere in un blog.

Come indicato già lo scorso anno, il motivo può essere legato alla difficoltà di parlare di una professione molto legata ai rapporti personale e meno alla “scienza”. Difficile, ma non impossibile. Un vero peccato.

Partecipazione a eventi formativi

Perceived relevance of education by job title (2007)

Perceived relevance of education by job title (2008)

Anche questo risultato è in linea con lo scorso anno.

Il web project manager è una tra le figure professionali che più partecipa ad eventi formativi. La percentuale è molto vicina a quella di professionisti che per cultura e necessità sono abituati a una formazione continua, come i designer di interfaccia e i diversi tipi di consulenti.

L’eterogeneità di competenze richieste a un web project manager, sia in termini manageriali sia tecnici è sicuramente un fattore che giustifica queste percentuali.

Lacune professionali

Perceived back end skill gaps by job title (2007)

Perceived back end skill gaps by job title (2008)

Come per l’anno scorso, mi limito a riportare uno solo dei 4 grafici che indicano le difficoltà che i web project manager incontrano nello svolgimento del proprio lavoro.

Relativamente alla programmazione lato server meno del 17% dichiara di avere lacune rispetto al totale. Questo dato, se confrontato con la programmazione lato client, conferma una tendenza anticipata lo scorso anno, ovvero che web project manager si diventa molto spesso partendo da ambiti che sono vicini alla programmazione, più che dal design o al marketing.

Perché i designer falliscono gli obiettivi

Scott Berkun ha recentemente pubblicato i risultati di un sondaggio utili per evidenziare i motivi che possono condurre i designer a realizzare prodotti non in linea con gli obiettivi.

Ecco le principali cause di fallimento secondo gli intervistati (tenete conto che il pubblico di Scott Berkun è composto in gran parte da project manager):

  1. Non designer che prendono decisioni relative al design;
  2. Manager che prendono decisioni senza un background appropriato;
  3. Designer che non compiono le opportune ricerche prima di iniziare il lavoro;
  4. Non è concesso tempo sufficiente per pensare nel lungo termine;
  5. Mancanza di ricettività ai feedback;
  6. Scarsa conoscenza delle logiche di business;
  7. Lo “user centered design” è considerato una disciplina importante, ma solo a parole;
  8. Non è concesso di sbagliare e neppure di sperimentare;
  9. Al designer non è data autonomia nella gestione del progetto;
  10. Si fa troppo affidamento a un unico stile di design.

Dal mio punto di vista di web project manager concordo con quasi tutti gli elementi di questa lista e ammetto che in passato ho forse preteso un po’ troppo controllo sulla parte creativa di un progetto (applicando di fatto quanto riportato al punto 1).

I risultati del sondaggio di Berkun ricordano tra l’altro molto da vicino i fattori che limitano l’influenza del design in azienda evidenziati da Luke Wroblewski e Tom Chi, soprattutto la mancanza di visione sull’importanza del design. 

Il tema è importante: ancora oggi il design è considerato un semplice abbellimento dell’interfaccia su cui chiunque può dare la propria autorevole opinione. L’analisi dell’applicazione si concentra spesso sulle sole funzionalità tecniche e di programmazione, ritenute il vero cuore dell’applicazione.

Attenzione però: se fino a qualche anno fa il cliente era conquistato da un prodotto che faceva quanto richiesto, oggi lo dà per scontato. A parità di funzionalità vince la soluzione più semplice da utilizzare, armoniosa, organizzata con logica, bella. Una sfida tutt’altro che banale.

Imparare dai propri errori

La scorsa settimana ho ricevuto questa email da un nostro cliente:

Buongiorno [responsabile commerciale] e Antonio,

vi comunichiamo il nostro disappunto riguardo il vostro comportamento e il lavoro finora svolto.

Riteniamo che le numerose richieste di modifica in corso d’opera che vi stiamo sottoponendo siano la diretta conseguenza del vostro lavoro. Ci riferiamo al fatto che noi vi avevamo chiesto a_b_c e invece voi ci avete proposto d_e_f. Potrete concordare con noi che in questo modo non è stato raggiunto il nostro obiettivo. Ci troviamo ora a dover mettere in linea un prodotto che non è quello che volevamo.

La nostra critica si basa fondamentalmente sulla mancanza di idee e proposte da parte vostra che siete gli esperti del settore e sul vostro atteggiamento di mera esecuzione di ordini a seguito delle nostre richieste, che si basano sull’esperienza nel nostro settore, che a quanto pare non si possono sempre tradurre in campo informatico.

E’ la prima volta che ricevo una missiva del genere: c’è da rimanere sconcertati, vero?

Un messaggio con questo tono non arriva come un fulmine a ciel sereno, ma è una diretta conseguenza a una nostra email in cui, senza tanti complimenti, abbiamo chiesto al cliente di permetterci di chiudere le diverse attività in cantiere senza aggiungerne in continuazione di nuove. Non si fa così. Questo è però solo l’ultimo di una serie di errori che, da una parte e dall’altra, hanno caratterizzato la vita dell’intero progetto.

Prima di cominciare ad analizzare cosa non ha funzionato vale però la pena di inquadrare il progetto nel suo contesto e fornire qualche cifra di riferimento:

  • i primi incontri per la definizione del progetto insieme al cliente si svolgono a Giugno 2007, più di un anno fa;
  • il progetto prevede la realizzazione di un sito di presentazione, ricerca, prenotazione e di ecommerce non standard, che attinge ad anagrafiche e listini presenti in gestionali usati dal cliente;
  • il sito va a sostituire una precedente versione, anche questa realizzata da noi;
  • dopo aver raccolto gli elementi utili da più fonti e aver svolto diverse analisi, ad Agosto del 2007 è presentato e motivato al cliente un prototipo funzionante dell’intera applicazione. Prototipo lasciato a disposizione per ogni valutazione;
  • l’impegno previsto per la realizzazione del progetto è stimato in circa 350 ore uomo, con data di consegna 15 Febbraio 2008.

Il cliente, anche se non sembrerebbe leggendo l’email, è stato coinvolto in ogni fase del progetto:

  • la raccolta di elementi utili per la progettazione del sito è partita da una serie di incontri in cui il cliente ha espresso le proprie esigenze;
  • abbiamo presentato un prototipo funzionante dell’applicazione condividendo ogni scelta;
  • abbiamo realizzato, in un ambiente accessibile al cliente, circa 5 rilasci intermedi su dati reali per verificare le diverse funzionalità

Sembrerebbero le basi su cui realizzare un prodotto apprezzato. L’email ricevuta non lascia però spazio ad alcun dubbio: il cliente è insoddisfatto, è convinto che questo non sia il prodotto richiesto e manifesta chiari dubbi sulla competenza della società che li ha accompagnati in questo percorso. Come è possibile?

Se analizziamo più approfonditamente quello che è successo nell’arco di questi 12 mesi si capisce che in realtà di errori ne sono stati commessi tanti, troppi, da ambo le parti. Ecco i principali:

  • Errore 1: c’è bisogno di un sito nuovo (?) – Tutto comincia quando il cliente manifesta perplessità per alcune problematiche del sito attualmente online. Si tratta di alcuni bug e soprattutto di problemi relativi all’usabilità e non coerenza dell’interfaccia di navigazione. Il cliente viene convinto a riprogettare da capo l’intero sito, promettendo un’applicazione più usabile, più veloce, migliore. Viste le richieste, sarebbe forse stato più semplice sistemare quanto era già online.
  • Errore 2: ti costa 100. No 300. Vabbè facciamo 200 – Al cliente è proposto un investimento contenuto, il tutto senza verifiche. Dopo una breve sessione di macroanalisi si evince che l’impegno è invece circa tre volte rispetto quanto promesso. A questo punto inizia il tira-e-molla che porta il prezzo finale a circa il doppio, una via di mezzo che non fa felice nessuna delle due parti.
  • Errore 3: un cliente fantasma – Non abbiamo spiegato chiaramente al cliente che avremmo avuto bisogno, per tutta la durata del progetto, del suo apporto. Trovandosi davanti a un prototipo funzionante alcuni clienti sono infatti convinti che sia già stato fatto tutto, che sia sufficiente procedere con l’implementazione e vedersi consegnato il progetto dopo alcuni mesi. Nel documento di progetto va invece quantificato l’impegno richiesto al cliente in termini di verifica funzionalità, test, prove sul campo e supporto per le inevitabili domande che nascono nello sviluppo di tutti i giorni. Il cliente ha inoltre risposto con enorme ritardo ad ogni comunicazione che gli è stata inviata. Alcune email non hanno ricevuto risposta, altre dopo un mese, con casi di risposte dopo ben 5 mesi rispetto alle richieste. Abbiamo più volte sollecitato il cliente, via email e verbalmente, senza alcun risultato apprezzabile.
  • Errore 4: referenti aziendali non all’altezza – Punto cardine di un progetto di successo è l’interazione con referenti aziendali competenti e in grado di farsi portavoce delle richieste dei consulenti e dell’azienda per cui lavorano. Così non è stato. Il progetto è stato affidato a un dipendente part-time dell’azienda che non è riuscito a trasmettere dubbi, perplessità, richieste, proposte. Come se non bastasse un altro attore del progetto, che ha seguito la precedente realizzazione del sito, lavora part-time con orario di lavoro non coincidente con quello del referente principale. Non è sempre facile accorgersi della presenza di un referente non motivato, ma quando succede l’azienda va immediatamente informata oppure la situazione, come in questo caso, precipita. E, nella maggior parte dei casi, è il web project manager a dover alzare la mano.
  • Errore 5: il software si modifica anche all’ultimo minuto – Il software è un prodotto di ingegneria. Il fatto che un progetto web sia accessibile da un monitor fa sì che il cliente non sempre riesca a valutare, diversamente da altre opere di ingegneria, l’impatto di alcune richieste di modifica. Aver presentato un prototipo funzionante ha lo scopo di confrontare proposte e punti di vista, ma anche di limitare il numero di modifiche in corso d’opera. In realtà nulla è scolpito nella pietra e, come ben sa chi adotta metodologie di sviluppo agile, è impossibile prevedere ogni caratteristica a priori. Il problema in questo caso è ancora una volta legato alla mancanza di feedback da parte del cliente in tempi accettabili. Le richieste di modifica sono pervenute mesi dopo che la funzionalità era stata consegnata per verifica.
  • Errore 6: non serve capire chi è il visitatore – Al cliente è stato suggerito, prima ancora di iniziare l’analisi del sito, di compiere alcuni fondamentali studi relativi agli utenti a cui il sito si rivolge, alle loro aspettativi e modalità di ricerca. Per motivi di budget, ma non solo, il cliente si è limitato a indicare alcuni siti concorrenti che presentano, rispetto alla versione attualmente online, alcuni spunti di miglioramento. Questa è una strategia che non paga, perché a sito terminato rimane il dubbio che non tutto sia stato realizzato come si sarebbe dovuto.
  • Errore 7: il sito non fa quello che voglioIl sito non deve fare quello che vuoi tu, ma quello che vuole il tuo utente (vedi punto precedente). Il nostro interlocutore, nel giustificare il nostro pessimo lavoro, parla di sito che non voleva, di sito che non corrisponde alle sue attese. Sbaglia due volte: perché ogni sua indicazione è stata presa in considerazione e perché cerca di mettersi nei panni di un visitatore che in realtà non conosce e si fa ingannare da dettagli e particolarità che sarà l’unico a notare.

Realizzare un progetto che soddisfi ambo le parti, soprattutto un progetto che richiede alcuni mesi di lavoro, è un’attività che il cliente e l’azienda di consulenza devono affrontare sapendo di mettere in campo tutto l’impegno necessario. Referenti non motivati, stime di costo in continua variabilità, scorciatoie di progettazione, tempi non rispettati sono gli elementi che piano piano, giorno dopo giorno, minano la riuscita di un progetto che è apparentemente solido. Esattamente quello che è successo in questo caso.