” Feature rekest!!!”
het is vaak de strijdkreet die software-ingenieurs gebruiken om de urgentie van het probleem van een klant te bagatelliseren. Immers, er is geen tijd om toe te voegen in nieuwe functies wanneer we staren naar de nooit eindigende bug log die ons geconfronteerd.
voor Amerikaanse Software engineers is het verschil tussen een bug en een feature request glashelder. Een bug is een discrepantie tussen hoe code eigenlijk werkt en hoe onze code bedoeld was om te werken. Een feature request vereist nieuwe code om te voldoen aan een zaak die niet kan worden behandeld door de huidige codebase.
dit soort denkproces leidt ons altijd tot de meer algemene vraag hoe software zoals DoneDone moet worden gebruikt. Moet uw organisatie een Type software gebruiken om bugs te loggen, een ander type software om aankomende taken te beheren, en nog een ander type software om feature requests bij te houden?
We besteden veel mentale energie proberen te ziften door problemen geregistreerd door een klant of klant, proberen om te bepalen of we gooien een probleem in de “bug” emmer of de “feature request” emmer. Voor advieswerk, wanneer we werken uit een vooraf gedefinieerde overeenkomst over hoe software zich moet gedragen, is dit zinvol. Voor Feature requests kan een toeslag nodig zijn.
maar, als het gaat om de pure praktijk van het bouwen van goede software, vooral als we werken aan onze eigen producten, hoeveel moeten we geven over het categoriseren van een probleem op deze manier?
we laten technicities (en tech) in de weg staan om problemen op te lossen.
Robert Martin (alias Uncle Bob) praat veel over software. Hij beschouwt het Web slechts als een aflevermechanisme en niets meer. Het is niet de eindgebruiker ervaring, en het is niet het doel van de software. Het is gewoon een klein Dom detail. Maar als wij programmeurs programmeren, wordt de architectuur van onze applicaties te Volledig beïnvloed door het feit dat het een webapplicatie is.
op dezelfde manier, wat als we de term die we gebruiken voor “a thing that needs to get done” als een dom detail beschouwen?
vanuit het oogpunt van de persoon die dat “ding” registreert, maakt het haar echt uit dat ze een nieuwe functie aanvraagt in plaats van een bug te ontdekken? Ze wil gewoon dat haar probleem wordt opgelost door een ander mens, en bij voorkeur, om te weten wanneer haar probleem kan worden opgelost.
u kunt de techniciteit duidelijker zien als we de softwarewereld verlaten. Als de loodgieter komt om de lekkende douche te repareren, denk ik dat je niet om de details geeft. Als de douchekop verkeerd is geïnstalleerd (bug) of als de pakking is gebroken (bug) of als Teflon tape ontbrak in een goedkope pijp (feature), alles wat je de zorg over is hoe lang het zal duren om te repareren en hoeveel je zal worden opgeladen.
Bug of verzoek? Het is allebei. En, het maakt niet uit.
vorige week zijn we Mammoth vrijgegeven Kin, een HR software tool voor kleine bedrijven. Kin geeft u een eenvoudige manier om elke werknemer time off verzoeken te volgen. Een ding Kin doet niet op dit moment is het onderscheiden van weekends en feestdagen van werkdagen. Dus, als je wilde opstijgen een volledige week tijdens Thanksgiving, je nodig hebt om handmatig het aantal uren dat u vraagt uit te voeren.
het team heeft al enkele verzoeken ontvangen om Kin deze tracking automatisch te laten uitvoeren. In feite staat het in de wachtrij. Maar, wanneer het is aangemeld, op welke plaats het is aangemeld, moet het Kin-team beschouwen het als een bug, een functie verzoek, een taak, of een taak?
mijn innerlijke Oom Bob noemen, mijn antwoord is eenvoudig: het maakt niet uit hoe je het verzoek classificeert. Het is gewoon een dom detail.
dat wil niet zeggen dat we het helemaal niet moeten classificeren. Het Kin-team kan het probleem labelen onder “feature request” en werken aan het oplossen van meer kritieke problemen Eerst (zoals een gebruiker met een autorisatieprobleem). Dat is prima en dandy, en een geldige aanpak.
het zou echter een vergissing zijn om automatisch aan te nemen dat alle dingen-die-we-bellen-feature-verzoeken minder urgent zijn dan alle dingen-die-we-bellen-bugs. Dat maakt het nogal kleine detail van hoe we het probleem classificeren het middelpunt voor wanneer we het oplossen. Zo zou het niet moeten zijn. Uiteindelijk zijn al deze verzoeken gewoon zaken die opgelost moeten worden.
laat de techniciteit het domme detail zijn
daartoe is het label dat we aan al deze verzoeken geven grotendeels onbelangrijk. Wat belangrijker is, is dat iemand ze behandelt en er is een algemeen idee van wanneer deze verzoeken zullen worden behandeld. Wat belangrijker is, is dat 33% meer gebruikers zullen profiteren van punt A wordt aangepakt versus punt B. ongeacht wat voor soort ding punt A of punt B is, punt A is een waardevoller aan te pakken. Dat is het. Niets meer.
dus de volgende keer dat u te veel tijd besteedt aan het categoriseren van taken, bugs, feature requests en taken, vergeet dan de technische details. Het zijn gewoon de domme details.
Meld u aan voor een DoneDone account in 30 seconden. Wil je meer lezen van Ka Wai Cheung? Ka Wai ‘ s nieuwe boek over de moderne programmeur, de code van de ontwikkelaar, is beschikbaar in eBook en print. Je kunt hem volgen op Twitter @developerscode.