Optimalizace schůzek technického designu pomocí strukturovaných šablon vstupenek

Když jsem v roce 2020 dostal práci ve Wayfair, byl jsem nadšený, že jsem se mohl připojit k štíhlému, špinavému týmu, který udržoval b2b nástroj, který přinesl obrovské množství obchodů. Přicházel jsem z role, kde jsem pracoval převážně v sile, takže jsem byl obzvlášť nadšený, že jsem znovu součástí vývojového týmu. Velmi rychle jsem však zjistil, že velká část týmu měla tolik zkušeností s nástroji, které jsme používali, že měli předem daný předpoklad, že ostatní vývojáři mají stejné zázemí, zkušenosti a znalosti jako oni. Hlavním problémem bylo, že nástroje, na kterých jsme pracovali, byly interní a proprietární, takže je mnoho novějších vývojářů neznalo tak dobře jako ostřílení vývojáři. Teď to není problém obecně. To se však stalo velmi problematickým, když byly lístky Jira vytvořeny, upřednostněny, odhadnuty a přiřazeny s několika detaily. Jistě, název vysvětloval obecný problém a ostřílený vývojář, který jej napsal, pravděpodobně přesně věděl, kde začít hledat změny, ale ti z nás, kteří byli na platformách noví, měli jen velmi málo na čem stavět, aby mohli začít. To způsobilo obrovské díry v efektivitě, kdy jsme neustále pronásledovali více informací od zkušenějších vývojářů.

Dalším vedlejším produktem tohoto nastavení bylo, že naše schůzky týkající se technického designu měly tendenci se protahovat, protože stále více z nás mělo dotazy ohledně lístků, které byly předloženy k odhadu. V konverzaci se neustále zjišťovaly podrobnosti, ale žádné nebyly zaznamenány. Tyto schůzky se protahovaly a po přidělení lístku se znovu objevily stejné otázky (pokud si nabyvatel nemohl magicky vzpomenout na rozhovor před týdny, kde byly otázky původně položeny).

Tento pracovní postup byl neuvěřitelně frustrující a neefektivní. Ale, je tu naděje! Krátce poté, co jsme tento problém rozpoznali a diskutovali o něm, začaly schůzky probíhat hladce, zabraly méně času a měly větší dopad. Vstupenky byly bohaté na detaily a snadno se s nimi pracovalo, testovalo a kompletovalo. Zde je návod, jak jsme to udělali.

Problém: Nepřipravené vstupenky a zdlouhavá jednání

Naše schůzky v oblasti technického designu byly často vykolejeny kvůli lístkům, které postrádaly dostatečné podrobnosti. Vývojáři, návrháři a další zúčastněné strany by strávili příliš mnoho času hledáním dalších informací nebo objasňováním nejasných aspektů úkolu. To nejen prodloužilo naše schůzky, ale také zdrželo vývoj, protože přidělené vstupenky se často vracely, což vyžadovalo více objasnění, než mohla práce pokračovat.

Skvělým příkladem toho může být lístek, který nahlásil vývojář s působností a který jednoduše uvedl: „Musíme opravit ceny podlahových skusů.“

Je zřejmé, že bez dostatečného množství základních informací nemůžete udělat absolutně nic, když obdržíte tuto vstupenku. Jaký je problém s cenotvorbou na podlaze? Co se očekává, že se stane? Záleží na množství KU v košíku? Existuje mnoho otevřených otázek a opravdu neexistuje způsob, jak začít pracovat, aniž byste skočili na schůzku. Lepší popis lístku by mohl být.

"Podlahové skusy mají hromadné ceny a náš systém nezpracovává správně kalkulaci ceny/množství, když množství v košíku překračuje limity pro hromadné ceny."

Stále zde není dost podrobností, ale alespoň to správně vysvětluje problém.

Nebudu tento příklad unavovat, ale vývojáři by museli všechny tyto podrobnosti doplnit opakovanými otázkami, rozhovory a prezentacemi, dokud bychom neměli dost podrobností k odhadu nebo práci na tiketu, v závislosti na aktuálním úkol. To vedlo ke spoustě ztraceného času, který jsme jako vývojáři nemohli získat zpět.

Řešení: Implementace šablon lístků

Abychom tento problém vyřešili, vyvinuli jsme sadu strukturovaných šablon tiketů přizpůsobených typu prováděné práce. Tyto šablony zajistily, že každý lístek – ať už hlášení o chybě, změna designu, požadavek na funkci nebo optimalizační úkol – obsahoval všechny potřebné informace předtím, než byl projednán nebo přidělen. Pravidlo bylo jednoduché: pokud šablona nebyla zcela dokončena, lístek nebyl připraven pro schůzku nebo pro vývoj.

Hlášení chyb

Změny designu

Požadavky na funkce

Optimalizační úkoly

Vliv šablon

Výsledky byly okamžité.

Rychle jsme viděli, že bychom mohli projít asi 3x více vstupenek během jediné hodinové schůzky o technickém designu, než jsme mohli předtím. Také diskuse, které jsme na těchto setkáních vedli, byly přínosnější a působivější. Dali jsme si čas na to, abychom upozornili na okrajové případy, ovlivněné týmy a potenciální překážky nebo překážky v procesu, připravovali vývojáře na práci, místo abychom trávili veškerý čas snahou o získání dalších podrobností. Vnutili jsme se také vzoru, kdy jsme veškerou tuto zpětnou vazbu zaznamenávali do tiketu buď do popisu nebo do komentářů. Šablony byly neustálou připomínkou toho, že tyto detaily jsou důležité a že musí být přítomné a snadno k nalezení. Tyto šablony svým způsobem přeškolily naše mozky, abychom k těmto lístkům zaujali přístup založený na dokumentaci, což zajistilo, že kdokoli si lístek chytne, ať už jde o začínajícího vývojáře nebo zkušeného inženýra, bude mít dostatek informací k napsání kvalitního kódu. .

Dále jsme si všimli, že naše vývojové cykly byly stručnější, naše odhady byly přesnější a dosahovali jsme kýžené 100% známky dokončení na sprintech mnohem častěji než kdy předtím. Byli jsme schopni vyčistit naši desku téměř důsledně. Nejen, že je to důležité pro firmu, protože dostávali aktualizace, když jsme jim řekli, že je dostanou, ale pro tým to bylo obrovské posílení sebevědomí, protože se neustále dostáváte do pozice úspěchu. Naši akcionáři viděli naši zlepšenou efektivitu a propustnost a získali větší důvěru v náš tým a náš proces. Také si všimli, že náš kód byl kvalitnější, protože jsme mohli strávit více času soustředěním se na aktuální problém.

Od začátku jsme věděli, že nám to jako vývojářům zlepší život, ale neuvědomili jsme si, jak velký pozitivní dopad to bude mít i na naše obchodní partnery.

Klíčové poznatky pro ostatní týmy

Pokud máte pocit, že je váš tým neustále zatěžován nedostatkem informací, možná by stálo za to prozkoumat, zda by pro vás vytvoření strukturovaných šablon tiketů mohlo fungovat. Je důležité upozornit na to, že vývojářům to zabere další čas, než doplní lístky dostatečně podrobně, aby na nich bylo možné jednat. Věřím, že jde o oprávněné náklady a z dlouhodobého hlediska to vede k obrovským úsporám nákladů, protože to ohromně zlepšuje vaše pracovní postupy, ale je důležité upozornit na to, že tyto změny se nedějí jen tak zdarma. Někdo musí věnovat čas výzkumu a sepsání vysoce kvalitního lístku a ten někdo bude pravděpodobně váš vývojový tým.

Jak již bylo řečeno, je snadné vidět, jak obrovská výhra to může být pro tým. Pro začátek bych doporučil několik krátkých kroků.

Nejprve zjistěte, zda skutečně máte problém. Někdy se jeden nebo dva vývojáři potýkají s dokumentací nebo přenosem znalostí, ale to nesvědčí o úplném problému s vašimi lístky. Možná by některé z těchto problémů mohly vyřešit jiné věci, jako je lepší onbaording nebo dokumentace.

Za druhé, pokud zjistíte, že se jedná o rozšířený problém, který je třeba vyřešit, dalším krokem je kategorizovat, jaký typ lístků běžně dostáváte a jaký typ informací je v každém požadován. Zřejmými kandidáty jsou chyby a funkce, ale v závislosti na povaze podnikání vaší společnosti možná máte jiné typy lístků, které neustále proudí vaším systémem a mají různé potřeby. Možná váš tým spravuje kanál ETL a vy potřebujete vědět, jaké vstupy/výstupy mají vliv na související lístky. Možná váš tým vlastní sadu SDK a s tikety, které s ní souvisejí, musí být zacházeno zvláštním/prioritním způsobem a musí zahrnovat, jaké obchodní funkce by mohla změna ovlivnit? Poznejte svůj tým a jeho požadavky, abyste mohli přesně určit, jaké typy šablon jsou vyžadovány.

Poté, jakmile budete mít všechny tyto informace, zapište je na nějaké sdílené místo, ke kterému má přístup každý. Možná se jedná o sdílený dokument nebo wiki stránku, kterou tým spravuje a má k ní přístup, nebo dokonce můžete vytvořit šablony v samotném Jira a donutit lidi, aby je používali. Bez ohledu na to, jaký je váš přístup, musíte získat podporu od týmu a vývojářů, což znamená, že to musí vidět. Toto je jeden z nejdůležitějších kroků, protože tento proces nebude pokračovat, pokud nebudete mít 100% buy-in od kohokoli, kdo bude psát vstupenky. Prezentujte tyto šablony svému týmu, shromažďujte zpětnou vazbu a vysvětlete, jak si myslíte, že tento nový proces ovlivní vás a vaše zainteresované strany. Ujistěte se, že všichni v týmu jsou s novým procesem spokojeni.

Nakonec musíte tyto změny vynutit. Vstupenky předložené bez dostatečných podrobností by měly být okamžitě bez diskuse vhozeny zpět. Je důležité přísně dodržovat pokyny pro šablony, jinak lidé vždy najdou důvody, proč je obejít. „Tento problém je příliš kritický, nemám čas to sepisovat“ je běžná stížnost, kterou bychom dostávali. Když však budete přísní na potřebu šablony a budete pracovat s lidmi, kteří se to snaží obejít, nakonec si je získáte.

Na Wayfair jsme viděli masivní zlepšení procesů našeho týmu i morálky provedením malých změn uvedených výše. Doufám, že to pomůže i vašemu týmu.