Gestione dei progetti - Lista di controllo delle best practice

ATTENZIONE

AEM 6.4 ha raggiunto la fine del supporto esteso e questa documentazione non viene più aggiornata. Per maggiori dettagli, consulta la nostra periodi di assistenza tecnica. Trova le versioni supportate qui.

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

Per aiutarti, le best practice consistono in:

Dashboard di Project Heartbeat

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

  • Qualità fase

  • Salute a 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 del progetto, indica il livello di completamento per ogni fase del progetto.

Stato per ruolo

La Stato per ruolo Il foglio di lavoro mostra la suddivisione dettagliata di Salute, qualità e completezza da Fase e Persona.

Fasi e tappe fondamentali

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

Ogni fase contiene le proprie tappe. Per ogni persona (o ruolo), sono elencate le tappe 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 i requisiti chiave insieme a obiettivi e aspettative chiari per:

  • Motivazione aziendale

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

  • Ambito e programma

    • È opportuno mettere a disposizione un ambito di applicazione di base e un calendario approssimativo per definire ciò che è necessario e entro quale arco 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 dell'implementazione della soluzione saranno influenzate dalle restrizioni utilizzate, ad esempio budget fisso, scadenze fisse, quantità di contenuto, qualità richiesta.

Come sempre, la regolazione di uno qualsiasi dei fattori avrà un impatto sugli altri. Ad esempio, ridurre il tempo, ma richiedere lo stesso livello di qualità probabilmente aumenterà il prezzo e ridurrà la quantità di contenuto che è possibile soddisfare. Il bilancio è spesso un fattore chiave per cui tali relazioni non possono essere dimenticate.

I Quattro Fattori:

fasi_progetto

Milestone

  • Convalida

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

    • Cosa desideri 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 definirai il successo?
    • Come misurerai 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 esaminerai i progressi compiuti durante la durata del progetto?

  • Bilancio

    Prima di iniziare 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.
    • Valuta e rispetta tutte le linee guida, i processi o le restrizioni dei clienti a cui il cliente può essere soggetto.
    • Valutare i processi di contingenza e di revisione nel caso in cui sia necessaria una revisione o un perfezionamento del budget in una fase successiva.
    • Ricordate che i costi si presentano in molte forme; acquisti, utilizzo di risorse e commissioni, tra l'altro.

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 compiti concreti, vincolati da una comunicazione chiara, con revisioni rigorose per misurare il progresso.

Milestone

  • Consegna

    Un cambio di consegna sicuro assicura che l’utente/i gruppi appropriati siano consapevoli delle proprie responsabilità all’interno del progetto.

    Devono essere forniti/generati dettagli completi per garantire 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 sorprese sgradevoli, utilizzare la valutazione del rischio per identificare 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 variabilità siano individuate e valutate. Sulla base dei risultati puoi riferire alle parti interessate se è possibile implementare tutti i requisiti e, se necessario, se è possibile pianificare azioni appropriate da intraprendere e monitorate.

  • Comunicazione

    La comunicazione è sempre fondamentale per il successo di qualsiasi progetto. Devi comunicare in modo chiaro ed efficiente per garantire che tutti siano:

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

  • Spegnimento

    L'incontro Kick Off è usato 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 primi giocatori (inclusi i potenziali autori) all'inizio del progetto, aumenta le possibilità di ottenere il loro impegno per il progetto.

Preparazione allo sviluppo

Pianificare lo sviluppo è fondamentale per garantire che il progetto sia basato su un progetto solido di un team che disponga delle conoscenze necessarie.

Milestone

  • Team di Sviluppo Personalizzato e Formato

    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:

    • Struttura del contenuto; incluse le risorse
    • Strutture di base; incluse le campagne, ecc.
    • Strutture multisito e multilingue (MSM, traduzione, ecc.)
    • Contenuto supportato (compresi tag e concetti di assegnazione 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 l'altro):

    • Struttura del sistema per tutti gli ambienti richiesti
    • Sottosistemi
    • Sistemi di terze parti
    • Interfacce; hardware, software e interazione umana
    • Server per ogni ambiente; vedi Requisiti tecnici e Linee guida per il dimensionamento dell'hardware
    • Processi per ciascun ambiente; ad esempio, requisiti di distribuzione e manutenzione
    • Attività di manutenzione (GC Datastore, ottimizzazione TarPM, ecc.)
    • 🔗Memorizzazione in cache di Dispatcher
    • Clustering Pubblica/Condividi autore
    • Prestazioni lato client (minimizzazione JS, concat, sprites css, numero totale di richieste http e altre)

  • Architettura dell'applicazione

    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 da consumare e produrre dalle applicazioni, anziché la loro struttura interna.

    Le definizioni dovrebbero riguardare:

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

  • Integrazione di sistema

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

    • Come tutti i sottosistemi e integrazioni di soluzioni sarà riunito per funzionare come un unico sistema coerente
    • Come verranno integrati i sistemi di terze parti; insieme a qualsiasi considerazione particolare, ad esempio offline/online, lato client/lato browser o gestione del failover quando un sistema di terze parti è inattivo

  • Concetto di prova

    Prima di iniziare lo sviluppo è necessario elaborare un concetto approfondito e completo di tutti test requisiti del progetto.

    Ciò dovrebbe includere (tra l'altro):

    • Dettagli di tutte le prove da eseguire
    • Preparazione del contenuto necessario per tali test
    • Informazioni su eventuali strumenti di prova da utilizzare
    • indicazione ad alto livello di chi sarà coinvolto nelle prove; specialmente i gruppi esterni al team QA
    • dettagli dell'automazione dei test; ad esempio, con modalità Selenium o AEM Developer

  • Progettazione esperienza

    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 del supporto

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

    Vedi anche Adobe Support Portal.

Pianificazione e operazioni

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

Milestone

  • Autorizzazioni

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

    Ad esempio:

    • Un elenco di ruoli (ovvero gruppi) con read/ write definizioni di accesso per ogni
    • Definizione dell'uso dei privilegi che interessano l'ambiente di pubblicazione; ad esempio, replicate
    • Per gli utenti con privilegi minimi, è necessario definire i flussi di lavoro
    • Utenti nel editor il gruppo non deve avere admin i diritti e non far parte del administrators gruppo

    Per ulteriori informazioni, consulta Amministrazione degli utenti e sicurezza.

  • Monitoraggio e manutenzione

    Il monitoraggio e la manutenzione sono aspetti fondamentali per garantire il funzionamento ottimale della soluzione una volta che questa è attiva. A questo scopo è necessario definire:

    • Che cosa richiede il monitoraggio
    • compiti di manutenzione; sia regolari che per casi speciali

    Vedi anche Monitoraggio e manutenzione per ulteriori informazioni.

  • Migrazione

    Eventuali contenuti del sistema legacy devono essere rivisti e convalidati per la migrazione.

  • Piano di ripristino

    Assicurati 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 quali backup, ripristino, fallover e altre.

Ambiente di sviluppo

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

Milestone

  • Ambiente di sviluppo

    Pianifica e documenta l'ambiente di sviluppo, tra cui:

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

  • Sistema di prova

    Pianifica e documenta l’ambiente di test, tra cui:

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

  • Sistema di produzione

    Pianifica e documenta l'ambiente di produzione, tra cui:

  • Integrazione

    Pianificare, documentare e testare tutti gli aspetti del sistema e integrazione delle soluzioni, tra cui:

  • Migrazione

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

    • Architettura dei contenuti
    • Strategia di migrazione

  • Comunicazione

    Assicurati che tutti i membri del team e l’utente tipo del progetto siano aggiornati in base alle esigenze.

  • Documentazione.

    Documentare pienamente 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 la funzionalità che per prestazioni.

NOTA

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

Spetta al responsabile del progetto valutare le eventuali implicazioni dei risultati e decidere le azioni appropriate.

Milestone

  • Test di accettazione da parte dell'utente finale

    Test di accettazione degli utenti (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 lista di controllo ufficiale per la consegna del cliente; idealmente automatizzato ed eseguito su base notturna contro un'istantanea. I risultati devono essere inviati al project manager e al team di sviluppo

  • Test di prestazioni e di carico

    I test di prestazione e carico sono utilizzati per garantire che la soluzione soddisfi i livelli di prestazioni richiesti, in media e nei carichi di picco.

    Per ulteriori informazioni sui test delle prestazioni, vedi:

    NOTA

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

Rollout

Il rollout della tua nuova applicazione richiede un'attenta pianificazione per garantire un Go Live fluido. Ciò include la conferma di un elevato livello di sicurezza, la formazione di tutti i potenziali utenti e l'esecuzione di più prove per confermare che tutte le questioni sono state affrontate.

Milestone

  • Preparazione

    La preparazione e la pianificazione contribuiranno a garantire un rollout uniforme.

  • Formazione

    Assicurare che tutto il personale coinvolto sia stato formato.

    Vedi Adobe Experience Manager nel catalogo dei corsi.

  • Amministratori formati

    Assicurati che gli amministratori delle soluzioni abbiano:

    • Formati
    • Ricevuto materiale di formazione adeguato
    • Ricevuta la documentazione appropriata

  • Utenti formati

    Assicurati che gli autori abbiano:

    • Formati
    • Ricevuto materiale di formazione adeguato
    • ha ricevuto la documentazione appropriata; ad esempio, la Guida utente

  • Test di penetrazione

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

  • Test di penetrazione/sicurezza

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

    Consulta la sezione Lista di controllo sicurezza per ulteriori dettagli.

Vai in diretta

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

Milestone

  • Preparazione

    La preparazione e la pianificazione contribuiranno a garantire un buon Go Live.

  • Sicurezza

    Conferma la sicurezza della soluzione per gli utenti interni ed esterni e i relativi contenuti.

  • Regresso

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

  • Assistenza

    Assicurati che i servizi di supporto siano in-place e pronti.

  • Transizione

    Pianifica ed esegui la transizione al tuo ambiente di produzione e agli utenti.

  • Uscita

    Prepara ed esegui i test di fumo.

Persona

Le liste di controllo sono progettate da persone. Questi sono i ruoli con un significativo coinvolto nel ciclo di vita del progetto.

Ci sono anche alcuni altra persona che sono coinvolti in compiti specifici.

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:

    • la definizione e i criteri del successo
    • KPI principali

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

Project Manager

Il project manager è:

  • Responsabile della consegna complessiva del progetto in base ai requisiti (ad esempio ambito, KPI, criteri di successo e definizione) forniti dal promotore del progetto.
  • Responsabile della definizione del budget e delle risorse del progetto in base a tale budget.
  • Il punto principale di comunicazione per tutti coloro che partecipano al progetto.

Architetto

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 standby a freddo oppure quando è necessaria una rete di distribuzione dei contenuti (CDN).
  • Definisci anche l'architettura della soluzione AEM in base ai requisiti del cliente. Ciò può includere il concetto di ruoli utente (con i diritti correlati), la relazione tra modelli e componenti o quando utilizzare la gestione multisito.

Analista aziendale

L'analista:

  • È principalmente responsabile della raccolta e dell'analisi dei requisiti di alto livello, trasformandoli poi in specifiche:

    • per il project manager da utilizzare per la pianificazione dello sviluppo
    • affinché il team di sviluppo possa lavorare da durante la progettazione e lo sviluppo.

  • Lavora a stretto contatto con il cliente per analizzare i requisiti. I loro punti di corrispondenza sono:

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

Lead di sviluppo

Il ruolo guida nello 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:

    • garantire l’allineamento con i KPI aziendali e prestazionali
    • tenendo conto dei criteri di successo e della definizione

  • Lavora a stretto contatto con l'architetto (in particolare 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.

Piombo di qualità

Il piombo di qualità:

  • è responsabile della qualità della consegna; garantire che soddisfi i criteri di successo e gli eventuali KPI definiti dal client.
  • Definisce le metriche di qualità, in linea con tutte le parti interessate, elabora i piani di test e ne assicura l’esecuzione.
  • Crea e distribuisce rapporti alle parti interessate del progetto.

Ingegnere del sistema

Il tecnico del sistema:

  • È responsabile della supervisione dell'infrastruttura del progetto.

  • È responsabile di:

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

  • Fornisce consigli hardware, controlla le varie 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 criteri del cliente.
  • fornisce un concetto di sicurezza, operazioni di sicurezza e consigli per qualsiasi concetto di sicurezza basato su hardware; quali zone e firewall.

Altro Persona

  • Parti interessate

    • Persone (spesso provenienti dal mondo degli affari) che hanno un interesse (partecipazione) 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

    • Le persone che utilizzeranno il sistema per creare e gestire il contenuto del sito web.

Documenti richiesti e risultati finali

Le liste di controllo coprono le Documenti richiesti e Risultati finali per ogni cardine.

  • Non esiste una relazione 1:1 tra questi; ad esempio, un gruppo di documenti richiesti può dare luogo a un singolo recapito.
  • Un risultato finale da una persona può essere un documento obbligatorio per un’altra persona durante lo stesso cardine.

Documenti richiesti

La Documenti richiesti sono necessarie per l’utente di destinazione appropriato al momento della produzione dei relativi risultati finali.

Per ogni Documento richiesto l’utente tipo deve indicare:

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

Risultati finali

Per ogni tappa, l’utente appropriato è responsabile della consegna di documenti specifici e quindi della realizzazione delle proprie responsabilità per una specifica tappa.

Per ogni Consegna l’utente deve indicare:

  • Y/N: se è stato completato.

I risultati finali sono spesso utilizzati come Documenti richiesti per l'attività cardine corrente o successiva.

Per le best practice su distribuzione, amministrazione, sviluppo o authoring, consulta:

Aree principali della documentazione

In questa pagina