Duplikaty próśb o funkcje: scalanie bez utraty głosu
5 min czytania
Trzy klientki proszą o tę samą zdolność w trzech różnych tygodniach, sformułowaną na trzy różne sposoby, i proces triażu zbudowany, by wyłapywać duplikaty, robi swoje: grupuje je, liczy jako jedną prośbę z trzema głosami, a backlog zostaje czysty. To łatwa część. Które etykiety się opłacają ujmuje grupowanie według podstawowej zdolności przed triażowaniem według sformułowania jako mechaniczną poprawkę dla duplikatów; czego nie ujmuje, to co dzieje się z samymi słowami, gdy trzy prośby stają się jedną linią, a ta strata zwykle jest większa niż problem liczenia duplikatów, który rozwiązała.
Co faktycznie ginie, gdy duplikaty są scalane?
Konkretne sformułowanie użyte przez każdą proszącą, które jest często bardziej informacyjne niż liczba głosów, w którą się zapada. Jedna klientka może poprosić o “sposób na eksport przefiltrowanych wyników”, inna o “eksport CSV, który respektuje moje zapisane filtry”, a trzecia o “eksport, który nie zawiera ukrytych kolumn”. Wszystkie trzy to ta sama podstawowa prośba, poprawnie zgrupowana, ale każde sformułowanie niesie nieco inny nacisk na to, co jest ważne dla tej osoby, a scalenie, które zachowuje tylko sformułowanie pierwszego zgłoszenia, całkowicie odrzuca pozostałe dwa. Liczba przetrwa; faktura, która pomogłaby komuś zbudować właściwą wersję funkcji, nie.
Dlaczego faktura ma znaczenie, skoro liczba głosów już mówi, że popyt istnieje?
Bo popyt i projekt to różne pytania, i tylko konkretne sformułowanie odpowiada na drugie. Dziesięć głosów na “eksport” mówi zespołowi, że warto zbudować funkcję; nic nie mówi o tym, czy “eksport” oznacza CSV, PDF, zaplanowany email, czy endpoint API, a scalenie, które odrzuca dziewięć z dziesięciu oryginalnych zgłoszeń na rzecz sformułowania pierwszego, może po cichu zawęzić specyfikację do tego, o co przypadkiem poprosiła pierwsza proszącą, nawet jeśli pozostałych dziewięć chciało czegoś subtelnie innego. Co powinna naprawdę rejestrować prośba o funkcję ujmuje dokładnie tę samą lukę od strony przyjmowania; scalanie duplikatów to miejsce, w którym wraca po przyjęciu, dokładnie w punkcie, w którym zespół najbardziej potrzebuje zakresu tego, o co naprawdę poproszono.
Jak wygląda proces scalania, który zachowuje sformułowanie zamiast je odrzucać?
Dodawanie zamiast zastępowania. Kanoniczny element zachowuje jeden tytuł dla widoku backlogu, ale oryginalne sformułowanie każdego scalonego zgłoszenia pozostaje do niego dołączone, albo jako lista cytatów, albo jako połączone tickety źródłowe, więc każdy, kto przejrzy element później, może zobaczyć rzeczywisty zakres tego, o co ludzie prosili, zamiast podsumowania jednej osoby z zespołu. Kosztuje to prawie nic do zbudowania, pole na tickecie zamiast nowego systemu, i to jest różnica między scaleniem, które kompresuje informację, a takim, które kompresuje tylko jej wyświetlanie.
Funkcja: Przefiltrowany eksport CSV
Głosy: 12
Scalone prośby:
- "sposób na eksport przefiltrowanych wyników" (acct_4421)
- "eksport CSV, który respektuje moje zapisane filtry" (acct_8832)
- "eksport, który nie zawiera ukrytych kolumn" (acct_1097)
...Czy każdy duplikat zasługuje na scalenie, czy są fałszywe dopasowania?
Niektóre to fałszywe dopasowania, a traktowanie “brzmi podobnie” jako “to ta sama prośba” to własny tryb awarii. “Pozwólcie mi wyeksportować moje dane” i “pozwólcie mi wyeksportować tylko przefiltrowany widok” mogą zostać zgrupowane przez dopasowanie słowa kluczowego “eksport”, choć faktycznie opisują dwa różne zakresy tej samej ogólnej zdolności; scalenie ich albo zawyża liczbę głosów dla złej rzeczy, albo, gorzej, dostarcza węższą wersję, bo przypadkiem przyszła pierwsza. Ludzkie przejrzenie grupowania, nawet szybkie, wyłapuje to, zanim się nawarstwi; sama automatyczna zgodność podobieństwa nadmiernie scali według słownictwa i niedostatecznie scali według intencji.
Kiedy sprawdzanie duplikatów powinno się właściwie odbywać, przy przyjęciu czy później?
Oba, z różnych powodów. Sprawdzanie przy przyjęciu wyłapuje oczywisty przypadek, nową prośbę, która powtarza coś już otwartego, zanim stanie się własną, nieśledzoną pozycją; wyszukiwanie podobieństwa wśród otwartych próśb w momencie zgłoszenia załatwia większość takich przypadków bez udziału człowieka. Drugie przejście później, w wolniejszym rytmie, wyłapuje przypadek, który przyjęcie pomija: dwie prośby, które użyły na tyle różnego języka, by w tamtym momencie prześlizgnąć się obok dopasowania słów kluczowych albo embeddingów, ale które, gdy zespół zobaczy już tuzin wariantów, okazują się opisywać tę samą leżącą u podstaw zdolność. Pominięcie drugiego przejścia zostawia prawie-duplikaty rozproszone pod osobnymi tytułami bez końca, każdy z własną małą liczbą głosów, która nigdy nie sumuje się do liczby, która sprawiłaby, że funkcja zostałaby zbudowana.
Czy proszącą powinna wiedzieć, że jej zgłoszenie zostało scalone z istniejącym elementem?
Tak, i to ta sama dyscyplina co zamykanie pętli feedbacku klienta zastosowana o krok wcześniej niż zwykle: proszącą, która coś zgłosiła i nigdy więcej o tym nie usłyszała, wnioskuje, że jej prośba donikąd nie doprowadziła, nawet jeśli została poprawnie scalona z elementem z jedenastoma innymi głosami, który ostatecznie został wydany. Krótkie potwierdzenie, “połączyliśmy to z istniejącą prośbą, którą złożyły też inne osoby”, kosztuje jedną wiadomość i zapobiega ponownemu zgłaszaniu tej samej prośby przez klientkę co kilka miesięcy, bo nie ma wglądu w to, czy kiedykolwiek była faktycznie śledzona.
Czy scalanie zmienia, kto dostaje uznanie, gdy funkcja zostaje wydana?
Powinno obejmować wszystkich, nie tylko tego, kto zgłosił pierwszy. Zamykanie pętli
feedbacku ujmuje informowanie proszących, gdy ich prośba
zostaje wydana; dla scalonego elementu oznacza to każde konto dołączone do scalenia, nie tylko
to, którego sformułowanie stało się kanonicznym tytułem, bo z perspektywy każdej proszącej ona o
to poprosiła i to zostało wydane, niezależnie od tego, czyje sformułowanie proces triażu
przypadkiem zachował. W Changeloop oznacza to, że pull request wymienia każde powiązane issue
(Fixes #142, fixes #187); issue, którego nie wymienia, nie dostaje komentarza.
FAQ
Ile sformułowania warto zachować na scaloną prośbę, cytat czy pełny link do ticketu? Krótki cytat zwykle wystarcza w typowym przypadku, bo jego celem jest pozwolić recenzentce zobaczyć zakres sformułowań na pierwszy rzut oka; zachowajcie też pełny link do ticketu, gdy oryginał miał istotny dodatkowy kontekst, jak zrzut ekranu czy szczegółowy opis workflow, który jednolinijkowy cytat by spłaszczył.
Czy zachowywanie sformułowania każdego duplikatu utrudnia skanowanie backlogu? Nie, jeśli jest domyślnie zwinięte. Kanoniczny tytuł to to, co widzi recenzentka skanująca pobieżnie; scalone sformułowanie jest o jedno kliknięcie lub jedno rozwinięcie dalej, obecne dla kogoś robiącego głębsze badania, ale nie zaśmieca widoku dla kogoś, kto tylko liczy głosy.
Co, jeśli dwie prośby wyglądają identycznie, ale po zbudowaniu okazuje się, że chcą różnych rzeczy? Rozdzielcie je z powrotem, gdy tylko stanie się to jasne, i traktujcie oryginalne scalenie jako rozsądną decyzję podjętą z dostępną wtedy informacją, nie jako błąd, którego trzeba unikać powtórzenia. System grupowania, który nigdy niczego nie rozdziela, w końcu będzie miał kilka błędnych scaleń trwale zapieczonych.
Czy istnieje próg głosów, po którym scalona prośba powinna dostać ludzką recenzję leżącego u podstaw sformułowania? Nie ustalona liczba, ale każda prośba zbliżająca się do decyzji o budowie zasługuje na to niezależnie od liczby głosów, bo to punkt, w którym różnica między “eksport” a “eksport jako CSV z zapisanymi filtrami” przestaje być niuansem i zaczyna być specyfikacją.
Twierdzenia techniczne w tym artykule nie zostały niezależnie zweryfikowane. Jeśli coś się nie zgadza, daj nam znać, a poprawimy to.