Non esiste una dimensione perfetta per un ciclo di feedback

Più ho redatto questo post, più mi sembrava di dover scrivere un tipo di TL; DR per alcune persone che lo leggono. Quindi, nel tentativo di risparmiare tempo, eccolo qui:

Sto scrivendo questo per coloro che sono nuovi al lavoro autonomo, alla gestione dei progetti o in generale hanno meno esperienza di coloro che chiedono "Perché scrivi questo?" In definitiva, è qualcosa che la maggior parte di noi impara ad un certo punto in questo industria, ma se possiamo aiutarci a vicenda, abbreviare prima o poi, ne traiamo tutti vantaggio.

Se sei ancora interessato dopo aver letto la nota sopra, presumo che tu stia cercando di migliorare questo aspetto della comunicazione. Il che è positivo, perché lo sono anch’io 😏, e l’uso di un piccolo ciclo di feedback è un modo in cui ho scoperto di farlo.

---

Ogni settore ha un po’ del proprio gergo e molti di noi ne ridono, eppure tutti continuiamo a usarlo in un ambiente professionale. Siamo divertenti in questo modo.

Ad ogni modo, nel nostro settore, una delle frasi che usiamo molto – me compreso – è "feedback loop". La prima volta che mi sono imbattuto in questa frase è stato per quanto riguarda il feedback degli amplificatori. Non aveva nulla a che fare con il software. Tuttavia, in quello che facciamo generalmente lo usiamo per riferirci ad esso come:

• inviare una richiesta, un commento o un’informazione generale a un cliente,
• ricevere una risposta dal cliente in merito a tali informazioni.

E per coloro che non sono abituati all’idea (perché c’è chi fa “rilasci big bang" di cui parlerò tra un minuto), i feedback loop sono generalmente considerati piccoli o grandi.

Più a lungo lavoro nel software, più miro sempre a un piccolo ciclo di feedback, qualunque cosa accada.

Il ciclo di feedback perfetto

Un piccolo ciclo di feedback significa che c’è una comunicazione frequente tra un’azienda e il cliente (quindi, naturalmente, un grande ciclo di feedback si ha quando c’è una comunicazione meno frequente).

Se hai intenzione di usare il gergo, almeno pensaci in qualche modo divertente, giusto?

Ma sai tutta quella cosa del gergo che ho menzionato all’inizio dell’articolo? Nella normale conversione, direi solo:

Quando si tratta di lavorare su un progetto, preferisco una comunicazione più frequente.

E il motivo per cui preferisco questo e anche per impostazione predefinita è perché quando si tratta di costruire una soluzione, indipendentemente dalle dimensioni, per qualcun altro, ci sono sempre parti mobili da considerare.

Quando ci sono più parti in un progetto, ci sono più punti in cui qualcosa potrebbe aver bisogno di essere modificato o modificato (o che può avere un impatto sul sistema generale) e farlo bene in anticipo anziché in seguito consente di risparmiare un sacco di tempo (e quindi denaro) e stress per la maggior parte delle parti coinvolte.

E allora?

Perché preoccuparsi di scrivere su questo, però? Per me, il motivo è perché più a lungo gestisco un piccolo negozio, più sento dai clienti i problemi che derivano dalla mancanza di chiarezza, comunicazione e gestione dei progetti nei progetti precedenti.

Peccato. Non voglio eseguire quel tipo di operazione. Quindi è una cosa facile da risolvere, giusto?

Inoltre, l’industria dello sviluppo è piena di persone che prenderanno i requisiti di un progetto, presumeranno di aver compreso tutto ciò che è necessario e poi torneranno solo per aver costruito qualcosa che non solo manca l’obiettivo ma assomigli in qualche modo a quello previsto dal cliente.

Questo non è necessariamente un colpo ai programmatori, ma l’intero "[mancare] l’obiettivo" può essere risolto se comunicassimo semplicemente con coloro con cui stiamo lavorando un po’ più frequentemente che no.

Non dare per scontato di sapere cosa vogliono.

Invece, fai domande, chiarisci il requisito, lavora sulla funzione, quindi presenta al cliente in un ambiente di staging. Sapranno se hai costruito ciò che hanno chiesto. In tal caso, passa alla funzionalità successiva. In caso contrario, c’è più lavoro da fare. Operare in questo modo snellisce gran parte dei punti di tensione che sorgono nei progetti.

E sì, fare molte domande può diventare noioso e persino fastidioso. Grande affare. Ricorda fin dall’inizio che farai molte domande per comprendere appieno il problema prima di provare a risolverlo. Dai una ragione per cui stai facendo quello che stai facendo. Tende a ripagare bene.

Uscite del Big Bang

In precedenza nel post, ho menzionato "rilasci del big bang" e questo generalmente si riferisce all’idea di un cliente che ti fornisce i requisiti, torni a lavorarci per settimane, poi ti mostri e dici "Ehi, io ho finito, dai un’occhiata! solo per scoprire che è lontano.

Se dovessi contestualizzare questo all’interno di un tipo di ciclo di feedback, direi che non ce n’è uno. Non è nemmeno grande perché non è stato richiesto alcun feedback. È semplicemente:

• Ecco i requisiti per il progetto,
• Ho finito con il progetto.

Spesso, questo porta gli sviluppatori a fraintendere i requisiti, i clienti sono all’oscuro dei progressi e il progetto generale va verso il basso. In poche parole, non farlo in questo modo.

La dimensione perfetta?

Non so quale sia la dimensione perfetta di un ciclo di feedback. Ci sono alcuni clienti con cui ho lavorato dove ci sono i check-in giornalieri, ci sono da qualche parte ci sono i check-in settimanali e ci sono alcuni che hanno detto "completa questo e fammi sapere quando hai finito".

I check-in settimanali, i commit, i rilasci, ecc. tendono ad essere i miei preferiti, ma ciò è dovuto alle dimensioni del progetto e alle dimensioni del team con cui lavoro. Anche ogni giorno non è male a seconda dell’attività.

Non faccio mai il big bang anche se un cliente dice che va bene. Mi piace ancora avere posti di blocco per la mia sanità mentale. Quindi, qualunque tipo di ciclo di feedback funzioni meglio per te, il tuo team e il tuo cliente avrà la dimensione perfetta.