Jak řešit chyby, nevyřízené položky, stanovení priorit a komunikaci s Burndown Frameworkem

Ve dvou předchozích příspěvcích jsem představil, jak jsme vytvořili vlastní rámec pro stavbu produktu v Drift (Burndown) a hovořil jsem o tom, jak můžete implementovat rámec Burndown Framework ve své vlastní společnosti v mém druhém příspěvku.

Nyní je čas mluvit o věcech, které se někdy cítí jako vedlejší, které jsou ve skutečnosti klíčem k tomu, aby všechny tyto věci správně proudily. Ty věci jsou…

  1. Řešení chyb
  2. Zpracování nevyřízených produktů
  3. Volba toho, co má být stanoveno jako další
  4. Týdenní kadence plně transparentních aktualizací

1 - Řešení chyb

Věříme, že chyby by měl být zcela ve vlastnictví technického týmu. Githubovy problémy jsou tedy místem, kde žijí. Když se objeví chyby, může kdokoli v týmu vytvořit problém s Githubem. Pokud jde o chybu nahlášenou zákazníkem, přidáme jí v Githubu červený štítek „Bug“ a pošleme odkaz na konverzaci, kde byla nahlášena. Tyto chyby upřednostňujeme před ostatními.

Obecně platí, že utrácíme asi 20% našeho času za řešení chyb a dalších 80% za nové funkce, práci s infrastrukturou a vylepšení stávajících funkcí.

Jako povrch bugů záleží na uvážení inženýra, který vyžaduje okamžitou pozornost a který může chvíli vydržet. Proto je štítek „Bug“ v Githubu tak důležitý, protože zvyšuje viditelnost a naléhavost skutečnosti, že se to děje pro platícího zákazníka, což by mohlo mít za následek churn, pokud je chyba kritická.

Zatímco jsme implementovali Burndown, prvních pár měsíců, jednou týdně, se produktový manažer v každém týmu posadil s technologickým vedením a procházel nevyřízenými chybami v úložišti Githubu, které jejich tým vlastní. Tímto způsobem se mohli PM a inženýři vyrovnat tomu, co bylo nejdůležitější, proč, a naučit se důvěřovat si navzájem v čase.

Vzhledem k tomu, že Burndownské zásady a rámec se staly více součástí kultury, a protože premiér by důvěřoval technikům, aby uskutečňovali stejná volání, jaké by chtěli, nebylo toto týdenní setkání nutné. Nyní, na začátku každého týdne (obvykle o víkendu), technický vedoucí a inženýři projdou problémy s Githubem a vyberou si nejdůležitější nejdůležitější chyby, které plánují v tomto týdnu řešit.

Vzhledem k tomu, že Burndown nepracuje v náročných týdenních cyklech, jsou neustále zaváděny chyby, které vyžadují, abychom zastavili to, co děláme, a okamžitě se vypořádali s tím, abychom zajistili, že jim ponecháme další kapacitu, abychom je mohli zvládnout, jakmile přijdou. lze na nich pracovat paralelně.

2 - Správa nevyřízených produktů

Nyní by vás mohlo zajímat ... co děláte s nevyřízeným počtem nevyřešených nápadů na 4, 6 a 12 měsíců? Kde jsou všechny tyto informace a jsou uspořádány?

V závislosti na velikosti vašeho nevyřízeného záznamu se může deska Trello, kterou používáte k implementaci rámce Burndown, začít odlamovat od příliš mnoha seznamů na pravé straně desky, což je zcela v pořádku. To se nám stalo. Takže jsme se vyvinuli.

Nyní používáme desku hlavního produktu Trello pouze jako místo, kde jsme zaměřili a dokumentovali mikrotisky, které se ve skutečnosti zvládnou. Pokud tam něco bylo déle než měsíc a neustále se tlačí a nikdy se nedělá, znamená to, že to není nejvyšší priorita a pravděpodobně nikdy nebude. Takže tento seznam archivujeme.

Rámec Burndown je navržen tak, aby vás soustředil na to, co je v krátkodobém a krátkodobém horizontu kolem věcí s nejvyšší pákou, které můžete dělat. Všechno, co bylo navrženo a stanoveno na 3 a více měsíců, pokud nejste větší, extrémně strukturovanou organizací, se v době, kdy toho času dosáhnete, často dramaticky změní. Měli jsme designéra v jednom z našich týmů dostat 3 + měsíc dopředu týmu a nakonec většina z toho, co navrhla nikdy se to na světlo dne, protože jsme se rychle dozvěděli, že chceme, aby se věci jiným směrem. A to je v pořádku. To je to, co se přihlašujeme k používání Burndownu. Nejhorším scénářem by bylo pokračovat v provádění těchto návrhů jednoduše proto, že již byly hotové. Vzhledem k tomu, že Burndown je ze své podstaty flexibilní, umožnilo nám to snadno říci ne a vydat se jiným směrem, který měl více slibné.

Pokud jste jako já a zaměřujete se na vývoj zákazníků, stále potřebujete místo, kde můžete uspořádat veškerou zpětnou vazbu od zákazníků, kterou získáte každý týden a denně. Navrhl bych buď vytvořit jinou desku Trello, která bude držet všechny tyto myšlenky a kousky zpětné vazby, nebo neustále rozšiřovat šířku desky Trello donekonečna tak dlouho, dokud jdete skrz a odzkoušejte ji každých pár týdnů a archivujte věci, které nejsou zarovnáno s místem, kam produkt směřuje.

3 - Volba toho, co má být upřednostněno dále

Nejlepším způsobem, jak zjistit, jaké další nejdůležitější seznam je řešit, je položit si otázku ...

"Co je jedna věc, která poskytuje našim zákazníkům největší hodnotu a je v souladu s našimi obchodními cíli a zaměřením?"

Odpověď na tuto otázku by vám měla poskytnout věc, která vám v dlouhodobém horizontu poskytne maximální využití, abyste mohli svým zákazníkům přidávat hodnotu. Otázka je odvozena z otázky, kterou Gary Keller klade ve své knize The One Thing, což je „Co mohu udělat hned teď, abych všechno ostatní usnadnil nebo zbytečně?“ Jsme velcí fanoušci této filozofie na Drift, protože věříme, že nám pomáhá soustředit se na správné věci.

Také tematicky strukturujeme nadcházející priority společnosti, které jsme vložili do jednoho snímku nebo seznamu a opakujeme je znovu a znovu týmu. V našem případě by seznam příkladů vypadal asi takto ...

  1. Udržování produktu stabilní
  2. Řízení dalších registrací
  3. Zvýšení míry aktivace
  4. Inovace našeho widgetu pro chat

To nám všem poskytuje vodítko k odkazování, když se ptáme sami sebe, na co bychom se mohli dále soustředit. Pokud nemůžete udělat něco, co přímo prospívá # 1, pak pracujte na něčem, co má dopad na # 2 atd.

4 - Týdenní kadence plně transparentních aktualizací

Vzhledem k tomu, že rámec Burndownu se neustále mění, protože mikrosparty uvnitř se neustále vyvíjejí, aby odpovídaly potřebám, přáním a touhám zákazníka, je důležité zajistit, aby tým byl na dobré cestě a měl milníky, které musí zasáhnout.

Zde je návod, jak zůstat v souladu s prioritami v pátek v Drift, produktový manažer se posadí s technologickým vedením každého týmu a promluví prostřednictvím nadcházejících mikrospinů na desce Trello po dobu přibližně 5–10 minut. Někdy je jasné, co je další nejdůležitější věc a jsme okamžitě na stejné stránce. Jindy se v rozhovoru objeví dobré body a mikrosparty / seznamy se trochu posunou a dohodnou se jako zaměření na nadcházející týden.

Každý nedělní večer pak produktový manažer píše interní wiki příspěvek s taktickým rozpisem, jehož seznamy z Trello se zaměří na tento nadcházející týden a na jakou hodnotu přinesou zákazníkovi. Obvykle to trvá 1–2 hodiny, ale stojí za to 100% udržet tým ve vyrovnanosti, když se objeví příští ráno. Pokud se to povede správně, jedná se o jediný projektový management, který by produktový manažer musel každý týden dělat.

Tento příspěvek má čtyři části (každá rozdělena do sekcí pro každý tým produktů)…

  1. Oznámení, které pošleme zákazníkům v pátek, pokud jsme odeslali vše, co plánujeme odeslat
  2. Vizuální / screenshoty (z karet HIGH LEVEL v Trello), co bude dodáno
  3. Přehled toho, na co se každý technik a designér zaměřuje
  4. Seznam toho, co bylo odesláno z předchozího týdne

V horní části tohoto interního příspěvku (číslo 1 v seznamu) je písemné prohlášení zaměřené na zákazníky Drift. Toto prohlášení je psáno, jako by to byl pátek na konci týdne; je to přesně to, co bychom na konci týdne oznámili našim zákazníkům, pokud dokončíme všechny mikrosparty, které jsme plánovali řešit. Zde je příklad jednoho pro tým webových aplikací ...

Poté, pro část # 2, jsem prostě upustil screenshoty ze všech funkcí, seskupené podle týmu. Obvykle tomu dávám rychlý název a přetáhnu celou screenshot, jako je tento ...

Pro část 3 jsem sestavil seznam odrážek pro každého inženýra a designéra. Cílem je být stručný a ukázat všem ve společnosti, na koho se obrátit v průběhu týdne na něco konkrétního. A dokumentovat to, co řekl každý inženýr a designér, jsou jejich priority. Obvykle si na konci každého týdne uděláme rychlou check-in s členy týmu, abych uslyšel, co mají na mysli, a v případě potřeby cokoli upravil. Většinu času by měl mít PM pocit, co každý inženýr a designér dělá z jiných rozhovorů, které se dějí během týdne. Zde je příklad, jak tato třetí část vypadá ...

Část 4 je krátkým seznamem toho, co bylo dodáno a co ještě probíhá. To je na prodejních a úspěchových týmech, aby viděli, co se stalo a co je téměř tam. Vypadá to takto ...

Pamatujte, že během každého týdne mohou existovat 2–4 mikrosparty a věci expedujeme ihned po jejich dokončení. Tyto týdenní check-iny a aktualizace slouží spíše jako způsob, jak zajistit, aby každý měl pocit, jak vypadá pokrok a hmatatelný způsob, jak říct: „Měl jsem produktivní týden“, než se vydají v pátek. Věci zveřejněné v nedělní aktualizaci nejsou „seznamem, které musí být provedeno bez ohledu na to“. Někdy se věci stanou a věci, které jsme plánovali udělat, se již nepracují, protože přišlo něco vyššího priority, které by mohlo lépe ovlivnit naše současné firemní priority / témata.

-

Začínáme experimentovat s novým způsobem komunikace cílů společnosti a produktových priorit, o kterých budu pravděpodobně mluvit v dalším příspěvku.

Prosím, dejte mi vědět, pokud máte nějaké další otázky k Burndown Framework. Věřím, že jsem se zabýval všemi nezbytnými aspekty toho, jak tuto práci provést ve vaší vlastní společnosti, takže dejte mi vědět, pokud máte pocit, že otázky jsou stále nezodpovězeny prostřednictvím komentáře.

S Davidem Cancel jsem také na toto téma napsal úplnou elektronickou knihu. Koukni na to!