Tempo di lettura: 5 minuti
Nello sviluppo del software, la premessa di buono, veloce ed economico è difficile da raggiungere. Possiamo ottenerli tutti e tre? È possibile raggiungere un equilibrio? Ve ne parleremo qui.
Molti di noi che lavoriamo nell’industria del software, quando iniziamo a lavorare su preventivi, consulenze o stime di progetti, abbiamo affrontato un must quasi inevitabile dal mercato: sviluppare software buono, veloce ed economico. È possibile avere queste tre variabili allo stesso tempo? È un’idea utopica?
Per rispondere a questa domanda e vedere la fattibilità di questo postulato, è importante che prima rivediamo due idee chiave.
Che prezzo si dà a un’entità intangibile?
Il software è un prodotto intangibile; non possiamo vederlo, né conoscerne la bontà finché non è finito. Dare un prezzo allo sviluppo di un software è qualcosa di complesso (a meno che non si compri un software confezionato invece dello sviluppo personalizzato), non solo per la soggettività che esiste del suo valore (basato su molti criteri), ma anche per le differenze esistenti sul fatto che il progetto sia più facile o più complesso da realizzare.
Stime, un pilastro per il successo
Data la congiuntura dell’intangibile, fare una stima corretta -e il più accurata possibile, dato che è un’approssimazione-, è molto importante per evitare sforamenti di budget e perdite di tempo.
Contenuto relativo: 10 consigli utili per la stima dei progetti software
Tenendo presente che una buona stima è la base per il successo di un progetto di sviluppo, non possiamo ignorare il fatto che ogni stima si traduce in ore uomo. La qualità professionale dei membri del team e la loro esperienza sono direttamente proporzionali al costo dello sviluppo.
In breve, sapendo che la stima, la pianificazione e l’esecuzione di un progetto sono eseguite da persone, possiamo dedurre che la qualità e la competenza dei professionisti influiscono sul costo di un progetto.
Il buono, il veloce e l’economico
Avendo capito che il software è un’entità immateriale il cui prezzo è difficile da definire, soprattutto se non c’è una stima chiara, passiamo a spiegare gli attributi del buono, del veloce e dell’economico e come è possibile combinarli ma non averli tutti e tre contemporaneamente.
Buono e veloce
È possibile fare qualcosa di buono con la velocità. Per ottenere questo, è essenziale fare una buona stima e poi avere un buon piano di esecuzione del progetto in modo che la velocità non influisca sulla qualità del risultato.
La chiave per ottenere qualità e velocità sta nelle persone che lavorano al progetto, che devono essere abbastanza qualificate per affrontare il progetto. Ricorda che la qualità dei professionisti è un fattore determinante per il costo.
Tieni conto che la velocità può essere controproducente per la produttività: In teoria, una squadra (e i suoi membri) raggiunge il suo picco di produzione in un dato tempo e lo mantiene fino alla fine del progetto. Più alta è la velocità, più breve sarà il tempo in cui la squadra sarà al picco di produttività.
Anche la coordinazione sarà un fattore da analizzare: Più persone lavorano in parallelo, maggiore sarà la coordinazione necessaria (forse bisognerebbe aggiungere più persone come coordinatori).
Il buono e veloce vale soprattutto per progetti critici o chiave, dove la qualità del prodotto deve essere garantita ad ogni costo. In questi casi, è necessario avere squadre con molta esperienza. Se questo è il caso, la soluzione sarà buona e veloce, ma anche costosa.
Veloce ed economica
Ecco la seconda delle nostre combinazioni delle tre variabili: Il modo più semplice per fare qualcosa di veloce ed economico è quello di farlo senza qualità o, almeno, essere consapevoli che può essere inferiore a quella desiderata. Potremmo sacrificare la qualità fino a un certo punto, a patto che il software non gestisca informazioni critiche, o non dipenda da qualche parte sensibile dell’organizzazione.
Per effetti di velocità -perché in futuro la qualità dell’applicazione può essere migliorata-, è possibile andare in produzione con le caratteristiche chiave perché il prodotto funzioni. In questi casi, questo è ciò che si può fare:
- Minimizzare la qualità del codice
- Semplificare la sua usabilità
- Lasciare da parte le revisioni del codice
- Ridurre i controlli di qualità e i test.
Facendo questo, molto probabilmente otterremo uno strumento con una funzionalità di base, ma non un prodotto soddisfacente al 100%. La sua usabilità potrebbe non essere la migliore, così come la qualità del codice, e la sua estensibilità (possibilità di cambiamento o estensione) e riusabilità potrebbe essere problematica.
Questo vale per applicazioni demo, test di concetto, software non critico, o qualsiasi applicazione scalabile o estensibile nel tempo.
Buono ed economico
Le do l’ultima delle nostre equazioni: Se il cliente vuole una soluzione buona ed economica, non può aspettarsi una consegna rapida.
Si può fare qualcosa di buono e ad un costo accettabile ma a scapito del tempo. Fondamentalmente, se c’è tempo, è più facile da pianificare -perché non ci sono tanti compiti in parallelo e non è richiesta tanta coordinazione-, e il picco di produttività delle persone coinvolte sarà al massimo per più tempo.
Per ottenere qualcosa di buono ed economico è adatto a progetti dove il tempo non è una variabile critica, così come per progetti incrementali o con team con tempi parziali (che hanno progetti o iniziative interne).
Non perdere questo: Qualità del software o prezzo: Quale conta davvero?
Per riassumere
Nello sviluppo del software, il postulato dello sviluppo del software buono, veloce ed economico è molto difficile da realizzare. Saremo sempre in grado di ottenerne due, ma dovremo abbandonare il rimanente. In questo modo, è possibile ottenere la qualità in tempi prestabiliti e ad un costo ragionevole; è solo necessario saper trovare l’equilibrio tra queste tre variabili, conoscendone le implicazioni e come si relazionano tra loro per raggiungere tale equilibrio.
Avvicinarsi a questo equilibrio sarà possibile finché le stime, il coordinamento, la selezione del team, la metodologia di lavoro e l’uso di strumenti e tecnologie saranno quelli giusti.
Hai raggiunto un equilibrio tra queste variabili in qualche progetto? Come ci sei riuscito?
.