Enter your keyword

Il trucco del piccolo avanzamento lavori che salverà il tuo sviluppo software on-demand

Il trucco del piccolo avanzamento lavori che salverà il tuo sviluppo software on-demand

Il trucco del piccolo avanzamento lavori che salverà il tuo sviluppo software on-demand

Ogni volta che sento parlare un manager o un imprenditore sulla loro ultima esperienza di sviluppo software, mi rendo conto che delegare questa attività in modo che abbia successo è veramente difficile e bisogna essere preparati a tutto.

Indipendentemente dalle caratteristiche del fornitore che è stato incaricato della realizzazione del software, sento che le loro storie manifestano sempre gli stessi problemi.

Conosco bene il perché di queste preoccupazioni e non posso fare a meno di mettere in guardia tutti coloro che hanno intenzione di far realizzare un software per il proprio business da cui si aspettano grandi soddisfazioni.

E’ impensabile che ancora oggi le software house adottino lo stesso approccio ai lavori, imparato nelle università senza averlo adattato al continuo cambiamento delle esigenze degli imprenditori e dei manager di oggi.

Per questo motivo la collaborazione non può che essere molto ardua.

Ho deciso quindi di scrivere questo articolo attraverso 3 passaggi

  • Il racconto dell’andamento tipico dei lavori di sviluppo software (tratto da una storia vera)
  • La spiegazione del perché le cose si mettono sempre male
  • Come dovrebbe invece essere affrontata questo tipo di collaborazione

Puoi veramente fidarti della software house che ti consigliano i conoscenti?

 

Edoardo ha capito a sue spese le difficoltà che ci sono nel far realizzare del software ai fornitori…

Nella sua azienda era ammirato da tutti i dipendenti perché aveva una forza di volontà strepitosa e perché era riuscito a creare all’interno un clima fraterno.

C’era molta complicità e piena fiducia.

Questo ha permesso ad Edoardo di delegare ai suoi dipendenti molte attività.

Era un vero gioco di squadra, Edoardo “passava la palla” ai propri compagni in piena fiducia senza il bisogno di sprecare tempo in inutili attività di controllo.

Un giorno però Edoardo ebbe la splendida idea di migliorare la vita dei propri colleghi migliorando i processi interni dell’azienda, permettendo loro di lavorare meglio e con più soddisfazione.

Era sicuro che questo avrebbe avuto un impatto positivo sulla redditività della sua azienda.

Visto che i suoi colleghi utilizzavano vari strumenti sia informatici (più o meno evoluti) che “tradizionali”, decise di coinvolgere una software-house che potesse realizzare un sistema informatico all’avanguardia e che potesse portare i benefici previsti.

Armato di tutte buone intenzioni, Edoardo si avvicinò ad una azienda che produceva software consigliata dal suo migliore amico che, in precedenza, aveva acquistato da loro un gestionale per il magazzino della sua società.

Si apprestò quindi a svolgere l’incontro iniziale con questo fornitore.

Durante l’incontro Edoardo ascoltò con molta attenzione la storia della software-house che gli venne raccontata con estremo orgoglio dal fornitore, il quale brillantava grandi capacità di sviluppo software che gli avevano permesso addirittura di realizzare un prodotto tutto loro che rivendevano alle aziende che gestivano un magazzino.

Oltre a questo prodotto per il magazzino, quando capitava, si occupavano anche di realizzare i software che le aziende gli commissionavano.

Edoardo, preso dall’entusiasmo con cui il fornitore gli raccontò la propria storia e confortato della raccomandazione del suo migliore amico, decise di affidargli la realizzazione del software di cui aveva bisogno.

Nel suo caso non necessitava di uno strumento che avesse a che fare con la gestione del magazzino (quello di cui andava fiero la software house in questione) ma dopo tutto:
Che differenza poteva mai esserci per il fornitore a realizzare un software piuttosto che un altro?

Durante l’incontro, il nostro protagonista fece emergere tutte le caratteristiche del sistema che voleva e chiese la possibilità di riceverlo per il primo giorno di lavoro di Gennaio, così da fare ai propri colleghi una sorpresa per l’anno nuovo.

Ricevuto un documento di analisi redatto dal fornitore, Edoardo terminò di prendere gli accordi economici per la commissione del suo lavoro (classica modalità acconto + saldo) e dette così inizio ai lavori.

Segnali di allarme di uno sviluppo software che non ti aspetti

 

Le settimane trascorsero ed Edoardo non si pose molte domande su come stavano andando i lavori.

Dopo tutto perché perdere tempo in ulteriori confronti? Senza contare che le sue giornate erano già molto piene di attività da svolgere.

I giorni però passavano in fretta e non arrivavano notizie da parte del fornitore. Il dubbio, inevitabilmente, iniziava a farsi sentire nella testa del nostro protagonista.

Ad un mese dalla scadenza concordata, Edoardo non resisté e chiamò la software-house chiedendo molto gentilmente informazioni sull’avanzamento lavori (dato che la scadenza pattuita si stava avvicinando).

In risposta alla sua richiesta gli venne proposto un incontro 20 giorni prima della scadenza in cui mostrargli l’avanzamento lavori oramai al termine.

Il nostro protagonista quindi si rassicurò e quasi si sentì in colpa per aver sollecitato.

Quello che non ti aspetteresti dal tuo fornitore di software personalizzato

 

Ma il giorno della riunione arrivò e contro ogni sua aspettativa Edoardo si accorse di avere un problema da non poco da risolvere.

Il fornitore gli mostrò il software che aveva sviluppato fino a quel momento ma, pur facendo finta di non vedere quegli strani errori che si presentavano sullo schermo durante la dimostrazione, non poteva ignorare il fatto che ciò che vedeva non rispecchiava affatto quello che lui si aspettava.

Ad aggravare la situazione c’era la sensazione che il programma fosse realizzato per solo il 50% rispetto a tutte le funzionalità che aveva richiesto, pur essendo molto vicini alla scadenza pattuita.

Non resisté e durante l’incontro rese i toni più aspri esponendo la sua preoccupazione.

Il fornitore, una volta ascoltato i pensieri del nostro protagonista, mise sul tavolo il documento di analisi concordato in fase di trattativa e spiegò come (per la sua visione) le funzionalità che aveva realizzato erano invece in linea con gli accordi presi.

Inoltre, il fornitore, giustificò il ritardo che aveva percepito Edoardo. Nello specifico disse che fino a quel momento aveva fatto un grande sforzo nel creare le parti del software che nell’utilizzo non si vedevano, ma che erano essenziali per un software professionale (aspetti legati alla sicurezza, la banca dati su cui registrare tutte le informazioni e via dicendo).

In fine, il fornitore, per dimostrare la sua buona fede prese atto di alcune osservazioni del nostro protagonista sulle funzionalità che erano state già realizzate, ma che non rispondevano alle sue aspettative e si fece carico di modificarle sulla volontà di Edoardo.

La terribile verità sulla selezione errata della software house

 

A questo punto ti aspetteresti di leggere che Edoardo arrivò al 1 di Gennaio con il software che aveva richiesto e che con grande soddisfazione lo avesse presentato ai suoi colleghi.

Ahimè, purtroppo non è andata così…

Poco prima della scadenza finale, Edoardo ricevette la notizia che lo sviluppo del software era in ritardo, ed il fornitore lo giustificò per aver speso tempo a riadattare quello che già era stato fatto, per seguire le aspettative di Edoardo emerse nell’ultimo incontro.

In altre parole: erano inattaccabili.

Quando ricevette il software (con netto ritardo rispetto agli accordi) si rese conto che era pieno di malfunzionamenti che – oltre a lui – venivano riscontrati anche dai suoi colleghi che lo stavano utilizzando.

Non solo, i suoi colleghi durante l’utilizzo del software, si resero conto che alcune funzionalità erano state implementate in un modo non corretto rispetto alla loro modalità operativa.

In altre parole: gli utenti ci mettevano più tempo ad utilizzare il nuovo software che non a seguire il metodo “tradizionale” a cui erano abituati.

Magicamente la realizzazione di questo software sembrava non avere mai fine, tra modifiche richieste dai colleghi e gli errori che emergevano durante l’utilizzo sembrava impossibile vedere una data di arrivo.

Ad aggravare questo scenario ci fu la reazione negativa dei colleghi che maturarono una certa sfiducia nel nuovo software ed iniziarono a vederlo come del lavoro sporco in più da fare piuttosto che come un’agevolazione alle loro attività.

Questa storia non finisce nel migliore dei modi, come quelle di tante aziende che commissionano all’esterno lo sviluppo del software di cui hanno bisogno.

Ti assicuro però che una strada migliore di quella intrapresa da Edoardo esiste, preparati a scoprirla.

sistema software newsletter

5 Punti fallimentari che devi assolutamente far evitare alla software house di turno

 

Per darti la possibilità di comprendere al 100% questo articolo, passo a descriverti quelli che sono i 5 punti fallimentari dell’approccio ai lavori che hai appena letto nella storia:

Il fornitore lavorava anche ai suoi prodotti:

 

1) La software house ingaggiata dal nostro protagonista era ben disposta a realizzare il software su richiesta, ma ha mostrato un segnale di allarme importante, quello di aver realizzato un software per il magazzino che rivende ad altri clienti

Devi sapere che realizzare prodotti propri, è deleterio per le software house che si vogliono occupare anche di sviluppare software su richiesta dei clienti, perché minacciano l’avanzamento lavori programmato che – puntualmente – finisce per avere posticipazioni sulla data di consegna dei lavori.
Ricordi che Edoardo si accorse che il suo software era solo al 50% pur essendo vicini alla scadenza?

In altre parole, le attività di sviluppo dei software su richiesta (come quello di Edoardo) vengono costantemente minacciate dalle urgenze che derivano dai prodotti che la software house selezionata rivende ad altri clienti.

Per farti capire meglio, nella storia che hai appena letto, la software house (pur avendo preso accordi con il nostro protagonista) si trovava impegnata a fronteggiare richieste da parte dei clienti che utilizzavano il prodotto per il magazzino e non riusciva a concentrarsi sull’avanzamento lavori del software di Edoardo.

In quasi 15 anni abbiamo imparato da tempo che sviluppare nostri prodotti era tutt’altra cosa rispetto a sviluppare il software per i nostri clienti.

Ci siamo così accorti che potevamo fare al meglio solo una cosa, la nostra scelta è stata lo sviluppo dei software su richiesta.

Ti chiederai: Che differenza ci potrà mai essere nello sviluppare prodotti da rivendere in autonomia piuttosto che sviluppare i software su commissione dei clienti?

Sappi che la differenza è così enorme che ci sono metodi diversi e specifici di lavorare per ogni situazione.

Non possono coesistere (con successo) in un’unica società.
Una software house esclusivamente specializzata in una delle due cose porterà sempre i maggior benefici.

 

2) Il fornitore aveva basato la sua analisi sulle sensazioni e le ipotesi iniziali di Edoardo

Utilizzando il metodo tradizionale , la software house ha fondato la sua analisi e la sua offerta, sulla base delle considerazioni che il committente (Edoardo) ha espresso durante l’incontro iniziale.

Per lo sviluppo del software “che non esiste” (quello su richiesta del committente) è oramai obsoleto questo metodo in quanto puntualmente smentito dal cambio requisiti in corso d’opera dovuti da tantissimi fattori, primo tra cui il cliente che (toccando con mano il software che è in corso lavori) prende atto di cambiamenti da apportare.

Ti chiederai: In che modo può essere migliorata la scrittura dell’analisi e relativa offerta economica in fase iniziale?

La risposta a questa domanda è molto complessa (pensa che per scoprirla ci abbiamo impiegato quasi 10 anni).

Cercando di sintetizzarti la cosa, un approccio lavori fortemente basato sui piccoli avanzamenti di sviluppo software ti permettano di azzerare i rischi tipici del mestiere e di produrre il software di cui il cliente ha veramente bisogno. Senza sprechi di tempo, denaro e di fegato.

Ovviamente, questo approccio a piccolo avanzamento lavori, per avere la sua massima efficacia deve essere adottato sia in fase di progettazione e sviluppo sia negli accordi economici.

 

3) Il fornitore non aveva proposto degli incontri che accompagnavano l’avanzamento lavori

In questo caso (come tanti altri) la software house non promuove un approccio al lavoro basato su un puntale confronto in fase di avanzamento sviluppo.

Nel caso di Edoardo siamo passati dalla riunione iniziale col fornitore, alla presentazione quasi al termine dei lavori. E’ decisamente troppo e questo succede molto spesso, dando luogo a tutte le problematiche che hai appena letto.

Più tempo passa da un confronto tra il cliente ed il fornitore, più sviluppo software deve essere cestinato e fatto secondo specifiche nuove (o semplicemente più corrette) secondo le reali necessità del committente.

 

4) Il fornitore non aveva dato alcuna garanzia al cliente su come tutelarsi da un lavoro non corretto

Se hai fatto attenzione, avrai notato che appena Edoardo ha inasprito i toni per condividere la sua preoccupazione su come stavano procedendo i lavori, il fornitore ha subito risposto ricorrendo all’analisi pattuita e respingendo ogni segnalazione.

Questo accade sempre.

Le analisi iniziali (per quando dettagliate) hanno sempre un margine di interpretazione su cui il fornitore può aggrapparsi per respingere le tue osservazioni, le tue preoccupazioni e sollecitazioni.

E’ un’arma che troppo spesso viene usata in maniera impropria.

Eppure se ci pensi bene, alla fine dei lavori poi, confrontando le analisi iniziali con il software finito, ci si accorge sempre che il tempo investito nel produrre inizialmente quel documento è stato sprecato e poteva essere utilizzato in maniera più efficiente.

Dai vantaggi che abbiamo ottenuto nello scegliere di specializzarci esclusivamente nello sviluppo software on demand, siamo riusciti ad essere i primi in Italia ad offrire ai nostri clienti una garanzia sui lavori svolti.

Abbiamo chiamato questa garanzia “Avanti Solo Se Soddisfatti” grazie alla quale il nostro cliente può non acquistare l’avanzamento lavori se non rispetta le sue aspettative e gli accordi presi. Senza spendere quindi 1 solo euro.

 

5) Il fornitore non aveva consegnato il software al cliente durante l’avanzamento lavori

Ricordi che nella storia di Edoardo i suoi dipendenti (pur essendo parte di una società che aveva un clima fraterno) si erano irrigiditi e vedevano il nuovo software come un loro nemico?

Questo è un aspetto essenziale.

Dare la possibilità agli utilizzatori finali di usare il software durante l’avanzamento lavori, apre le porte ad enormi benefici.

Uno dei più importanti è quello di far iniziare ad utilizzare lo strumento agli utenti in modo che lo possano conoscere in corso d’opera evitando che ciò gli venga imposto da un momento all’altro.

Questo fa la differenza tra:

  • Avere degli utilizzatori finali che accolgano nel migliore dei modi il nuovo software
  • Avere un grosso problema da gestire in azienda dato dagli utilizzatori finali del software che ostacolano l’ingresso del nuovo software

Senza contare che gli utenti danno sempre preziose considerazioni sul software che prima emergono più si riesce ad accontentarli e ad agevolarli nell’utilizzo finale.

Questo vale sia per software aziendali sia per software destinati ad essere rivenduti come prodotto o servizio.

 

CONCLUSIONE

Delegare la realizzazione di un software è corretto, ma ci vuole abilità nel farlo con successo e ti assicuro che la tua attenzione (quella del committente) è essenziale per il buon esito del progetto.

Molto probabilmente non hai mai fatto realizzare software attraverso piccolo avanzamento lavori.

Che tu lo stia facendo sviluppare per ottenere una gestione migliore in azienda o che tu lo stia facendo realizzare per poterlo rivendere, la cosa non cambia.

Un’impostazione dei lavori basata sul piccolo avanzamento (che noi chiamiamo Iterazione) è sempre la soluzione migliore.

Non voglio illuderti, lavorare in questo modo richiede impegno, sia da parte del fornitore che hai incaricato, sia da parte tua.

Questo perché sviluppare un software da zero (quindi che non esiste) è un lavoro molto delicato a tal punto che sia te che il fornitore non potete permettervi distrazioni.

Il rischio è sempre il solito: ritardo sulle consegne, lavoro da rifare perché non è come te lo aspettavi, malfunzionamenti sull’applicativo, utenti che ostacolano l’utilizzo del nuovo software.

Certo, il fatto che tu non abbia mai provato a delegare uno sviluppo software personalizzato secondo un metodo a piccoli avanzamento lavoro non è di certo una tua mancanza.

La software house deve proporti il metodo migliore di approccio ai lavori, ma la realtà è che le cose non funzionano affatto così e trovare una azienda specializzata – che ti proponga quindi una soluzione professionale minimizzando i rischi – risulta molto difficile.

Ecco perché ti consiglio di leggere con attenzione e applicare i miei consigli, così da colmare la mancanza del fornitore a cui ti sei rivolto.

Tieni presente che:

  1. Se sviluppi ad iterazioni hai il controllo su come stanno andando le cose.
  2. Se sviluppi ad iterazioni ottieni da subito qualcosa da utilizzare. Ottimo se ne hai un bisogno urgente, fondamentale per farlo provare fin da subito agli utilizzatori finali.
  3. Se sviluppi ad iterazioni hai il fornitore “in pugno”: non può distrarsi e svolgere altri lavori, le scadenze intermedie non glielo permettono.

Non ti rimane che riflettere bene su quanto hai letto e scaricare il nostro Ebook gratuito che ti rivela i 4 segreti che le software house non vogliono rivelarti!

===> CLICCA QUI PER SCARICARE L’EBOOK GRATUITO <===

 

A questo punto la domanda nasce spontanea:

Ma quello che riceverai da Sistema Software  fin dal primo avanzamento lavori, può essere davvero utilizzato? Oppure potrebbe essere una parte del software che non ha senso senza tutto il resto?

Il modo per ottenere da subito qualcosa di funzionante e che abbia senso esiste e ti consiglio di iscriverti alla Newsletter per scoprirlo: www.sistemasoftware.it/newsletter

Al prossimo Sviluppo!

No Comments

Leave a Reply