Gestione dei progetti - Elenco di controllo Best Practices

La gestione di un progetto per l’implementazione di Adobe Experience Manager (AEM) richiede pianificazione e comprensione per essere consapevoli dei problemi e delle decisioni (correlate) da prendere (sia prima che durante l’implementazione del progetto).

Per aiutarti, le best practice sono:

Pannello Heartbeat progetto

Il foglio di lavoro di Project Heartbeat fornisce una panoramica grafica delle metriche critiche per il progetto:

  • Qualità fase

  • Stato fase

    • un indicatore di stato di alto livello per il progetto; utile per evidenziare le aree che potrebbero essere a rischio.

  • Completamento fase

    • In qualsiasi momento durante il progetto questo indica quanto è già stato completato per ciascuna fase del progetto.

Stato per ruolo

Il foglio di lavoro Stato per ruolo mostra una suddivisione dettagliata di Salute, Qualità e Completezza di Fase e Persona.

Fasi e pietre miliari

Il piano del progetto è suddiviso in fasi distinte (ad alto livello).

Ogni fase contiene le proprie tappe. Per ogni persona (o ruolo) sono elencati i punti cardine pertinenti, insieme ai documenti necessari per produrre i risultati finali definiti.

NOTA

Non esiste una relazione diretta 1:1 tra i singoli documenti richiesti e i risultati finali.

Preparazione

La preparazione del progetto costituisce la base dell'intero progetto. È necessario definire requisiti chiave insieme a obiettivi chiari e aspettative per:

  • Motivazione aziendale

    • Le ragioni e le motivazioni fondamentali per l'esecuzione del progetto.

  • Ambito e programma

    • È opportuno rendere disponibili un ambito di applicazione di base e un calendario approssimativo per definire i requisiti e entro quale periodo di tempo; se aiuta a chiarire la situazione, puoi anche definire cosa si trova al di fuori dell'ambito.

Le modalità di preparazione, pianificazione ed esecuzione del progetto e implementazione della soluzione saranno influenzate dalle restrizioni applicate, ad esempio budget fisso, scadenze fisse, quantità di contenuto, qualità richiesta.

Come sempre, l'adeguamento di uno qualsiasi dei fattori influirà sugli altri. Ad esempio, ridurre il tempo, ma richiedere lo stesso livello di qualità probabilmente aumenterà il prezzo e ridurrà la quantità di contenuto per cui si può gestire. Il budget è spesso un fattore chiave per non dimenticare tali relazioni.

I Quattro Fattori:

videofasi_quattro

Pietre miliari

  • Convalida

    In questa fase è necessario convalidare e confermare gli obiettivi del progetto; ad esempio:

    • Cosa si desidera ottenere/fornire?
    • Chi ne beneficerà?
    • Qual è il campo di applicazione?
      • Se aiuta a chiarire la situazione, puoi anche definire cosa si trova al di fuori dell'ambito.
    • Come definirete il successo?
    • Come misurerete il successo?
      • Quali sono i requisiti, aziendali e tecnici?
      • Esistono sistemi legacy da sostituire e, in caso affermativo, esistono dati da migrare?
      • Chi sarà coinvolto?
      • Come misurerai il progresso?
      • Con quale frequenza verificherete i progressi compiuti nel corso della durata del progetto?

  • Budget

    Prima di avviare un progetto è necessario disporre di una stima affidabile e realistica dei costi di implementazione:

    • Utilizzare le informazioni del cardine di convalida come base per le stime.
    • Siate realistici nelle vostre stime.
    • Considerare e rispettare le linee guida, i processi o le restrizioni per i clienti a cui il cliente può essere soggetto.
    • Valutare i processi di contingenza e di revisione qualora sia necessaria una revisione, o perfezionamento, del bilancio in una fase successiva.
    • Ricordate che i costi si presentano in molte forme; acquisti, utilizzo di risorse e tasse tra gli altri.

Pianificazione

La pianificazione del progetto consolida la preparazione. Qui è necessario iniziare a convertire gli obiettivi e le aspettative in una roadmap ben definita, costituita da attività concrete, legate da una comunicazione chiara, con revisioni rigorose per misurare i progressi.

Pietre miliari

  • Consegna

    Una consegna sicura garantisce che la persona o i gruppi appropriati siano consapevoli delle proprie responsabilità all'interno del progetto.

    Devono essere forniti/generati dettagli completi per garantire che abbiano una piena comprensione di tutti gli aspetti pertinenti, compresi la roadmap, l'ambito, gli obiettivi, i requisiti e i KPI.

  • Valutazione del rischio

    Per evitare spiacevoli sorprese, utilizzare la valutazione del rischio per individuare e quantificare eventuali rischi potenziali insieme al loro impatto e alla loro probabilità.

    Ciò dovrebbe essere fatto all'inizio del ciclo di vita del progetto per garantire che le eventuali vulnerabilità siano individuate e valutate. In base ai risultati, puoi segnalare alle parti interessate se è possibile implementare tutti i requisiti e, se necessario, se è possibile pianificare azioni appropriate da intraprendere e monitorare.

  • Comunicazione

    La comunicazione è sempre la chiave per il successo di qualsiasi progetto. È necessario comunicare in modo chiaro ed efficiente per garantire che tutti:

    • Lavorare verso gli stessi obiettivi fondamentali
    • Dalla stessa base di informazioni
    • Con gli stessi canali

  • Spegni

    L'incontro Kick Off viene utilizzato per sensibilizzare l'opinione pubblica sull'inizio del progetto. Si tratta di una buona opportunità per:

    • Invitare tutte le parti interessate (o almeno i rappresentanti del gruppo).
    • Presentare i fatti chiave sul progetto.
    • Rispondi alle domande.
    • Assicurati che tutti abbiano la stessa base di conoscenze.
    • Ottenere l'impegno da tutti coloro che saranno coinvolti - questo dovrà essere guadagnato.
      • Coinvolgendo i protagonisti principali (inclusi i potenziali autori) all'inizio del progetto, aumenterai le possibilità di ottenere il loro impegno per il progetto.

Preparazione sviluppo

La pianificazione dello sviluppo è fondamentale per garantire che il progetto sia basato su un progetto solido da parte di un team che disponga delle conoscenze necessarie.

Pietre miliari

  • Team di sviluppo con personale e formazione

    Prima di iniziare qualsiasi progetto, è necessario assicurarsi che il team di sviluppo disponga di personale adeguato e che tutti i membri del team siano formati per l'attività in corso.

  • Architettura dei contenuti

    L'architettura dei contenuti definisce e descrive la futura architettura dei contenuti; compresi:

    • La struttura del contenuto; incluse le risorse
    • strutture di base; incluse le campagne, ecc.
    • Strutture multisito e multilingue (MSM, Traduzione, ecc.)
    • Contenuto di supporto (inclusi tag e concetti di tag)
    • Strategie di memorizzazione nella cache e di riutilizzo dei contenuti

  • Architettura del sistema

    L'architettura del sistema definisce la vista concettuale del sistema; tra cui (tra le altre informazioni):

    • Struttura del sistema per tutti gli ambienti richiesti
    • Sottosistemi
    • Sistemi di terze parti
    • Interfacce; interazione hardware, software e umana
    • Server per ogni ambiente; vedere le Requisiti tecnici e le Linee guida sul ridimensionamento hardware
    • Processi per ogni ambiente; ad esempio, requisiti di implementazione e manutenzione
    • Attività di manutenzione (Datastore GC, ottimizzazione TarPM, ecc.)
    • 🔗Memorizzazione in cache di Dispatcher
    • 🔗 ClusteringPublish/Authorshare
    • Prestazioni lato client (JS minify, concat, sprites css, numero totale di richieste http e altre)

  • Architettura applicativa

    L'architettura dell'applicazione definisce e descrive il comportamento delle applicazioni proposte.

    Si concentra su:

    • Come interagiranno tra loro e con gli utenti.
    • I dati che devono essere consumati e prodotti dalle applicazioni, piuttosto che la loro struttura interna.

    Le definizioni dovrebbero riguardare:

    • Struttura del codice di base per il progetto
    • Artefatti di codice (pacchetti, pacchetti, ecc.)
    • Suddivisioni dei modelli/componenti e delle loro relazioni
    • Dettagli di alto livello sulle personalizzazioni richieste (in seguito verranno applicate sovrapposizioni specifiche)
    • Progettazione dei flussi di lavoro richiesti dalla soluzione (ad esempio creazione di contenuti, approvazione, pubblicazione, trasformazioni, importazioni, esportazioni ecc.)
    • Considerazione speciale per tutti i moduli complessi, come MSM, Commerce, integrazione di terze parti

  • Integrazione del sistema

    L'integrazione del sistema richiede la pianificazione (e quindi l'implementazione):

    • In che modo tutti i sottosistemi e le integrazioni di soluzioni saranno uniti per funzionare come un unico sistema coerente
    • Come saranno integrati i sistemi di terze parti? insieme a qualsiasi considerazione speciale, ad esempio offline/online, lato client/browser o gestione del failover quando un sistema di terze parti è offline

  • Concetto di test

    Prima di iniziare lo sviluppo, è necessario definire un concetto approfondito e completo di tutti i requisiti testing per il progetto.

    Ciò dovrebbe includere (tra gli altri):

    • Dettagli di tutte le prove da eseguire
    • Preparazione del contenuto necessario per tali test
    • Informazioni sugli strumenti di prova da utilizzare
    • indicazione ad alto livello di chi sarà coinvolto nelle prove; in particolare i gruppi esterni al team di controllo della qualità
    • dettagli sull'automazione del test; ad esempio, con la modalità Selenium o AEM Developer

  • Experience Design

    Experience Design (XD) prevede la progettazione dell'esperienza utente per la soluzione.

    L’esperienza utente deve essere analizzata e sviluppata sia per gli autori che per gli utenti finali del sito Web.

  • Configurazione supporto

    Prima di sviluppare tutti i processi di supporto, necessari per distribuire, rilasciare, testare e segnalare i problemi, dovrebbero essere impostati.

    Vedere anche il portale supporto Adobe.

Pianificazione delle operazioni e operazioni

Allo stesso modo, le operazioni devono essere pianificate in modo appropriato per garantire l'esistenza degli ambienti richiesti, per tutte le fasi del ciclo di vita del progetto. È inoltre necessario disporre dei processi appropriati per la loro manutenzione.

Pietre miliari

  • Autorizzazioni

    È necessario pianificare e quindi implementare un concetto di ruoli e diritti per tutti gli utenti/gruppi che utilizzeranno la soluzione.

    Esempio:

    • Elenco di ruoli (ovvero gruppi) con definizioni di accesso read/ write per ogni
    • Definizione dell’uso dei privilegi che hanno un impatto sull’ambiente di pubblicazione; ad esempio, replicate
    • Per gli utenti con privilegi minimi, i flussi di lavoro devono essere definiti
    • Gli utenti del gruppo editor non devono avere diritti admin né far parte del gruppo administrators

    Per ulteriori informazioni, vedere Amministrazione utente e sicurezza.

  • Monitoraggio e manutenzione

    Il monitoraggio e la manutenzione sono aspetti chiave per garantire il corretto funzionamento della soluzione una volta che sarà live. A tal fine è necessario definire:

    • Quali sono le necessità di monitoraggio
    • Attività di manutenzione; sia regolare che per casi speciali

    Per ulteriori informazioni, vedere anche Monitoraggio e manutenzione.

  • Migrazione

    Qualsiasi contenuto del sistema legacy deve essere rivisto e convalidato per la migrazione.

  • Piano di ripristino

    Assicurarsi di disporre di un piano di ripristino. In una situazione di emergenza ciò deve essere disponibile per garantire l'uso della produzione di AEM. Questo dovrebbe coprire situazioni come backup, ripristino, failover e altri.

Sviluppo

Lo sviluppo è una fase cruciale che richiede più di una semplice codifica.

Pietre miliari

  • Ambiente di sviluppo

    Pianificare e documentare l'ambiente di sviluppo, compresi:

    • Architettura
    • Strumenti di sviluppo
      • Un ambiente tipico è costituito da:
        • un sistema di monitoraggio dei problemi; come Jira
        • un IDE; come Eclipse
        • uno strumento di gestione della costruzione; come Maven
        • uno strumento per l'integrazione continua; come Jenkins
        • uno strumento per il controllo della versione; come GIT/SVN
        • un gestore dell'archivio degli artifact; come Archiva/Nexus
    • Integrazione/dipendenze software di terze parti
    • Integrazione/dipendenze della soluzione
    • Ritardo di distribuzione

  • Sistema di prova

    Pianificare e documentare l'ambiente di test, compresi:

    • Architettura
    • Dipendenze dalle build di sviluppo; comprese le build notturne
    • Possibilità o limitazioni di verifica dell'integrazione/dipendenze di software di terze parti
    • Strumenti di test
    • Strategia di test automatizzata

  • Sistema di produzione

    Pianificare e documentare l'ambiente di produzione, compresi:

  • Integrazione

    Pianificare, documentare e testare tutti gli aspetti del sistema e integrazione della soluzione, compresi:

  • Migrazione

    Pianificare, documentare e verificare tutti gli aspetti della migrazione dei contenuti; compresi:

    • Architettura dei contenuti
    • Strategia di migrazione

  • Comunicazione

    Assicurati che tutti i membri del team e il personale del progetto siano aggiornati in base alle esigenze.

  • Documentazione

    Documentare appieno la soluzione; compresi:

    • Manuale operativo
    • Eventuali personalizzazioni che possono influenzare gli aggiornamenti
    • Note sulla versione

Prestazioni e test

Una volta che la nuova applicazione sarà disponibile, dovrà sottoporsi a test rigorosi, sia per le funzionalità che per le prestazioni.

NOTA

Qualsiasi team di test deve poter rimanere neutrale e fornire i risultati dei test.

È responsabilità del responsabile del progetto valutare le implicazioni dei risultati e decidere le azioni appropriate.

Pietre miliari

  • Test di accettazione da parte dell'utente finale

    Il test di accettazione da parte dell'utente (UAT) è fondamentale per garantire che:

    • La soluzione soddisfa i requisiti utente/cliente
    • I clienti/utenti accettano la soluzione (funzione, progettazione e prestazioni)

    Dovrebbe essere prevista una checklist formalizzata per la consegna del cliente; idealmente automatizzato ed eseguito su base notturna su uno snapshot. I risultati devono essere inviati al project manager e al team di sviluppo

  • Test prestazioni e carico

    I test di prestazioni e di carico sono utilizzati per garantire che la soluzione soddisfi i livelli di prestazioni richiesti, a carichi medi e massimi.

    Per ulteriori informazioni sui test delle prestazioni, vedete:

    NOTA

    Questo processo dovrà essere proseguito durante il normale uso di AEM, ma queste fasi iniziali sono le più importanti.

Rollout

L'implementazione della nuova applicazione richiede un'attenta pianificazione per garantire un Go Live uniforme. Ciò include la conferma di un elevato livello di sicurezza, la formazione di tutti i potenziali utenti e la realizzazione di più prove a secco per confermare che tutti i problemi sono stati affrontati.

Pietre miliari

  • Preparazione

    La preparazione e la pianificazione contribuiranno a garantire un'implementazione uniforme.

  • Formazione

    Garantire che tutto il personale coinvolto sia stato formato.

    Vedete Adobe Experience Manager nel catalogo del corso.

  • Amministratori formati

    Assicurati che gli amministratori della soluzione abbiano:

    • È stato addestrato
    • Ricevuto materiale di formazione appropriato
    • Ricevuta la documentazione appropriata

  • Utenti con formazione

    Assicuratevi che gli autori abbiano:

    • È stato addestrato
    • Ricevuto materiale di formazione appropriato
    • ha ricevuto la documentazione appropriata; ad esempio, la Guida utente

  • Prove Di Penetrazione

    I test di penetrazione simulano un attacco a un sistema informatico per identificare potenziali carenze di sicurezza.

  • Test di penetrazione/sicurezza

    Per garantire la sicurezza della soluzione, eseguire test di penetrazione specifici, insieme a una più ampia gamma di test di sicurezza.

    Per ulteriori informazioni, vedere Elenco di controllo della sicurezza.

Go Live

Vuoi che il tuo Go Live sia il più liscio possibile. Anche in questo caso, i passaggi finali richiedono una pianificazione per l'esecuzione pulita.

Pietre miliari

  • Preparazione

    La preparazione e la pianificazione contribuiranno a garantire un ciclo di vita uniforme.

  • Sicurezza

    Confermate la sicurezza della soluzione sia per gli utenti interni che per quelli esterni e i loro contenuti.

  • Fallback

    Assicurarsi che tutti i sistemi, le procedure e i meccanismi necessari per il fallback siano in funzione prima di iniziare il ciclo di vita.

  • Supporto

    Verificate che i servizi di supporto siano pronti e pronti.

  • Transizione

    Pianificate ed eseguite la transizione al vostro ambiente di produzione e agli utenti.

  • Rollout

    Preparate ed eseguite i test di fumo.

Persona

Gli elenchi di controllo sono progettati per persona. Questi sono i ruoli che hanno un ruolo significativo nel ciclo di vita del progetto.

Esistono anche altre persone che sono coinvolte in attività specifiche.

Sponsor del progetto

Lo sponsor del progetto è:

  • Responsabile della fornitura/presentazione del business case per il progetto.

  • La definizione e la definizione della portata del progetto; compresi:

    • definizione e criteri di successo
    • i KPI principali

  • Fornire le tappe principali in base alla roadmap del cliente.

Project Manager

Il project manager è:

  • Responsabile della fornitura complessiva del progetto in base ai requisiti (ad esempio ambito, KPI, criteri di successo e definizione) forniti dallo sponsor del progetto.
  • Responsabile della definizione del budget e delle risorse del progetto in base a tale budget.
  • Il punto principale di comunicazione per tutte le persone coinvolte nel progetto.

Architetto

L'architetto della soluzione:

  • È responsabile della progettazione di alto livello della soluzione e del sistema.
  • Consente di definire la strategia di implementazione per AEM. Ad esempio, se implementare un’installazione in cluster o una modalità standby a freddo oppure se è necessaria una rete di distribuzione dei contenuti (CDN).
  • Definite anche l'architettura della soluzione AEM in base ai requisiti del cliente. Ciò può includere il concetto di ruoli utente (con diritti correlati), la relazione tra modelli e componenti o quando utilizzare la gestione multisito.

Analista aziendale

L'analista aziendale:

  • È principalmente responsabile della raccolta e dell'analisi dei requisiti di alto livello, e quindi della loro trasformazione in specifiche:

    • per consentire al project manager di utilizzare la pianificazione dello sviluppo
    • per consentire al team di sviluppo di lavorare durante la progettazione e lo sviluppo.

  • Lavora a stretto contatto con il cliente per analizzare i requisiti. Si confrontano con questi:

    • La definizione di successo.
    • I criteri per il successo.
    • KPI (basati sia sulle attività aziendali che sulle prestazioni).

Lead di sviluppo

Il lead di sviluppo:

  • È responsabile della fornitura tecnica del progetto.

  • È responsabile della selezione di una metodologia di sviluppo conforme ai requisiti dei clienti.

  • Elaborare la strategia di sviluppo:

    • assicurare che sia allineata con i KPI aziendali e delle prestazioni
    • tenendo conto dei criteri di successo e della definizione

  • Lavora a stretto contatto con l'architetto (soprattutto quando elabora la strategia di sviluppo per AEM) per definire aspetti quali la relazione tra modelli e componenti, la strategia di integrazione per applicazioni di terze parti e qualsiasi funzionalità specializzata.

Lead di qualità

Lead di qualità:

  • è responsabile della qualità della consegna; garantire che soddisfi i criteri per il successo e gli eventuali KPI definiti dal client.
  • Definisce le metriche di qualità, si allinea con tutti i soggetti interessati, elabora i piani di test e ne assicura l’esecuzione.
  • Crea e invia report ai soggetti coinvolti nel progetto.

Progettazione sistemi

Il tecnico del sistema:

  • È responsabile della supervisione dell'infrastruttura del progetto.

  • È responsabile di:

    • la configurazione di ambienti di sviluppo e test interni
    • per la corrispondenza di tali sistemi con i sistemi client

  • Fornisce raccomandazioni hardware, controlla le diverse implementazioni e fornisce supporto operativo sia prima che dopo.

Lead di sicurezza

Responsabile della sicurezza:

  • È responsabile del concetto di sicurezza globale della soluzione, garantendo che sia allineata con eventuali requisiti e politiche del cliente.
  • fornisce un concetto di sicurezza, operazioni di sicurezza e consigli per qualsiasi concetto di sicurezza basato su hardware; come zone e firewall.

Altra persona

  • Parti interessate

    • Persone (spesso provenienti dall'azienda) che hanno un interesse (partecipazioni) nel successo del progetto. Spesso contribuiscono al bilancio.

  • Legale

    • È necessaria una consulenza legale quando si negoziano i contratti.

  • Formatori

    • A seconda delle dimensioni e della natura del progetto, i formatori specializzati possono essere utilizzati per sviluppare e presentare sessioni di formazione per i gruppi interessati.

  • Scrittori Tecnici

    • A seconda delle dimensioni e della natura del progetto, gli autori tecnici specializzati possono essere utilizzati per scrivere linee guida e manuali per gruppi specifici; ad esempio un manuale di manutenzione per gli amministratori di sistema o una Guida utente per gli autori.

  • Amministratori di sistema

    • Responsabile del funzionamento continuo del sistema.

  • Autori e utenti finali

    • Gli utenti che utilizzeranno il sistema per creare e mantenere il contenuto del sito Web.

Documenti richiesti e risultati finali

Gli elenchi di controllo coprono i Documenti richiesti e Consegne per ogni attività cardine.

  • Non esiste una relazione 1:1 tra questi due elementi; ad esempio, un gruppo di documenti richiesti può generare un singolo risultato finale.
  • Un risultato finale da un utente può essere un documento obbligatorio per un altro utente durante la stessa fase cardine.

Documenti richiesti

I Documenti richiesti sono necessari al soggetto appropriato per la produzione dei risultati finali.

Per ogni Documento richiesto il soggetto deve indicare:

  • S/N: se è stato ricevuto.
  • 1-3: un'indicazione della qualità del documento ricevuto.

Risultati

Per ogni pietra miliare la persona appropriata è responsabile della consegna di documenti specifici e quindi della realizzazione delle proprie responsabilità per una specifica pietra miliare.

Per ogni Consegna il soggetto deve indicare:

  • S/N: se è stato completato.

I risultati finali vengono spesso utilizzati come Documenti richiesti per la fase cardine corrente o successiva.

Per le procedure ottimali per l’implementazione, l’amministrazione, lo sviluppo o l’authoring, consulta:

Aree principali della documentazione

In questa pagina