Pianificare e definire le 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. Misurare il successo definendo gli obiettivi aziendali.
Per iniziare, valutare prima di tutto dove si trova l'organizzazione con il modello di funzionalità di progettazione della piattaforma. Usare il modello per creare un grafico in cui l'organizzazione si trova in sei funzionalità di progettazione della piattaforma di base: investimenti, adozione, governance, provisioning e mangement, interfacce e misurazioni 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 come usare il modello.
È possibile pianificare e aggiornare continuamente gli obiettivi di progettazione della piattaforma nel tempo. Essere chiari su ciò che si vuole ottenere da investire nel percorso di progettazione della piattaforma può andare molto a lungo per aiutare a creare il supporto organizzativo.
In qualità di responsabile dell'ingegneria della piattaforma, una volta messo in testa, "Non faccio qualcosa per l'ingegneria della piattaforma fino a quando non ho qualcosa che posso guadagnare." - Peter, responsabile dell'ingegneria della piattaforma, Multinazionale Tech Company
Quando si pensa agli obiettivi, definire l'ambito per gli obiettivi aziendali correlati al lavoro di progettazione della piattaforma, anziché le specifiche di un determinato team di sviluppo. Gli obiettivi comuni di progettazione della piattaforma di alto livello includono:
- Aumentare la qualità dell'applicazione, ridurre i bug e i problemi durante il rilascio.
- Migliorare la sicurezza, ridurre il numero di eventi imprevisti di sicurezza o rilevare vulnerabilità ed esposizioni comuni una volta nell'ambiente di produzione.
- Ridurre i rischi attraverso una migliore conformità in aree come licenze, accessibilità, privacy o regolamentazione governativa.
- Accelerare il valore time-to-business riducendo la complessità, il sovraccarico e promuovendo la condivisione del codice tramite procedure di origine interne.
- 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 porta 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à.
Dopo aver identificato gli obiettivi, scegliere gli scenari chiave per escludere il backlog e la roadmap. Ad esempio, vedere questi scenari e i processi associati da eseguire.
- Comprendere e applicare le procedure consigliate e i criteri dell'organizzazione
- Crea un nuovo repository
- Strumenti per il provisioning
- Effettuare il provisioning di un'infrastruttura comune
- Concedere ai membri del team l'accesso
- Stabilire pipeline CI/CD
- Effettuare il provisioning dell'infrastruttura di sviluppo
- Distribuzione iniziale per testare "pipe"
- Aggiornare l'accesso agli strumenti, ai servizi
- Configurare il computer per sviluppatori
- Aumentare le dimensioni dei membri del team nelle applicazioni
- Creare un ambiente sandbox dell'applicazione
- Creare ed esaminare la prima richiesta pull
- Informazioni sulle procedure consigliate dell'organizzazione, opzioni disponibili
- Aggiornare/aggiungere l'infrastruttura come artefatti di codice
- Creare un ambiente sandbox dell'applicazione
- Verificare gli aggiornamenti
- Implementare le modifiche ad altri ambienti
- 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 in client o pipeline CI/CD
- Individuare le API disponibili, l'SDK, i servizi
- Valutare se soddisfa le esigenze
- Connettersi con il team proprietario per eventuali domande
- Adottare per l'applicazione
- Notifica di un problema
- Valutare se il codice o l'infrastruttura dell'app (o entrambi)
- Creare un ambiente sandbox che rispecchia prod (se diverso)
- Apportare modifiche, testare, rilasciare fuori banda
- 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
- Informazioni sull'utilizzo degli strumenti
- Notificare agli utenti la deprecazione
- (Facoltativo) Coordinamento della migrazione degli utenti a un nuovo strumento
- Architettura proposta pilota
- Regolare in base ai risultati pilota
- Aggiornare la documentazione sulle procedure consigliate
- Creare modelli, aggiornare automazione, criteri, governance
- 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.
Cercare quindi di comprendere i problemi più importanti che gli sviluppatori e altri ruoli affrontano 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. Uno è 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ù interviste. In questo modo, l'agilità continua a garantire che l'utente sia concentrato sulla fornitura di valore ai clienti interni.
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 più sottile valida (TVP) (MVP per la piattaforma), eseguirne il progetto pilota con un set di team di sviluppo che sono 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 modo in cui si ha successo è una parte importante di una mentalità orientata ai prodotti. Anche piccoli successi con investimenti modesti possono gettare le basi per investimenti più grandi da costruire.
Ad esempio, può essere difficile proteggere i finanziamenti o l'acquisto per le attività di conformità perché possono essere percepite come un'imposta operativa per i 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. Zero in su quelli che consentono di misurare se l'utente e i clienti del team di sviluppo hanno raggiunto gli 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 mediani per completare la prima richiesta pull (onboarding), minuti di mediana per i processi di compilazione e test (ad esempio: CI), tempo mediano per unire la richiesta pull.
- Qualità del software: eventi imprevisti (problemi) creati al mese per ogni sviluppatore(conteggio normalizzato in numero di sviluppatori), tempo medio per correggere (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. Per iniziare, è necessario misurare alcune linee di base, ma è possibile osservare queste metriche cambiano man mano che si migliora la piattaforma.
Altre metriche potrebbero interessare la misurazione di te o dei tuoi sponsor:
Area | Metriche di esempio |
---|---|
Prestazioni di distribuzione del software | DevOps Research and Assessment (DORA): Modificare il lead time, la frequenza di distribuzione, la frequenza di modifica, il tempo necessario per ripristinare il servizio (MTTR) |
Operazioni | DORA (MTTR), tempo medio tra l'errore (MTBF), il tempo medio per riconoscere, la disponibilità dei clienti finali, latenza, metriche di velocità effettiva, 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. Indipendentemente da ciò, assicurarsi di misurare regolarmente la facilità d'uso e il sondaggio della piattaforma che si dispone di 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.
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.
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.
Iniziare con le nuove applicazioni di dimensioni ragionevoli quando si stanno pilotando le nuove funzionalità della piattaforma o della piattaforma. In questo modo si avrà anche esperienza nella gestione della piattaforma come prodotto. Evitare che i progetti di ripiattaformazione inizino da quando si impara mentre si procede e le applicazioni esistenti di grandi dimensioni hanno spesso esigenze specifiche che vengono scoperte solo durante la ripiattaforma stessa. Per questo motivo, l'accoppiamento del successo a questi tipi di sforzi può comportare mancate corrispondenze o problemi di interruzione tardiva. A partire da qualcosa di più recente è possibile avere fiducia nella direzione in cui fornisce il valore fornito. Ciò riduce il rischio di affrontare questi sforzi più grandi. Metti un altro modo, se sei sicuro che le persone possono iniziare a destra e rimanere a destra, allora diventa più facile guidare una campagna di ottenere una campagna giusta con ciò che impari dall'esperienza. Se questo approccio non è possibile, è consigliabile eseguire un'analisi attenta, impostare le aspettative e eseguire un passaggio incrementale invece di provare a modificare tutto contemporaneamente.
Gli sviluppatori sono più propensi ad adottare e mantenere le nuove funzionalità quando vengono rilevate in qualcosa che già amano e usano. Durante la valutazione dei concetti per offrire nuove funzionalità, assicurarsi di esaminare le opzioni che estendono i "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 che gli sviluppatori abbiano accesso limitato ai sistemi downstream per elementi come l'infrastruttura di provisioning. È necessario un modo controllato per abilitare questo accesso per le esperienze self-service.
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.
Evitare di creare funzionalità personalizzate della piattaforma dell'applicazione che potrebbero essere oscurate dalle funzionalità rilasciate dai fornitori di software nel tempo. Ad esempio, hosting di runtime, mesh di servizi, sistemi di identità e così via. Se si ritiene che un'urgenza in un'area sospetta potrebbe essere simile a questa, pianificare più opzioni di implementazione in base alla manutenzione a lungo termine causerà probabilmente il passaggio nel tempo.