Come assumere e dare un brief a uno sviluppatore se non sei tecnico

Assumere uno sviluppatore quando non puoi valutare di persona il codice sembra rischioso, e in effetti lo è, ma non nel modo in cui pensa la maggior parte delle persone. Non serve capire il lavoro tecnico per assumere bene. Serve sapere cosa preparare, quali domande rivelano davvero un buon sviluppatore e come appare una comunicazione sana una volta iniziato il lavoro.

Mi sono trovato dall'altra parte di centinaia di queste conversazioni con i founder, e quelle che vanno bene hanno uno schema in comune. Ecco come prepararti in modo da non andare alla cieca.

Il problema di business: stai giudicando qualcosa che non sai leggere

Un founder non tecnico non può revisionare una pull request né individuare una scelta architetturale traballante. Quindi sei costretto a giudicare uno sviluppatore tramite indicatori indiretti: come comunica, come definisce il perimetro del lavoro, quanto è onesto sui compromessi. La buona notizia è che questi indicatori sono sorprendentemente affidabili. Uno sviluppatore che comunica con chiarezza e definisce il lavoro con attenzione fa quasi sempre un lavoro migliore di uno che dice "sì" a tutto.

Il rischio non è scegliere qualcuno di cui non sai leggere il codice. È scegliere qualcuno che ti dice ciò che vuoi sentirti dire, sparisce per due settimane e riemerge con qualcosa che non centra il punto.

Cosa preparare prima di contattare qualcuno

Non ti serve una specifica tecnica. Ti serve chiarezza sul problema, non sulla soluzione. Prima di contattare chiunque, prova a mettere per iscritto:

• Il problema che stai risolvendo e per chi, in parole semplici.
• La cosa principale che il prodotto deve fare: la funzionalità senza la quale non avrebbe senso.
• Esempi: app o siti che fanno qualcosa di simile, anche solo vagamente.
• I tuoi vincoli: budget indicativo, tempistiche indicative, eventuali scadenze inderogabili.
• Come appare il successo per una prima versione.

Non deve essere perfetto. Mezza pagina chiara sul problema vale più di una vaga lista dei desideri con cinquanta funzionalità, e aiuta un buon sviluppatore a definire il lavoro in modo onesto. (Se sei ancora alla fase dell'idea, come definire il perimetro di un MVP è un utile complemento a questo articolo.)

Segnali positivi e segnali d'allarme

Dopo un certo numero di progetti, i segnali diventano facili da leggere.

Segnali positivi:

• Fanno domande prima di fare un preventivo, soprattutto sul problema, non solo sulle funzionalità.
• Mettono in discussione il perimetro e suggeriscono cosa tagliare per una prima versione.
• Spiegano i compromessi in parole semplici invece di nascondersi dietro il gergo.
• Ti danno tempistiche oneste, incluso ciò che è incerto.

Segnali d'allarme:

• Dicono sì a tutto e fanno un preventivo all'istante senza domande.
• Non sanno spiegare il loro piano senza gergo, o non vogliono farlo.
• Restano in silenzio per lunghi periodi e riemergono con delle sorprese.
• Il prezzo sembra troppo bello per essere vero, il che di solito significa che pagherai due volte.

Come appare una buona comunicazione una volta iniziato il lavoro

Il miglior indicatore del buon esito di un progetto non è la pura abilità tecnica. È la comunicazione. Quello che vuoi vedere è un ritmo costante: aggiornamenti regolari, progressi onesti (incluso ciò che va più lento del previsto), piccoli pezzi di lavoro revisionabili invece di una grande rivelazione finale, e una vera conversazione quando c'è da prendere una decisione.

È esattamente il modo in cui cerco di lavorare: aggiornamenti settimanali chiari, segnalare i blocchi il giorno stesso in cui li vedo e nominare i compromessi invece di nasconderli. Puoi leggere di più su come affronto il lavoro con i clienti. Il punto è che tu, da founder non tecnico, puoi giudicare questo. Non serve leggere il codice per capire se qualcuno ti tiene informato ed è sincero con te.

Un esempio concreto

Molto del mio lavoro arriva da founder che avevano avuto una prima esperienza difficile: uno sviluppatore sparito nel nulla, o un progetto che si era allontanato da ciò di cui avevano davvero bisogno. La soluzione raramente è più genialità tecnica; è una comunicazione più stretta e una definizione onesta del perimetro. Quando io e i founder lavoriamo bene insieme, è perché ci siamo accordati prima sul problema centrale, abbiamo mantenuto breve il ciclo di feedback e abbiamo preso le decisioni apertamente invece di sperare. È la parte su cui hai pieno controllo, che tu sia tecnico o no.

Errori comuni dei founder non tecnici

• Descrivere funzionalità invece del problema, così lo sviluppatore ottimizza per la cosa sbagliata.
• Assumere solo in base al prezzo e pagare due volte quando il lavoro al risparmio va rifatto.
• Saltare le domande perché sembrano troppo tecniche, quando la comunicazione è proprio ciò che puoi giudicare.
• Accettare una grande rivelazione finale invece di progressi piccoli e regolari a cui poter reagire.
• Scambiare la sicurezza per competenza: chi mette in discussione il tuo perimetro spesso ti serve meglio di chi è d'accordo su tutto.

Come lavoro con i founder non tecnici

1. Parto dal problema, non da un elenco di funzionalità, e faccio subito le domande che contano.
2. Definisco il perimetro con onestà, incluso cosa tagliare per una prima versione più snella e veloce.
3. Comunico in parole semplici: compromessi e progressi, senza muri di gergo.
4. Mantengo il ciclo breve con aggiornamenti regolari e lavoro piccolo e revisionabile.
5. Segnalo subito i blocchi, così non ci sono sorprese a fine progetto.

Non dovresti diventare tecnico per far costruire un buon software. Dovresti poterti fidare di chi lo costruisce, e quella fiducia è qualcosa che puoi assolutamente giudicare.

Cerchi uno sviluppatore con cui riesci davvero a comunicare?

Se sei un founder non tecnico e cerchi qualcuno che tratti il tuo progetto come se fosse suo (aggiornamenti chiari, compromessi onesti, nessuna sparizione) è esattamente il mio modo di lavorare.

Leggi qualcosa su come lavoro, guarda cosa ho costruito e contattami per raccontarmi il tuo progetto. Farò le domande giuste prima di iniziare.