Když každý chápe projekt trochu jinak
Klient, designer, vývojář a projektový manažer mohou mluvit o stejném produktu, a přesto si pod ním představovat něco úplně jiného.
Vezměme si zdánlivě jednoduchý nápad: aplikaci pro online objednávky.
Co přesně znamená „online objednávka“? Registrace? Různé typy objednávek? Platba? Notifikace? Historie objednávek? Administrace?
Takové otázky často vyplavou na povrch až ve chvíli, kdy už vývoj začal.
Dobrý projekt proto nezačíná seznamem úkolů. Začíná společným porozuměním produktu.
Před zahájením vývoje by mělo být jasné:
- Jaký problém má produkt řešit?
- Pro koho ho vyvíjíme?
- Jaké jsou jeho klíčové funkce?
- Co patří do první verze?
- Co může počkat na později?
Čím jasněji jsou tyto otázky zodpovězené, tím méně prostoru zůstává pro nedorozumění během vývoje.
„To ještě přidáme během vývoje“
Nové nápady jsou naprosto normální. Často vznikají až ve chvíli, kdy člověk vidí produkt konkrétněji.
Problém nastává, když se nové požadavky jednoduše přidávají k existujícímu projektu bez ohledu na jejich dopad na čas, rozpočet a již vyvinuté funkce.
Zdánlivě malá změna může například znamenat úpravy databáze, backendu, API, oprávnění, designu i testování.
Právě tady vzniká scope creep – projekt postupně narůstá nad svůj původně plánovaný rozsah.
Řešením není změny úplně zakázat. Je potřeba mít jasný proces:
Co se má změnit? Proč? Kolik práce navíc to vyžaduje? Jaký bude dopad na harmonogram? A je potřeba kvůli tomu něco jiného z aktuálního rozsahu odstranit?
Projekt tak zůstává flexibilní, aniž by každý nový nápad automaticky narušil celý plán.
Nekonečné revize nejsou proces
Design ani funkce se jen málokdy povedou dokonale na první pokus. Zpětná vazba a úpravy jsou přirozenou součástí dobrého vývojového procesu.
Problém nastává ve chvíli, kdy není jasné, kdy je něco skutečně hotové a schválené.
Pokud se již odsouhlasený design po několika týdnech znovu mění, může to ovlivnit vývoj. Pokud se během implementace objeví nové požadavky, může být nutné předělávat práci, která už byla dokončena.
Smysluplný proces může vypadat například takto:
Design → zpětná vazba → úpravy → schválení → vývoj
Nové požadavky, které přijdou po schválení, samozřejmě nezmizí. Přidají se do backlogu a vyhodnotí se samostatně.
Díky tomu je jasné, co patří do aktuálního rozsahu projektu a co už představuje nový požadavek.
Backlog není seznam přání
Backlog by neměl být jen dlouhým seznamem všeho, co by někdy mohlo v aplikaci být.
Dobrý backlog by měl jasně říkat:
- Co je potřeba udělat?
- Proč je to potřeba?
- Jakou to má prioritu?
- Jak poznáme, že je úkol hotový?
- Co může ještě počkat?
Pokud má 80 úkolů současně status „urgentní“, ve výsledku není skutečně prioritní žádný z nich.
Právě u MVP je prioritizace zásadní. Cílem není hned implementovat každou myslitelnou funkci. Cílem je vytvořit nejmenší smysluplnou verzi produktu, se kterou se lze dostat ke skutečným uživatelům a na základě jejich zpětné vazby se dále učit a iterovat.
Když si klient a vývojový tým nerozumí
Jedním z nejdůležitějších úkolů projektového managementu je fungovat jako spojovací článek mezi businessem a technickou stránkou projektu.
Klient nemusí vědět, jaký dopad bude mít nová funkce na API architekturu. Zároveň ale vývojář potřebuje rozumět tomu, proč je daná funkce důležitá pro business.
Projektový manažer by proto měl rozumět oběma stranám a umět pokládat správné otázky.
Nejen: „Co máme udělat?“
Ale také: „Proč to potřebujeme? Jaký je skutečný cíl? Co tato změna znamená pro zbytek produktu?“
Čím lépe tato komunikace funguje, tím méně času se ztratí kvůli nedorozuměním a zbytečné práci.
Status meeting ještě není projektový management
Množství schůzek automaticky neznamená dobrý projektový management.
Pokud každý týden skončí status meeting větou „Podíváme se na to zase příště“, možná nechybí další schůzka, ale rozhodnutí.
Projektový management není jen o zjišťování aktuálního stavu. Znamená odstraňovat blokery, hlídat priority, sledovat závislosti a posouvat důležitá rozhodnutí dopředu.
Cílem není co nejvíce procesů.
Cílem je tolik procesu, kolik je potřeba k tomu, aby se projekt posouval.
Co tedy skutečně funguje?
Neexistuje jediný framework projektového managementu, který by fungoval pro každý projekt aplikace.
Důležitější jsou některé základní principy:
Společné porozumění produktu. Všichni zúčastnění by měli vědět, co se vyvíjí a proč.
Jasné požadavky. Úkoly by měly být dostatečně konkrétní, aby designéři i vývojáři věděli, co se od nich očekává.
Prioritizovaný backlog. Ne všechno může mít současně nejvyšší prioritu.
Jasná definice „hotovo“. Úkol by neměl týdny zůstávat někde mezi „skoro hotovo“ a „ještě to předělejme“.
Strukturovaný proces pro změny. Nové nápady je potřeba vyhodnotit, nikoli je nekontrolovaně přidávat do existujícího rozsahu.
Pravidelná a smysluplná komunikace. Schůzky by měly pomáhat s rozhodováním a posouváním projektu – ne jen plnit kalendář.
Projektový management je součástí produktu
Technologie, design a funkce jsou důležitými součástmi digitálního produktu. Stejně důležitý je ale i způsob, jakým se tyto části propojují.
Projekt může mít skvělé vývojáře, dobrý design i silný produktový nápad, a přesto zbytečně ztrácet čas a rozpočet kvůli nejasným požadavkům, neustálým změnám, chybějícím prioritám nebo nekonečným revizím.
Dobrý projektový management proto neznamená mít všechno pod co největší kontrolou.
Znamená snižovat nejistotu, eliminovat zbytečnou práci a dát týmu prostor soustředit se na samotný produkt.
Protože nakonec nejde o to odškrtnout co nejvíce úkolů.
Jde o to vytvořit správný produkt – a spolehlivě ho dostat až do cíle.