“Feature anmodning!!!”
det er ofte det kampråb, vi programmører bruger til at bagatellisere, hvor presserende en kundes problem er. Når alt kommer til alt er der ikke tid til at tilføje nye funktioner, når vi kigger ud på den uendelige buglog, der står over for os.
for amerikanske programmelingeniører er forskellen mellem en fejl og en funktionsanmodning krystalklar. En fejl er en uoverensstemmelse mellem, hvordan kode faktisk fungerer, og hvordan vores kode var beregnet til at fungere. En funktionsanmodning kræver ny kode for at tilfredsstille en sag, der ikke kan håndteres af den aktuelle kodebase.
denne form for tankeproces fører os altid til det mere generelle spørgsmål om, hvordan programmer som DoneDone skal bruges. Skal din organisation bruge en type program til at logge fejl, en anden type program til at styre kommende opgaver og endnu en type program til at spore funktionsanmodninger?
vi bruger en masse mental energi på at prøve at Sile gennem problemer, der er logget af en klient eller kunde, forsøger at afgøre, om vi kaster et problem i “bug” – spanden eller “funktionsanmodning” – spanden. For konsulentarbejde, når vi arbejder ud af en foruddefineret aftale om, hvordan programmer skal opføre sig, giver det mening. Feature anmodninger kan kræve en ekstra afgift.
men når det kommer til bare den rene praksis med at opbygge gode programmer, især hvis vi arbejder på vores egne produkter, hvor meget skal vi bekymre os om at kategorisere et problem på denne måde?
vi lader tekniske (og tekniske) komme i vejen for at løse problemer.
Robert Martin (alias Onkel Bob) taler meget om programmer. Han betragter Internettet kun som en leveringsmekanisme og intet mere. Det er ikke slutbrugeroplevelsen, og det er ikke formålet med programmet. Det er simpelthen en lille smule dum detalje. Men når vi programmører programmerer, er arkitekturen i vores applikationer for helt påvirket af, at det er en internetapplikation.
på samme måde, hvad nu hvis vi betragtede det udtryk, vi bruger til “en ting, der skal gøres” for at være en dum detalje?
set fra den person, der logger den “ting”, betyder det virkelig noget for hende, at hun anmoder om en ny funktion versus at opdage en fejl? Hun vil bare have sit problem løst af et andet menneske, og helst, at vide, hvornår hendes problem kan løses.
du kan muligvis se det tekniske mere tydeligt, hvis vi forlader programmelverdenen. Når blikkenslager kommer ind for at ordne det utætte brusebad, jeg kan forestille mig, at du ikke er ligeglad med detaljerne. Hvis brusehovedet var forkert installeret (bug), eller hvis pakningen er brudt (bug), eller hvis teflon-tape manglede i et billigt rør (funktion), er alt hvad du holder af, hvor lang tid det tager at ordne, og hvor meget du bliver opkrævet.
fejl eller anmodning? Det er begge dele. Og det er lige meget.
i sidste uge er vi Mammoth released Kin, et HR-værktøj til små virksomheder. Kin giver dig en enkel måde at spore hver medarbejders fri anmodninger. En ting, Kin ikke gør lige nu, er at skelne fridage og helligdage fra arbejdsdage. Så hvis du ønskede at tage en hel uge under Thanksgiving, skal du manuelt indtaste det antal timer, du anmoder om.
holdet har allerede modtaget et par anmodninger om at få Kin til at udføre denne sporing automatisk. Faktisk er det i frigivelseskøen. Men når det er logget, uanset hvor det er logget ind, skal Kin-teamet betragte det som en fejl, en funktionsanmodning, en opgave eller en opgave?
opkald til min indre Onkel Bob, mit svar er simpelt: det betyder ikke noget, hvordan du klassificerer anmodningen. Det er bare en dum detalje.
det er ikke at sige, at vi slet ikke bør klassificere det. Kin-teamet kan mærke problemet under” funktionsanmodning ” og arbejde på at løse mere kritiske problemer først (som en bruger med et autorisationsproblem). Det er fint og dandy, og en gyldig tilgang.
det ville dog være en fejl at automatisk antage alle ting-vi-call-feature-anmodninger er mindre presserende end alle ting-vi-call-bugs. Det gør den ret mindre detalje om, hvordan vi klassificerer problemet, midtpunktet for, når vi løser det. Det burde ikke være sådan. I sidste ende er alle disse anmodninger simpelthen ting, der skal løses.
lad det tekniske være den dumme detalje
til dette formål er etiketten, vi giver til alle disse anmodninger, stort set uvigtig. Hvad der betyder mere er, at nogen tager sig af dem, og der er en generel ide om, hvornår disse anmodninger vil blive behandlet. Hvad der betyder mere er, at 33% flere brugere vil drage fordel af punkt A, der adresseres i forhold til punkt B. Uanset hvilken type ting punkt A eller punkt B er, er punkt A en mere værdifuld at adressere. Sådan. Ikke andet.
så næste gang du bruger for meget tid på at kategorisere opgaver, bugs, funktionsanmodninger og gøremål, skal du huske at glemme teknikkerne. Det er bare de dumme detaljer.
Tilmeld dig en DoneDone-konto på 30 sekunder. Vil du læse mere af Ka Cheung? Den nye bog om den moderne programmør, udviklerens kode, er tilgængelig i e-bog og print. Du kan følge ham på kvidre @developerscode.