6 cose da discutere col tuo sviluppatore web prima di cominciare il lavoro

E cosi’ stai progettando un nuovo sito web o un negozio online e hai bisogno di uno sviluppatore web. Potresti aver bisogno hai bisogno di sviluppare un sito da zero oppure fare soltanto con alcune modifiche per risolvere dei problemi di funzionamento o aggiungere delle funzionalità extra.

In ogni caso, la tua relazione con il tuo sviluppatore web può essere difficile da gestire. Avendone gestite moltissime, so che ci sono tantissimi modi in cui la relazione può rivelarsi non produttiva:

  • Scadenze non rispettate
  • Mancanza di comunicazione
  • Comunicazione lenta
  • Nessuna comunicazione
  • Lo sviluppatore fa piu’ di quel che gli viene chiesto
  • Lo sviluppatore fa meno di quel che gli viene chiesto
  • Lo sviluppatore scompare
  • Lo scopo dell’intervento non è definito chiaramente
  • Mancanza di protocollo per decisioni meno importanti
  • Bug o problemi non risolti

Chiunque abbia lavorato con sviluppatori web puo’ raccontare una qualche storia di fallimenti dovuti a questo tipo di problemi ed è per questo che una piccola lista di elementi da chiarificare prima di cominciare la relazione puo’ aiutare a raggiungere il successo dell’operazione.

Prima di approfondire, vorrei essere chiaro: questo non è un toccasana per tutte le relazioni tra committenti e sviluppatori: stiamo parlando di relazioni umane e quindi variabili a seconda delle persoe coinvolte, ma posso assicurare che una conversazione aperta su questi elementi può far partire un progetto con il piede giusto.

1. Come comunicheremo?

Come comunicherete mentre lavorate al progetto? Skype? Chiamate telefoniche? SMS? Messaggi di posta elettronica? Altrettanto importante: quanto spesso comunicherete? Ogni giorno? Una volta a settimana? All’inizio del lavoro , e poi silenzio fino alla consegna? Se effettuate un controllo giornaliero, sarà un’e-mail a due frasi o una telefonata di 15 minuti? Qual è il piano in caso di emergenza?

In quest’elenco non ci sono risposte sbagliate a patto di impostare le aspettative fin dall’inizio. Ma ricorda: più comunicazione non sempre equivale a una migliore comunicazione.

Per riuscire ad avere un buon rapporto con il tuo sviluppatore c’è bisogno di una modalità di comunicazione consolidata. La cosa migliore è sicuramente trovare un equilibrio in modo da non controllare troppo ma nemmeno troppo poco. Se si contola troppo si rischia di scadere nel micromanagement. Se invece si controlla troppo poco lo sviluppatore potrebbe non rimanere in pista. Bisogna cercare di definire questi protocolli all’inizio e poi cercare di attenervisi.

2. Come gestirai il progetto?

Dove sono i file e le credenziali di accesso di cui lo sviluppatore avrà bisogno? Dove seguirai compiti, traguardi e scadenze? Userete dei software di gestione? Quali? Oppure userete un foglio di calcolo o un documento Google? Fondamentalmente, cercate di definire l’hub centrale per tutto ciò che riguarda il progetto.

Durante il progetto, la gestione e l’informazione dovrebbero essere centralizzate e tracciabili. Diversamente si rischia di perdere molto tempo nel tentativo di cercare file, check-in, aggiornamenti, progressi, domande, decisioni, ecc. Ecco perché è importante stabilire dove lo sviluppatore può trovare tutto ciò di cui ha bisogno.

3. Chi dà le direttive di progetto?

Sei tu il decisore finale del progetto? C’è un team UI / UX coinvolto? C’è qualcun altro che ha contribuito alle decisioni? C’è un team di marketing o un manager che vuole valutare le decisioni? Qualcun altro oltre a te sta dando delle direttve direttamente allo sviluppatore? C’è un cliente terzo che puo’ prendere delle decisioni? Questo cliente avrà una comunicazione diretta con lo sviluppatore?

Si devono assolutamente definire queste informazioni per non rischare di dover tornare indietro nello sviluppo o doer far rifare il lavolo al tuo sviluppatore. Per evitare simili situazioni è importante che ogni stakeholder sia consapevole di tutte le decisioni rilevanti e che ogni decisione sia registrata in un’unica posizione centrale.

4. In che modo lo sviluppatore deve gestire le piccole decisioni?

Quanta libertà ha lo sviluppatore mentre interpreta le istruzioni che ha ricevuto? Deve creare il sito web perfetto al pixel in base ai progetti o puo’ fare piccole ipotesi sulla coerenza e la riusabilità delle sezioni? Se si tratta della creazione di un sito responsivo, sono stati progettati tutti i breakpoints? Hai fornito istruzioni su eventuali animazioni, transizioni e effetti al passaggio del mouse? Hai progettato stati di convalida per i campi? (Ad esempio i popup: “Password non valida.” o “Utente non riconosciuto”.) Se non lo hai fatto, lo sviluppatore è libero di prendere decisioni o dare suggerimenti?

Spesso succede che i progettisti sono insoddisfatti quando un sito web non corrisponde esattamente ai progetti, o viceversa, quando il sito segue troppo da vicino i progetti, a scapito delle sue prestazioni o della tempistica di esecuzione. E’ sempre meglio definire fin da subito il livello di dettaglio desiderato in modo da rendere molto più agevole sia il processo di controllo qualità che il lavoro dello sviluppatore.

5. Quali sono le tempistiche di esecuzione?

Quali sono le scadenze da non mancare e quali le scadenze piu’ elastiche? E’ previsto un qualche evento di lancio per la cui data il sito deve assolutamente essere in linea? Se la data di consegna non è realistica, c’è un modo per lanciare in piu’ fasi? Quali sono i tempi di risposta per effettuare modifiche rapide? Una settimana? Un’ora?

Se c’è una scadenza non procrastinabile, informa lo sviluppatore e assicurati di lasciare il tempo per fare dei test correttamente.un corretto. Dopo il lancio del sito, sappi che la maggior parte degli sviluppatori non può essere in servizio a qualsiasi le ore per apportare modifiche. Attendere che uno sviluppatore possa apportare una correzione può essere frustrante, ma bisogna tenere conto che anche richieste di piccole dimensioni richiedono il mantenimento del controllo della versione, l’avvio dell’ambiente di sviluppo, la connessione al server, la distribuzione al sito di produzione, ecc. E’ importante determinare in anticipo per quanto tempo si prevedono correzioni e modifiche e fare il punto sul livello di priorità di ogni attività.

Inoltre, in realtà ,creare scadenze rigide artificiali non aiuta il corretto sviluppo di un prodotto web. Basta essere trasparenti con il proprio sviluppatore e fidarsi di lui per per avere delle proposte realistiche.Nella costruzione di una collaborazione proficua l’onestà è la miglior politica.

6. Qual è lo scopo del progetto e come sono strutturati il contratto ed i pagamenti?

Qual è il costo del progetto? Qual è il punto di riferimento per la fine del progetto? Cosa è incluso nello scopo del progetto? Quando bisogna eseguire il pagamento? Stai assumendo lo sviluppatore per fare il progetto a una tariffa oraria o fissa?

Definire questi punti è fondamentale perchè l’ultima cosa che vuoi è che uno sviluppatore realizzi un sito al 95% delle funzionalità richieste, e quindi non avviare il progetto a causa di una discrepanza nella comprensione dello scopo che determina un malinteso su contratto o su pagamento.

Conclusione

Nel complesso, le cose fondamentali per avere una collaborazione efficace con uno sviluppatore web sono la definizione corretta delle aspettative e della comunicazione. Può sembrare un po ‘sciocco discutere di come parlerai durante un progetto, specialmente se hai già un buon rapporto con uno sviluppatore. Ma è sempre bene definire le aspettative in anticipo, così da non rischiare il fallimento del progetto a causa di dettagli apparentemente poco importanti.