Come assumere uno sviluppatore freelance

La maggior parte dei progetti di sviluppo falliti non sono stati mal codificati. Sono stati mal specificati, assunti in base al segnale sbagliato e consegnati in modo così incompleto che lo sviluppatore successivo ha dovuto ricominciare da capo. La parte tecnica è raramente il punto in cui il denaro scompare.

Questa è una buona notizia per un acquirente non tecnico, perché significa che le decisioni più importanti sono quelle che sei qualificato a prendere. Non hai bisogno di valutare il JavaScript di qualcuno per assumere bene. Devi essere in grado di descrivere il problema con precisione, riconoscere prove pertinenti, porre domande a cui è difficile bluffare e insistere su una consegna che ti lasci in mano le chiavi. Questa guida illustra tutti e quattro i punti.

Decidi cosa stai effettivamente costruendo

Inizia con il risultato, non con la tecnologia. "Ho bisogno di un'app" non è un brief; "i clienti devono poter prenotare e pagare un posto sul loro telefono, e io devo vedere le prenotazioni di domani in un'unica lista" lo è. La seconda versione può essere quotata, testata e discussa. La prima no.

Prima di parlare con chiunque, scrivi quattro cose:

• Il lavoro da fareCosa un utente dovrebbe essere in grado di realizzare che oggi non può. Una frase per ogni capacità, nel linguaggio dell'utente piuttosto che in quello tecnico.
• Gli indispensabiliLe poche cose senza le quali la costruzione è inutile. Se la tua lista ne ha più di sei, è una lista dei desideri, non una specifica.
• Cosa esiste giàSito attuale, hosting, dominio, fornitore di pagamenti, CRM, fogli di calcolo. Ogni integrazione è lavoro, e le integrazioni non dichiarate sono il punto in cui le stime si rompono.
• Chi lo mantieneIl software non è un acquisto, è un impegno. Decidi ora se manterrai lo sviluppatore, assumerai qualcun altro o lo gestirai tu stesso.

Una disciplina utile: descrivi la prima versione come la cosa più piccola che sarebbe veramente utile. Tutto il resto va in una seconda lista. Gli sviluppatori quotano la prima lista; la seconda lista è ciò che finanzi una volta che la prima sta guadagnando.

Che tipo di sviluppatore ti serve

"Sviluppatore" copre una dozzina di mestieri distinti che non sono intercambiabili. Assumere quello sbagliato è l'errore di categoria più comune e costoso in questo processo.

• Front-endCiò che l'utente vede e tocca: layout, interazione, reattività, accessibilità. Assumi per un redesign, un sito di marketing o una nuova interfaccia su un sistema esistente. Vedi freelance per lo sviluppo front-end.
• Back-endDati, logica, API, autenticazione, pagamenti. Assumi quando il valore è in ciò che accade dopo aver premuto il pulsante. Vedi freelance per lo sviluppo back-end.
• Full-stackEntrambi, a uno standard di lavoro. La scelta giusta per la maggior parte delle piccole costruzioni, perché il coordinamento tra due specialisti costa più di quanto risparmi su piccola scala.
• CMS e piattaformaWordPress, Shopify, Webflow e simili. Se il tuo requisito è soddisfatto da una piattaforma esistente, assumere uno sviluppatore personalizzato per ricostruirla è denaro bruciato. Vedi sviluppo WordPress e sviluppo Shopify.
• MobileiOS o Android nativo, o multipiattaforma. Una disciplina genuinamente diversa dal web, con le proprie restrizioni di revisione e rilascio degli store. Vedi sviluppo di app mobili.
• Manutenzione e correzioniDebug, aggiornamenti, prestazioni, sicurezza. Spesso l'assunzione di maggior valore di tutte, e quella che gli acquirenti rimandano più a lungo. Vedi manutenzione siti web.

Se non riesci davvero a capire di quale hai bisogno, questo è di per sé un lavoro piccolo, economico e ben definito: paga uno sviluppatore esperto per una breve conversazione di scoping prima di commissionare qualsiasi cosa.

Scegliere la tecnologia prima della persona

Non è necessario scegliere la lingua. Devi prendere una decisione: piattaforma o personalizzato. Ha un effetto maggiore sul costo totale rispetto a qualsiasi altra scelta in questa guida.

Una costruzione su piattaforma — WordPress, Shopify, Webflow, uno strumento no-code — significa che la maggior parte del software esiste già e tu stai pagando per la configurazione, il design e le parti specifiche per te. È più veloce, più economico e più facile da consegnare alla persona successiva, perché migliaia di sviluppatori lo conoscono. Il limite è che vivi all'interno delle ipotesi della piattaforma.

Una costruzione personalizzata significa che il software è scritto per te. Si adatta esattamente e costa molte volte di più per essere creato e mantenuto, perché solo la persona che lo ha scritto lo conosce finché non lo documenta. Personalizzato è la risposta giusta quando ciò che fai è il prodotto; è la risposta sbagliata per un sito vetrina o un negozio standard.

Due regole pratiche. Primo, se una piattaforma mainstream fa l'ottanta per cento di ciò di cui hai bisogno, inizia da lì e paga per il venti per cento mancante. Secondo, qualunque cosa venga scelta, chiedi perché — uno sviluppatore che non riesce a spiegare la scelta in termini dei tuoi requisiti sta scegliendo ciò che gli piace, non ciò di cui hai bisogno. Se stai valutando la costruzione di un sito completo, la nostra guida ai costi dei siti web stabilisce le fasce.

Scrivere un breve documento che uno sviluppatore può citare

Un buon brief tecnico è breve e specifico. Non dice allo sviluppatore come costruire; gli dice cosa deve essere vero quando ha finito.

• Il problema, in un paragrafo. Cosa sta succedendo ora e perché non è accettabile.
• Le user story. “Come cliente, posso… in modo che…”. Da cinque a quindici di queste costituiscono una vera e propria specifica.
• Le integrazioni. Nomina ogni sistema esterno per nome, inclusi quelli che consideri banali.
• Cosa stai fornendo. Testi, immagini, design, accessi, dati di test. Le lacune non dichiarate diventano ore fatturabili.
• Vincoli. Scadenza, fascia di budget, hosting su cui devi rimanere, conformità che devi soddisfare.
• La definizione di “fatto”. Dove è stato distribuito, come è stato testato, a che livello è stato documentato, con cosa è stato consegnato.

Includi una fascia di budget. Gli acquirenti la trattengono sperando in un preventivo più basso; in pratica, ciò produce solo proposte mirate alla scala sbagliata, e si perde un giro di corrispondenza per scoprirlo. La nostra guida su come scrivere un brief di progetto che ottenga ottime proposte ha un modello più completo, e prezzo orario vs prezzo fisso spiega quale modello di prezzo richiede il tuo brief.

Creare una lista ristretta

Punta a tre-cinque candidati. Meno e non avrai confronti; di più e non farai una valutazione adeguata su nessuno di essi.

Ci sono due direzioni da cui cercare. Inizia dal lavoro se il tuo compito è ben definito e vuoi acquistare qualcosa di specifico — sfoglia gli annunci a prezzo fisso sotto sviluppo di siti web, sviluppo software o applicazioni web, o per marketplace su web design, sviluppatori WordPress, sviluppo di app mobili o esperti Shopify.

Inizia dalla persona se il lavoro richiede discussione. Sfoglia gli sviluppatori per disciplina o per strumento — React, WordPress, PHP, Python o Webflow — oppure pubblica il brief e lascia che le proposte ti arrivino. Su Zinn Hub, pubblicare un progetto è gratuito, e puoi indirizzarlo a un'area specifica come sviluppo di siti web, sviluppo back-end o sviluppo di app mobili.

Filtra rigorosamente per pertinenza e leggermente per tutto il resto. Uno sviluppatore che ha realizzato tre cose simili alle tue batte quasi sempre uno con il doppio dell'esperienza in un dominio diverso.

Come leggere un portfolio di sviluppatori

Non puoi controllare il codice di qualcuno, e non ne hai bisogno. Un portfolio ti dice comunque molto se sai cosa guardare.

• Apri i link live. Uno screenshot non prova nulla. Carica il sito sul tuo telefono, usalo, rompilo. Qualsiasi cosa rotta oggi è stata approvata rotta.
• Cerca problemi simili ai tuoi. Non lo stesso settore — la stessa forma. Un flusso di prenotazione è un flusso di prenotazione sia che venda tagli di capelli o elicotteri.
• Controlla cosa hanno fatto. Nei progetti di squadra, chiedi quali parti erano le loro. “Ci ho lavorato” può significare molto o molto poco.
• Testa tu stesso le basi. La pagina si carica velocemente? Funziona su un telefono? I moduli sono utilizzabili con una tastiera? Questi sono segnali di artigianato che un acquirente non tecnico può leggere perfettamente.
• Leggi le recensioni come un corpo di prove. Una recensione entusiasta è rumore. Un modello in molte, specialmente sulla comunicazione e le scadenze, è un segnale. Su Zinn Hub le recensioni richiedono un acquisto confermato.
• Chiedi cosa è andato storto. La risposta più forte a “parlami di un progetto andato male” è una storia specifica, poco lusinghiera e ben analizzata. Non esiste uno sviluppatore con solo progetti senza intoppi.

Per una versione sistematica di questo, consulta la nostra checklist di verifica dei freelancer in 12 passaggi.

Domande da porre prima di assumere

L'obiettivo non è cogliere nessuno in fallo. È ascoltare come pensa una persona quando la risposta non è stata provata.

• Spiega una costruzione passata“Parlami di uno di questi progetti e dei compromessi che hai fatto.” Un buon sviluppatore nominerà qualcosa che ha scelto di non fare e perché. Il gergo senza compromessi è un segnale di avvertimento.
• Cosa ti preoccupa quiChiedi qual è la parte più rischiosa del tuo brief. Chiunque dica “niente, è semplice” non l'ha letto correttamente.
• Cosa manca“Cosa avresti bisogno da me che non ho fornito?” I candidati forti rispondono a questo immediatamente e in dettaglio.
• Come vedrò i progressiUn link di staging, un aggiornamento settimanale, una bacheca condivisa. Qualsiasi risposta va bene; nessuna risposta non va bene.
• Cosa succede dopo il lancioFinestra per i bug, termini di supporto, documentazione. Concorda questo prima di iniziare, non quando qualcosa si rompe.
• Chi possiede il codiceChiedi direttamente. La risposta dovrebbe essere tu, alla consegna, per iscritto, inclusa tutto il necessario per eseguirlo.

Testa prima di impegnarti

L'assicurazione più economica disponibile per un acquirente è un piccolo lavoro retribuito prima di uno grande. Non una prova non retribuita, che i buoni freelancer rifiutano e che non ti dice nulla su come si comporta una persona quando ci sono soldi di mezzo — un compito reale, piccolo, retribuito.

Un buon compito di prova è rappresentativo, autonomo e completabile in una seduta: correggere un bug specifico, rendere una pagina responsiva, aggiungere un modulo e collegarlo, migliorare una pagina lenta. Ciò che stai realmente valutando non è il codice. È se hanno fatto una domanda chiarificatrice prima di iniziare, se hanno consegnato ciò che è stato chiesto piuttosto che ciò che preferivano, se hanno spiegato cosa hanno fatto e se la tempistica che hanno dato è stata la tempistica che hai ottenuto.

Su Zinn Hub il formato naturale è un Micro Zinn — un compito a prezzo fisso a $5, $10, $15 o $20. Sfoglia correzioni di bug e piccoli compiti di codice o correzioni e modifiche di bug di siti web, o inizia da un prezzo con $20 Micro Zinns. La nostra guida su come testare un freelancer prima di impegnarsi copre come strutturare e giudicare il test.

Costo e modalità di pagamento

I prezzi di sviluppo variano più di qualsiasi altra categoria freelance, perché il lavoro varia di più. Quelli che seguono sono fasce di mercato tipiche per l'intero lavoro, non prezzi di Zinn Hub, e ogni freelancer stabilisce i propri.

• Piccolo compito

  Meno di $200

  Una correzione di bug, un conflitto di plugin, un modulo, un passaggio di velocità, una piccola funzionalità su una build esistente. Meglio acquistato come compito a prezzo fisso.

• Costruzione standard

  $500–$2,000

  Un sito o negozio basato su piattaforma: configurazione del tema, diversi modelli di pagina, moduli, integrazioni di base, lancio.

• Avanzato

  $2,000–$8,000

  Funzionalità personalizzate, account e accessi, pagamenti, integrazioni di terze parti o un design su misura implementato da zero.

• Applicazione

  $8,000+

  Un vero prodotto software: sistemi multi-ruolo, dashboard, app mobili, qualsiasi cosa con una logica di back-end significativa e ingegneria continua.

I costi variano in base all'ambito, alla complessità e all'esperienza. Utilizza le fasce per verificare la congruità di un preventivo piuttosto che come tariffario — se un numero si trova a due fasce di distanza da dove dovrebbe essere il tuo brief, quel divario è la conversazione che vale la pena avere.

Su Zinn Hub, ogni Zinn ha un prezzo stabilito dal suo Zinner, gli acquirenti non pagano alcuna commissione di piattaforma e tutti i prezzi sono in USD con un equivalente approssimativo mostrato nella tua valuta. Un ordine viene pagato e protetto come un unico importo totale; non ci sono rilasci a tappe o per milestone, quindi una costruzione a fasi viene effettuata come ordini separati o concordata come fasi separate con prezzo nel tuo brief di progetto. Scegli uno Zinner protetto dalla piattaforma e il tuo pagamento sarà trattenuto da Zinn Hub fino al completamento dell'ordine; qualsiasi rimborso viene accreditato sul tuo Zinn Wallet per intero, in USD. Gli Zinners che collegano il proprio account PayPal o Stripe vengono pagati direttamente al momento del checkout.

Proprietà, accesso e consegna

Questa è la sezione che gli acquirenti saltano e in seguito rimpiangono. Concorda tutto per iscritto prima che il lavoro inizi, perché dopo la consegna non hai più alcuna leva.

• Account a tuo nome. Dominio, hosting e qualsiasi servizio di terze parti dovrebbero essere registrati a te, con lo sviluppatore aggiunto come utente. Mai il contrario.
• Proprietà del codice alla consegna. Dichiara chiaramente che al pagamento finale il lavoro è tuo da usare, modificare e portare altrove. Chiedi informazioni su eventuali componenti di terze parti con le proprie licenze.
• Accesso al repository. Anche se non lo apri mai, devi essere in grado di darlo al prossimo sviluppatore.
• Credenziali, tutte. Accessi amministrativi, chiavi API, accesso al database, accesso alla distribuzione — trasferiti e confermati funzionanti prima del pagamento finale.
• Documentazione. Una breve nota scritta su come distribuire, dove si trovano le cose e cosa fare se si rompe. Una pagina è sufficiente; niente non lo è.
• Una finestra per i bug. Un periodo definito dopo il lancio in cui i difetti genuini vengono corretti senza costi aggiuntivi. Trenta giorni è una richiesta comune e ragionevole.

I termini di copyright e licenza variano a seconda del paese e del contratto, quindi considera questo come una guida generale piuttosto che un consiglio legale e ottieni una consulenza professionale su qualsiasi cosa commercialmente significativa.

Errori che affondano i progetti di sviluppo

• Assumere prima che esista il brief. Ogni ora spesa a specificare ne salva diverse nella costruzione e nella rielaborazione. Nient'altro in questa lista è così importante.
• Scegliere solo in base al prezzo. Il preventivo più basso è spesso quello che ha capito meno, e la differenza emerge come richieste di modifica.
• Aggiungere l'ambito in silenzio. Le piccole richieste durante una costruzione sono il modo in cui i prezzi fissi diventano controversie. Raggruppale, prezzale, decidi su di esse.
• Nessun ambiente di staging. Revisionare il lavoro solo quando è live è il modo in cui un sito rotto viene scoperto dai clienti invece che da te.
• Saltare il controllo mobile. La maggior parte dei tuoi visitatori è su un telefono. Non approvare nulla che non hai aperto su uno.
• Lasciare la consegna alla fine. Il momento per concordare l'accesso e la proprietà è prima del primo commit, non durante l'ultima fattura.
• Nessun piano di manutenzione. Il software si deteriora. Prevedi un budget per aggiornamenti, backup e sicurezza dal primo giorno, o paga per un salvataggio in seguito.
• Ignorare i segnali di avvertimento. Risposte vaghe, piccole scadenze mancate e pressioni per pagare al di fuori della piattaforma sono tutte trattate nella nostra guida alle truffe comuni dei freelance.

Se stai ancora decidendo se un freelance sia la strada giusta, freelance vs agenzia confronta onestamente i due per la costruzione di una piccola impresa.