Internal Company Test experiment

Tomáš Veselý - podpořen AI
před 2 dny
Minut čtení: 3

Tvoříme obsáhlou knihovnu znalostí o produktovém vývoji jako součást naší mise. Knihovna slouží všem, kteří se snaží zlepšit v rozhodování, primárně v rozhodování o dalším rozvoji produktu. Ať už jsi vynálezce, produktový manažer nebo Chief Product Officer, používání určitých výzkumných metod a experimentů zvyšuje šanci na vytvoření správných produktů a jejich funkcí pro správné publikum (build the right thing for right audience). Dnes si představíme validační metodu Internal Company Testing.

Kdy experiment použít?

Internal company testing se používá ve chvíli, kdy je produkt nebo nová funkce natolik funkční, že ji lze již plně interně využívat, ale ještě není připravená pro zákazníky. Navazuje na fázi, kdy si produkt vyzkoušel sám jeho tvůrce (Test it Yourself), a předchází externímu ověření (Beta Testing).

Funcke nebo produkt je dostatečně stabilní pro každodenní reálnou práci, ne jen pro demo.
Produkt řeší problém, který mají samotné týmy ve firmě, takže ho mohou denně používat.
Je třeba odhalit chyby ve workflow a použitelnosti pod reálnou zátěží dříve, než produkt uvidí externí uživatelé.
Je vhodné sjednotit terminologii v produktu a vybudovat sdílené porozumění produktu před spuštěním v intenrích týmech.

Základní princip experimentu

Princip spočívá v tom, že lidé, kteří produkt staví, ho sami každý den používají k reálné práci dříve než zákazníci. Z běžného používání se strukturovaným sběrem zpětné vazby stává validační signál na intenrích zákaznících.

Vymezit rozsah a cíl. Určit, které funkce se testují, které týmy se zapojí a zda půjde o krátký sprint před vydáním, nebo o dlouhodobější intenrí testování.
Nasadit interní verzi. Doručit předprodukční produkt nebo funkci napříč odděleními (nejen inženýrům), typicky přes feature flags nebo interní distribuci. U fyzických produktů poté daný fyzický produkt.
Zacházet s kolegy jako s uživateli. Připravit onboarding, dokumentaci a podporu, aby používání produktu nestálo jen na zasvěcených jednotlivcích.
Zajistit nízkoprahové kanály pro zpětnou vazbu. Umožnit hlášení problémů přímo v prácei, například vlákně v Slacku, issue tracker nebo vložený widget v produktu. U mobilních zařízení například lze použít zatřepání (anglicky shake) telefonu pro odeslání diagnostických dat.
Sbírat data a metriky. Sledovat počet a závažnost interních hlášení chyb, čas do opravy (anglicky time-to-fix), interní NPS či spokojenost a míru reálného (opakovaného) používání. dobré je také sledovat, zdali týmy používají stejnou temrinologii, jako je v produktu. Signálem pro posun k externímu beta testu je, že jsou uzavřené všechny kritické chyby, produkt dobrovolně každý den používají i netvůrci a interní spokojenost překročí stanovený práh.
Třídit a opravovat. Označit každé hlášení kategorií (použitelnost, výkon, navigace, chybějící funkce), navázat ho na úkol s jasným vlastníkem a opravovat kritické věci jako první.
Identifikace rizik. intenrí zaměstnanci tolerují menší chyby, které reální uživatelé berou jako závažnou chybu. Hrozí také upřednostnění interních workflow před potřebami trhu.

Reálná ukázka experimentu

Odkaz na reálný výzkum: Developing GitLab Duo: How we are dogfooding our AI features

GitLab má zásadu interně používat každou novou funkci dříve, než se dostane k zákazníkům. Před obecnou dostupností (general availability) sady nástrojů s umělou inteligencí GitLab Duo — zejména Code Suggestions a Duo Chat — používaly tyto funkce denně vlastní týmy GitLabu, a to nejen inženýři, ale i produktoví manažeři a techničtí písaři.

Interní používání mělo konkrétní podobu: shrnování merge requestů při code review, formulování a zpřesňování OKR, psaní release notes, generování boilerplate CI/CD konfigurací i testování nových funkcí (například podpory Markdownu v Code Suggestions) ještě před jejich vydáním. Pro vyhodnocení postavil GitLab analytický dashboard „AI Impact", který sleduje adopci — míru přijetí návrhů kódu, využití chatu a celkovou zapojenost uživatelů.

Díky tomu GitLab funkce vyladil a ověřil v reálném provozu dříve, než je nabídl zákazníkům.

Co vše se dá experimentem testovat?

Metoda nejlépe prověří realizovatelnost (feasibility) v reálné práci a pod skutečnou zátěží, tedy chyby, které se ukáží až při každodenním používání aplikace mnoha lidmi.

Realizovatelnost pod reálnou zátěží: ověřuje se, zda produkt obstojí při skutečné každodenní práci; signálem je, že týmy dokončují reálné úkoly přímo v produktu a nevracejí se ke starým nástrojům.
Použitelnost workflow: testuje se, kde tvůrci i kolegové zakopávají v reálných postupech; signálem jsou opakující se třecí body a místa, kde uživatelé odpadávají.
Odhalení chyb a okrajových případů: hledají se funkční defekty při různorodém reálném používání
Srozumitelnost dokumentace a onboardingu: ověřuje se, zda se i netvůrci (podpora, marketing, právní oddělení) dokážou v produktu zorientovat; signálem jsou dotazy a selhání při prvním nastavení u lidí mimo vývojový tým.
Vnitřní desirabilita a sjednocení týmů: sleduje se, zda lidé produkt dobrovolně dál používají; signálem je trvalé opakované používání a rostoucí interní NPS.
Připravenost k vydání: ověřuje se splnění objektivních kritérií pro spuštění; signálem je uzavření všech kritických chyb a dosažení minimální interní spokojenosti.