Okamžik, kdy váš software jde do ostrého provozu, bývá pocitově jako cílová páska. Měsíce analýzy, návrhu a vývoje jsou za vámi. Systém běží. Podařilo se.
Na co většina majitelů firem není připravena, je to, co přijde potom.
Prvních 90 dní po spuštění není doba odpočinku — je to jedno z nejaktivnějších a nejméně předvídatelných období celého projektu. Pochopení toho, co se v tomto čase typicky děje, a příprava na to může rozhodnout mezi hladkým přechodem a chaotickým.
Dny 1–7: Skuteční uživatelé změní vše
Vývoj a testování probíhají v řízených podmínkách. Testovací prostředí má čistá data, známé scénáře a malý počet uživatelů, kteří vědí, co dělají. Ostrý provoz není nic z toho.
V prvním týdnu začnou vaši skuteční uživatelé pracovat se systémem způsoby, které žádný testovací plán plně nepředvídá. Navigují jinak. Zadávají data v nečekaných formátech. Najdou kombinaci kroků, která způsobí chybu, kterou nikdo při testování neviděl.
To je zcela normální. Neznamená to, že software byl špatně naprogramován — znamená to, že reálné používání je vždy pestřejší, než může zachytit jakákoli sada testovacích scénářů.
Co čekat v prvním týdnu:
- Vlna dotazů od vašeho týmu, bez ohledu na to, jak důkladné bylo školení
- Hrstka drobných chyb nebo okrajových případů, které testování nezachytilo
- Zmatení ohledně toho, kde co najít, zvláště pokud uživatelé přecházejí ze zaběhnutého systému
- Vyšší zátěž podpory než v jakémkoli dalším týdnu
Jak se připravit:
- Před spuštěním určete interního koordinátora — někoho, na koho se tým může obracet s dotazy, aby nešli všichni přímo na tým vývojářů
- Nastavte očekávání svého týmu předem: první týden bude drsný a to se předpokládá
- Mějte jasný, dohodnutý postup pro hlášení problémů: co je urgentní, kdo dostane hlášení a jaká je očekávaná doba reakce
Dny 8–30: Začínají se rýsovat vzorce
Po první vlně chaosu po spuštění se věci začnou uklidňovat. Váš tým si s novým systémem vytvoří rutiny. Počáteční příval otázek podpory klesá, jak si lidé nacházejí cestu.
Právě teď začínají být patrné vzorce ve zpětné vazbě.
Všimnete si, že většina hlášení chyb se soustřeďuje kolem stejných dvou nebo tří pracovních postupů. Začnete vidět, které funkce váš tým používá nejvíce — a které jsou ignorovány nebo obcházeny. Získáte první skutečný přehled o tom, jestli systém věci skutečně zjednodušuje, nebo přidává neočekávané tření.
Na co si dávat pozor:
- Funkce, které nikdo nepoužívá: je to proto, že nefungují, protože uživatelé nebyli proškoleni, nebo proto, že řeší problém, který se ukázal jako neexistující?
- Obcházení: pokud si váš tým vymyslel způsob, jak obejít nějakou funkci, téměř vždy to ukazuje na mezeru mezi navrženým postupem a tím, jak práce skutečně probíhá
- Problémy s kvalitou dat: reální uživatelé často zadávají data způsoby, které odhalí mezery ve validaci — zachycení těchto problémů brzy předchází problémům v budoucnosti
Co dělat:
Veďte průběžný záznam zpětné vazby od svého týmu. Nesnažte se na vše reagovat okamžitě. Vaším cílem v této fázi je nashromáždit dostatek signálů, abyste pochopili, co je důležité, než se rozhodnete, co opravit jako první.
Dny 31–60: Odkrývání skutečného backlogu
V tuto chvíli naléhavost po spuštění opadla. Váš tým je se systémem z velké části spokojený. Kritické chyby jsou opraveny. A začínáte chápat, jak by měl vypadat příští soubor vylepšení.
Je to přirozený okamžik pro strukturovaný rozhovor s vaším vývojovým partnerem o tom, co přijde dál. Ne každá zpětná vazba potřebuje okamžitě jít do vývoje — něco jsou příjemné doplňky, něco je důležité a pár věcí skutečně brání lidem efektivně pracovat.
Jak stanovit priority:
- Co brání vašemu týmu pracovat na plný výkon?
- Co způsobuje ruční obcházení, která přidávají čas do každodenních procesů?
- Co by mělo nejvyšší dopad na lidi, kteří systém používají nejvíce?
Požadavky od lidí, kteří systém používají každý den, bývají cennější než ty od těch, kteří ho používají příležitostně. Dejte větší váhu vzorcům, které vidíte konzistentně, než nejhlasitějším jednotlivým hlasům.
Dny 61–90: První iterace
Pokud vaše vývojová smlouva zahrnuje průběžnou práci — retainer, další vývojovou fázi nebo balíček podpory — je období 60 až 90 dní typicky okamžikem, kdy je připravena naplánovat první smysluplnou post-launch iteraci.
V tuto chvíli máte něco, co jste během původní tvorby neměli: reálná data o používání. Víte, které části systému mají největší provoz, kde uživatelé tápou a jaký je skutečný dopad konkrétních problémů na byznys. Použijte to k lepším rozhodnutím, než jste mohli udělat před spuštěním.
První iterace je také dobrá příležitost pro řešení věcí, které byly záměrně odloženy na později. Většina softwarových projektů zahrnuje kompromisy ohledně toho, co se dostane do prvního vydání a co je odloženo. Teď je čas přezkoumat ty odložené položky ve světle toho, co jste se naučili za prvních 90 dní — některé z nich budou stále důležité a jiné už nebudou mít smysl.
Na co se většina klientů nepřipraví
Kromě praktických otázek existuje emocionální dimenze post-launch období, která mnohé majitele firem překvapí.
Propast. Po vzrušení ze spuštění přichází často pokles nálady. Systém ještě není plynulý, tým se stále učí a přínosy produktivity, které jste očekávali, zatím nejsou viditelné. Tato propast je dočasná a zcela předvídatelná — ale může působit jako důkaz, že investice byla chybou. Není. Je to jen normální adaptační období, než se nový systém stane přirozeným.
Požadavky "jen ještě jednu věc". Jakmile uživatelé systém vidí a mohou s ním pracovat, přicházejí s nápady. Některé z nich jsou výborné. Jiné jsou reakcí na neznámost, která se vyřeší sama, jakmile se lidé cítí pohodlněji. Naučte se rozlišovat mezi oběma, než se zavážete k vývojové práci.
Zátěž podpory. I s dobrou dokumentací a školením bude prvních 30 dní spotřebovávat více interního času na podporu než jakýkoli následující měsíc. Počítejte s tím z hlediska něčího času — nejen peněz — aby byl správný člověk k dispozici a nebyl přetížen.
Co dělá dobrý vývojový partner v tomto období
Pokud máte důvěryhodného vývojového partnera, neměli byste tímto obdobím procházet sami.
Dobrý partner bude monitorovat vaše produkční prostředí na chyby, reagovat na kritické problémy rychle a aktivně se ozývat — ne jen když nahlásíte problém. Pomůže vám oddělit to, co je skutečně potřeba opravit, od toho, co potřebuje trochu více přizpůsobení uživatelů. A začne budovat jasný obraz o tom, čemu by se měla věnovat příští fáze vývoje.
Pokud se v prvních 90 dnech musíte dohánět svého vývojového partnera za odpověďmi, je to signál, který stojí za pozornost pro dlouhodobý vztah.
Pokud se váš software chystá spustit a chcete vědět, na co se připravit — nebo pokud jste již v prvních 90 dnech a věci se zdají chaotičtější, než jste očekávali — ozvěte se nám. Tímto přechodem jsme prošli mnohokrát a rádi vám pomůžeme ho zvládnout.