Show Menu
ARGOMENTI×

Gestione dei progetti - Elenco di controllo Best Practices

La gestione di un progetto per implementare Adobe Experience Manager (AEM) richiede pianificazione e comprensione per essere certi di essere a conoscenza dei problemi e delle relative decisioni da prendere (sia prima che durante l’implementazione del progetto).
Per aiutarti, le best practice sono:

Pannello Heartbeat progetto

Il foglio di lavoro Heartbeat progetto 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 ​per​ 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 rilevanti, insieme ai documenti necessari per produrre i risultati finali definiti.
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 termine; 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:

Milestones

  • 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 durante la 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.

Milestones

  • 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 allo 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.

Milestones

  • 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 (compresi 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; consultate le linee guida sui requisiti Requisiti tecnici tecnici e sul ridimensionamento hardware
    • Processi per ogni ambiente; ad esempio, requisiti di implementazione e manutenzione
    • Attività di manutenzione (Datastore GC, ottimizzazione TarPM, ecc.)
    • Dispatcher caching
    • Clustering Publish/Authoring
    • 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):
    • Come tutti i sottosistemi e le integrazioni di soluzioni saranno riuniti 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 di test 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.
    Consultate anche Adobe Support Portal .

Pianificazione e operazioni

Analogamente, 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. Sono inoltre necessari i processi appropriati per la loro manutenzione.

Milestones

  • Autorizzazioni
    Devi pianificare e 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 definizioni di read / write accesso 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 editor gruppo non devono avere admin diritti né far parte del administrators gruppo
    For more information, see User Administration and Security .
  • 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, consulta 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 situazioni di emergenza, questo deve essere disponibile per garantire l’utilizzo della produzione in AEM. Questo dovrebbe coprire situazioni come backup, ripristino, failover e altri.

Sviluppo

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

Milestones

  • Ambiente di sviluppo
    Pianificare e documentare l'ambiente di sviluppo, compresi:
    • Architettura
      • 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 di 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
    • 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:
    • Architettura
    • Ritardo di distribuzione
    • Integrazione/dipendenze software di terze parti
    • Configurazione della sicurezza
    • Prestazioni della linea di base verificate eseguendo i test Giorno Duro del giorno duro nella configurazione di produzione
    • Requisiti per le prove di prestazione; consulta Best practice per la garanzia della qualità
  • Integrazione
    Pianificare, documentare e testare tutti gli aspetti dell'integrazione del sistema e 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, sarà necessario sottoporsi a test rigorosi, sia per le funzionalità che per le prestazioni .
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.

Milestones

  • Test di accettazione 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:
    Questo processo dovrà essere proseguito durante il normale utilizzo 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 risolti.

Milestones

  • Preparazione
    La preparazione e la pianificazione contribuiranno a garantire un'implementazione uniforme.
  • Formazione
    Garantire che tutto il personale coinvolto sia stato formato.
    Consultate Adobe Experience Manager nel catalogo dei corsi.
  • Amministratori formati
    Assicurati che gli amministratori della soluzione abbiano:
    • Formati
    • Ricevuto materiale di formazione appropriato
    • Ricevuta la documentazione appropriata
  • Utenti con formazione
    Assicuratevi che gli autori abbiano:
    • Formati
    • 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 dettagli, vedere l'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.

Milestones

  • 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 con un ruolo significativo nel ciclo di vita del progetto.
Ci sono anche altre persone coinvolte 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:
    • 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.

Architect

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, quindi trasformarli 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 sul business 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 (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 Qualità

Lead 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à, 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.

System Engineer

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.

Altro 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 e i risultati finali ​richiesti 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 all'utente appropriato per la produzione dei risultati finali.
Per ciascun documento ​obbligatorio, 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 risultato finale il soggetto deve indicare:
  • S/N : se è stato completato.
I risultati finali vengono spesso utilizzati come documenti ​richiesti per l'attività cardine corrente o successiva.

Aree principali della documentazione