Nella realizzazione di un progetto identifico due "obiettivi": realizzazione dell’infrastruttura e soddisfazione dei requisiti utente in termini di funzionalità. Per quanto riguarda il secondo punto il problema del cambio dei requisiti in corsa è cosa nota... Problematica largamente discussa dalle metologie agili (e non solo) che indirizzano verso modalità di lavoro quanto più flessibili per poter venire in contro alle variazioni delle esigenze di business del cliente, “Customer collaboration over contract negotiation, Responding to change over following a plan”. In fondo non soddisfare le esigenze di business del cliente porterebbe alla realizzazione di impianti inutili... <polemico>ahimè molto simile a quanto succede nelle opere pubbliche ;-)</polemico>
Quello di cui voglio parlare in questo post é la questione “infrastruttura” facendo un parallelo con il capitolato per quanto riguarda l’edilizia. Spulciando tra le varie defizioni si legge “Il capitolato è un documento progettuale tecnico amministrativo che raccoglie e sintetizza tutte le indicazioni del progetto esecutivo, rendendo manifeste tutte quelle indicazioni (tecniche, contrattuali, operative, eccetera) che non appaiono in maniera esplicita sugli altri documenti progettuali.”. Per quanto riguarda il capitolato edile si dice che in esso “Vi si indicano, ad esempio, le finiture interne di un'abitazione: finestre, pavimenti, rivestimenti.”. Quindi il capitolato in genere non parla del numero di stanze, della disposizione delle casa, del numero di finestre o dell’ampiezza del box ma il capitolato ci diei che tipo di piastrelle, che tipo di porte o che tipo di finestre ci verranno montate, questioni che in linea di massima quindi non riguardano requisiti funzionali.
Vi state chiedendo dove voglio andare a parare? Il pensiero di questi giorni cade su quei dettagli – ad esempio, per qualche riguarda il web, posizione e dimensione e/o comportamento dei controlli base - che il commitente chiede/impone di introdurre e/o variare, non defniti da contratto, e che escono da quelle che sono le funzionalità standard. Richieste che richiedono a volte tempo di realizzazione non irrelevante, incidendo non banalmente nell’economia del progetto e che fondamentalmente non sono rilevanti per quanto riguarda gli scopi funzionali del progetto stesso. Ci state chiedendo se ho idee per risolvere la questione? In realtà no... ma ho alcune considerazioni che fa piacare condividere.
-
Al momento della contrattazione del progetto dovrebbe essere illustrati e concordati sia i requisiti funzionali sia i capitolati. Come avviene per altri settori, dovrebbero essere illustrate le funzionalita del proprio capitolato di librerie ed eventualmente mostrare librerie terze parti integrabili nel progetto (esempio i controlli Infragistics etc).
-
Si parte troppo spesso a crere progetti da zero o come copia di progetti esistenti... questo perchè molto spesso mancano librerie da riutilizzare o strutture che aiutano a partire da veri semilavorati. E’ ben ovvio che in questa condizione c’è ben poco capitolato da mostrare.
-
La mancanza di librerie/strutture base indica – IMHO - una carenza di investimento in “ricerca e svilluppo”, ed in effetti sempre più società hanno smesso di investire in questo.
Si potrebbero ancora fare molte altre considerazioni in merito all’argomento. IT e sviluppo software è un settore relativamente giovane e in che deve ancora raggiungere un certa maturità. Perchè non provare a fare un parallello con settori più consolidati e più maturi, capire quali sono le similitudini nel modello di business, e come avviene per i pattern provare ad applicare soluzioni già adotattate. I settori con cui mi piace fare paragoni sono sicuramente l’edilizia, che conserva una parte artigiale, e la produzione di auto sicuramente più effeciente ma meno agile nelle personalizzazioni.
o0O ( solo vaneggiamenti? )
posted @ domenica 19 aprile 2009 20:08