Le prime 48 ore con un freelance decidono come finisce il progetto
Hai scelto la persona giusta e il progetto va male lo stesso. Quasi sempre il danno è già fatto nei primi due giorni, e si evita con tre cose che costano mezz'ora.
Il momento in cui i progetti si rovinano non è quello in cui qualcuno sbaglia. È quello, molto prima, in cui nessuno ha detto una cosa che sembrava ovvia.
Chi arriva da fuori non sa niente di come funzionate. Non sa chi decide, non sa quali sono le cose intoccabili, non sa che quel file lo aggiorna solo una persona e che il martedì siete tutti in riunione. Sono informazioni che dentro non si dicono più perché le sanno tutti, e sono esattamente quelle che fanno perdere una settimana.
Il primo giorno: dare il contesto, non i compiti
La riunione di avvio media dura venti minuti e serve a ripetere il brief. È tempo sprecato: il brief lo ha già letto.
Quella utile risponde a domande diverse. Perché fate questo progetto adesso? C'è quasi sempre una ragione che nell'annuncio non era scritta, una scadenza, un concorrente, un problema che è esploso. Saperla cambia le scelte tecniche.
Cosa avete già provato e non ha funzionato? Risparmia il rifacimento di un tentativo già fallito, che succede più spesso di quanto si creda.
Cosa non si può toccare? Un sistema fragile, un fornitore da non scavalcare, un colore aziendale, una persona da coinvolgere sempre. Scriverlo il primo giorno evita la conversazione imbarazzante del quindicesimo.
Una persona sola che risponde
Il modo più efficace per far fallire un progetto è dare al freelance tre interlocutori con opinioni diverse. Passa il tempo a fare da mediatore fra voi, e le decisioni non arrivano mai.
Serve una persona con potere di dire sì. Può raccogliere pareri da chi vuole, ma la risposta arriva da lei sola. Se quella persona è troppo occupata per rispondere in ventiquattro ore, il progetto non è pronto per partire.
Questo vale anche per le revisioni: un giro di commenti raccolti e ordinati batte cinque email scollegate che si contraddicono.
Gli accessi, prima del primo giorno
La causa numero uno di ritardo nella prima settimana è banale: mancano le credenziali. Il pannello, il repository, l'analitica, la casella email di prova, il contatto di chi gestisce il dominio.
Ogni accesso mancante costa mezza giornata: quella in cui viene chiesto, quella in cui qualcuno lo cerca, quella in cui arriva. Preparali prima e il progetto parte davvero il primo giorno invece che il quarto.
Un'avvertenza: le credenziali non si mandano in chat. Usate un gestore di password con condivisione, oppure canali separati per utente e chiave.
Concordare il ritmo, non controllare
Il committente ansioso chiede aggiornamenti a caso e interrompe di continuo. Quello assente sparisce e riappare alla consegna con venti obiezioni. Entrambi fanno danni.
La via di mezzo è un ritmo deciso all'inizio: un aggiornamento scritto ogni tot giorni, breve, con cosa è fatto, cosa è in corso, cosa serve da voi. Venti righe.
Questo formato ha un vantaggio che si vede solo alla fine: lascia una traccia. Quando fra due mesi qualcuno chiederà perché è stata presa quella decisione, la risposta è scritta.
Dire come si misura la fine
"Quando è pronto" non è una definizione. Prima di iniziare deve essere chiaro cosa si guarda per dire che una fase è chiusa: quali schermate, quali funzioni, quali test, chi approva.
Senza quello, la consegna diventa una trattativa, e le trattative fanno perdere tempo a tutti e rovinano il rapporto anche quando il lavoro era buono.
Il conto
Contesto, un solo referente, accessi pronti, ritmo concordato, definizione di finito. Sono cinque cose e chiedono meno di un'ora, una volta.
Il tempo che fanno risparmiare si misura in settimane. E soprattutto cambiano la natura del rapporto: chi lavora bene, messo nelle condizioni giuste, torna volentieri la prossima volta. Chi ha passato il primo mese a inseguire informazioni, no.