Optimaliseren van technische ontwerpvergaderingen met gestructureerde ticketsjablonen

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

Ontwerpwijzigingen

Functieverzoeken

Optimalisatietaken

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 eerst 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.

Ten tweede, 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.

Vervolgens, 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.

Ten slotte 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.

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.