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   Popis:  Stručný, ale podrobný popis problému   Očekávané chování:  Podrobnější vysvětlení, včetně snímků obrazovky nebo odkazů na Figma, jak by věci měly fungovat.   Skutečné chování:  Podrobný popis toho, co se děje a jak se to liší od očekávaného chování   Kroky k obnovení:  Konkrétní, podrobné kroky, jak problém znovu vytvořit. K tomu je třeba přistupovat tak, aby někdo mohl v nástroji otevřít nové anonymní okno a znovu vytvořit problém, aniž by se odchýlil od kroků.   (volitelné) Poznámky pro vývojáře:  Toto je volitelná část, kam můžeme zahrnout navrhované přístupy, pokud již máme dobrou představu o tom, kam by se to mělo ubírat nebo jak by se to mělo rozvíjet. Nechceme vývojáře nutit, aby dělali věci určitým způsobem, ale jakékoli pokyny zde mohou pomoci urychlit realizaci tiketu později.   (volitelné, ale preferované) Vnější dopady:  Zde uvádíme všechny externí zdroje, které mohou ovlivnit tuto práci. Existují týmy, které již vytvořily řešení pro chybu v našem rozhraní API, které bude třeba upozornit, když ji opravíme? Spoléhá tato chyba na jiné týmy/apis/zdroje, pokud jde o informace, které by mohly mít vliv na to, jak dlouho bude trvat její oprava?   (volitelné) Dopad:  Má to známý, měřitelný dopad na tým nebo podnikání? To není vždy známé nebo snadno měřitelné, proto je to volitelné pole. Je však důležité vědět pro stanovení priorit, zda existuje.   Změny designu   Popis:  Stručný, ale podrobný popis problému   Očekávané chování:  Snímky obrazovky nebo odkazy Figma pro očekávané navržené chování.   Skutečné chování:  Snímky obrazovky nebo videa s podrobnostmi o tom, co se skutečně děje, a také popis toho, co se děje a jak se to liší od očekávaného chování   (volitelné) Kroky k opětovnému vytvoření:  Pokud se jedná o specifický prvek uživatelského rozhraní, který se zobrazuje pouze v určitých situacích, musíme přesně vědět, jak/kdy by to mělo být přítomno, abychom věděli, jak naše změny otestovat.   (volitelné) Poznámky pro vývojáře:  Toto je volitelná část, kam můžeme zahrnout navrhované přístupy, pokud již máme dobrou představu o tom, kam by se to mělo ubírat nebo jak by se to mělo rozvíjet. Nechceme vývojáře nutit, aby dělali věci určitým způsobem, ale jakékoli pokyny zde mohou pomoci urychlit realizaci tiketu později.   (volitelné) Dopad:  Má to známý, měřitelný dopad na tým nebo podnikání? To není vždy známé nebo snadno měřitelné, proto je to volitelné pole. Je však důležité vědět pro stanovení priorit, zda existuje.   Požadavky na funkce   Popis:  Kompletní podrobný obrázek o tom, co je funkce. Jak by měl fungovat, jaké jsou očekávané vstupy/výstupy atd. Měli bychom také uvést jakékoli zdůvodnění, proč je zde tato funkce požadována.   Poznámky pro vývojáře:  Vývojář by měl tuto část použít k poskytnutí pokynů ke známým rámcům/vzorům, které by měly být použity, aby hladce zapadly do zbytku naší kódové základny. Nechceme vývojáře nutit, aby psali kód nějakým určitým způsobem, ale jakékoli pokyny zde urychlí provádění tiketu a měly by vést k efektivnější PR konverzaci.   (volitelné, ale preferované) Makety:  Pokud máme příklady užitečného zatížení, snímky obrazovky nebo odkazy na Figma, které by měly vést vývoj, měly by být všechny uvedeny zde.   (volitelné, ale preferované) Vnější dopady:  Zde uvádíme všechny externí zdroje, které mohou ovlivnit tuto práci. Existují týmy, které již vytvořily řešení pro chybějící funkci v našem rozhraní API, které bude třeba upozornit, když ji přidáme? Spoléhá tato funkce na jiné týmy/apis/zdroje ohledně informací, které by mohly mít vliv na to, jak dlouho bude trvat její vytvoření?   (volitelné) Dopad:  Má to známý, měřitelný dopad na tým nebo podnikání? To není vždy známé nebo snadno měřitelné, proto je to volitelné pole. Je však důležité vědět pro stanovení priorit, zda existuje.   Optimalizační úkoly   Popis:  Stručný, ale podrobný popis problému   Aktuální stav:  Podrobnější vysvětlení toho, jak kód aktuálně funguje a proč je neefektivní.   Preferovaný stát:  Podrobný popis toho, co chceme touto optimalizací opravit, jakých cílů se snažíme dosáhnout   Poznámky pro vývojáře:  Toto je návod od vývojáře, který upozorňuje na nutnost optimalizace. To by mělo vyvolat konkrétní soubory a testy, které je třeba upravit, a také konkrétní sekce, o kterých se domníváme, že jsou překážkou ve výkonu nebo způsobují zmatek.    : Testování  Poznámky k tomu, jak lze tuto optimalizaci ověřit nebo ověřit. Potřebujeme nejen vidět, že jsme z tohoto procesu skutečně něco získali (a mohlo by to být něco, čím se můžeme pochlubit), ale také musíme ověřit, že změny neovlivnily žádné známé externí procesy, které se spoléhaly na kód. změněno.   Vnější dopady:  Zde uvádíme všechny externí zdroje, které mohou ovlivnit tuto práci. Spoléhá tato funkce na jiné týmy/apis/zdroje, pokud jde o informace, které by mohly mít vliv na to, jak dlouho trvá její vytvoření nebo testování?   Dopad:  Má to známý, měřitelný dopad na tým nebo podnikání? To není vždy známé nebo snadno měřitelné, ale abychom mohli ospravedlnit refaktor nebo optimalizaci, potřebujeme tyto informace mít.  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ů.    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. Nejprve    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. Za druhé,    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. Poté,    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. Nakonec  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.

Super Career Strategist of 2022

Learn something new with me!

Nominated for Super Career Strategist of 2022

Software Engineer

Tento zvuk je produkován v původním jazyce příběhu!

Příliš dlouho; Číst

Boost your HackerNoon story @ $159.99! 🚀

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

About Author

KOMENTÁŘE

ZAVĚŠIT ZNAČKY

TENTO ČLÁNEK BYL PŘEDSTAVEN V

Related Stories

Coinshift Launches csUSDL, Announces Strategic Partnerships

Coinshift Launches csUSDL, Announces Strategic Partnerships

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps