” funktionsförfrågan!!!”
det är ofta stridsropet vi mjukvaruingenjörer använder för att bagatellisera hur brådskande en kunds problem är. När allt kommer omkring finns det inte tid att lägga till nya funktioner när vi blickar ut på den oändliga buggloggen som står inför oss.
för oss mjukvaruingenjörer är skillnaden mellan en bugg och en funktionsförfrågan kristallklar. Ett fel är en skillnad mellan hur koden faktiskt fungerar och hur vår kod var avsedd att fungera. En funktionsförfrågan kräver ny kod för att uppfylla ett ärende som inte kan hanteras av den aktuella kodbasen.
denna typ av tankeprocess leder oss alltid till den mer allmänna frågan om hur programvara som DoneDone ska användas. Ska din organisation använda en typ av programvara för att logga fel, en annan typ av programvara för att hantera kommande uppgifter och ännu en typ av programvara för att spåra funktionsförfrågningar?
vi spenderar mycket mental energi på att försöka sikta igenom problem som loggas av en klient eller kund och försöker avgöra om vi kastar ett problem i ”bug” – hinken eller ”feature request” – hinken. För konsultarbete, när vi arbetar med ett fördefinierat avtal om hur programvara ska bete sig, är det meningsfullt. Funktionsförfrågningar kan kräva en extra kostnad.
men när det gäller bara den rena praxisen att bygga bra programvara, särskilt om vi arbetar med våra egna produkter, hur mycket ska vi bry oss om att kategorisera ett problem på detta sätt?
vi låter teknikaliteter (och teknik) komma i vägen för att lösa problem.
Robert Martin (aka farbror Bob) pratar mycket om programvara. Han anser att webben bara är en leveransmekanism och inget mer. Det är inte slutanvändarupplevelsen, och det är inte syftet med programvaran. Det är helt enkelt en liten liten dum detalj. Men när vi programmerare programmerar, är arkitekturen i våra applikationer alltför helt påverkad av det faktum att det är en webbapplikation.
på samma sätt, tänk om vi betraktade termen vi använder för ”en sak som behöver göras” för att vara en dum detalj?
ur den synvinkel som personen loggar den ”saken”, spelar det verkligen någon roll för henne att hon begär en ny funktion mot att upptäcka en bugg? Hon vill bara att hennes problem löses av en annan människa, och helst, att veta när hennes problem kan lösas.
du kanske kan se tekniken mer uppenbart om vi lämnar mjukvaruvärlden. När rörmokaren kommer in för att fixa den läckande duschen, skulle jag föreställa mig att du inte bryr dig om detaljerna. Om duschhuvudet var felaktigt installerat (bugg) eller om packningen är trasig (bugg) eller om teflontejp saknades från ett billigt rör (funktion), är allt du bryr dig om hur lång tid det tar att fixa och hur mycket du kommer att debiteras.
fel eller begäran? Det är båda. Och det spelar ingen roll.
förra veckan är vi Mammoth släppt Kin, ett HR-verktyg för småföretag. Kin ger dig ett enkelt sätt att spåra varje anställds ledighet förfrågningar. En sak som Kin inte gör just nu är att skilja helger och helgdagar från arbetsdagar. Så, om du ville ta av en hel vecka under Thanksgiving, måste du manuellt ange hur många timmar du begär av.
teamet har redan fått några förfrågningar om att släkt ska göra denna spårning automatiskt. Det är faktiskt i släppkön. Men när den är inloggad, på vilken plats den är inloggad, bör Kin-teamet betrakta det som en bugg, en funktionsförfrågan, en uppgift eller en att göra?
ringa min inre farbror Bob, mitt svar är enkelt: det spelar ingen roll hur du klassificerar begäran. Det är bara en dum detalj.
det är inte att säga att vi inte borde klassificera det alls. Kin-teamet kan märka problemet under” funktionsförfrågan ” och arbeta med att fixa mer kritiska problem först (som en användare med ett auktoriseringsproblem). Det är bra och dandy, och ett giltigt tillvägagångssätt.
det skulle dock vara ett misstag att automatiskt anta att alla saker-vi-kallar-funktion-förfrågningar är mindre brådskande än alla saker-vi-kallar-buggar. Det gör den ganska små detaljerna om hur vi klassificerar problemet som mittpunkten för när vi löser det. Det borde inte vara så. I slutet av dagen är alla dessa förfrågningar helt enkelt saker som behöver lösas.
låt tekniken vara den dumma detaljerna
för det ändamålet är etiketten vi ger till alla dessa förfrågningar i stor utsträckning obetydlig. Det som är viktigare är att någon tar hand om dem och det finns en allmän uppfattning om när dessa förfrågningar kommer att behandlas. Det som är viktigare är att 33% fler användare kommer att dra nytta av att Artikel a adresseras mot artikel B. oavsett vilken typ av sak A eller artikel B är, Är Artikel a mer värdefull att ta itu med. Det är det. Inget mer.
så nästa gång du spenderar för mycket tid med att kategorisera uppgifter, buggar, funktionsförfrågningar och uppgifter, kom ihåg att glömma tekniken. De är bara dumma detaljer.
registrera dig för ett DoneDone-konto på 30 sekunder. Vill du läsa mer av Ka wai Cheung? Ka Wai nya bok om dagens programmerare, utvecklarens kod, finns i eBook och tryck. Du kan följa honom på Twitter @developerscode.