Gli Architects di Salesforce progettano soluzioni end-to-end che sono resistenti, nonostante le pressioni del sistema, e che scalano insieme alle aziende che le utilizzano. Gli architect passano molto tempo a disegnare, discutere, stabilire e valutare soluzioni. Tuttavia, il ruolo di Salesforce Architect va ben oltre la semplice gestione delle soluzioni.

Le risposte all’intervista con l’architect devono considerare il quadro generale; dovrete aggiungere colore includendo considerazioni nelle vostre risposte che portano l’intervistatore nelle vostre spiegazioni. Pensa oltre le risposte dirette che avrebbero potuto essere prese da un libro di testo. Ricordate che quasi sicuramente avrete a che fare con più unità/dipartimenti aziendali in un’organizzazione di livello aziendale.

Le domande dell’intervista con l’architect di Salesforce sono pensate per:

  1. Condividere esperienze di vita reale: L’esperienza è il modo principale con cui un responsabile delle assunzioni valuta il vostro inserimento nel ruolo. Questo potrebbe includere la gestione degli stakeholder o scenari in cui avete avuto una conversazione difficile con un cliente. Ci vuole tatto per dire a un cliente che quello che sta facendo non è scalabile e che, se il suo modello di business dovesse cambiare, dovrà eliminare una parte significativa e ricostruire.
  2. Dimostrare le proprie conoscenze tecniche: In primo luogo, dovete sapere di cosa state parlando, a partire da un’ampia gamma di funzionalità della piattaforma Salesforce, ad esempio cosa comporta l’implementazione di una CPQ, come gestire al meglio grandi volumi di dati, e come risolvere i problemi per evitare risultati indesiderati. Mostrate la vostra abilità tecnica!
  3. Dimostrare le proprie qualità di leadership: Gran parte del ruolo consiste nel guidare un team, guidando tutti nella giusta direzione e assicurando che ciò che viene sviluppato/costruito sia performante e scalabile. Gravitas, compostezza e anzianità tecnica sono tutte caratteristiche da tenere ben presenti quando si risponde alle domande.

Sezione 1: Esperienza di vita reale

1. Spiegare il ruolo di un Salesforce Architect in un contesto di progetto.

Descrivete cosa fate in ogni fase del ciclo di vita del progetto: dall’identificazione delle parti interessate, alla scoperta e alla definizione delle soluzioni, fino alla costruzione, alla migrazione dei dati, alla distribuzione e all’adozione.

Inoltre, dovete riconoscere che esistono altri tipi di Salesforce Architect ed essere in grado di spiegare cosa fanno.

In breve, i Salesforce Architect sono leader di consegna e possono essere coinvolti in diverse attività (a seconda del tipo di architect):

  • Business: Come l’azienda opera intorno a Salesforce (cioè il modello operativo).
  • Data/Integration: La struttura e l’integrità dei dati che entrano e escono da Salesforce.
  • Solutions: Il modello di dati e i processi che avvengono all’interno della piattaforma Salesforce.
  • Technical: come Salesforce si inserisce nel più ampio stack IT dell’azienda.

2. Quanti progetti ha diretto? Può descrivere alcuni dei progetti più rilevanti per le responsabilità del livello architect?

Questo serve a dimostrare cosa avete ottenuto con successo e come avete misurato il successo. In questa risposta è essenziale fornire esempi, o dimostrazioni, di ciò che si è fatto.

Potete anche menzionare la vostra esperienza di gestione di progetti agile o a waterfall (parleremo di agile più avanti nella sezione “qualità di leadership”).

Anche se gli architect non vengono sempre assunti in base alla loro esperienza specifica nel settore, potreste guadagnare punti in più con l’intervistatore, se forse:

  • Il settore dell’azienda richiede un modello di dati/processi/integrazioni molto diversi da quelli di altri settori.
  • State facendo un colloquio per un ruolo in una società di consulenza più grande, dove probabilmente sarete allineati con un settore.

Anche se non avete esperienza di lavoro su progetti specifici per il settore focale, potete comunque dimostrare di essere in grado di fare leva sulla vostra risposta.

3. Secondo la sua esperienza, quali sono i componenti chiave di un progetto di successo?

Questa è l’occasione per allontanarsi dalla teoria e dimostrare come avete sostenuto un’implementazione di successo. Prendete i punti elencati di seguito, così come altri che vi vengono in mente, e supportate queste componenti con esempi tratti da progetti a cui avete lavorato:

  • L’allineamento è stato stabilito fin dall’inizio con le parti interessate. La scoperta, la raccolta dei requisiti e la pianificazione dell’ambito e dello schema del progetto sono avvenute in modo corretto e sono state approvate dalle parti interessate.
  • La collaborazione tra i membri del team è stata fluida, un aspetto particolarmente importante dato che i team di sviluppo remoti sono sempre più diffusi.
  • In qualità di architect, avete condiviso con il cliente delle raccomandazioni (non solo una gamma di opzioni).
  • I rischi del progetto sono stati ridotti e sono stati presi in considerazione i risultati indesiderati, come il debito tecnico.
  • L’adozione da parte degli utenti è stata considerata una fase fondamentale del progetto, soprattutto quando si ha a che fare con più unità operative/dipartimenti in un’organizzazione di livello aziendale.
  • Costruire una roadmap per le modifiche e i miglioramenti continui di Salesforce, in modo che il cliente possa continuare a realizzare i propri obiettivi organizzativi e a massimizzare l’investimento in Salesforce. Naturalmente, non tutto ciò che desiderano può/deve essere affrontato tutto in una volta, ed è per questo che la roadmap è così importante per prendere in considerazione le fasi del progetto in corso.

4. Qual è la soluzione/costruzione più innovativa che avete realizzato?

Una volta imparato a riconoscere una domanda STAR, è facile rispondere. Descrivete la situazione (per creare la scena), lo scopo del compito, le azioni intraprese e i risultati.

5. Qual è stato il progetto di sviluppo software più difficile a cui ha partecipato?

Analogamente alla domanda precedente, utilizzare STAR per descrivere Situation-Task-Actions-Results.

Questa è un’opportunità per mostrare le vostre abilità e competenze nella risoluzione dei problemi. Non utilizzate un esempio di progetto andato male, a meno che non sia stato risolto da voi!

6. Ha partecipato alla prevendita?

Non è essenziale per tutti gli architect: dipende dall’organizzazione per cui si spera di lavorare. Gli architect saranno coinvolti nei processi di vendita, come le conversazioni per scoprire le dipendenze, la definizione del progetto e la stima dei tempi e degli sforzi.

7. Per raccogliere i requisiti di un cliente, quali domande bisogna porre?

Si può parlare di un metodo chiaro per scoprire le esigenze dei clienti. Un esempio è il metodo 5WH:

  • Perché: identificare i vantaggi che il cliente (le parti interessate) spera di ottenere dal progetto.
  • Chi: sapere chi interagisce con Salesforce e chi ne beneficerà.
  • Cosa: identificare i requisiti tecnici e di business. Questi definiscono il modo in cui Salesforce deve funzionare per gli utenti.
  • Dove: Capire se ci sono considerazioni sulla localizzazione che possono avere un impatto sull’utilizzo di Salesforce e di altre piattaforme in contesti geografici diversi. Potrebbero esserci normative sui dati, dispositivi e considerazioni sull’integrazione unici.
  • Quando: Definire le scadenze del progetto: qual è il fattore più importante?
  • Come: Comprendere lo stato di fatto, ovvero come funzionano attualmente i processi (il che indicherà la loro disponibilità al cambiamento).

8. Quando presentate una soluzione proposta alla direzione, cosa presentereste per ottenere il loro consenso?

Prima di passare al corpo principale della presentazione, dovrete riformulare il “cosa” e il “perché” del progetto. Il management, e in particolare i dirigenti, sono persone impegnate e spesso dimenticano i dettagli del progetto.

Ridurre la conversazione ai fatti e presentare qualcosa di visivo sono entrambi approcci validi. I diagrammi dell’architettura di riferimento di Salesforce mostrano i modelli di dati/integrazioni/utilizzo consigliati dei prodotti della piattaforma Salesforce, comunicando facilmente l’approccio migliore alla progettazione di Salesforce.

Inoltre, è bene sapere a quali dirigenti/manager ci si rivolge. Naturalmente, persone diverse usano una certa terminologia e hanno motivazioni e interessi diversi da proteggere. Il direttore finanziario (CFO) non sarà interessato al modo in cui il team di marketing può ottenere i lead, ad esempio.

9. Come valutate, registrate e presentate il rischio in un progetto?

Questa domanda potrebbe essere interpretata in modi diversi. Cominciate a chiarire quale delle due interpretazioni si aspettano che rispondiate (o entrambe!).

a) Se si riferiscono ai rischi del progetto, dovrete parlare dei seguenti aspetti e fornire le relative mitigazioni:

  • Tempistica: Aspettatevi l’inaspettato. Ricordate che ci saranno delle incognite note che possono influenzare il calendario del progetto. Per attenuarle, coinvolgete l’intero team (+ il team del cliente) nelle fasi di pianificazione e definizione del progetto, in modo da ottenere un feedback precoce e costante che potrete affrontare nelle discussioni con le parti interessate.
  • Scope creep: Compaiono requisiti che non fanno parte dell’ambito del progetto concordato, diventando una lista della spesa infinita. Per attenuare il problema, discutete come mantenere la concentrazione mantenendo gli stakeholder, gli utenti e il team di sviluppo vicini al progetto, ad esempio con regolari stand-up o ricontrollando i requisiti con gli stakeholder.
  • Turnover dei dipendenti: Quando le persone lasciano l’organizzazione, spesso se ne va anche il contesto prezioso del progetto e delle operazioni aziendali. Per mitigare il problema, è necessario concentrarsi sulla generazione di documentazione frequente nel corso del progetto: spesso, una piccola documentazione è meglio che aspettare l’ultimo “hurrah” e potenzialmente perdere un individuo esperto prima di arrivare a quel punto. La documentazione non è il lavoro preferito di nessuno; gli strumenti di collaborazione, come Slack, possono aiutarvi a raccogliere frammenti chiave per la documentazione.

b) Se si riferiscono alla gestione dei rischi all’interno della piattaforma Salesforce, potete parlare degli standard di conformità, ad esempio di come definire e implementare i controlli per l’accesso, l’integrazione, la sicurezza e la privacy, gestendo al contempo il rischio operativo. Potreste citare le funzioni di sicurezza avanzate, come Salesforce Shield per crittografare i dati sensibili, automatizzare i criteri di sicurezza, monitorare l’utilizzo di app e dati da parte degli utenti ed eseguire controlli di conformità.

10. Vi è mai capitato di lavorare con clienti resistenti al cambiamento, forse protettivi nei confronti di una soluzione che hanno costruito? Come avete superato questa resistenza iniziale?

Dovete usare le vostre abilità “umane” per essere disponibili e avvicinabili. Aprite la conversazione con curiosità, ponendo domande non minacciose per scoprire perché la soluzione è stata costruita nel modo in cui è stata costruita. Non criticate mai, ma ascoltate. In seguito a queste conversazioni (e una volta costruita la fiducia), fissate un incontro separato per spiegare gradualmente il vostro approccio alternativo, ovviamente dopo essere stati pienamente informati del contesto e degli obiettivi aziendali.

11. Come gestireste un requisito aggiuntivo che viene sollevato verso la fine del ciclo di vita del progetto?

Anche se potreste essere tentati di respingere la richiesta a questo punto del progetto, dire di no non è necessariamente compito dell’architect. Innanzitutto, è meglio informare i membri del progetto interessati, in particolare il project manager, della richiesta in arrivo, prima ancora di valutarla. La richiesta è prioritaria? La mancata esecuzione della richiesta limiterà in modo significativo la produttività degli utenti? Ci sono limitazioni al completamento della richiesta? La richiesta è accompagnata da dipendenze che potrebbero comportare ulteriori requisiti?

Dopo la vostra valutazione, incontrate lo sponsor del progetto (executive sponsor) e il team di sviluppo per valutare l’impatto.

La conclusione potrebbe essere una delle seguenti. Il requisito non è tecnicamente realizzabile né ora né mai. Potreste suggerire di rimandare il problema a un progetto futuro. Lo stakeholder esecutivo potrebbe essersi opposto, soprattutto se soddisfare la richiesta avrebbe fatto lievitare i tempi (e/o il budget). Il requisito potrebbe non essere stato necessario fin dall’inizio.

12. Come misurereste l’adozione di Salesforce una volta che sarà operativo? Dal punto di vista di un architect, cosa suggerirebbe?

Aiutare i clienti ad adottare determinate funzioni o parti del sistema dimostra che potete essere un coach, un mentore.

Gran parte dell’incoraggiamento all’adozione può essere teorico, ad esempio suggerendo al cliente di installare gli Adoption Dashboard dall’AppExchange nella sua organizzazione. In qualità di architetto, dovrete pensare al quadro generale nella vostra risposta a questa domanda, aggiungendo ulteriori dettagli alla vostra risposta con considerazioni chiave, soprattutto quando si tratta di più unità aziendali/dipartimenti in un’organizzazione di livello enterprise.

13. Indicate tre cose a cui consigliereste ai clienti di prepararsi (nel contesto della loro organizzazione Salesforce) che potrebbero avere un impatto futuro.

Mostrare la propria consapevolezza di:

  1. La roadmap di Salesforce (e dove è possibile accedervi).
  2. Funzionalità e miglioramenti (incluso il ritiro delle funzionalità) nella release più recente/successiva.
  3. Tempi di inattività del sistema, sia previsti che imprevisti.

La cosa più importante è sottolineare che il cliente ha bisogno di indicazioni da parte vostra per sapere cosa cercare di rilevante per la sua organizzazione specifica. I comunicati di Salesforce contengono una quantità di informazioni che, in mancanza di queste indicazioni, risulterà schiacciante per il cliente. Potete anche consigliare loro di tenersi aggiornati con i siti di notizie su Salesforce.

Sezione 2: Conoscenze tecniche

Dovete sapere di cosa state parlando, a partire da un’ampia gamma di funzionalità della piattaforma Salesforce. Mentre le domande delle altre sezioni non sono semplici da rispondere (poiché l’esperienza di ciascuno determinerà la risposta), queste domande tecniche di esempio consentiranno all’intervistatore di esprimere un giudizio più chiaro sulla vostra abilità tecnica.

Considerando la popolarità delle certificazioni nell’ecosistema Salesforce, gli intervistatori potrebbero porre domande che compaiono negli esami. Gli esami di certificazione forniscono una base per testare le conoscenze, ma non dovreste esitare a sviluppare ulteriormente queste risposte con le vostre esperienze pratiche.

14. Potreste disegnare [inserire una soluzione] alla lavagna?

Un colloquio è un doppio test per vedere dove le vostre conoscenze tecniche si incontrano con le capacità di comunicazione. Potreste essere l’architetto più esperto di soluzioni, ma dovete comunicare in modo chiaro. Quindi, ripassate la tecnica della lavagna (sia quella fisica che quella virtuale).

  • Di persona, evitate di dare le spalle al pubblico e mantenete il più possibile il contatto visivo.
  • Spiegate cosa state disegnando, man mano che procedete.
  • Gli elementi devono essere sufficientemente grandi da poter essere visti e devono essere scritti in modo chiaro e leggibile.

15. Come affrontereste la personalizzazione di un prodotto/funzionalità Salesforce già pronto per soddisfare meglio le esigenze dell’azienda?

Questo potrebbe riferirsi a un prodotto/funzionalità specifico (se l’intervistatore sa cosa sta cercando) o al vostro processo di pensiero, in generale. Come valutereste l’attuale implementazione dell’organizzazione e se/come le funzionalità out-of-the-box potrebbero essere sfruttate o sostituite?

Un’altra opportunità di usare STAR per descrivere la situazione, i compiti, le azioni e i risultati. Scegliete una funzionalità OOTB (sperando che abbiate un esempio reale), delineate le sfide aziendali (situazione), spiegate brevemente come è stata realizzata tecnicamente (attività/azioni) e quali sfide sono state risolte.

Un esempio calzante è la conversione dei lead. La conversione dei lead è un processo manuale, ma esistono opzioni programmatiche (Apex) per automatizzare il processo. Un architetto dovrebbe sapere che, a seconda del caso d’uso, sfruttare uno strumento di terze parti potrebbe essere l’opzione migliore (più appropriata e scalabile).

16. Come giudicate se un cliente ha superato le capacità standard di Salesforce e deve quindi utilizzare uno strumento alternativo per soddisfare le sue esigenze?

Questa domanda è simile a quella precedente, ma fa un passo indietro. In questo caso, è necessario prendere in considerazione sia lo sforzo di personalizzazione iniziale, sia la manutenzione continua e qualsiasi potenziale impatto a valle.

Un esempio interessante è quello delle previsioni molto avanzate. Fino a che punto si può spingere il forecasting di Salesforce e come reggerebbero le personalizzazioni se altri moduli/piattaforme integrate in Salesforce dovessero cambiare?

17. [Domanda di nicchia] Speriamo di introdurre un Data Warehouse per integrare la nostra organizzazione Salesforce. Se, ad esempio, volessimo archiviare le fatture nel Data Warehouse, dovremmo consumare i dati da diversi oggetti Salesforce (Ordini, Prodotti, Quantità, Prezzi, ecc.) per generare una fattura. Ci sono considerazioni o dubbi su questo approccio?

Incontrate il team di progetto per discutere i pro e i contro di ciascun sistema come master per diversi tipi di informazioni.

18. [Domanda di nicchia] Vorremmo utilizzare B2B Commerce, CPQ e Partner Communities. Qual è la “best practice” per collegare B2B Commerce a CPQ (secondo Salesforce)?

Il ruolo di architetto richiede una conoscenza abbastanza ampia della piattaforma Salesforce. La risposta (ufficiale) è che installereste il CPQ B2B Commerce Cloud Connector, anche se potreste essere consapevoli del fatto che il connettore ha delle limitazioni che lo rendono impraticabile per alcune organizzazioni (supporto limitato per modelli di prezzo e pacchetti complessi, che potrebbero richiedere uno sviluppo personalizzato in aggiunta al connettore). Poiché si tratta di prodotti Salesforce, si può ipotizzare che sia disponibile un connettore.

Anche se non è possibile conoscere la risposta esatta a questa domanda in questo momento, è possibile descrivere il processo di a) ricerca dei connettori disponibili che non richiedono alcun lavoro di integrazione, b) valutazione degli strumenti di integrazione di Salesforce, come MuleSoft, e c) creazione di un’integrazione personalizzata utilizzando le API di Salesforce.

Questa domanda dimostra quanto sia importante comprendere l’attuale stack tecnologico Salesforce dell’organizzazione, nonché i suoi piani a breve e lungo termine. Anche se manca più di un anno all’avvio di un progetto, il responsabile delle assunzioni potrebbe essere interessato a sapere come gestireste un progetto che ha un grande valore commerciale.

19. [Domanda di nicchia] Vi è mai capitato di dover classificare e proteggere i dati dei campi di Salesforce a causa di (regolamenti o mandati, come ad esempio) il GDPR? Cosa consigliereste ai membri del team di amministrazione? Ci sarebbero implicazioni?

In primo luogo, gli amministratori di Salesforce possono facilmente contrassegnare i campi standard e personalizzati come “riservati” utilizzando i campi di metadati “Classificazione dei dati” (nella configurazione del campo).

Potreste quindi approfondire i requisiti di sicurezza dell’organizzazione. Questo è particolarmente importante se si tratta di un settore altamente regolamentato, come quello dei servizi finanziari o sanitari. Dovrebbero invece criptare i dati? Questo potrebbe essere il momento e il luogo per proporre la crittografia della piattaforma, utilizzando Salesforce Shield.

20. [Domanda di nicchia] Avete mai lavorato con i Big Objects? Quali sono le considerazioni chiave da fare durante la soluzione?

Sono sufficienti un paio di punti. I campi personalizzati possono essere aggiunti ai grandi oggetti; tuttavia, non tutti i tipi di campo sono supportati. Possono esserci al massimo 100 oggetti grandi per ogni organizzazione.

21. Siete stati incaricati di importare due milioni di record. In che modo potreste garantire le prestazioni e il successo dell’operazione?

Il caricamento dei dati è fondamentale e può rappresentare fino al 25% di una tipica implementazione di Salesforce. È anche facilmente responsabile di spese aggiuntive.

Chiedete se una soluzione è scalabile e cosa succede quando cercate di inserire centomila record. Si romperà, si raggiungeranno dei limiti? Ci sono problemi con la parte tecnica?

Ad esempio, il caricamento dei record delle opportunità, in tutte le fasi e categorie di previsione, nell’istanza di produzione di Salesforce. In questo caso, è necessario confermare che al team di vendita siano stati assegnati i ruoli corretti e assicurarsi che “Concessione dell’accesso tramite gerarchie” (“Grant Access Using Hierarchies”) sia abilitato.

22. Come si potrebbe risolvere il problema per evitare di creare debito tecnico?

Il debito tecnico è inevitabile, ma ci sono misure che si possono adottare per ridurlo quando si progettano soluzioni e si pianificano progetti.

  1. Coinvolgetevi per tempo. Non volete ritrovarvi in una situazione in cui la soluzione è già stata costruita e viene resa operativa la settimana successiva.
  2. Dedicate del tempo a voi/ad un altro membro del team per valutare la maturità dell’organizzazione.
  3. Non reinventare la ruota. Perché costruire qualcosa di personalizzato quando esiste una funzione già pronta che consente di ottenere il risultato desiderato?
  4. La soluzione resisterà alla prova del tempo o dovrà essere modificata in modo significativo nel prossimo futuro?

Se il tempo non è dalla vostra parte (cioè non siete stati coinvolti abbastanza presto nel processo), fate domande per scoprire perché la soluzione è stata costruita come è stata costruita. In questo modo, in futuro, potrete disporre di un piano d’azione. Ad esempio, dovremmo rimuovere questi quattro oggetti, creare un nuovo oggetto al loro posto che richieda questi campi e l’automazione si adatterà in questo modo e il trigger Apex dovrà essere rimosso.

Sezione 3: Qualità di leadership

23. Come deve lavorare un architect con i team del cliente e con quelli interni?

L’approccio “one team” è il migliore. Descrivete come comunicate con i clienti: con quale frequenza, quali canali e perché. Descrivete la stessa cosa con il vostro team interno. Spiegate come questi ritmi di comunicazione uniscano tutti da entrambe le parti. Utilizzate esempi di progetti in cui siete stati coinvolti.

24. Come bilanciate le priorità quando lavorate con più clienti, stakeholder o progetti?

In qualità di architect, è necessario adattarsi rapidamente, sia che si tratti di lavorare all’interno del team principale, sia che si tratti di lavorare in più team o di inserirsi nei team lato cliente.

Potete menzionare il numero di clienti con cui lavorate contemporaneamente; non è raro che un architect si occupi di tre clienti alla volta. Riconoscete che ogni organizzazione cliente avrà uno stack tecnologico diverso oltre ai prodotti “cloud” di Salesforce.

L’intervistatore vorrà essere rassicurato sul fatto che avete la capacità di gestire le aspettative, non di essere a disposizione, ma di comunicare la vostra disponibilità in modo cortese.

25. Qual è il vostro approccio preferito alla gestione dei progetti?

Come abbiamo detto in precedenza, parlare di come avete lavorato in modo agile o waterfall darà colore alla vostra esperienza e a come potete gestire un progetto, giorno per giorno.

L’Agile, in particolare, è un argomento interessante. Tenere scrum giornalieri – per discutere di ciò che si è fatto ieri, di ciò che si sta facendo oggi e di ciò che blocca il lavoro – mette naturalmente in mostra la capacità di guidare un team di sviluppo nella giusta direzione (in modo “high-touch” e comunicativo). Lo stesso si può dire per le cerimonie, in cui si pianificano gli sprint, il backlog refinement, in cui si esamina il backlog e si stima la durata delle attività.

Le retrospettive (riunioni per chiedere “cosa possiamo migliorare?”, “cosa possiamo imparare?”) possono rivelare tratti positivi. Dopo tutto, ci vuole una persona matura per ammettere che c’è qualcosa che avrebbe potuto fare meglio, o ammettere che non ha adottato l’approccio giusto. A nessuno piace ammettere di aver sbagliato, ma “cadere in avanti” (cioè inquadrare il problema come un’esperienza di apprendimento positiva) è fondamentale per gestire un team trasparente e di successo.

Questo riflette anche la questione della “richiesta di modifica del cliente” di cui sopra. Adattarsi alla situazione è altamente “agile”.

26. Quali sarebbero le sue priorità all’inizio dell’attività in azienda, ad esempio nel primo mese?

In questa fase, potreste non avere tutti i dettagli tecnologici per spiegare in modo approfondito i vostri piani. Tuttavia, potete sottolineare l’importanza di inserirvi nel team e di capire come gli utenti di Salesforce nei team dell’organizzazione operano con Salesforce.

È essenziale familiarizzare con gli obiettivi dell’azienda. Il vostro primo mese non sarà quello di imporre ciò che deve essere cambiato; proprio come fareste in un contesto di clienti, ascoltate e assorbite, invece di entrare nel vivo sottolineando ciò che è “sbagliato”.

27. Quali sono le caratteristiche positive che ha riscontrato in analisti aziendali, project manager e/o amministratori?

Abbiamo incluso questa domanda perché dimostra il riconoscimento del valore che ogni membro del team apporta al tavolo, incoraggiando al contempo questi individui a lavorare sui loro punti di forza durante i progetti.

  • Business Analyst: Tra i ruoli elencati, la maggiore sovrapposizione tende a riguardare l’architect e il business analyst (BA). I BA forniscono assistenza comprendendo le sfide e mettendosi nei panni del cliente. Ad esempio, perché i loro agenti di assistenza sono così agitati o cosa rende il loro processo di vendita così inefficiente? La capacità di analizzare e mappare i processi “as-is” e “to-be” è il segno di un BA competente.
  • Project Manager: Organizzati, orientati alle scadenze e al budget, i project manager sono molto comunicativi e tengono il polso del progetto. Sono un’altra serie di occhi e orecchie per identificare e segnalare i rischi del progetto.
  • Salesforce Admin: Fornendo le basi della conoscenza, gli amministratori possono fornire chiarezza su come Salesforce dovrebbe essere configurato con una visione più “ingrandita” dell’organizzazione. Senza un amministratore esperto, si rischia di reinventare la ruota, costruendo qualcosa di personalizzato quando sono disponibili funzioni già pronte.

28. Quale consiglio darebbe a un amministratore/consulente Salesforce che vuole intraprendere la carriera di architect?

Questa sarebbe un’ottima domanda per dimostrare ancora una volta le sue qualità di coach e mentore.

Innanzitutto, si tratta di una scelta fantastica! Diventare architect permette di progredire nella carriera in un ambito tecnico (rispetto a un percorso manageriale).

Lavorare come architetto è molto diverso dall’essere un amministratore/consulente, come saprete già dalla vostra esperienza.

Siate realistici sul lavoro che comporta il passaggio al settore degli architect e sottolineate l’importanza di coltivare le soft skills. Non si tratta di un cambio di carriera che avviene da un giorno all’altro.

Sebbene si debbano stabilire delle aspettative, non bisogna scoraggiare completamente la persona. Potete evidenziare le competenze e le qualità trasferibili e persino individuare un paio di responsabilità “simili a quelle di un architect” che potrebbe già svolgere, senza esserne pienamente consapevole.

29. Come formerebbe/abiliterebbe gli altri membri del team?

Gli architect sono spinti dalla loro passione per Salesforce a condividere le loro conoscenze e ad aiutare gli altri a crescere. Ad esempio, condividono i compiti e permettono agli altri di seguire il proprio lavoro, ecc.

I datori di lavoro sono interessati ad avere architect che possano potenzialmente aiutare gli altri membri del team a sviluppare le proprie competenze, soprattutto se nel team mancano professionisti esperti.

30. Dove vede la sua carriera?

I responsabili delle assunzioni sono interessati a sapere dove avete intenzione di andare. È un segno che siete ambiziosi e che continuerete a impegnarvi.

La risposta non deve essere necessariamente CTA: non tutti vogliono raggiungere quel livello. Qualunque sia il tipo di architect, c’è sempre spazio per acquisire ulteriore esperienza, specializzazione e nuove tecnologie da padroneggiare.

Dentro la mente di un intervistatore

A differenza di altri ruoli in Salesforce, il colloquio con gli architect non è così semplice; ci saranno molte meno domande e risposte “da manuale”, che richiederanno di fornire considerazioni significative all’interno delle risposte e di portare l’intervistatore con sé nelle spiegazioni.

Per continuare la ricerca, si possono esaminare i consigli che i responsabili delle assunzioni ricevono. How to Hire Salesforce Architects “On Demand” fornisce una buona introduzione a come penserà l’intervistatore.

Gli attributi “must-have” e “nice-to-have” includono competenze tecniche – cloud di competenza (CPQ o Service Cloud, ad esempio), settori industriali, ecc. – e le soft skills professionali. Hanno una forte padronanza dello sviluppo di Salesforce? Hanno gestito una migrazione di dati? Hanno bisogno di un’esperienza di contatto con i clienti? Dovranno interagire con specifici stakeholder interni? Questi dettagli creano uno schema per guidare gli architetti con le giuste competenze tecniche, soft e di base”.

 

 

Fonte: tradotto da Salesforceben

Share:

administrator

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *