Richieste duplicate: unire senza perdere la voce originale
6 min di lettura
Tre clienti chiedono la stessa capacità in tre settimane diverse, formulata in tre modi diversi, e un processo di triage costruito per intercettare i duplicati fa il suo lavoro: li raggruppa, li conta come un’unica richiesta con tre voti, e il backlog resta pulito. Questa è la parte facile. Quali etichette valgono la pena copre il raggruppare per capacità sottostante prima di smistare per formulazione come soluzione meccanica ai duplicati; quello che non copre è cosa succede alle parole stesse quando tre richieste diventano una sola riga, e quella perdita è di solito più grande del problema di conteggio dei duplicati che ha risolto.
Cosa si perde davvero quando i duplicati vengono uniti?
La formulazione specifica usata da ogni richiedente, che spesso è più informativa del conteggio voti in cui collassa. Una cliente potrebbe chiedere “un modo per esportare i risultati filtrati”, un’altra “esportazione CSV che rispetti i miei filtri salvati”, e una terza “esportazione che non includa colonne nascoste”. Tutte e tre sono la stessa richiesta sottostante, raggruppata correttamente, ma ogni formulazione porta un’enfasi leggermente diversa su cosa conta per quella persona, e una fusione che conserva solo la formulazione della prima segnalazione butta via completamente le altre due. Il conteggio sopravvive; la trama che aiuterebbe qualcuno a costruire la versione giusta della funzionalità, no.
Perché la trama conta se il conteggio voti già dice che esiste domanda?
Perché domanda e design sono domande diverse, e solo la formulazione specifica risponde alla seconda. Dieci voti su “esportazione” dice a un team che vale la pena costruire la funzionalità; non dice nulla su se “esportazione” significhi CSV, PDF, un’email programmata o un endpoint API, e una fusione che scarta nove delle dieci segnalazioni originali a favore della formulazione della prima può silenziosamente restringere la specifica a qualunque cosa la prima richiedente abbia chiesto per caso, anche se le altre nove volevano qualcosa di sottilmente diverso. Cosa dovrebbe registrare davvero una richiesta di funzionalità copre proprio questo divario dal lato dell’acquisizione; unire i duplicati è dove riemerge dopo l’acquisizione, proprio nel punto in cui un team ha più bisogno della gamma di ciò che è stato davvero chiesto.
Com’è un processo di fusione che conserva la formulazione invece di scartarla?
Aggiungere invece di sostituire. L’elemento canonico conserva un unico titolo per la vista del backlog, ma la formulazione originale di ogni segnalazione unita resta attaccata ad esso, o come elenco di citazioni o come ticket sorgente collegati, così chiunque riveda l’elemento in seguito può vedere la gamma reale di ciò che le persone hanno chiesto invece del riassunto di una persona del team. Costa quasi niente costruirlo, un campo sul ticket invece di un nuovo sistema, ed è la differenza tra una fusione che comprime informazione e una che comprime solo come viene mostrata.
Funzionalità: Esportazione CSV filtrata
Voti: 12
Richieste unite:
- "un modo per esportare i risultati filtrati" (acct_4421)
- "esportazione CSV che rispetti i miei filtri salvati" (acct_8832)
- "esportazione che non includa colonne nascoste" (acct_1097)
...
Ogni duplicato merita di essere unito, o ci sono corrispondenze false?
Alcune sono corrispondenze false, e trattare “suona simile” come “è la stessa richiesta” è un modo di fallire a sé stante. “Lasciami esportare i miei dati” e “lasciami esportare solo la vista filtrata” possono essere raggruppate da una corrispondenza di parola chiave su “esportare” mentre in realtà descrivono due ambiti diversi della stessa capacità generale; unirle o gonfia il conteggio voti per la cosa sbagliata o, peggio, rilascia la versione più ristretta perché è arrivata prima per caso. Un passaggio umano sul raggruppamento, anche veloce, coglie questo prima che si accumuli; una corrispondenza automatica per similarità da sola unirà troppo per vocabolario e troppo poco per intento.
Quando dovrebbe girare davvero il controllo dei duplicati, all’intake o dopo?
Entrambi, per motivi diversi. Controllare all’intake coglie il caso ovvio, una nuova richiesta che riformula qualcosa già aperto, prima ancora che diventi una voce non tracciata a sé stante; una ricerca per similarità contro le richieste aperte al momento dell’invio gestisce la maggior parte di questi casi senza alcun intervento umano. Un secondo passaggio più avanti, con un ritmo più lento, coglie il caso che l’intake si perde: due richieste che hanno usato un linguaggio abbastanza diverso da sfuggire a una corrispondenza per parola chiave o per embedding al momento, ma che si scoprono, una volta che un team ne ha viste una dozzina di varianti, descrivere la stessa capacità di fondo. Saltare il secondo passaggio lascia i quasi-duplicati sparsi sotto titoli separati a tempo indeterminato, ciascuno con il proprio piccolo conteggio voti che non si somma mai al numero che l’avrebbe fatta costruire.
La richiedente dovrebbe sapere che la sua segnalazione è stata unita a un elemento esistente?
Sì, ed è la stessa disciplina di chiudere il ciclo di feedback del cliente applicata un passo prima del solito: una richiedente che ha inviato qualcosa e non ne sente più parlare conclude che la sua richiesta non è andata da nessuna parte, anche se è stata unita correttamente a un elemento con altri undici voti che alla fine è stato rilasciato. Un breve riconoscimento, “abbiamo combinato questo con una richiesta esistente che anche altri hanno fatto”, costa un messaggio ed evita che una cliente reinvii la stessa richiesta ogni pochi mesi perché non ha visibilità su se sia mai stata effettivamente tracciata.
Unire cambia a chi viene dato credito quando la funzionalità viene rilasciata?
Dovrebbe includere tutti, non solo chi ha inviato per primo. Chiudere il ciclo di
feedback copre l’avvisare le richiedenti quando la loro
richiesta viene rilasciata; per un elemento unito questo significa ogni account collegato alla
fusione, non solo quello la cui formulazione è diventata il titolo canonico, perché dal punto di
vista di ogni richiedente lei ha chiesto questo ed è stato rilasciato, indipendentemente da quale
formulazione un processo di triage abbia scelto di conservare. Con Changeloop significa che la pull
request nomina ogni issue collegato (Fixes #142, fixes #187); un issue che non nomina non riceve
alcun commento.
FAQ
Quanta formulazione vale la pena conservare per richiesta unita, una citazione o un link completo al ticket? Una citazione breve di solito basta per il caso comune, dato che il suo scopo è far vedere a chi revisiona la gamma di formulazioni a colpo d’occhio; conservate anche il link completo al ticket quando l’originale aveva contesto extra significativo, come uno screenshot o una descrizione dettagliata del flusso che una citazione di una riga appiattirebbe.
Conservare la formulazione di ogni duplicato rende il backlog più difficile da scorrere? No, se è collassata di default. Il titolo canonico è ciò che vede chi scorre velocemente; la formulazione unita è a un clic o un’espansione di distanza, presente per chi fa ricerca più approfondita ma senza affollare la vista di chi conta solo i voti.
Cosa succede se due richieste sembrano identiche ma si scoprono volere cose diverse una volta costruite? Separatele di nuovo nel momento in cui diventa chiaro, e trattate la fusione originale come una decisione ragionevole presa con le informazioni disponibili all’epoca, non come un errore da evitare di ripetere. Un sistema di raggruppamento che non separa mai nulla finirà per avere alcune fusioni sbagliate incorporate permanentemente.
C’è una soglia di voti oltre la quale una richiesta unita dovrebbe ricevere una revisione umana della formulazione sottostante? Non un numero fisso, ma qualsiasi richiesta vicina a una decisione di costruzione la merita indipendentemente dal conteggio voti, perché è il punto in cui la differenza tra “esportazione” e “esportazione come CSV con filtri salvati” smette di essere una sfumatura e comincia a essere la specifica.
Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.