Come Gestire Un Progetto Di Sviluppo Sito Web Aziendale (con Rich Butkevic di Project Zendo)

Leggi La Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast con un programma software. Scusate eventuali errori di battitura, il bot non è sempre preciso al 100%.

Ben Aston

Grazie per essere qui con noi. Sono Ben Aston, fondatore di The Digital Project Manager. Benvenuto al podcast DPM. Che tu sia un project manager esperto, un digital producer o qualcosa di completamente diverso, magari ti sei ritrovato, per caso, a gestire progetti: sappi che oggi, nelle tue cuffie, sei in compagnia di migliaia di altre persone nella stessa situazione, che cercano di iniziare, pianificare e consegnare progetti migliori.

Noi di thedigitalprojectmanager.com siamo qui per aiutarti a diventare più sicuro e competente come project manager, e vogliamo metterti in contatto con altre persone che gestiscono e guidano progetti come te. Se vuoi veramente portare il tuo gioco di PM al livello superiore, dai un’occhiata alla nostra DPM School e iscriviti alla nostra membership pro per accedere a tutte le nostre risorse selezionate.

Infine, mentre ascolti il podcast, iscriviti e unisciti alla nostra newsletter su thedigitalprojectmanager.com per restare aggiornato su tutte le novità. Se hai mai partecipato alla costruzione di un sito web aziendale, saprai bene quanto sia difficile farlo nel modo giusto. In parte questo succede perché non è una cosa che si fa spesso, ma c’è anche dell’altro: obiettivi poco chiari, richieste poco definite, quella matassa di stakeholder e intrecci politici.

Tutto ciò rende già difficilissimo portare a termine (e bene) un sito web aziendale. Aggiungi una buona dose di sfide tecniche, e questi nuovi progetti scintillanti possono trasformarsi in un disastro totale. Nel podcast di oggi spieghiamo come realizzare davvero progetti di siti web aziendali nel modo giusto: continua ad ascoltare per scoprire consigli pratici su come pianificare, gestire e controllare i tuoi prossimi progetti di siti web aziendali e portarli a termine come si deve.

Grazie per essere qui con noi. Sono Ben Aston, fondatore di The Digital Project Manager, e benvenuto al podcast DPM. Che tu sia un project manager esperto, un digital producer o qualcos’altro, magari ti sei ritrovato per caso a gestire progetti: sappi che oggi nelle tue cuffie sei insieme a migliaia di altre persone nella stessa situazione, che cercano di iniziare, pianificare e consegnare progetti migliori. Noi di thedigitalprojectmanager.com siamo qui per aiutarti a diventare più sicuro/a e abile come project manager, e anche per collegarti con altri che gestiscono e guidano progetti.

Quindi, se vuoi davvero migliorare e portare la tua attività da PM al livello successivo, scopri la nostra DPM School e iscriviti alla membership pro per accedere a tutte le risorse selezionate. Infine, mentre segui il podcast, iscriviti e unisciti alla nostra newsletter su thedigitalprojectmanager.com per restare sempre aggiornato.

Questo podcast è offerto da Clarizen, leader nel software di gestione progetti e portfolio per grandi aziende. Visita clarizen.com per saperne di più. Oggi sono qui con Rich Butkevic...

Rich Butkevic

Perfetto.

Ben Aston

L'ho pronunciato bene?

Rich Butkevic

Hai detto perfettamente.

Ben Aston

Ecco, mi sono allenato. Quindi, Rich è un consulente di project management, autore del blog projectzendo.com (dagli un’occhiata!), e organizza workshop di project management in tutto il Texas. Puoi vedere anche artofpmo.com se ti interessa. Dopo toccheremo anche questo. Rich ha una combinazione unica di ruoli in ambito project e product management, QA, analisi di business, marketing e formazione. Utilizza Agile e Scrum, possiede tutte le certificazioni desiderabili: PMP, Certified Scrum Master, IBM Rational Unified Process, certificato Amazon ed E-Marketer. Ha tutto.

Ciao Rich, grazie per aver accettato il nostro invito.

Rich Butkevic

Ciao Ben, grazie a te per avermi invitato. Lo apprezzo molto.

Ben Aston

Vorrei iniziare parlandoti di tutte queste qualifiche e delle lettere dopo il tuo nome. Alcuni non ci danno peso, tu invece hai deciso di prendere tutte le certificazioni possibili. È per un interesse particolare nell'apprendimento? Cosa ti ha motivato?

Rich Butkevic

Non so se proprio tutto, ma ho una passione per l’apprendimento. È qualcosa che mi piace davvero fare. Ma penso che ottenere una certificazione, sia in project management o in generale, dimostri una grande serietà e l’impegno nel restare aggiornati. A parte la PMP, le altre certificazioni le ho acquisite principalmente in base alle esigenze dei progetti.

Ad esempio, con la certificazione AWS, se lavoravo su un progetto che utilizzava Amazon Web Services, mi piaceva approfondire la tecnologia per svolgere meglio il mio lavoro da PM. Più studiavo, più mi appassionavo, e se devo imparare comunque, tanto vale avere un obiettivo da raggiungere. Così ho deciso di puntare alle certificazioni, ed ecco come le cose sono andate avanti.

Ben Aston

Raccontaci come hai iniziato a occuparti di project management. Chiaramente hai una forte inclinazione tecnica. Non sono molti i PM che conosco con certificazioni tecniche tipo AWS…

Rich Butkevic

Certo.

Ben Aston

Come hai iniziato, quindi?

Rich Butkevic

Durante l'università ero tecnico di supporto, rispondevo al telefono proprio quando la banda larga iniziava a diffondersi. Ho iniziato così, in un periodo molto stimolante a livello tecnico, e dopo la laurea sono diventato business analyst in una grande azienda di telecomunicazioni a Chicago, dove allora vivevo. Da lì sono passato al QA, ho iniziato a gestire il QA e poi a occuparmi di project management. Ho preso la mia certificazione e le cose si sono evolute da lì.

Ben Aston

Curioso di sapere: il tuo primo giorno da project manager, avrai imparato tante cose. Se potessi dire qualcosa al te stesso di allora, cosa diresti?

Rich Butkevic

Penso che la cosa più importante sia che non è una questione di strumenti. Molti project manager si concentrano troppo sulle funzionalità degli strumenti che usano, ma per me lo strumento serve solo a rendere più agile e automatizzato un processo che dovresti poter gestire anche con una matita e un foglio.

Se non ti senti sicuro a gestire un progetto con carta e penna (non che debba essere sempre così), vuol dire che qualcosa manca. Essere un bravo project manager non vuol dire conoscere alla perfezione Microsoft Project o ogni altro strumento. Ci sono molti aspetti soft, competenze trasversali e la comprensione degli obiettivi di fondo.

Ben Aston

Sì, ma parliamo di strumenti, perché mi piacciono…

Rich Butkevic

Certo, anche a me.

Ben Aston

A parte carta e penna, cosa non manca mai nel tuo toolkit da PM?

Rich Butkevic

Penso che la differenza più grande, oltre allo strumento di project management vero e proprio, sia dove utilizzo un tool di collaborazione. Adoro Slack, è semplice ed efficace per tutti, cambia radicalmente la gestione rispetto a decine di email ed Excel sparsi nei drive aziendali.

Mi piace Slack, ma come per lo strumento di project management, il concetto e il valore sono più importanti dello strumento scelto.

Ben Aston

Hai delle integrazioni preferite con Slack?

Rich Butkevic

Niente di particolare a parte eventuali integrazioni per la gestione del tempo come consulente; di solito seguo gli standard del cliente. Ma la cosa che ho trovato più utile in Slack sono le scorciatoie da tastiera: conoscerle davvero cambia il modo di lavorare.

Ben Aston

La tua scorciatoia preferita?

Rich Butkevic

Eh, ora mi metti in difficoltà. È come il mio numero di telefono: faccio i gesti con le dita, ma a memoria non li ricordo!

Ben Aston

Capisco… Ma torniamo a quello che dicevi: il project management non è fatto di strumenti. Raccontaci di più…

Rich Butkevic

Quando parlo di soft skill, intendo anche comprensione concettuale. Capire cos’è un project manager, come dovrebbe funzionare un progetto, ti permette di concentrarti sulle cose essenziali, non su quelle inutili. In un progetto devi identificare i requisiti, assicurarti che business e team tecnico siano allineati, che si faccia testing, che si gestiscano difetti… Insomma, capirne il senso profondo. Se non riesci a spiegarlo in un tweet, probabilmente dovresti chiarirti meglio le idee.

Ben Aston

Entriamo nel tema della gestione di uno sviluppo sito web aziendale. Abbiamo appena scritto un post su cosa può andare storto. La verità è che sono progetti davvero complessi: spesso vengono fatti ogni 3-5 anni e chi li gestisce magari lo fa una o due volte nella carriera. Le sfide sono tante: stakeholder, brief poco chiari, politica aziendale, problemi tecnici…

Vorrei parlare di come rendere più efficace il processo, costruendo sulle cose che hai menzionato: puoi raccontarci perché è così difficile e magari un esempio/horror story dal tuo passato?

Rich Butkevic

Sicuramente. Una delle lezioni più importanti che ho imparato all’inizio è stata: fidati ma verifica. Molte volte i membri del team dicono che una task è conclusa, ma in realtà intendono che hanno in programma di concluderla. Poi altre priorità fanno sparire tutto e magari ci si accorge del problema solo in produzione…

Un’altra cosa chiave è la collaborazione su grandi progetti con team distribuiti. Più grande è il progetto, meno puoi contare su uno o due eroi che salvano tutto. Per esempio, come consulente lavoro su vari progetti l’anno, mentre un amministratore IT aziendale fa forse uno sviluppo sito aziendale ogni 10-15 anni. Per lui è tutt’altro che routine... quindi, pur sembrando banali, queste cose sono cruciali.

Ben Aston

Ti racconto anch’io un epic fail: su un sito aziendale ci siamo accorti solo alla fine che serviva un ulteriore livello di approvazione nella governance. Il brief non era stato condiviso correttamente e dopo aver progettato e sviluppato il sito ci hanno detto che serviva il via libera del fondatore e presidente, mai coinvolto nelle fasi precedenti! Grande richiesta di change, cliente arrabbiato e rapporto incrinato. La lezione per me? Chiarirsi fin dall’inizio su tutto il processo di governance e di approvazione, e mappare bene chi davvero prende le decisioni.

Rich Butkevic

Verissimo. Soprattutto nelle grandi aziende, gli stakeholder hanno tutti dei “capi”, e spesso quello che decide è molto sopra le persone con cui parli ogni giorno…

Ben Aston

Già. E bisogna chiarire subito che se si scopre tardi chi ha diritto di approvare, ci saranno impatti su costi e tempi. Molte volte il team marketing delega tutto a un junior che poi coinvolge solo all’ultimo il suo capo. Bisogna “allargare il cerchio” delle persone coinvolte fin dall’inizio.

Parlaci del processo ad alto livello: come si passa dalla richiesta di “voglio un nuovo sito aziendale” al “ta-daa, è online”?

Rich Butkevic

A livello generale, prima di tutto occorre definire i veri obiettivi del progetto: si tratta di un’acquisizione/fusione? Un rebrand? Un nuovo CMS? Da qui dipende poi tutto il resto. Subito dopo bisogna passare alle user story: spesso ce le dimentichiamo, ma è fondamentale capire i diversi tipi di utenti (avatar) che navigheranno il sito e quali saranno i loro obiettivi. Scrivere le user story ti guida nella definizione della gerarchia e struttura del sito: meno click possibili per raggiungere ciò che serve, niente info nascoste venti pagine sotto. È importante sia per la UX sia lato SEO.

Poi si affronta la questione dei contenuti, che può essere banale in siti piccoli ma davvero impegnativa per le realtà corporate con migliaia di pagine. Serve capire cosa mantenere, aggiornare, eliminare o unire, e qui gli strumenti possono aiutare molto.

Solo dopo questi passaggi passo agli aspetti tecnici, perché sono più statici e meno influenti sul successo del progetto rispetto alla struttura, all’organizzazione e ai contenuti.

Ben Aston

Quindi l’importante è definire bene il brief, le persone chiave, la IA del sito, e poi affrontare la parte di design e wireframe. Tu lavori in parallelo tra discovery, planning e design? Idee utili per chi ascolta e pensa che sia un processo troppo lungo?

Rich Butkevic

Non amo “accorciare” troppo i tempi perché la pianificazione è la chiave di un progetto later veloce. Se non hai tempo per farlo bene non avrai tempo per rifarlo. Però molto si può fare in parallelo: definire utenti e obiettivi, iniziare a lavorare su struttura e contenuti usando la versione esistente come base migliorabile. Coinvolgere i vari reparti per la revisione dei loro contenuti. Tutto può essere fatto a “palla di neve”.

Per quanto riguarda Scrum o approcci iterativi, il valore sta nel coinvolgere quanto prima gli stakeholder decisori, mostrando loro (all’occhio!) i progressi: sono loro che danno il feedback più importante, specie se capita qualcosa che non vogliono a fine progetto. Quindi, anche se a volte serve un approccio più “a cancelli”, nella mia esperienza meglio iterativo.

Ben Aston

E anche i test utenti sono fondamentali: identificare le personas, allinearsi sugli obiettivi veri del sito, testare davvero le wireframe con compiti reali (es: “trova la nuova tariffa” e se non ci riescono si capisce che qualcosa è da rivedere!). È un ottimo modo per portare dati oggettivi alla discussione con il cliente.

Rich Butkevic

Assolutamente, ma è fondamentale che i tester siano rappresentativi degli avatar usati: troppo spesso si usano dipendenti interni, abituati a gergo e processi, che non sono affatto clienti reali...

Ben Aston

Passiamo ora alla fase di sviluppo: il design è fondamentale per raggiungere gli obiettivi di business, ma realizzarlo in modo tecnico efficace è tutto un altro lavoro. Cosa deve considerare un PM che gestisce per la prima volta lo sviluppo tecnico di un sito aziendale? Luoghi comuni, errori da evitare?

Rich Butkevic

Di solito gli sviluppatori hanno esperienza sulla gestione di un sito già online, meno sulla migrazione o la messa in produzione. Le aree critiche sono, ad esempio, i redirect HTTPS (spesso realizzati male, portano a doppioni su Google, tracciamenti analytics sballati, ecc.). Altro errore: chi gestisce il DNS non sempre ha accesso al registrar — serve verificare prima chi può operare il cambio! E bisogna spiegare a leadership e stakeholder che la propagazione del DNS richiede tempo, onde evitare allarmi inutili il giorno del go-live.

Ben Aston

Ottimi suggerimenti anche per il lancio! Bisogna pensarci prima, non il giorno prima… Parlando invece di gestione degli sviluppatori: che fare se non si è tecnici? Come controllarli davvero?

Rich Butkevic

Qui serve iterazione: vedere ciclicamente il lavoro svolto con demo effettive. Mai lasciare che passino settimane da una review all’altra. Meglio stand-up TV minuti ogni giorno o ogni due giorni, come nello Scrum, anche solo per aggiornarsi, sciogliere i nodi e mantenere la rotta.

Ben Aston

La cadenza regolare di demo permette di accorgersi subito di errori. Anche solo una navbar non responsive si scopre subito, non dopo sei settimane. Così il team resta attivo e nessuno si perde “nella nebbia dello sviluppo”.

Ma pensando a chi ascolta mentre guida: qual è il consiglio base che daresti per evitare disastri nella gestione e nel controllo? La chiave per restare davvero sul pezzo e non perdere il controllo su budget e calendario?

Rich Butkevic

Quello che conta è la collaborazione continua, anche tramite tool digitali. Le daily stand-up aiutano enormemente. Inoltre, accorciare i cicli di feedback: nell’Agile, ogni due settimane si fa una demo reale, ma si può stringere ancora di più la frequenza con check quotidiani e usando tool come Slack. L’importante è non aspettare la review per sollevare i problemi: segnalarli subito riduce attriti e rallentamenti.

Una cosa fondamentale ancora poco praticata: prima di andare live, fare un crawl del sito per individuare link rotti. Sembra banale, ma raramente vedo farlo — e invece dà subito indizi sulla bontà del codice e dei processi.

Ben Aston

Consigli su quali strumenti usare per il crawl?

Rich Butkevic

Non ne ho uno preferito: cerca online, va bene qualsiasi link checker. Dipende se il sito è nuovo, redesign, se serve qualcosa che lavora da dentro o da fuori la rete… ma la cosa importante è farlo!

Ben Aston

Grazie mille Rich, penso che il focus più importante emerso sia sulla fase iniziale di briefing e definizione degli obiettivi. Se ci si concentra su questo, tutto il resto fila meglio e il ROI è assicurato. Grazie di cuore!

Rich Butkevic

Grazie a te, Ben, è stato un piacere.

Ben Aston

E voi? Quali sono i vostri trucchi e consigli per progetti di siti? Raccontateci nei commenti sotto, o unitevi alla nostra community con la membership DPM. Troverete risorse, piani di progetto per grandi site build, sia con metodologie agili sia waterfall — venite su thedigitalprojectmanager.com/membership.

Potrete accedere al nostro gruppo Slack, template, workshop, office hours, eBook e altro ancora. Se ti è piaciuto il podcast, iscriviti e lasciaci una recensione. Grazie per l’ascolto e alla prossima, abbi cura di te!