Il web project management è una disciplina complessa, un po’ perché molti sono i compiti del web project manager, ma soprattutto perché il web project manager interviene per facilitare il lavoro degli altri, per ridurre gli attriti, per decidere la strada da seguire a seguito di problemi importanti.

Avere qualche indicazione su come semplificare il web project management non può che essere di aiuto. Alcune le ho trovate leggendo Project Management Made Easy, un intervento pubblicato qualche mese fa nel blog di Blue Flavor (se siete web project manager è uno dei pochi blog a cui vale la pena di iscriversi). Scorrendolo la prima volta ho però sorriso. “Un poco ovvio” – mi sono detto – “questi sono argomenti che non è necessario ricordare a un web project manager”. Ho aggiunto comunque l’intervento nel mio del.icio.us per una futura occasione.

Da allora ho avuto modo di ricredermi sulla banalità degli argomenti, sopravvalutati da molti, e ho deciso di riportare qui uno stringato riassunto dell’intervento, integrandolo con la mia esperienza.

Se vuoi ridurre la complessità del tuo lavoro di web project manager:

• assicurati che tutti sappiano quali sono gli obiettivi del progetto
• verifica che ogni componente del gruppo conosca quale è il suo specifico ruolo in questo progetto
• tieni traccia dei tempi e dei costi
• impara a comunicare

Quasi tutti i punti hanno a che fare con la comunicazione, e non è una coincidenza. La complessità nel web project management si riduce solo spendendo tutto il tempo necessario con i propri colleghi e con i clienti, così da anticipare i problemi prima che sia difficile intervenire. Ho paura quando ci si butta a capofitto a sviluppare un progetto senza che sia stata prodotta neppure un briciolo di documentazione o che sia stato stabilito come il progetto va suddiviso tra i diversi componenti del gruppo.

Non sto dicendo che prima di iniziare un progetto devono essere prodotte tonnellate di pagine di specifiche; non mi rifiuto di procedere con uno sviluppo senza trascrizioni di interviste con il cliente, analisi dei requisiti e analisi funzionali. Molto spesso, soprattutto per i progetti di media complessità, basta probabilmente un wireframe opportunamente commentato, che però ha fatto capolino al cliente (dove qualcuno lo ha illustrato) ed è poi tornato con le opportune correzioni in azienda.

Non dimenticate poi che non tutti i componenti del gruppo di lavoro con cui lavorate hanno messo piede dal cliente o nelle sale riunioni, per cui non è sufficiente limitarsi a spiegargli la loro parte di lavoro. Dovete coinvolgerli sull’intero progetto, anche se poi si troveranno a lavorare in una minima parte. A meno che non vogliate, ovviamente, che vengano commessi errori non appena le specifiche sono ambigue (il che succede sempre) o che vogliate rinunciare all’apporto che ogni membro del gruppo può dare anche al lavoro degli altri. Centellinare le informazioni porta anche a dipendere da ogni membro del gruppo, evento traumatico quando poi qualcuno va a lavorare da un’altra parte (come ho avuto modo di dire in Quando finisce un amore).

Non so voi, ma io odio essere disturbato ogni due minuti perché chi lavora con me non ha tutti gli elementi per procedere o perché il cliente non si ricorda quanto avevamo stabilito. Se è così anche per voi provate a mettere in pratica qualcuno di questi punti. Lavorerete meglio.