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.

WordPress per un blog aziendale

Che la gestione di un blog aziendale richieda competenze e accorgimenti diversi da quelli per un blog a carattere personale è evidente e la documentazione in questo senso non manca (ne ho parlato a proposito dei suggerimenti di lettura per il 2007; un’altra fonte è l’intervento consigli a un giovane blogger aziendale).

Lo stesso discorso vale anche per il software: non è sufficiente l’installazione standard di una piattaforma di blogging per gestire un blog aziendale, soprattutto perché questi strumenti sono pensati prima di tutto per esigenze personali.

Negli ultimi mesi ho fatto un po’ di esperienza con progetti di startup per blog aziendali, in particolare gestiti con WordPress (nella versione 2.2 e 2.3), esperienza che vorrei condividere in qualche dettaglio.

Template personalizzato

Potete decidere di utilizzare un template di WordPress scaricato dalla rete e variarne pochi elementi, come per esempio il logo e i colori. Ma non farete una grande figura. La scelta migliore è quella di personalizzare il blog secondo i canoni del sito aziendale. Questo non vuol dire che la grafica del blog debba essere identica a quella del sito corporate, ma sarebbe bene che alcuni elementi, come per esempio i font, le scelte cromatiche e i rimandi alle sezioni del sito adottassero lo stesso stile.

E’ bene che il template ricordi il sito aziendale, ma non realizzatelo identico: l’utente che naviga le due realtà potrebbe non orientarsi, per esempio non capendo cosa cliccare per tornare alla home del weblog rispetto alla homepage del sito.

Se decidete comunque di partire da un template di base su cui lavorare – scelta consigliabile soprattutto per chi è alle prime armi – impiegate del tempo per analizzare con pazienza il codice. Al di là delle possibilità di localizzazione di WordPress in italiano con l’impiego di opportuni file, per esempio, è quasi certo che alcuni template contengano, cablati nel codice, richiami in lingua inglese. Varrebbe la pena sostituirli.

Non fatevi poi tentare ed eliminare i credits verso il sito di WordPress. Se volete (e l’avete concordato con il cliente) aggiungete la vostra paternità al template, ma non sostituitevi ai creatori della piattaforma di blogging.

Il dominio

La soluzione migliore, potendo gestire un dominio di terzo livello, è che il weblog sia ospitato a un indirizzo del tipo blog.azienda.it. In alternativa, in dipendenza comunque dell’infrastruttura aziendale, è accettabile un percorso del tipo azienda.it/blog.

Weblog multiautore e moderazione

Non è consigliabile, soprattutto nei primi mesi che seguono la messa online del weblog, dare a ogni autore la possibilità di pubblicare in autonomia i propri interventi nel blog. Una soluzione efficace, almeno per il primo periodo, è quella di permettere agli autori la sola possibilità di salvare l’intervento tra le bozze, per poi lasciare a una figura di moderatore o amministratore la facoltà di portare online i diversi interventi. Questo atteggiamento a prima vista dispotico è in realtà prezioso in molti modi:

  • per correggere, nelle prime fasi, contenuti ambigue o dai risvolti potenzialmente pericolosi
  • per dare alle diverse voci del weblog uno stile e direzioni comuni
  • per programmare la pubblicazione dei diversi interventi, così che a periodi di intensa attività non ne seguano altri senza alcun intervento. In aziende che lavorano “a commessa” questa situazione è abbastanza comune, per cui vale la pena di preparare alcuni interventi evergreen da usare in questi casi

Per limitare gli autori all’inserimento di contenuti in bozza è consigliabile assegnarli al ruolo Contributor. Così facendo l’autore ha la possibilità di salvare l’intervento, ma non di pubblicarlo online. Con WordPress 2.3, inoltre, il Contributor può scegliere, oltre a salvare l’intervento nelle bozze, di richiederne la “valutazione per revisione” (potete trovare una descrizione di questa funzionalità nel mio intervento Uno sguardo a WordPress 2.3). In questo modo l’amministrazione ha la possibilità di distinguere quelle che sono normali bozze dagli interventi che sono in attesa di essere pubblicati.

Assegnare il ruolo di Contributor sembra quindi un’ottima soluzione, ma così facendo il redattore perde una funzionalità permessa solo agli amministratori e agli autori, ovvero la possibilità di caricare immagini, foto e documenti tramite il modulo di upload di WordPress.

L’architettura dei ruoli e delle capacità degli utenti in WordPress 2.2 è fortunatamente estensibile e configurabile in ogni dettaglio, caratteristica sfruttata da alcuni interessanti plugin. Tra questi vale la pena segnalare Role Manager, che permette di assegnare a ogni gruppo di utenti specifiche capacità.

Il plugin Role Manager in azione

Ora ogni autore ha tutto quello che serve per realizzare in autonomia un proprio intervento da salvare nelle bozze (o di cui richiedere approvazione).

Se l’amministratore non si collega a WordPress, però, non ne verrà mai al corrente.

Anche in questo caso può essere di aiuto un plugin, Draft Notification, che permette di ricevere alla casella di posta elettronica definita in WordPress un messaggio contenente il titolo e l’autore dell’intervento ogniqualvolta ne venga inserito uno. La soluzione non è però ottimale, perché viene inviata un’email anche a ogni salvataggio (incluso quelli automatici) dell’intervento, generando anche 5/10 email per ogni intervento inserito. Non resta che sperare in un aggiornamento del plugin, configurando nella contingenza una regola del proprio programma di posta per eliminare i messaggi di aggiornamento, che sono contrassegnati da un diverso oggetto.

A questo punto WordPress è opportunamente configurato per permettere a più autori di lavorare e un amministratore di moderare i diversi interventi. Tenete comunque conto che gli autori possono leggere il titolo degli interventi degli altri, anche se questi non sono ancora pubblicati. Questo avviene sia nella bacheca dell’utente, sia nella lista degli articoli pubblicati. Come è però facile immaginare, anche qui c’è da tempo un plugin, IWG Hide Dashboard, che nasconde agli autori la bacheca di Worpress.

I classici plugin e qualcosa in più

Nel progettare l’installazione e configurazione di un blog aziendale tornano utili anche plugin impiegati per i blog personali. Tra questi meritano un accenno sicuramente Akismet per quanto riguarda la protezione da commenti e trackback di spam (già incluso nell’installazione base di WordPress) e il plugin di Feedburner per la gestione e verifica degli iscritti ai propri feed Rss. Se avete la possibilità di creare un dominio di terzo livello, può valere la pena configurare Feedburner con le preferenze di MyBrand, così da poter disporre di un indirizzo proprietario per i feed (ad esempio nella forma feed.azienda.it), piuttosto che di un generico http://feeds.feedburner.com/azienda. In questo caso vi garantite la possibilità di abbandonare in futuro Feedburner, magari a favore di qualche nuovo servizio che dovesse nascere, senza rischiare di perdere i visitatori già iscritti ai feed e doverli informare della variazione.

Ci sono poi altri plugin che permettono di aumentare ancora più il livello di personalizzazione di WordPress. Non è questa la sede adatta per parlarne, ma chi fosse interessato può dare un’occhiata a I migliori (o quasi) plugin per WordPress.

Sicurezza

Trattandosi di un blog aziendale vale la pena porre qualche cautela per evitare che i contenuti vengano compromessi o che persone non autorizzate possano autenticarsi. Di sicurezza delle piattaforme di blogging si potrebbe scrivere pagine e pagine. Non l’ho farò io qui, visto che il Worpress Security Whitepaper contiene un’ottima introduzione all’argomento.

Blogging alle conferenze

La mia valigia per il FOWASto ultimando la valigia per il FOWA: macchina fotografica, blocco appunti, batterie, portatile…l’arsenale tecnologico è al completo.

Spero di avere la possibilità di scrivere dalla conferenza e – guarda caso – scorrendo i feed Rss ho trovato questo interessante intervento di Bruno Giussani, Tips for conference bloggers.

C’è il link a un agile manuale in PDF, meno di 10 pagine, ricco di suggerimenti che per chi vuole scrivere per il proprio blog il riassunto di una conferenza durante lo svolgimento.

I suggerimenti, alcuni ovvi, altri meno, sono raggruppati per categorie:

  1. strumenti
    • carica la batteria del portatile
    • ricordati di sederti dove ci sono le prese di corrente
    • guarda che il portatile scalda le gambe (vero!); procurati qualcosa per proteggerle
    • organizzati per tempo
  2. posizione
    • non sederti nelle prime file, perché potresti disturbare, né al centro
    • fai vedere che stai seguendo la conferenza, e non rispondendo alle tue email private
  3. preparazione
    • guarda il programma della conferenza e preparati delle bozze con almeno il titolo dell’intervento, meglio se con il profilo dello speaker e i link al suo blog
    • mettici magari anche una foto
    • prova a iniziare già l’intervento, così partirai con il piede giusto quando sarai costretto, durante la conferenza, a lavorare in multitasking

Mi fermo ai primi 3 punti, perché rischio di fare tardi: leggerò il resto in aeroporto. Intanto date un’occhiata al documento, ne vale la pena.

Ci vediamo!

Uno sguardo a WordPress 2.3

E’ sempre difficile resistere alla tentazione di provare la nuova versione di un programma, soprattutto se è un software, come il caso di Wordress, che si usa ogni giorno. Visto poi che, come dicevo qualche giorno fa, WordPress 2.3 promette di essere ricco di interessanti funzionalità e migliorie, resistere è quasi impossibile.

Ho allora installato una versione beta 1 di WordPress 2.3 evitando però di lavorare sul sito che vedete in linea, ma procedendo alla copia in una sottocartella. Perché quando parliamo di “beta” per un software come WordPress non si intende, come è stato per esempio con Gmail, una versione che ospita solo funzionalità base o che può comportarsi, a volte, come non ci si aspetta. No, installare la versione beta di WordPress vuol dire rischiare di compromettere i dati e non avere neppure la possibilità di ritornare alla versione precedente.

Ho proceduto in questo modo:

  • ho creato una sottocartella nel dominio di Fucinaweb in cui ho copiato la beta di WordPress
  • vi ho copiato dall’attuale sito il contenuto della cartella wp-content, selezionando però a mano i plugin, così da non sovrascrivere quelli della versione 2.3
  • ho esportato il database di Fucinaweb e l’ho reimportato in altra istanza
  • poiché cambia il percorso del blog, è necessario intervenire a mano in una tabella del database, la wp_options. Niente di tremendo per la verità: ho semplicemente trovato le due occorrenze dell’URL del sito e aggiunto la cartella in cui si trova la versione beta
  • ho disabilitato tutti i plugin
  • ho anche configurato per sicurezza WordPress (Opzioni, Privacy) in modo da bloccare motori di ricerca, Technorati e altro, così che il sito di prova non compaia improvvisamente da qualche parte.

Così sono riuscito a ottenere una versione speculare del sito da provare in tranquillità. Ed ecco i risultati con le prime impressioni su questa beta.

Schermata di gestione

La schermata di gestione degli interventi è più funzionale rispetto alla precedente, nel senso che permette una ricerca efficace grazie a una rinnovata maschera posizionata in alto.

image

Come per WordPress 2.2, ciascun autore può vedere il titolo degli articoli pubblicati, presenti e futuri, anche dagli altri. Avrei sperato in un filtro

Inserimento di un intervento

Chi scrive molte bozze troverà un po’ di pulizia: solo le ultime 3 compaiono in alto alla schermata. Le altre sono invece accessibili mediante ricerca.

image

La modifica più attesa riguarda comunque l’inclusione del sistema di tagging, che precedentemente richiedeva plugin esterni. In effetti nella maschera di inserimento è prevista questa possibilità.

image

Non sembra però che i tag già usati vengano “autocompletati” (alla del.icio.us) o che sia possibile far comparire una lista dello storico (alla Ultimate Tag Warrior). Speriamo il tutto sia dovuto solo al carattere di beta 1, perché sarebbe davvero un peccato non disporre di qualche aiuto nella selezione dei tag. Va anche segnalato che questa beta non funziona con l’ultima versione di Ultimate Tag Warrior (c’è qualche variabile definita allo stesso modo che dà errore), per cui il consiglio è di non abilitare il plugin.

Se l’autore non ha i diritti di pubblicazione diretta (è, per esempio, un “contributor”) cambiano, rispetto alla versione 2.2, le opzioni di salvataggio. In particolare compare “submit for review”, che indica la possibilità di richiedere a chi ne ha i diritti, l’amministratore per esempio, di valutare l’intervento per la pubblicazione.

image

E in effetti l’articolo salvato in questo modo è catalogato a parte. Ecco cosa vede l’amministratore dopo il salvataggio da parte di un “contributor”.

image

Sarebbe bello, in futuro, che l’amministrazione e gli altri utenti in grado di valutare questi interventi potessero ricevere anche una notifica via email.

Importazioni

Se già usate Ultimate Tag Warrior per aggiungere i tag ai vostri interventi, sarete felici di sapere che WordPress 2.3 prevede una funzione di importazione.

image

Per prima cosa sono letti i tag dalla tabella di Ultimate Tag Warrior.

image

Poi sono lette le relazioni con gli interventi inseriti e i tag.

image

E infine sono importati.

image

Il tutto nella mia installazione ha funzionato senza alcun problema. Agli interventi sono in effetti stati associati i tag precedentemente gestiti con Ultimate Tag Warrior.

WordPress 2.3 porta all’estremo il concetto di tag dando la possibilità di importare le stesse categorie in tag. Se vi siete chiesti a cosa serve distinguere categorie e tag, in questa mossa c’è forse un accenno di risposta.

image

Tutto rose e fiori?

La beta 1 di WordPress 2.3 è abbastanza stabile: abbastanza, non molto. Nelle mie prove ho riscontrato qualche serio problema nella gestione delle categorie. Provando a eliminarne qualcuna ne sono improvvisamente comparse altre con nomi esoterici. Segno che qualcosa da sistemare c’è ancora.

image

Sempre in tema di categorie, anche l’importazione delle categorie in tag ha creato qualche problema. Ho infatti provato a importare una categoria (accessbilità) già presente come tag. Ricevendo in risposta un messaggio di errore fin troppo chiaro.

image

Conclusioni

WordPress 2.3 promette bene. Speriamo che da qui alla versione finale venga migliato il supporto ai tag, in quanto al momento è poco più che embrionale. Un’eventuale migrazione di un blog andrà comunque pianificata con attenzione, viste le numerose modifiche alla struttura dati del prodotto.

Stai leggendo uno di una serie di interventi dedicati a WordPress 2.3.

Aspettando WordPress 2.3

Il 24 Settembre è previsto il rilascio della versione 2.3 di WordPress che dovrebbe come al solito contenere importanti novità, tra cui l’inclusione nel pacchetto standard delle funzionalità di tagging (che fino a oggi richiedevano l’uso di plugin, come per esempio Ultimate Tag Warrior) e una migliorata interfaccia di gestione.

Per raggiungere l’obiettivo gli sviluppatori hanno iniziato la fase di consolidamento del codice: da questo momento non verranno aggiunte nuove caratteristiche, ma si procederà con i test e successive correzioni di errori.

Ne parla un po’ più nel dettaglio Ryan Boren di Automattic, che riporta anche un interessante calendario con i passi che porteranno alla versione definitiva. Un esempio di trasparenza e capacità di previsione che probabilmente varrebbe la pena seguire anche per progetti web molto meno ambiziosi di WordPress.

Stai leggendo uno di una serie di interventi dedicati a WordPress 2.3.