Apprezzo il fatto che il team di Discourse sia aperto ai suggerimenti di nuove persone, lì e altrove.
Ho visto questo problema verificarsi spesso su Meta nel corso degli anni, ma questo mi ha spinto a offrire anche i miei pensieri in generale. Mi è anche frustrante vederlo accadere, ma non sapevo davvero come sollevare la questione. Quindi proverò a scriverne ora:
Contesto
A volte su Meta, ho visto una tendenza a criticare i suggerimenti delle nuove persone per funzionalità o modifiche di Discourse. Invece di ascoltare e comprendere l’esperienza di persone più nuove al software – le cui intuizioni possono essere utili anche a noi che usiamo Discourse da oltre 10 anni – a volte le persone della community demoliscono preventivamente l’idea.
Spesso questo accade se un’idea è stata respinta in passato dal team di Discourse, o se un’impostazione predefinita particolare è stata scelta rispetto ad altre configurazioni dal team di Discourse e così via.
Anche se fosse così, vorrei offrire i miei pensieri sul perché non dovremmo respingere preventivamente le idee o i reclami sul software, anche se sono stati discussi in passato.
Il team di Discourse ha l’ultima parola. Molto è cambiato. Le cose di allora potrebbero non valere più ora.
Innanzitutto, noi, come membri della community, non siamo i product manager di Discourse. Se ci affrettiamo a dire a qualcuno che la sua idea è stata respinta in passato e perché, questo potrebbe non riflettere necessariamente le decisioni attuali del team di prodotto di Discourse.
A volte anche il team di Discourse stesso può decidere di lavorare su una funzionalità che in passato era stata scartata. Per molto tempo, la chat è stata una di queste funzionalità.
Quindi non c’è mai una garanzia al 100% che le decisioni passate saranno le stesse di quelle presenti.
Anche le persone del team di Discourse possono avere opinioni diverse tra loro riguardo a ciò che dovrebbe essere una priorità per Discourse.
Ad esempio, ho spesso seguito il blog di @erlend_sh e lui discute di come avesse un’opinione diversa dal resto del team su come la chat dovesse essere in Discourse – enfasi in grassetto mia:
La maggior parte dei progetti open source non ha un forum dedicato, ma quelli che lo hanno quasi certamente hanno anche una chat di gruppo. Il mio ultimo periodo in Discourse è stato un tentativo di unire le due modalità, con l’introduzione di Discourse Chat.
Sono davvero orgoglioso di quell’MVP (che da allora è diventato parte del core), ma la direzione in cui volevo andare da lì era comprensibilmente incompatibile con il DNA del progetto Discourse come forum tradizionale: ho proposto di rendere la chat il leader della nostra esperienza comunitaria. La community inizia nelle chat, ho pensato. Discourse non la pensava così, quindi ci siamo separati amichevolmente.
Anni dopo, la mia posizione rimane invariata. ‘Chat di gruppo’ e ‘forum’ dovrebbero significare più o meno la stessa cosa. Questa è infatti la direzione in cui sembriamo dirigere, poiché Discord, sovrano delle nostre terre comunitarie, ora supporta una varietà di funzionalità di thread e bacheche che si adattano perfettamente al paradigma del forum.
Quindi non spetta a noi decidere prematuramente cosa non dovrebbe essere incluso in Discourse, poiché anche questo può cambiare nel tempo.
Coloro di noi che hanno vissuto i primi giorni di Discourse ricorderanno quando CDCK aveva meno di 10 persone e la gestione del prodotto era spesso molto guidata dai co-fondatori di Discourse. Ma oggi CDCK conta 100 persone e CDCK ha un intero team di prodotto!
Discourse stesso ha una base utenti molto, molto più ampia, le cui esigenze e l’uso del software sono cresciuti oltre i primi adottanti iniziali di Discourse. Più in generale, il panorama delle piattaforme sociali è cambiato (lo slancio si è spostato da Facebook a Discord e altro, ecc.), e le aspettative generali delle persone sono cambiate.
Poiché il team è molto più grande rispetto ai primi giorni di Discourse, ha più capacità di lavorare su altre funzionalità che potrebbero essere state di priorità molto bassa durante i primi giorni di sviluppo del prodotto, negli anni passati.
Quindi, il modo in cui esaminano le richieste di funzionalità ora sarà probabilmente molto diverso rispetto all’inizio. Il team di prodotto avrà il proprio processo decisionale e deciderà cosa verrà effettivamente realizzato e quando.
Più punti dati sono meglio
In secondo luogo, è solitamente utile per il team di Discourse sentire più punti dati piuttosto che meno.
C’era qualcosa vaghemente reso popolare su Meta come Regola del 3 (un minimo di 3 persone che si lamentano di qualcosa prima che la richiesta di funzionalità venga considerata). Anche con questo, devi lasciare che le persone condividano le loro esperienze e si lamentino, per poter ascoltare 3 persone diverse che trovano un problema con qualcosa.
Oltre a ciò, un’altra idea resa popolare è stata lo Sviluppo Guidato dai Reclami. E con questo, devi anche ascoltare le opinioni delle persone:
L’unica cosa che ho mai visto funzionare è scendere in trincea con i tuoi utenti, comunicare con loro e coltivare relazioni.
Dopo aver riletto quello, sostengo anche molto fortemente che la premessa originale dietro quella “regola del 3” NON è che la tua opinione non conti se nessun altro si lamenta.
Il cuore della questione era che (soprattutto se sei un team con poche risorse) trovare le cose di cui le persone si lamentano di più è un modo efficiente per trovare i problemi che infastidiscono di più i tuoi utenti, in modo da risolverli per primi.
Come dice Steve Krug in Don’t Make Me Think:
Troverai sempre più problemi di quanti ne abbia le risorse per risolverli, quindi è molto importante concentrarsi prima sulla risoluzione dei più seri. E tre utenti incontreranno molto probabilmente molti dei problemi più significativi relativi ai compiti che stai testando.
Quindi, solo perché non molte altre persone si sono lamentate della stessa cosa, non significa che non sia importante. Più punti dati sono ancora utili per il team di Discourse quando considera quali sono gli attuali punti dolenti principali/minori per gli utenti.
È possibile apprezzare il feedback delle persone, anche se non lo implementerai
Terzo, è ancora possibile ringraziare per il feedback delle persone, anche se non puoi implementare tutti i loro suggerimenti o se hai deciso di non farlo.
Sono diventato più pratico nel gestire il feedback in questo modo, dopo aver studiato game design dove dare e ricevere feedback era una parte enorme del processo. Su iterazioni di ogni livello di gioco, documento di progettazione o qualsiasi altra cosa, davamo feedback sul lavoro di almeno altre 3 persone e ricevevamo feedback da almeno altre 3. Cercavo di dare feedback per 4 o 5 persone per aiutare a compensare l’assenza di altre persone / la consegna tardiva dei loro compiti, ecc.
Spesso il feedback delle persone è molto perspicace e utile, ma ci sono più di 10 punti importanti e al momento hai tempo solo per implementare 1-3 cose.
Questo è stato anche il caso quando ho lavorato professionalmente come ingegnere del software, interagendo spesso con la community, come parte di una piccola startup. Ci potrebbero essere più di 10 segnalazioni di bug importanti, ma nel prossimo aggiornamento, hai tempo per correggerne 1-3.
In ogni caso, mi sento ancora molto obbligato a ringraziare le persone per le loro osservazioni, ringraziarle per aver condiviso i loro pensieri, ringraziarle per aver dedicato del tempo a scrivere i passaggi per riprodurre un bug e scusarmi per l’inconveniente.
La maggior parte delle volte, gli utenti/giocatori non dicono nulla a meno che non siano davvero infastiditi. Quindi quasi tutti i feedback scritti/richieste di funzionalità/segnalazioni di bug provengono da qualcuno che ha dedicato del tempo a condividere i propri pensieri su qualcosa – cose a cui molti altri potrebbero aver pensato ma che non hanno ancora identificato o detto nulla, cose che probabilmente ti sono sfuggite, e così via.
Quindi, anche se non puoi implementare tutto ciò che tutti dicono – il che potrebbe essere anche il 90% delle volte – non significa che devi affrettarti su tutto quel feedback e respingerlo. Il feedback è ancora importante, anche se non hai le risorse per agire su di esso in questo momento o anche se hai deciso di non agire su di esso.
Comunque, ecco perché penso che valga la pena, per noi come membri della community, lasciare che altre persone più nuove condividano i loro pensieri e non affrettarsi immediatamente a respingere i suggerimenti delle persone per Discourse. Questo perché la posizione del team di Discourse sulle funzionalità può cambiare nel tempo, e il feedback è ancora utile come punti dati per il team di Discourse, anche se potrebbero non implementarlo in questo momento.