Ecco i 5 segreti per selezionare il tuo fornitore software on-demand

Ecco i 5 segreti per selezionare il tuo fornitore software on-demand

Non ho tenuto il conto di quanti progetti di sviluppo software ho affrontato dal momento in cui ho iniziato a far parte di questo mondo.

Devo ammettere che col passare del tempo ho avuto modo anche di affrontarli ricoprendo ruoli diversi riuscendo sempre ad appassionarmi molto.

 

Chi ha mai avuto a che fare col codice sorgente, con le query al database piuttosto che con la progettazione delle interfacce utente o della user experience, sa bene che questo mondo ha il suo fascino!

 

Certo è che tra chi commissiona il software e chi lo realizza non è mai stata “vita facile” e se ti è mai capitato di delegare un lavoro di questo tipo saprai bene che sono molteplici i motivi per cui possono venire a crearsi frizioni tra le parti:

  • Una personalità nettamente diversa.
    Specie se chi commissiona il software ha un profilo manageriale mentre chi rappresenta la software-house è prettamente una figura tecnica.
  • Una interpretazione differente.
    Mi riferisco al momento in cui il software realizzato viene presentato e chi ha commissionato il lavoro si rende conto che aspettava una cosa diversa. Per esempio: pensa se il cliente (colui che paga) si aspetta di ricevere una Ferrari quando invece si vede arrivare un Caterpillar!
  • Un cambio di requisiti.
    Quante volte lo hai sentito dire?
    Sicuramente non poche dato che nel software il cambio dei requisiti iniziali è fisiologico. Continuando a leggere capirai il perché…
  • Dei tempi di consegna non rispettati.
    Un altro classico per chi già ha commissionato o avuto a che fare con lo sviluppo software almeno una volta. Rispetto agli accordi quanto tempo dopo è stato consegnato il lavoro?
  • Dei malfunzionamenti.
    Tipico di quando il cliente che ha commissionato il lavoro assume il ruolo di tester o beta-tester senza che questo sia stato concordato. Pensa che nei casi più sfortunati i malfunzionamenti persistono anche dopo la messa in produzione.

 

Ci vuole un attimo per capire che sono tutti elementi facilmente collegati tra di loro, non trovi?

 

Se ci pensi bene, tutti i progetti in cui si sono verificati uno o più di questi fattori avevano una cosa in comune: si basavano su tecnologie che erano all’avanguardia al momento della commissione del lavoro.

 

Concorderai quindi con me sul fatto che non è quindi la tecnologia che garantisce il successo del progetto e del rapporto cliente-fornitore.

 

Ma allora dove si nasconde il successo di uno sviluppo software?

 

Una domanda da cento milioni di euro!

 

Devi sapere che la risposta a questa domanda inizia da una storia che parte dal 2001, anno in cui è nata Vivido.

 

Se c’è una cosa di cui possiamo essere orgogliosi è di aver fatto sempre della retrospettiva sui lavori svolti, sia quando le cose andavano splendidamente bene per capirne il perché così da poterne ricreare le condizioni, ma soprattutto quando le cose si mettevano male così da imparare dall’insuccesso affinché non ricapitassero gli stessi errori.

 

La definirei una azienda umile sempre alla ricerca di un miglioramento continuo.

 

Col passare degli anni ci siamo accorti che le figure che avevamo indentificato come “Gli Analisti del software” seguivano fin dall’inizio il progetto a stretto contatto con i clienti con l’obiettivo di fare la famosa analisi blindata.

 

Per “analisi blindata” si intendeva (notare il tempo passato) il documento che rispecchiava al dettaglio il software che il Cliente ci commissionava.

 

L’analista era bravo e faceva un buon lavoro se, dall’inizio dello sviluppo alla consegna del software, non si presentavano cambi di prerequisiti. In particolare quelli di entità medio/grande che provocavano una naturale dilatazione dei tempi di sviluppo che a loro volta provocavano un ritardo sui tempi di consegna attivando così una serie di effetti collaterali non piacevoli sia per il Cliente che per il fornitore.

 

In definitiva questa analisi blindata si rivelava un’arma a doppio taglio sia per il cliente che per il fornitore e sul nascere degli “attriti” veniva presa come riferimento:

  • Fornitore: “Nella analisi questa cosa non la avevamo trattata”
  • Cliente: “Questa caratteristica era sottointesa nel documento di analisi dato che è essenziale”
  • Fornitore “Siamo in ritardo perché non ci avete dato le risposte alle domande fatte sui punti dell’analisi”
  • Cliente “Anche se non c’è nel documento di analisi che differenza fa aggiungere questo controllo alla pressione di questo tasto e spostare questa cosa da quest’altra parte?”

 

E potrei continuare per tutta la giornata ma per fortuna sia io che te abbiamo di meglio da fare 🙂

 

Eppure queste situazioni puntualmente si presentavano, immaginatevi il senso di frustrazione visto che i nostri analisti erano bravi ed i nostri Clienti erano persone per bene che non volevano certamente tentare di fregare nessuno.

 

Entrambi avevano ragione.

 

Nostra fortuna è stata che nelle nostre retrospettive ci siamo iniziati a chiedere: Ma esiste un modo in cui possiamo essere propositivi al cambio dei prerequisiti vivendo positivamente – ed insieme al cliente – l’evolversi del progetto?

 

Presi da questo dubbio amletico ci siamo messi alla sfrenata ricerca di una soluzione e mettendocela tutta siamo riusciti ad avvicinarci a figure di grande spessore che in tutto il mondo parlavano e affrontavano queste tematiche a noi divenute tanto care.

 

Siamo venuti così a conoscenza e ci siamo appassionati alla metodologia Agile e non per ultimo abbiamo iniziato a partecipare (fin dalla prima edizione del 2009) alla conferenza per eccellenza sullo sviluppo e sul management del software: Il Better Software.

 

E’ stata proprio la nostra costanza nel seguire questa conferenza, unita alla passione che avevamo maturato per il movimento Agile, che abbiamo deciso di coinvolgere un coach esterno iniziando così una intensa formazione per rendere lo sviluppo del software il più “agile” possibile.

 

In questa fase avevamo imparato molte cose, prima fra tutte che lo sviluppo del software è un processo di apprendimento che ha come inizio il livello massimo di ignoranza sull’argomento (sia per il cliente che per il fornitore).

 

Ecco scoperto perché il cambio dei requisiti in corso d’opera!

 

In altre parole: Il team di sviluppo, insieme al cliente, imparano sempre di più della problematica specifica per cui si sta sviluppando il software che una maggior presa di conoscenza corrisponde inevitabilmente ad un cambio di requisiti.

 

I feedback del mercato è stato positivo, avevamo raggiunto il modo di realizzare software di qualità anche là dove c’era forte incertezza sui requisiti iniziali e dove si presentavano tempi di realizzazione particolarmente ostili.

 

Abbiamo comunque deciso di non fermarci e di procedere con l’apprendimento e la rivoluzione del metodo arrivando fino a integrare l’approccio Agile negli aspetti commerciali e contabili della azienda, coprendo così a 360 gradi tutto cioà che ruota attorno al un rapporto di sviluppo software su richiesta.

 

Tornando alla domanda con cui ci eravamo lasciati prima, devi sapere che la tecnologia è soltanto una caratteristica non sufficiente a garantire il buon esito del progetto.

 

Il segreto del successo dello sviluppo software on demand si nasconde dietro al metodo con cui viene portato avanti il progetto.

 

A questo punto cosa puoi fare per evitare di scegliere un fornitore sbagliato per lo sviluppo software?

 

Di seguito, in riferimento alla lista delle problematiche caratteristiche che ho scritto in questo articolo, ti lascio una lista di punti che puoi seguire fin da subito così da evitare la scelta del fornitore sbagliato:

 

  • Problema:Una personalità nettamente diversa.
    Soluzione:Recupera o chiedi informazioni sullo staff che fa parte del fornitore. Tieni presente che uno staff molto ristretto è un campanello di allarme di due sintomi:

    • Chi sviluppa il software è colui che si occupa a 360 gradi degli altri aspetti
    • Chi sviluppa non appartiene a quella azienda
      Va da se che, la persona con cui ti confronterai, parlerà “l’informatichese stretto”, tu lo sai parlare?
  • Problema: Una interpretazione differente.
    Soluzione: Prima ancora di mostrare i documenti che hai redatto sul progetto che intendi far sviluppare, chiedi al fornitore due informazioni:

    • Di quali informazioni ha bisogno e se necessita di uno o più confronti con te prima di iniziare a scrivere la prima riga di codice
    • Chiedi se e quanti confronti sono previsti dal momento dell’affidamento lavori alla consegna.
      Il miglior modo per stanare l’eventuale errore di interpretazione è quello di avere più confronti che ti permettono di vedere il crescere del progetto.
      Non credere che scrivere il documento di prerequisiti ti porti in automatico a ricevere il software che effettivamente volevi.
  • Problema: Un cambio di requisiti.
    Soluzione: Anche se sei sicuro di avere le idee molto chiare, chiedi preventivamente se nei momenti di confronto con te per la presentazione di avanzamento lavori sarà possibile apportare dei cambiamenti e delle correzioni sulle caratteristiche oggetto dell’avanzamento lavori.
    Un’altra cosa: Ricordati di chiedere la possibilità di andare per sostituzione delle caratteristiche. Questo potrebbe servirti nel caso in cui tu decida di aggiungere una funzionalità che ti rendi conto essere prioritaria a scapito di toglierne un’altra già preventivata ma la cui importanza la porterà ad essere implementata eventualmente in una successiva versione dell’applicativo.

 

  • Problema: Dei tempi di consegna non rispettati.
    Soluzione: Ammetto che il cambio prerequisiti è normale in fase di lavori in corso, ma ammetto anche che è altrettanto normale una relativa dilatazione dei tempi di consegna.
    Se ricevere il software funzionante per una data ben precisa è per te un aspetto fondamentale su cui non puoi scendere a compromessi, assicurati anticipatamente che il fornitore (là dove ce ne fosse bisogno) possa aggiungere forza lavoro sul progetto per riuscire a rispettare i tempi accordati.

 

  • Problema: Dei malfunzionamenti.
    Soluzione: Informati su come il fornitore è strutturato per la fase di test del codice sorgente e dell’applicativo in genere.

    • A tal proposito è previsto un team dedicato? Avere personale dedicato al test del codice è un’ottima cosa soprattutto se queste persone non hanno anche la mansione di scrivere il codice.
    • Chi realizza il codice è la stessa persona che ne effettua il test? Se si: Grave errore!
    • In che modo vengono gestiti i rilasci del software? Che sia avanzamento lavori o rilascio nuova versione una risposta pronta a questa domanda stanerà la possibilità di ricevere nuovi errori (non previsti) ad ogni rilascio evitando quindi di ricevere quelle che si chiamano le regressioni del software.

 

Questa lista è già un buon punto di partenza e ti basterà per selezionare meglio i fornitori a cui affidarti per lo sviluppo software su richiesta. Quanto meno per spazzare via quelli meno professionali ed organizzati.

 

Certo è che per assicurarti il successo del tuo progetto hai solo una soluzione: Contattarci

UX Designer for passion & Team Leader @Vivido Srl. Life is too short for learn all.. why not combine our knowledge?

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *