Mentre studiavo algebra imparai un teorema con una dimostrazione lunga 2 facciate, negli esercizi tra le note curiose scoprii che un secolo prima lo stesso teorema per essere dimostrato aveva richiesto 10 e più libri.
Ora come allora la conoscenza che quel teorema portava era la medesima, ma allora trasmettere, comunicare o elaborare quella conoscenza richiedeva una quantità d'informazione estremamente più grande che oggi (10 libri contro 2 facciate).
Quando lo sviluppatore realizza una soluzione informatica ad un problema passa attraverso diverse fasi, dal problema alla sua soluzione sino alla implementazione del software in momenti successivi di analisi e sintesi sino al rilascio definitivo della versione ufficiale del software. Dal momento iniziale al rilascio la quantità d'informazione che lo sviluppatore considera, elabora e comunica varia sino a raggiungere la sintesi estrema con il rilascio definitivo del software che raccoglie e sintetizza tutta la conoscenza maturata del problema.
Vi è mai capitato di dover dare supporto o fare manutenzione ad un programma che risolve un problema al 90% e il 10% che manca contina a creare problemi ricorrenti e cronici senza trovare una definitiva soluzione? In questi casi la conoscenza che il programma (nel codice e nel suo funzionamento) contiene e la quantità d'informazione che la rappresenta sono incompleti e per dare il supporto richiesto o modificare il programma è necessario fare il grosso sforzo di recuperare l'intera quantità d'informazione elaborata (dalla analisi del problema sino al rilascio) nella sua forma più ingombrante, complessa e costosa in termini di tempo, sforzo e competenze richieste. In questi casi il software ha mancato l'obiettivo di fornire conoscienza immediatamente utilizzabile con la minima quantità d'informazione richiesta.
Queste le considerazioni finali che mi annoto:
- nella realizzazione del software è importante non confondere l'approccio graduale ad un problema (spesso utile) con la risoluzione parziale e incompleta di un problema (spesso dannoso).
- una soluzione informatica ad un problema va considerata quando risolve il problema nella sua interezza, altrimenti rischia di creare costi cronici superiori ai benefici sperati.
- applicando processi di sviluppo incermentali l'improvvisazione è pericolosa invece è preferibile dotarsi di quanto serve per garantire la convergenza verso una soluzione stabile e il raggiungimento della soluzione in un numero finito di passi.
- quando il rilascio ufficile del software rischia di risolvere solo il 90% del problema, ad un software incompleto è preferibile un software che riduce lo scope risolvendo un problema minore ma nella sua interezza.
- la qualità del codice prodotto non è un parametro negoziabile, la massima qualità è indispenzabile per ridurre costi dovuti a maggiore quantità di informazione (del problema, della soluzione e della implementazione) che dovrà essere gestita ripetutamente durante l'intero arco di vita del software.
|
In conclusione: una soluzione informatica va valutata nel contesto del processo aziendale in cui si inserisce, il rapporto tra i costi di implementazione e i benefici che porta all'azienda va valutato tenendo conto dell'intero ciclo di vita del software costituito al 70% dalla assistenza, manutenzione ed evoluzione.
Deroghe sulla qualità del disegno, del codice e sulla completezza della soluzione sono costi nascosti durante l'implementazione che incidono durante questo 70%.
|
Aggiornamento del 19-Giu-2006:
Un link in tema: How to Align IT With Business Goals
Tags :
Team Work |
Agile |
Comunicazione |