Pianificare e classificare in ordine di priorità

Informazioni su come identificare gli obiettivi per le attività di progettazione della piattaforma in base al modello di funzionalità di progettazione della piattaforma, esaminare gli scenari comuni e cercare modi per misurare il successo. Misura il successo allineando i tuoi obiettivi agli obiettivi aziendali.

Identificare gli obiettivi e gli scenari chiave

Per iniziare, valutare prima di tutto dove si trova l'organizzazione usando il modello di funzionalità di progettazione della piattaforma. Usare il modello per valutare e collocare la tua organizzazione nell'ambito di sei capacità principali di ingegneria delle piattaforme: investimenti, adozione, governance, provisioning e gestione, interfacce, e misurazione e feedback. Tutte le organizzazioni sono più avanzate in alcune funzionalità rispetto ad altre. Una volta che si sa dove si trova oggi l'organizzazione, è possibile scegliere le funzionalità che si vuole aumentare. Per altre informazioni, vedere Valutare le procedure correnti e definire obiettivi futuri.

È possibile pianificare e aggiornare continuamente gli obiettivi di progettazione della piattaforma nel tempo. Essere chiari su ciò che si vuole ottenere nell'investire nel percorso di ingegneria della piattaforma può essere molto utile per costruire il supporto organizzativo.

In qualità di responsabile dell'ingegneria della piattaforma, come ha affermato una volta, "Non faccio qualcosa per l'ingegneria della piattaforma fino a quando non ho qualcosa da cui posso trarre vantaggio." - Peter, responsabile dell'ingegneria della piattaforma, società tecnologica multinazionale

Quando si pensa agli obiettivi, definire l'ambito degli obiettivi aziendali correlati al lavoro di progettazione della piattaforma, invece che alle specifiche di un determinato team di sviluppo. Gli obiettivi comuni di progettazione della piattaforma di alto livello includono:

• Aumentare la qualità dell'applicazione e ridurre i bug e i problemi durante il rilascio.
• Migliorare la sicurezza e ridurre il numero di eventi imprevisti di sicurezza o rilevati vulnerabilità ed esposizioni comuni (CVE), una volta nell'ambiente di produzione.
• Ridurre i rischi attraverso una migliore conformità in aree come licenze, accessibilità, privacy o regolamentazione governativa.
• Accelerare il tempo di ottenere valore aziendale riducendo la complessità, il sovraccarico e promuovendo la condivisione del codice tramite pratiche di 'inner source'.
• Ridurre i costi di sviluppo o operazioni, ridurre al minimo la duplicazione e migliorare l'automazione.

La scelta dell'obiettivo principale è fondamentale perché l'obiettivo determina il modo in cui si pensa alla definizione delle priorità.

Ancora meglio, accettando obiettivi e risultati chiave (OKR) con la leadership e i partner interni aiuta a stabilire obiettivi misurabili per la fase corrente degli investimenti. Altri approcci di pianificazione hanno concetti simili se l'organizzazione usa qualcos'altro. I migliori OKR sono quelli che è possibile impostare in base a una misura concreta perché rimuove la soggettività.

Scenari e processi da eseguire

Dopo aver identificato gli obiettivi, scegliete gli scenari chiave per sviluppare il backlog e la roadmap. Ad esempio, vedere gli scenari seguenti e i processi associati da eseguire.

Scenario: iniziare a creare una nuova applicazione

• Comprendere e applicare le procedure consigliate e i criteri dell'organizzazione
• Creare un nuovo repository
• Strumenti di gestione del provisioning
• Fornire un'infrastruttura comune
• Concedere ai membri del team l'accesso
• Configurare pipeline CI/CD
• Configurare l'infrastruttura di sviluppo
• Distribuzione iniziale per testare le "pipe"

Scenario: aggiungere o rimuovere un nuovo membro a un team esistente

• Aggiornare l'accesso a strumenti e servizi
• Configurare un computer per sviluppatori
• Preparare il membro del team per le applicazioni
• Creare un ambiente sandbox dell'applicazione
• Creare ed esaminare prima la richiesta pull

Scenario: aggiungere o aggiornare l'infrastruttura per l'applicazione esistente

• Informazioni sulle procedure consigliate dell'organizzazione, opzioni disponibili
• Aggiornare o aggiungere l'infrastruttura come artefatti di codice
• Creare un ambiente sandbox dell'applicazione
• Verificare gli aggiornamenti
• Implementare le modifiche ad altri ambienti

Scenario: aggiungere o aggiornare lo strumento per il team esistente

• Informazioni sulle procedure consigliate dell'organizzazione, opzioni disponibili
• Richiedere l'uso di un nuovo strumento
• Aggiornare l'accesso dei membri del team agli strumenti
• (Se applicabile) Integrare lo strumento nel software client o nelle pipeline CI/CD

Scenario: trovare o riutilizzare l'API esistente, l'SDK o il servizio

• Individuare le API, l'SDK o i servizi disponibili
• Valutare se soddisfa le esigenze
• Connettersi con il team proprietario per eventuali domande
• Adottare per l'applicazione

Scenario: rispondere a un evento imprevisto operativo

• Notifica di un problema
• Valutare se il codice dell'app o l'infrastruttura (o entrambi) sono coinvolti.
• Creare un ambiente sandbox che rispecchia prod (se diverso)
• Apportare modifiche, testare, rilasciare fuori banda

Scenario: correggere rapidamente gli eventi imprevisti di sicurezza

• Notifica di un problema
• Valutare l'ampiezza dei problemi (quali sistemi)
• Comprendere se i clienti sono interessati direttamente
• Creare un ambiente sandbox che rispecchia prod (se diverso)
• Apportare modifiche, testare, rilasciare fuori banda
• Comunicare con chiunque sia interessato

Scenario: Strumento deprecato

• Informazioni sull'utilizzo degli strumenti
• Notificare agli utenti la deprecazione
• (Facoltativo) Coordinare la migrazione degli utenti a un nuovo strumento

Scenario: rollout del nuovo modello architettonico dell'app

• Architettura pilota proposta
• Regolare in base ai risultati pilota
• Aggiornare la documentazione sulle procedure consigliate
• Creare modelli, aggiornare automazione, criteri e governance

Controllare la conformità delle applicazioni (GDPR, accessibilità, standard dell'infrastruttura)

• Informazioni sulle regole di conformità correnti
• Verificare che l'applicazione soddisfi le regole
• Stabilire la scadenza per le correzioni per le deviazioni
• Apportare modifiche, testare, rilasciare

Molti scenari si applicano a più ruoli. Considerare le metriche per misurare il miglioramento.

Da problemi a concetti

Comprendere quindi i problemi più importanti che gli sviluppatori e altri ruoli devono affrontare con gli scenari e i processi identificati. Può essere tentabile iniziare ad analizzare nuovi prodotti per colmare le lacune percepite, ma se questi prodotti non risolvono un importante punto di dolore, è improbabile che vengano adottati o apprezzati.

Esistono diversi approcci che consentono di eseguire questo tipo di indagine, ad esempio il framework di progressione dell'ipotesi. Anche se non si usa un processo formalizzato come il framework di progressione dell'ipotesi, è consigliabile intervistare gli sviluppatori su un lavoro da svolgere per definire l'ambito della discussione e quindi identificare i problemi più importanti per svolgere il proprio lavoro. Una volta che si ha un buon senso di ciò che questi problemi sono, procedere con i piani per risolverli. In questo modo è possibile assicurarsi di creare funzionalità che gli sviluppatori vogliono usare.

Per poter ripetere rapidamente questo processo, identificare un utente che possa rappresentare la voce del cliente direttamente nel team della piattaforma per sviluppatori interna. Questo ruolo viene in genere chiamato product manager (anche se ha un titolo di lavoro diverso) e, man mano che le loro conoscenze aumentano, sono in grado di stimare accuratamente i risultati per decisioni più piccole e determinare quando è necessario fare più colloqui. In questo modo mantieni la tua agilità mentre ti assicuri di concentrarti sulla fornitura di valore ai tuoi clienti interni.

Sostieni i tuoi investimenti iniziali

Dopo aver creato un set di problemi e concetti convalidati, si è in buona posizione per decidere dove investire. Tuttavia, si considerino gli investimenti iniziali e la manutenzione a lungo termine necessari per valutare le soluzioni. La soluzione più bassa che può risolvere il problema tende a essere quella giusta per iniziare, ma spesso è il lavoro di manutenzione che in definitiva decide se l'investimento è riuscito.

In un altro modo, non creare soluzioni destinate a fasi successive del percorso, a meno che non sia davvero necessario.

Dopo aver identificato la piattaforma fattibile più sottile (TVP) (come un prodotto minimo vitale per la piattaforma), esegui una distribuzione pilota con un set di team di sviluppo disposti a fornire feedback. Se la soluzione pilota risolve i problemi riscontrati da questi team, non si dovrebbe avere problemi a trovare qualcuno interessato a impegnarsi.

È consigliabile acquisire alcune metriche chiave durante la distribuzione pilota di una nuova funzionalità o modifiche in modo da poter misurare se il concetto è riuscito prima di implementarlo.

Misurare il successo e la dimostrazione del valore

Misurare il successo è una parte importante di una mentalità orientata al prodotto. Anche piccoli successi con investimenti modesti possono gettare le basi su cui costruire investimenti più grandi.

Ad esempio, può essere difficile ottenere finanziamenti o il consenso per gli sforzi di conformità, perché possono essere vissuti come un costo operativo dai team di sviluppo che offrono valore aziendale. Una mentalità del prodotto può cambiare tale percezione. Con una mentalità orientata al prodotto, si sta cercando di garantire che i clienti per la piattaforma di sviluppo interna siano soddisfatti e che gli obiettivi aziendali degli stakeholder siano soddisfatti. Le metriche consentono di usare i fatti per dimostrare che si sta fornendo valore aziendale. L'impostazione degli OKR può essere utile, in particolare se si dispone di metriche che è possibile usare per rimuovere distorsioni soggettive. Anche se attualmente non si misura nulla di applicabile, è possibile impostare un OKR di apprendimento per impostare una linea di base che verrà quindi perfezionata dopo che questa baseline è nota.

Di seguito sono riportati esempi di metriche note che è possibile misurare per determinare se i team con cui si sta lavorando stanno ottenendo valore da ciò che si sta creando. Concentrati su quelli che ti aiutano a misurare se tu e i clienti del tuo team di sviluppo state raggiungendo i vostri obiettivi. Ad esempio, di seguito è riportato un set di metriche che consentono di valutare se la piattaforma contribuisce a un'organizzazione di progettazione efficace:

• Velocità/tempo per il valore aziendale: giorni medi per completare la prima richiesta di pull (onboarding), minuti medi per i processi di compilazione e collaudo (ad esempio: CI), tempo medio per il merge della richiesta di pull.
• Qualità del software: eventi imprevisti (problemi) creati al mese per sviluppatore (conteggio normalizzato in numero di sviluppatori), tempo medio per il ripristino (MTTR), tempo medio per analizzare e correggere il problema di sicurezza.
• Facilità d'uso della piattaforma: soddisfazione dell'utente netto (NSAT)
• Ecosistema fiorente: punteggio medio per ognuna delle domande intervistate seguenti: "Sono autorizzato a svolgere il mio lavoro migliore", "la maggior parte dei giorni sono eccitato dal lavoro che faccio", "il lavoro che faccio è significativo per me".

È quindi possibile suddividere queste metriche in base a organizzazione, team o progetto. È necessario misurare alcune linee di base per iniziare, ma è quindi possibile osservare queste metriche cambiano man mano che si migliora la piattaforma.

Altre metriche che l'utente o gli sponsor potrebbero essere interessati a misurare includono:

Area	Metriche di esempio
Prestazioni di distribuzione del software	DevOps Research and Assessment (DORA): Tempo di consegna delle modifiche, frequenza di distribuzione, tasso di fallimento delle modifiche, tempo di ripristino del servizio (MTTR)
Operations	DORA (MTTR), tempo medio tra i guasti (MTBF), tempo medio per il riconoscimento, disponibilità dei clienti finali, latenza, metriche di throughput, costo per team, costo per distribuzione
Metriche di adozione delle funzionalità della piattaforma	Numero di team o sviluppatori che usano uno strumento o una funzionalità nel tempo, percentuale di repository che usano la piattaforma, modelli più diffusi, pipeline e così via.

La raccolta delle metriche richiede tempo e impegno, quindi è importante concentrarsi sulle metriche critiche per gli obiettivi principali identificati, in particolare quelli che alimentano gli OKR. I prodotti basati su OpenTelemetry come Application Insights possono essere utili.

Assicurati di misurare la facilità d'uso della piattaforma e verifica regolarmente che tu abbia un ecosistema fiorente. Queste metriche vengono spesso perse per i sistemi interni e sono un indicatore principale per stabilire se si soddisfano gli obiettivi aziendali più ampi, poiché la partecipazione impegnata è fondamentale per il successo. Consente anche di sapere se è il momento di eseguire ulteriori attività di sviluppo dei clienti per capire dove procedere.

Altri suggerimenti

Indipendentemente dal modo in cui si inizia, tenere presente che è consigliabile pianificare il cambiamento, iniziare con le nuove applicazioni per i progetti pilota, concentrarsi sul miglioramento delle esperienze utente esistenti, adottare il principio dei privilegi minimi, pianificare la sperimentazione controllata e ridurre al minimo la personalizzazione.

Modifica prevista

La piattaforma dell'applicazione di destinazione si evolverà nel tempo e potrebbe non essere possibile eseguire la migrazione di tutti gli investimenti esistenti contemporaneamente. Si pensi a come è possibile supportare più varianti nel tempo e pianificare il cambiamento.

Convalidare idee con applicazioni più recenti

Inizia con nuove applicazioni di dimensioni ragionevoli quando si sta testando le capacità della nuova piattaforma. Questo offre anche esperienza nella gestione della piattaforma come prodotto. Evitare i progetti di replatforming per cominciare, poiché si impara mentre si procede, e le applicazioni esistenti di grandi dimensioni spesso hanno esigenze uniche che vengono scoperte solo durante il processo di replatforming stesso. A causa di ciò, legare il proprio successo a questi tipi di sforzi può comportare discrepanze nelle aspettative o problemi dell'ultimo minuto. Iniziare con qualcosa di più recente può infondere fiducia nella tua direzione e nel valore che essa può fornire. Ciò riduce il rischio di affrontare questi sforzi più grandi. In altre parole, se sei sicuro che le persone possano iniziare correttamente e continuare correttamente, diventa più facile promuovere una campagna di successo basata su ciò che si apprende dall'esperienza. Se questo approccio non è possibile, si vuole eseguire un'analisi attenta, impostare le aspettative e eseguire un passaggio incrementale invece di provare a modificare tutto contemporaneamente.

Concentrarsi sui centri di gravità esistenti per le esperienze utente prima di crearne di nuovi

Gli sviluppatori sono più propensi ad adottare e mantenere le nuove funzionalità quando vengono rilevate in qualcosa che già amano e usano. Quando si valutano i concetti per offrire nuove funzionalità, assicurarsi di esaminare le opzioni che accettano l'estensione dei centri di gravità esistenti. Ad esempio, editor/IDE (Visual Studio, VS Code), suite DevOps (GitHub, Azure DevOps), CLI esistenti o un portale interno esistente può essere più efficace di un portale completamente nuovo o di un'altra esperienza utente. Per altre informazioni, vedere Esperienze utente.

Si supponga il principio dei privilegi minimi

Si supponga che gli sviluppatori abbiano accesso limitato ai sistemi a valle per aspetti come la gestione dell'infrastruttura. È necessario un modo controllato per abilitare questo accesso per le esperienze self-service.

Pianificare la sperimentazione controllata

Sperimentare prima di implementare modifiche importanti o rischiose. Non tutto deve essere completamente automatizzato per iniziare. Un flusso di lavoro manuale attivato automaticamente può essere un ottimo modo per pilotare idee.

Ridurre al minimo la personalizzazione della piattaforma app

Evitare le funzionalità della piattaforma applicativa personalizzate che potrebbero essere sorpassate dalle funzionalità introdotte dai fornitori di software col tempo. Ad esempio, hosting di runtime, reti di servizio, sistemi di identità e così via. Se trovi un'urgenza in un'area che sospetti possa essere di questo tipo, pianifica più opzioni di implementazione, dato che la manutenzione a lungo termine probabilmente ti farà cambiare nel tempo.

Contenuti correlati

• Applicare sistemi di progettazione software