Me lo sono chiesta molte volte e l’esperienza mi fa dire che sarebbe meglio di si…soprattutto quando si opera in aziende che sviluppano software.
Mi spiego meglio…io per prima non saprei fare nulla di ciò che gli sviluppatori con cui collaboro fanno oggi! Ma quando, per spiegarmi qualcosa, aprono il loro IDE e mi mostrano del codice, o accedono a tabelle di Database, il mio atteggiamento non è di smarrimento o rifiuto, ma riesco a seguirli. Abbiamo un linguaggio in comune che mi permette di capire se ci sono dei limiti tecnici nei miei ragionamenti e intuire se i ragionamenti dei tecnici hanno colto tutti gli aspetti funzionali che ho esposto. Per questo devo ringraziare i miei anni da programmatrice.
Sono poi anche altri i motivi e situazioni per cui credo che un BA debba avere un livello minimo di competenze di programmazione. Li provo a descrivere qui di seguito…
- Autonomia nell’analizzare basi di dati accedendo direttamente ai Database con query SQL (in sola lettura ovviamente!!)
- Automatizzazione e prototipazione di alcuni ragionamenti funzionali (script in Excel, Gsheet e simili)
- Autonomia nello sviluppo di tool utili ai propri scopi (es. estrazione dei worklog di Jira e creazione di report di avanzamento progetto per la direzione)
- Capacità di personalizzare software di simulazione di scenari di business (es. utilizzavo un software di BPM — Business Process Modeling — e per poter simulare un processo ho dovuto descriverlo in VB .NET)
- Creazione di tool di generazione randomica di dati (in Excel) per simulazione di use case di test complessi
- Utilizzo di software come Postman o simili per simulare le interazioni con il backend
- Scrittura di casi di test per l’automazione degli User Acceptance Test
- Screen scraping per portarsi in casa il catalogo di un competitor
Questi sono solo alcuni esempi, ma ce ne sono stati tanti altri nel mio percorso professionale. Ovviamente, avrei potuto chiedere supporto ai colleghi sviluppatori per ognuno di questi task, e il risultato sarebbe stato sicuramente migliore del mio ma…
- Le risorse di sviluppo sono sempre scarse e non hanno tempo
- Se affidi sviluppi o personalizzazioni di questo tipo, ovvero secondari per il business dell’azienda, magari qualcuno ti aiuta a sviluppare la prima versione, ma per la manutenzione dovrai supplicare o corrompere i colleghi perché non riterranno mai prioritarie le tue richieste
- Questi sviluppi nascono da idee poco definite e un po’ prototipali, per cui ci vogliono un po’ di prove per mettere a fuoco il requisito. È difficile avere fin da subito le idee chiare per delegare lo sviluppo ad altri.
E poi, fondamentale per me, l’essere autonoma nello sviluppo delle mie idee ha sempre pesato molto di più dello sforzo di svilupparmele da sola.
Per chi invece non ha mai voluto avventurarsi nel magico mondo della programmazione, alcuni brevi consigli per acquisire a poco a poco delle competenze tecniche:
- Quando i colleghi tecnici parlano di tool o tecnologie, prendi nota delle sigle e cerca di capire di cosa si tratta
- Guarda tutorial introduttivi delle varie tecnologie utilizzate in azienda
- Chiedi di avere una panoramica architetturale della soluzione software su cui stai lavorando
- Chiedi uno schema che rappresenti il modello dei dati delle applicazioni su cui stai lavorando e cerca di comprenderlo a fondo
- Quando i colleghi tecnici parlano, tieni la mente aperta e non disconnetterti. Su 100 parole ne capirai 2, ma a poco a poco diventeranno 4, 6, 10 o 20…
- Individua il collega che “sa spiegare bene” e a cui piace spiegare le cose nel dettaglio. Fattelo amico (corrompilo con dolciumi o caffè) e vedrai che andrà sempre meglio.
- Cerca di capire dove “puoi mettere le mani” anche tu, e ritagliati del tempo per fare delle prove. Non aver paura di sperimentare!
Luisa Losito – Product Lead