„To je jen chvilka“
Každý, kdo pracuje na vytváření nebo údržbě webu, aplikace nebo systému, zná toto hlášení.
„Můžete jen změnit toto tlačítko?“
„To je opravdu drobná oprava.“
„Prosím, jen posuňte ten prvek.“
„Dá se to udělat rychle?“
„To bude asi 5 minut práce?“
A někdy to opravdu je tak krátké.
Někdy změna barvy tlačítka zabere pár minut. Někdy oprava překlepu vyžaduje jedno kliknutí. Někdy vývojář otevře kód, podívá se, změní jeden řádek a je hotovo.
Problém je v tom, že ne každá změna, která z uživatelského pohledu vypadá malá, je malá z hlediska systému.
A ještě větší problém nastává, když je takových „malých změn“ tucet, desítky nebo stovky za měsíc. Tehdy se začne dít něco zajímavého.
Firma může mít pocit, že vlastně nic velkého neobjednává. A přitom IT tým tráví značnou část času realizací právě těchto drobných úkolů.
A tady vzniká otázka: Kolik opravdu stojí jedno tlačítko „Opravte to rychle“?
Pojďme od jednoduchého příkladu
Představme si, že marketing pošle do software house zprávu:
„Hej, potřebujeme jen změnit text na tlačítku. Místo ‚Zjisti nabídku‘ by mělo být ‚Poznejte nabídku‘. Je to malá věc, prosím udělejte to rychle.“
Zní to banálně. Ale z technického pohledu to může vypadat úplně jinak.
Vývojář musí:
1. Analyzovat požadavek
Kde se to tlačítko nachází?
Je jen na jednom místě?
Vyskytuje se v několika verzích stránky?
Je text zapsaný přímo v kódu?
Řídí se přes CMS?
Týká se změna desktopu i mobilu?
Je tlačítko součástí komponenty používané jinde?
2. Provesti změnu
Změnit text.
Přestavět komponentu.
Aktualizovat obsah v CMS.
Nebo upravit kód.
3. Zkontrolovat výsledek
Vypadá tlačítko pořád správně?
Nevychází text mimo jeho oblast?
Na mobilu vše funguje?
Neovlivnila změna jiné části?
4. Otestovat
Jde na něj kliknout?
Vede odkaz tam, kam má?
Nevyskytla se chyba?
5. Nasadit změnu
Pokud změna vyžaduje deploy, je třeba ji umístit do produkčního prostředí.
A najednou se ukáže, že: „Jen změna textu“
ne nutně znamená: „Jen 5 minut práce“.
Kolik může stát jedna drobná změna?
Předpokládejme velmi konzervativní scénář.
Vývojář věnuje:
- 15 minut analýze,
- 20 minut implementaci,
- 15 minut testům,
- 10 minut přípravě a nasazení.
Celkem: 60 minut práce.
A tady přichází důležitý bod. Pokud hodinová sazba týmu je například 200 Kč bez DPH, jedna zdánlivě drobná změna stojí přibližně: 200 Kč bez DPH.
Ale to není všechno. V reálném procesu se mohou vyskytnout:
- předání úkolu,
- upřesňování rozsahu,
- dotazy na klienta,
- čekání na odpověď,
- kontrola výsledku osobou, která to zadala,
- oprava po feedbacku,
- opětovné nasazení.
Jedna hodina se tak velmi snadno může proměnit ve dvě. A jedna malá změna v několik hodin práce celého týmu.
Nejdražší není samotné provedení změny
To může znít paradoxně. Někdy samotné provedení úkolu zabere 10 minut. Ale příprava trvá dalších 20. A pak přijdou testy, nasazení, komunikace a přepnutí kontextu.
A právě ten poslední prvek je často nejvíc podceňovaný.
Context switching - skrytý náklad malých úkolů
Vývojář pracuje na velké funkci. Má otevřený kód. Analyzuje problém. Je soustředěný.
Najednou přijde zpráva: „Hej, jen malá věc. Můžeš opravit tlačítko?“
Vývojář přeruší práci. Otevře ticket. Zkontroluje stránku. Hledá místo v kódu. Provede změnu. Testuje. Nasadí. Vrátí se k předchozímu úkolu...
A pak si musí vzpomenout: „Na čem jsem to vlastně byl?“
To je právě context switching, tedy přepínání kontextu. A může být velmi nákladné. Ne proto, že každá jednotlivá změna vyžaduje hodně práce, ale proto, že každá změna přeruší myšlenkový proces.
Čím složitější úkol, tím vyšší náklady na návrat zpět. Proto 10 mikroúkolů není vždy 10 × 10 minut. V praxi může znamenat mnohem víc.
Jedno tlačítko nic; sto tlačítek už je proces
Předpokládejme, že firma posílá technickému týmu:
- 20 drobných změn měsíčně,
- každá zabere v průměru 45 minut.
To dává: 15 hodin práce měsíčně.
Při sazbě 200 Kč bez DPH: 3 000 Kč bez DPH měsíčně.
Ročně: 36 000 Kč bez DPH.
A mluvíme jen o 20 drobných úkolech měsíčně. Bez velkých funkcí. Bez rozvoje produktu. Bez nových modulů. Bez integrací. Bez designu.
Jen: „změňte“, „opravte“, „posuňte“, „přidejte“, „odstraňte“.
A teď si představte organizaci, kde je takových úkolů 50 měsíčně. Nebo 100.
Skála začíná vypadat úplně jinak...
Mikroúkoly mají ještě jeden náklad - blokují rozvoj
To je jeden z nejdůležitějších aspektů celé skládanky.
Pokud vývojový tým tráví 20 % času drobnými opravami, nemůže těch 20 % věnovat rozvoji produktu. Zní to samozřejmě. Ale v praxi se to často nevidí.
Firma říká: „Proč nová funkce ještě není hotová?“
Vývojář odpoví: „Protože jsme měli hodně běžných témat.“
„Jakých?“
„Opravy, drobné změny, aktualizace, malé úkoly.“
Každý z nich byl malý. Ale dohromady vytvořily obrovský pracovní blok. Je to trochu jako notifikace v telefonu. Jedno oznámení nevadí. Deset už trochu. Sto?... Najednou zjistíme, že celý den trávíme reagováním.
S mikroúkoly je to podobné.
„Malý úkol“ není vždy malý úkol
Je také důležité pochopit, že ne každá změna je stejná. Změna textu v CMS může skutečně zabrat pár minut.
Ale změna textu v aplikaci může vyžadovat:
- nalezení komponenty,
- úpravu kódu,
- aktualizaci překladů,
- testy,
- přestavbu aplikace,
- nasazení.
Změna jednoho pole může vyžadovat úpravy:
- front-endu,
- back-endu,
- databáze,
- API.
Změna jednoho prvku v systému může ovlivnit jiné prvky.
Proto dotaz: „Kolik zabere změna tohoto tlačítka?“
bez znalosti architektury systému často nemá smysluplnou odpověď.
Nejdřív je potřeba to prověřit. A teprve potom odhadnout.
Proč vývojář občas říká: „Musím to zkontrolovat“?
Není to vyhýbání se odpovědi. Často to je znak profesionality.
Dobrý vývojář by neměl slibovat: „Jasně, pět minut.“
pokud neví, co je pod tímto povrchem.
Měl by říct: „Zkontroluji, kde je ten prvek použitý, a dám vědět.“
To může zabrat 10 minut. Ale těch 10 minut může ušetřit několik hodin problémů. Protože nejnákladnější změna často není ta, která trvá hodinu.
Nejdražší je ta, která:
- poškodí jinou funkci,
- způsobí chybu v produkci,
- vyžaduje okamžitý rollback,
- generuje další reporty,
- vyžaduje zásah více lidí.
Proto je analýza před změnou součástí práce, nikoli ztrátou času.
Jak může klient snížit náklady na mikroúkoly?
Nejde o to, aby přestal posílat malé změny. Malé změny jsou normální součástí vývoje produktu. Jde o to, aby se s nimi dobře nakládalo.
1. Seskupujte drobné úkoly
Místo posílání:
„Změňte tlačítko.“
„Ještě opravte nadpis.“
„A mimochodem přidejte tento odkaz.“
„A ještě posuňte ten prvek.“
Je lepší je shromáždit do jednoho balíku.
Tým pak může provést několik změn během jednoho pracovního cyklu.
Méně přepínání kontextu.
Méně komunikace.
Méně nasazení.
Nižší náklad.
2. Stanovte priority
Ne vše je urgentní.
Pokud má každá věc status:
URGENTNÍ
pak není nic opravdu urgentní.
Stojí za to rozdělit úkoly na:
- kritické,
- důležité,
- plánované,
- kosmetické.
Díky tomu tým může pracovat efektivněji.
3. Zvažte, jestli je změna opravdu v kódu
Pokud firma pravidelně mění:
- texty,
- fotky,
- bannery,
- odkazy,
- sdělení,
možná problém není v rychlosti vývojáře.
Možná je problém v architektuře.
Pokud každá změna obsahu vyžaduje programátora, stojí za to uvažovat o CMS nebo administračním panelu.
Dobře navržený systém by měl umožnit lidem z byznysu spravovat to, co opravdu nevyžaduje zásah vývojáře.
Dobrý systém by měl odpovědět na otázku: kdo by měl provést tuto změnu?
To je velmi důležité designové pravidlo. Ne každá změna by měla putovat k vývojáři.
Pokud marketing může sám:
- změnit text,
- vyměnit fotografii,
- přidat článek,
- změnit pořadí sekcí,
pak nemá smysl zapojovat programátora.
Vývojář by se měl věnovat tomu, co vyžaduje jeho kompetence.
Tedy mimo jiné:
- tvorbě nových funkcí,
- vývoji systému,
- integracím,
- optimalizacím,
- bezpečnosti,
- architektuře,
- řešení technických problémů.
Jinak firma začne platit programátorovi za práci, kterou může provést uživatel systému.
Je to trochu jako najmout automechanika, aby natankoval auto. Umí to, ale opravdu to potřebujeme?
Kdy stojí za to říct: „Uděláme to jinak“?
Pokud se stejná žádost objevuje pravidelně, stojí za to se zastavit a položit si otázku:
Proč to musíme za každý případ dělat ručně?
Pokud každý týden žádáme o změnu téhož prvku, možná bychom měli vytvořit:
- nastavení v CMS,
- konfiguraci,
- admin panel,
- automatizaci,
- self-service mechanizmus.
Jednorázové náklady na vytvoření takového řešení mohou být vyšší. Ale později může každá další změna stát několik sekund místo hodiny.
To je rozdíl mezi: placením za každou změnu a investicí do systému, který umožní změny provádět samostatně.
Mikroúkoly a model spolupráce se software house
To je také důležité téma pro klienty.
Pokud spolupráce se software house stojí pouze na modelu: „hlásíme – naceníte – schválíme – uděláte“, každá drobná změna může generovat další organizační režii.
Proto při pravidelné spolupráci často lépe fungují:
- hodinové balíčky,
- údržbové abonmá,
- stálý tým,
- backlog úkolů,
- pravidelné sprinty,
- stanovená okna nasazení.
To neznamená, že každý klient by měl zvolit stejný model. Jde o přizpůsobení způsobu spolupráce charakteru projektu.
Pokud firma potřebuje jednu změnu měsíčně, rozsáhlý proces může být zbytečný. Pokud posílá 50 úkolů měsíčně, chybějící proces může být velmi nákladný.
Stojí za to účtovat každou změnu?
To záleží.
V některých projektech má smysl přesné účtování každé minuty. V jiných může vést k více administrativě než úsporám.
Proto je dobré dívat se na spolupráci šířeji.
Nejdůležitější otázka není: „Kolik stála tato jedna změna?“
Lepší otázka je: „Kolik nás stojí způsob, jakým spravujeme všechny změny?“
Pokud firma zaplatí 200 Kč za jednu změnu, ale díky tomu se vyhne chybám a má jistotu, že vše funguje správně, může to být rozumný náklad.
Pokud však každý měsíc platí několik tisíc korun za desítky podobných mikroúkolů, stojí za to zvážit, zda problém nejde systémově vyřešit.
Nejdražší slova v IT?
Možná zní: „To je jen malá změna.“
Ne proto, že malé změny jsou špatné. Jsou potřeba.
Digitální produkt žije. Potřeby klientů se mění. Trh se mění. Marketing se mění. Technologie se mění. Změny jsou přirozené.
Problém nastává, když organizace nevidí jejich kumulovaný náklad.
Jedna malá změna? – Nic velkého.
Deset? – Stále málo.
Sto? – Už je to proces.
A pokud je takových procesů několik? Najednou firma neutratí peníze za rozvoj produktu. Utrácí je za neustálé opravy drobností.
Místo počítání tlačítek spočítejme čas
Dobře řízený rozvoj digitálního produktu není o tom, zakazovat klientovi hlásit malé změny.
Je o tom vědět:
- které změny skutečně vyžadují programátora,
- které lze udělat samostatně,
- které stojí za to automatizovat,
- které je třeba seskupovat,
- které jsou opravdu naléhavé,
- které lze naplánovat,
- které je lepší řešit systémově.
Proto někdy nejlepší odpovědí na: „Opravte to rychle.“
není: „Dobře, uděláme to.“
ale: „Zamysleme se, proč to za měsíc zase budeme muset opravovat.“
Právě zde software house přestává být pouze vykonavatelem úkolů. Začíná být technologickým partnerem. Dobrý partner totiž ne jen realizuje další tickety.
Pomáhá také vidět, že někdy nejlevnější změna není ta, kterou uděláme rychleji. Nejlevnější je ta, kterou nebudeme muset dělat znovu stokrát.
A právě proto jedno tlačítko „Opravte to rychle“ může stát hodinu práce.
Ale dobře navržený systém může způsobit, že příštích sto takových změn provedete sami za pár minut.
Nejde o šetření na vývojářích. Je to investice do lepšího procesu, lepší architektury a chytřejšího využití času celého týmu.
