Il ruolo dell'Architetto di soluzioni nella governance di un progetto

Completato

Spesso, il ruolo dell'architetto della soluzione in un progetto consiste nell'usare la propria esperienza e competenza per valutare problemi e cambiamenti. Tuttavia, monitorare il cambiamento in un progetto è estremamente semplice, soprattutto in Microsoft Power Platform. Di conseguenza, l'architetto della soluzione potrebbe concentrarsi troppo sul monitoraggio del cambiamento invece di assicurare l'avanzamento del progetto. Per questo, l'Architetto di soluzioni dovrebbe guidare altri membri del team del progetto nell'esecuzione della valutazione e dell'analisi di problemi e cambiamenti.

Una sfida che devono affrontare i nuovi architetti di soluzioni sta nel lasciare il ruolo di chi agisce per ricoprire invece il ruolo di guida degli altri. Un Architetto di soluzioni deve essere a disposizione degli altri membri del team del progetto e supportare la loro crescita.

Coinvolgimento nella definizione della governance

Con i progetti Microsoft Power Platform, apportare cambiamenti può essere semplice; tuttavia, apportare diverse piccole modifiche senza un solido processo di governance può determinare il fallimento di un progetto. Ad esempio, l'architetto della soluzione deve assicurarsi che il processo di valutazione del cambiamento non richieda più tempo dell'implementazione del cambiamento.

È essenziale che l'architetto della soluzione sia coinvolto nella definizione dei processi e delle procedure per la governance del progetto. Il suo coinvolgimento aiuta a garantire che i processi e le procedure siano appropriati per le tecnologie Microsoft Power Platform usate e che non causino un inutile sovraccarico.

Condivisione di feedback utile

L'architetto della soluzione funge spesso da intermediario tra il cliente e i membri del team. Pertanto, deve fornire un feedback a entrambe le parti. In primo luogo, il feedback va fornito per aiutare a dare forma alla soluzione.

Si può proporre un feedback fin dalla creazione della richiesta di proposta (RFP)/dichiarazione dei lavori (SOW). Tuttavia, il feedback dovrebbe essere fornito su base continuativa durante tutto il progetto.

L'architetto della soluzione è responsabile di garantire che il feedback sia costruttivo e convertibile in azioni pratiche.

Gestione delle cattive notizie

Occasionalmente, l'architetto della soluzione fornisce feedback che potrebbe non essere ben accolto. Le cattive notizie non migliorano con il tempo. L'architetto deve riconoscere e condividere le cattive notizie nelle prime fasi del processo.

Esempi di cattive notizie che l'architetto della soluzione non dovrebbe nascondere:

  • Il costo delle licenze utente aumenterà dell'87% se si procede in base a quanto stabilito.
  • Questa funzionalità è stata deprecata.
  • Con l'aggiunta della relazione, l'importazione dei dati richiederà ora 30 giorni.
  • La migrazione dei dati ha identificato 200 nuove colonne e da questi dati sono stati individuati tre nuovi processi non documentati.

L'architetto della soluzione deve garantire che il feedback, in particolare le cattive notizie, sia convertibile in azioni pratiche. Affermare che "qualcosa non va" è inutile perché non fornisce un chiaro invito all'azione e il destinatario viene lasciato a cercare di capire quale potrebbe essere il problema. Al contrario, l'architetto della soluzione dovrebbe costruire una chiara dichiarazione del problema e quindi fornire riferimenti e specificare il potenziale impatto sul progetto.

Considerare i progetti in cui si è stati coinvolti e ricordare in che modo sono state gestite le cattive notizie e qual è stato l'effetto sul progetto.

Come aiutare le persone a raggiungere la stessa conclusione

Sebbene l'architetto della soluzione possa avere le maggiori competenze, è necessario aiutare i membri del team di progetto e il cliente ad arrivare alla soluzione di un problema. Dire "non funzionerà" probabilmente metterà qualcuno sulla difensiva. L'architetto della soluzione dovrebbe essere sempre costruttivo ed evitare di dire "no" troppo spesso. Al contrario, dovrebbe offrire opzioni o negoziare i requisiti.

Dovrebbe porre domande che indirizzano verso una specifica risposta, ad esempio "questo significa che 1.000.000 di flussi cloud di Power Automate verranno eseguiti con quella configurazione?" Formulare domande di questo tipo incoraggerà gli interlocutori a valutare l'impatto delle loro proposte. È importante ricordare che gli interlocutori potrebbero non avere la visione generale del progetto che ha l'architetto della soluzione.

Se si nutrono dubbi rispetto a una soluzione proposta o un cambiamento, è necessario evidenziarli ma, al tempo stesso, incoraggiare l'autore della proposta a riflettere e risolverli.

Esaminare il lavoro degli altri è un compito fondamentale dell'architetto della soluzione. La differenza tra esaminare ciò che qualcuno ha fatto e fare il lavoro direttamente è minima. Quando esamina il lavoro degli altri, l'architetto della soluzione deve essere costruttivo e fornire suggerimenti su dove cercare le risposte. Ad esempio, quando non è chiaro se il progetto proposto sia solido, l'architetto della soluzione può suggerire la creazione di un modello di verifica o altri test per convalidare la soluzione proposta.

In sostanza, il ruolo di un Architetto di soluzioni è quello di parlare costantemente con le persone coinvolte nel progetto per garantire il rispetto della visione del progetto. Gli architetti di soluzioni poco efficaci sono quelli che si nascondono dal team e trascorrono il tempo ad aggiornare i progetti architetturali invece di collaborare con il team e aiutarli a individuare soluzioni.

L'unità successiva descrive le tecniche che un Architetto di soluzioni può usare in un progetto.