La pratica dell’analisi

Nel mio metodo per l’analisi del software, vi ho parlato del lato più romantico dell’analisi: non mancano però i lati pratici e tecnici che renderanno la vostra analisi precisa, fino a consentire una progettazione pragmatica del software e a portare chiarezza in ogni fase analitica e progettuale. La pratica dell’analisi è mutata parecchio con gli anni, dal metodo a cascata fino all’agile development.

Io sono contrario alla navigazione a vista e preferisco che l’analisi sia un testo sempre presente in tutto il ciclo di sviluppo del software, un documento compiuto ma allo stesso tempo non dogmatico che consenta di tenere il timone dritto fino alla consegna di ogni fase.

LEGGI TUTTO …

Il mio metodo per l’analisi del software.

Un giorno, facendo quattro chiacchiere con un amico, “Analista Programmatore” della vecchia guardia,  è scoppiato nella mia testa una specie di A/B testing oltretutto nato dalla coincidenza di aver avuto alcuni clienti in comune per delle consulenze.

Le analisi software del mio amico sono tecnicamente perfette: un team di sviluppo può prenderle in mano e iniziare a lavorare in tempo zero. Ma spesso i suoi progetti non arrivano a questo step e finiscono nel dimenticatoio aziendale.

Maggiori informazioni

Enumerare i requisiti complementari

I requisiti complementari sono tutti i requisiti che non hanno diretta correlazione con I goal

Questo genere di requisiti spesso si dovranno poi demandare del tutto o parzialmente a consulenti esterni: non dobbiamo fare tutto noi e se non siamo competenti è il momento di consigliare al cliente di informarsi su quegli aspetti che non riguardano direttamente il software in analisi.

Per la GDPR per esempio meglio consultare un esperto, per la SEO un altro etc. Non cercate di proporvi come unica soluzione ai problemi dell’universo: Restate umili.

LEGGI TUTTO…

Elencare i requisiti funzionali

Una delle parti più laboriose e corpose dell’analisi del software è questa: elencare singolarmente tutti i requisiti funzionali, scorporandoli al minimo possibile. L’atomizzazione servirà poi a fare diverse stime.

Durante le interviste al cliente ed ai suoi collaboratori avrete di certo preso dozzine di appunti e vi sarete fatti una mappa mentale dei requisiti funzionali. Fidatevi di voi stessi ma controllate sempre quello che avete prodotto: a volte l’esperienza può farvi dei brutti scherzi.

Una volta provando la presentazione da fare al cliente mi resi conto che una delle funzioni assolutamente necessarie del software peccava nell’analisi: notte insonne per rimediare.

LEGGI TUTTO…

Requisiti del sistema

Una delle fasi più noiose del ciclo di vita di software è definire i requisiti del sistema: Eppure questa parte spesso è quella che può decretare il successo o la rovina di un progetto, cercate di farla meglio che potete.

Paradossalmente potreste sbagliare vari punti della vostra analisi e ottenere comunque un ottimo risultato, invece se i requisiti non sono quelli giusti lascerete a chi vi segue una pesante eredità.

LEGGI TUTTO…

Stabilire i processi necessari

Siamo arrivati alla seconda fase della nostra analisi: dobbiamo stabilire che cosa serve per ogni Goal dal punto di vista “informatico”: Librerie, linguaggi, demoni vari etc. 

Il primo lavoro è quello di ricerca: qual è l’ambiente migliore che vuoi creare per il progetto software? Rischierai l’innovazione, usando il linguaggio e le librerie dell’ultimo grido o opterai per un sistema stabile e ultra-utilizzato? 

La risposta è sempre la solita: dipende.

LEGGI TUTTO…

I goal.

Nella prima fase dell’analisi noi stessi potremmo non avere le idee pienamente chiare: occorre schematizzare le necessità del software che si deve realizzare. A questo punto la “magia dell’analisi” si dirama nei metodi e varietà di strumenti più originale: mind maps, lavagne, post-it attaccati ad un muro, Trello, documenti elettronici di qualsivoglia natura. 

LEGGI TUTTO…

Resta umile

Uno dei primi effetti sulla psiche del lavoro di consulente è il sopravvalutarsi.

Avete accumulato tanta esperienza al punto che il vostro know-how è diventato di grande valore: questo vi porterà a considerarvi in breve un Dio in terra della vostra specifica nicchia di conoscenza.

Non è così: tornate con i piedi per terra e restate umili: La vostra conoscenza non può che essere limitata: perfino nella vostra zona di comfort.

LEGGI TUTTO…

Fai dei follow-up sui progetti nei vari stage

La consulenza è finita, ma anche se non fate parte della realizzazione del progetto finale, occorre sempre ricontattare il cliente; sapere come procedono le cose e quali sono le criticità.

Non è raro scoprire che il progetto è bloccato e sia necessaria una ulteriore consulenza per risolvere: Non pensate che sia il cliente a richiamarvi in quel caso, probabilmente ha mille pensieri negativi e dà il progetto per spacciato. Quando una persona ottiene i finanziamenti o ci mette i suoi per un progetto, è più fragile che in altre fasi. Organizzare il team o implementare una soluzione esistente potrebbe sembrargli un ostacolo insormontabile.

LEGGI TUTTO…

Spenditi in prima persona

Avete raggiunto l’obbiettivo di completare l’analisi, il cliente è contento: ha ricevuto i materiali, la fattura è stata pagata; tutto viaggia per il meglio.

Il vostro lavoro sembra finito ma non è così: rendetevi disponibili a presentare voi, di persona o in videoconferenza, il progetto software al cliente ed ai suoi soci, o alla sua direzione: chi meglio di voi può illustrarlo e sanare i dubbi e le perplessità rimaste?

LEGGI TUTTO…

Fatti pagare

Uno dei problemi di qualsiasi freelance è quello di ottenere il pane in cambio delle rose che si danno al cliente.

Personalmente mi comporto seguendo alcuni punti fondamentali:

Essere chiari: In fase di contrattazione iniziale occorre sempre spiegare per bene al cliente che:

LEGGI TUTTO…