Toen ik in 2020 bij Wayfair aan de slag ging, was ik enthousiast om me aan te sluiten bij een klein, slordig team dat een b2b-tool onderhield die enorme hoeveelheden zaken genereerde. Ik kwam uit een rol waarin ik voornamelijk in een silo had gewerkt, dus ik was vooral enthousiast om weer deel uit te maken van een ontwikkelteam. Ik ontdekte echter al snel dat een groot deel van het team zoveel expertise had in de tools die we gebruikten dat ze van tevoren hadden aangenomen dat andere ontwikkelaars dezelfde achtergrond, ervaring en kennis hadden als zij. Het grootste probleem was dat de tools waaraan we werkten intern en bedrijfseigen waren, dus veel van de nieuwere ontwikkelaars kenden ze niet zo goed als de doorgewinterde ontwikkelaars. Nu is dit over het algemeen geen probleem. Het werd echter erg problematisch toen Jira-tickets werden gemaakt, geprioriteerd, geschat en toegewezen met weinig details. Natuurlijk, de titel legde het algemene probleem uit en de doorgewinterde ontwikkelaar die het schreef, wist waarschijnlijk precies waar hij moest beginnen met zoeken om wijzigingen aan te brengen, maar degenen onder ons die nieuw waren op de platforms hadden heel weinig om op voort te bouwen om te beginnen. Dit zorgde voor enorme efficiëntieproblemen, omdat we voortdurend de meer ervaren ontwikkelaars om meer informatie moesten vragen. Een ander bijproduct van deze opzet was dat onze technische ontwerpvergaderingen de neiging hadden om te slepen, omdat steeds meer van ons vragen hadden over tickets die werden gepresenteerd voor schatting. Details werden voortdurend uitgelekt in gesprekken, maar er werd niets opgenomen. Deze vergaderingen sleepten zich voort, en dan kwamen dezelfde vragen weer terug zodra het ticket was toegewezen (tenzij de toegewezen persoon zich op magische wijze het gesprek van weken geleden kon herinneren waarin de vragen oorspronkelijk waren gesteld). Deze workflow was ongelooflijk frustrerend en inefficiënt. Maar er is hoop! Kort nadat we dit probleem hadden herkend en besproken, begonnen vergaderingen soepeler te verlopen, minder tijd te kosten en meer impact te hebben. Tickets waren rijk aan details en eenvoudig om op te reageren, te testen en te voltooien. Dit is hoe we het deden. Het probleem: onvoorbereide tickets en lange vergaderingen Onze technische ontwerpvergaderingen werden vaak verstoord door tickets die niet voldoende details bevatten. Ontwikkelaars, ontwerpers en andere belanghebbenden besteedden te veel tijd aan het zoeken naar aanvullende informatie of het verduidelijken van vage aspecten van een taak. Dit verlengde niet alleen onze vergaderingen, maar vertraagde ook de ontwikkeling, omdat toegewezen tickets vaak terugkwamen, waardoor er meer verduidelijking nodig was voordat het werk kon worden voortgezet. Een goed voorbeeld hiervan is een ticket dat werd gerapporteerd door een ervaren ontwikkelaar, waarin simpelweg stond: "We moeten de prijzen voor vloeren-SKU's aanpassen." Het is duidelijk dat u zonder voldoende achtergrondinformatie absoluut niets kunt doen wanneer u dit ticket ontvangt. Wat is het probleem met de prijsstelling van floor sku's? Wat wordt er verwacht? Maakt de hoeveelheid van de sku in de winkelwagen uit? Er zijn veel open vragen en er is echt geen manier om aan het werk te gaan zonder in een vergadering te springen. Een betere ticketbeschrijving zou kunnen zijn. “Floor-sku's hebben bulkprijzen en ons systeem verwerkt de prijs-/hoeveelheidsberekening niet goed wanneer de hoeveelheid in het winkelwagentje de bulkprijsdrempels overschrijdt.” Er staan nog steeds niet genoeg details in, maar het probleem wordt in ieder geval goed uitgelegd. Ik ga het voorbeeld niet vermoeien, maar de ontwikkelaar(s) zouden al deze details moeten uitwerken met herhaalde vragen, gesprekken en presentaties totdat we genoeg details hadden om het ticket te schatten of eraan te werken, afhankelijk van de huidige taak. Dit leidde tot veel verloren tijd die wij, als ontwikkelaars, niet meer terug konden krijgen. De oplossing: ticketsjablonen implementeren Om dit probleem op te lossen, ontwikkelden we een set gestructureerde tickettemplates die waren afgestemd op het type werk dat werd gedaan. Deze templates zorgden ervoor dat elk ticket, of het nu ging om een bugrapport, ontwerpwijziging, feature request of optimalisatietaak, alle benodigde informatie bevatte voordat het werd besproken of toegewezen. De regel was simpel: als de template niet volledig was ingevuld, was het ticket niet klaar voor de vergadering of voor ontwikkeling. Bug-rapporten Beschrijving: Een korte, maar gedetailleerde beschrijving van het probleem Verwacht gedrag: Een meer gedetailleerde uitleg, inclusief screenshots of Figma-referenties, van hoe het zou moeten werken. Werkelijk gedrag: Een gedetailleerde beschrijving van wat er gebeurt en hoe het verschilt van het verwachte gedrag Stappen om te recreëren: Specifieke, gedetailleerde stappen over hoe het probleem opnieuw te creëren. Dit moet zo worden benaderd dat iemand een nieuw incognitovenster in de tool kan openen en het probleem opnieuw kan creëren zonder af te wijken van de stappen. (optioneel) Opmerkingen voor ontwikkelaars: Dit is een optioneel gedeelte waarin we voorgestelde benaderingen kunnen opnemen als we al een goed idee hebben waar dit naartoe moet of hoe het ontwikkeld moet worden. We willen ontwikkelaars niet dwingen om dingen op een bepaalde manier te doen, maar elke leidraad hier kan helpen om de ticketuitvoering later te versnellen. (optioneel maar de voorkeur) Externe effecten: Hier noemen we externe bronnen die van invloed kunnen zijn op dit werk. Zijn er teams die al een tijdelijke oplossing hebben gemaakt voor een bug in onze API die op de hoogte moeten worden gesteld wanneer we deze oplossen? Is deze bug afhankelijk van andere teams/API's/bronnen voor informatie die mogelijk van invloed kan zijn op hoe lang het duurt om dit op te lossen? (optioneel) Impact: Heeft dit een bekende, meetbare impact op het team of bedrijf? Dit is niet altijd bekend of makkelijk te meten, daarom is het een optioneel veld. Maar het is belangrijk om te weten voor prioritering als het bestaat. Ontwerpwijzigingen Beschrijving: Een korte, maar gedetailleerde beschrijving van het probleem Verwacht gedrag: Schermafbeeldingen of Figma-links voor het verwachte, ontworpen gedrag. Werkelijk gedrag: Schermafbeeldingen of video's waarin gedetailleerd wordt weergegeven wat er daadwerkelijk gebeurt, evenals een beschrijving van wat er gebeurt en hoe dit verschilt van het verwachte gedrag (optioneel) Stappen om opnieuw te maken: Als dit een specifiek UI-element is dat alleen in bepaalde situaties wordt weergegeven, moeten we precies weten hoe/wanneer dit aanwezig moet zijn, zodat we weten hoe we onze wijzigingen kunnen testen. (optioneel) Opmerkingen voor ontwikkelaars: Dit is een optioneel gedeelte waarin we voorgestelde benaderingen kunnen opnemen als we al een goed idee hebben waar dit naartoe moet of hoe het ontwikkeld moet worden. We willen ontwikkelaars niet dwingen om dingen op een bepaalde manier te doen, maar elke leidraad hier kan helpen om de ticketuitvoering later te versnellen. (optioneel) Impact: Heeft dit een bekende, meetbare impact op het team of bedrijf? Dit is niet altijd bekend of makkelijk te meten, daarom is het een optioneel veld. Maar het is belangrijk om te weten voor prioritering als het bestaat. Functieverzoeken Beschrijving: Een compleet gedetailleerd beeld van wat de feature is. Hoe het zou moeten functioneren, wat de verwachte inputs/outputs zijn, etc. We zouden ook elke redenering moeten opnemen die we hebben voor waarom deze feature hier wordt aangevraagd. Opmerkingen voor ontwikkelaars: De ontwikkelaar moet deze sectie gebruiken om richtlijnen te geven over bekende frameworks/patronen die gebruikt moeten worden om naadloos in de rest van onze codebase te passen. We willen de ontwikkelaars niet dwingen om code op een bepaalde manier te schrijven, maar elke richtlijn hier zal de ticketuitvoering sneller maken en zou moeten leiden tot meer gestroomlijnde PR-gesprekken. (optioneel maar wel gewenst) Mockups: Als we voorbeeldpayloads, screenshots of Figma-referenties hebben die als leidraad voor de ontwikkeling kunnen dienen, moeten deze hier worden opgenomen. (optioneel maar de voorkeur) Externe effecten: Hier noemen we externe bronnen die van invloed kunnen zijn op dit werk. Zijn er teams die al een tijdelijke oplossing hebben gemaakt voor een ontbrekende functie in onze API die op de hoogte moeten worden gesteld wanneer we deze toevoegen? Is deze functie afhankelijk van andere teams/API's/bronnen voor informatie die mogelijk van invloed kan zijn op de tijd die nodig is om deze te bouwen? (optioneel) Impact: Heeft dit een bekende, meetbare impact op het team of bedrijf? Dit is niet altijd bekend of makkelijk te meten, daarom is het een optioneel veld. Maar het is belangrijk om te weten voor prioritering als het bestaat. Optimalisatietaken Beschrijving: Een korte, maar gedetailleerde beschrijving van het probleem Huidige status: Een meer gedetailleerde uitleg over hoe de code momenteel werkt en waarom deze inefficiënt is. Gewenste staat: Een gedetailleerde beschrijving van wat we met deze optimalisatie willen oplossen, welke doelen we willen bereiken Opmerkingen voor ontwikkelaars: Dit is een handleiding van de ontwikkelaar die de noodzaak van optimalisaties benadrukt. Dit zou specifieke bestanden en tests moeten benoemen die bewerkt moeten worden, evenals de specifieke secties waarvan wij denken dat ze de bottleneck in performance zijn of verwarring veroorzaken. : Testen Opmerkingen over hoe deze optimalisatie gevalideerd of geverifieerd kan worden. We moeten niet alleen zien dat we daadwerkelijk iets uit dit proces hebben gehaald (en dat we er misschien over kunnen opscheppen), maar we moeten ook verifiëren dat de wijzigingen geen invloed hadden op bekende externe processen die afhankelijk waren van de gewijzigde code. Externe effecten: Hier noemen we externe bronnen die van invloed kunnen zijn op dit werk. Is deze functie afhankelijk van andere teams/api's/bronnen voor informatie die mogelijk van invloed kan zijn op hoe lang het duurt om dit te bouwen of testen? Invloed: Heeft dit een bekende, meetbare impact op het team of bedrijf? Dit is niet altijd bekend of makkelijk te meten, maar om een refactoring of optimalisatie te rechtvaardigen, hebben we deze informatie nodig. De impact van sjablonen De resultaten waren onmiddellijk merkbaar. We zagen al snel dat we ongeveer 3x meer tickets konden verwerken in een enkele technische ontwerpvergadering van een uur dan voorheen. Ook waren de discussies die we in deze vergaderingen hadden nuttiger en hadden ze meer impact. We namen de tijd om edge-cases, getroffen teams en potentiële showstoppers of knelpunten in het proces te benoemen, en bereidden devs voor op het werk in plaats van al onze tijd te besteden aan het proberen te achterhalen van meer details. We dwongen onszelf ook tot een patroon waarbij we al deze feedback in het ticket vastlegden, hetzij in de beschrijving of opmerkingen. De sjablonen waren een constante herinnering dat deze details belangrijk waren en dat ze aanwezig en gemakkelijk te vinden moesten zijn. Op een manier trainden deze sjablonen onze hersenen opnieuw om een documentatie-eerst-benadering te hanteren voor deze tickets, waardoor we ervoor zorgden dat degene die het ticket pakte, of het nu een junior developer of doorgewinterde engineer was, genoeg informatie zou hebben om hoogwaardige code te schrijven. Vervolgens merkten we dat onze ontwikkelingscycli bondiger waren, onze schattingen nauwkeuriger en we bereikten de felbegeerde 100% voltooiingsgrens op sprints veel vaker dan ooit tevoren. We konden ons bord bijna consistent leegmaken. Het is niet alleen belangrijk voor het bedrijf omdat ze updates ontvingen toen we ze vertelden dat ze die zouden ontvangen, maar het was ook een enorme vertrouwensbooster voor het team, omdat je jezelf voortdurend in een positie van succes plaatst. Onze stakeholders zagen onze verbeterde efficiëntie en doorvoer en kregen meer vertrouwen in ons team en ons proces. Ze merkten ook dat onze code van hogere kwaliteit was, omdat we meer tijd konden besteden aan het daadwerkelijke probleem. We wisten vanaf het begin dat dit ons leven als ontwikkelaars zou verbeteren, maar we realiseerden ons niet hoeveel positieve impact het ook op onze zakenpartners zou hebben. Belangrijkste punten voor andere teams Als je het gevoel hebt dat je team constant wordt belast door een gebrek aan informatie, kan het de moeite waard zijn om te onderzoeken of het maken van gestructureerde ticketsjablonen voor jou zou kunnen werken. Het is belangrijk om te benadrukken dat dit extra ontwikkelaarstijd kost om de tickets uit te werken met voldoende details om actie op te ondernemen. Ik geloof dat dit een gerechtvaardigde kostenpost is en dat het op de lange termijn tot enorme kostenbesparingen leidt, omdat het je workflows enorm verbetert, maar het is belangrijk om te benadrukken dat deze wijzigingen niet zomaar gratis gebeuren. Iemand moet tijd besteden aan het doen van onderzoek en het schrijven van een ticket van hoge kwaliteit en die iemand is waarschijnlijk je ontwikkelingsteam. Dat gezegd hebbende, is het makkelijk te zien hoe groot een overwinning dit voor een team kan zijn. Om te beginnen zou ik een paar korte stappen aanraden. Beoordeel of u echt een probleem hebt. Soms worstelen een of twee ontwikkelaars met documentatie of kennisoverdracht, maar dat is geen indicatie voor een grootschalig probleem met uw tickets. Misschien kunnen andere dingen, zoals betere onboarding of documentatie, een aantal van die problemen oplossen. eerst als u merkt dat dit een wijdverbreid probleem is dat opgelost moet worden, is de volgende stap om te categoriseren wat voor soort tickets u normaal krijgt en wat voor soort informatie vereist is in elk. De voor de hand liggende kandidaten zijn bugs en features, maar afhankelijk van de aard van de activiteiten van uw bedrijf, heeft u misschien andere soorten tickets die constant door uw systeem stromen en andere behoeften hebben. Misschien beheert uw team een ETL-pijplijn en moet u weten welke invoer/uitvoer wordt beïnvloed door tickets die daarmee verband houden. Misschien heeft uw team een SDK en moeten de tickets die daarmee verband houden op een speciale/prioritaire manier worden afgehandeld en moet u opnemen welke bedrijfsfuncties mogelijk worden beïnvloed door een wijziging? Ken uw team en hun vereisten, zodat u precies kunt bepalen welke soorten sjablonen vereist zijn. Ten tweede, zodra je al deze informatie hebt, schrijf je het ergens op waar iedereen toegang toe heeft. Misschien is dit een gedeeld document, of een wikipagina die het team beheert en waartoe het toegang heeft, of misschien kun je zelfs sjablonen maken in Jira zelf, waardoor mensen gedwongen worden om ze te gebruiken. Wat je aanpak ook is, je moet buy-in krijgen van het team en de ontwikkelaars, wat betekent dat ze het moeten kunnen zien. Dit is een van de belangrijkste stappen, want dit proces gaat niet verder tenzij je 100% buy-in hebt van iedereen die tickets gaat schrijven. Presenteer deze sjablonen aan je team, verzamel feedback, leg uit hoe je denkt dat dit nieuwe proces jou en je stakeholders zal beïnvloeden. Zorg ervoor dat iedereen in het team zich op zijn gemak voelt bij het nieuwe proces. Vervolgens, moet u deze wijzigingen afdwingen. Tickets die zonder voldoende details worden gepresenteerd, moeten onmiddellijk worden teruggegooid zonder discussie. Het is belangrijk om strikt te zijn in het volgen van de templaterichtlijnen, anders zullen mensen altijd redenen vinden om het te omzeilen. "Dit probleem is te kritiek, ik heb geen tijd om het op te schrijven" is een veelgehoorde klacht die we zouden ontvangen. Echter, door strikt te zijn met de noodzaak van een template en samen te werken met mensen die proberen het te omzeilen, zult u ze uiteindelijk overtuigen. Ten slotte Bij Wayfair zagen we enorme verbeteringen in het proces van ons team en in het moreel door de kleine veranderingen die hierboven staan. Ik hoop dat dit ook jouw team helpt.
