„To je len chvíľka”
Každý, kto pracuje pri tvorbe alebo údržbe webu, aplikácie či systému, pozná túto vetu.
„Môžete len zmeniť toto tlačidlo?”
„To je naozaj drobná oprava.”
„Prosím, len posuňte tento prvok.”
„Dá sa to spraviť rýchlo?”
„To bude asi 5 minút práce?”
A niekedy to naozaj tak je.
Niekedy zmena farby tlačidla trvá pár minút. Niekedy oprava preklepu vyžaduje jedno kliknutie. Niekedy developer otvorí kód, pozrie sa, zmení jeden riadok a je hotovo.
Problém je v tom, že nie každá zmena, ktorá vyzerá z používateľského pohľadu malá, je malá z pohľadu systému.
A ešte väčší problém nastane, keď takýchto „malých zmien” príde niekoľko, desiatky alebo stovky za mesiac. Vtedy sa začína diať niečo zaujímavé.
Firma môže mať pocit, že vlastne nič veľkého neobjednáva. A zároveň IT tím trávi značnú časť času realizáciou práve týchto drobných úloh.
A tu vyvstáva otázka: Koľko naozaj stojí jedno tlačidlo „Opravte to rýchlo”?
Začnime jednoduchým príkladom
Predstavme si, že marketing posiela softvérovému štúdiu správu:
„Hej, potrebujeme len zmeniť text na tlačidle. Namiesto ‚Prekontrolujte ponuku‘ by malo byť ‚Spoznajte ponuku‘. Je to malá vec, prosím len spravte to rýchlo.”
Znie to banálne. Ale z technického pohľadu to môže vyzerať úplne inak.
Developer musí:
1. Analyzovať požiadavku
Kde sa toto tlačidlo nachádza?
Je iba na jednom mieste?
Vyskytuje sa v niekoľkých verziách stránky?
Je text vložený priamo v kóde?
Je spravovaný cez CMS?
Zmena sa týka desktopovej aj mobilnej verzie?
Je tlačidlo súčasťou komponentu používaného inde?
2. Urobiť zmenu
Zmeniť text.
Prebudovať komponent.
Aktualizovať obsah v CMS.
Alebo upraviť kód.
3. Skontrolovať výsledok
Vyzerá tlačidlo stále správne?
Nevychádza text mimo jeho oblasť?
Funguje to na mobile?
Neovplyvnila zmena iné miesta?
4. Otestovať
Štandardne sa dá na to kliknúť?
Vedie odkaz tam, kam má?
Nevznikla chyba?
5. Nasadiť zmenu
Ak zmena vyžaduje nasadenie, treba ju umiestniť na produkčné prostredie.
A zrazu zistíme, že: „Len zmena textu”
nie nutne znamená: „Len 5 minút práce”.
Koľko môže stáť jedna drobná zmena?
Predpokladajme veľmi konzervatívny scenár.
Developer venuje:
- 15 minút na analýzu,
- 20 minút na implementáciu,
- 15 minút na testy,
- 10 minút na prípravu a nasadenie.
Dokopy: 60 minút práce.
A tu prichádzame k dôležitému bodu. Ak hodinová sadzba tímu je napríklad 200 € bez DPH, jedna zdanlivo drobná zmena stojí približne: 200 € bez DPH.
Ale to ešte nie je všetko. V reálnom procese sa môže objaviť:
- predanie úlohy,
- spresnenie rozsahu,
- otázky klientovi,
- čakanie na odpoveď,
- kontrola výsledku osobou, ktorá požiadavku poslala,
- oprava po feedbacku,
- opätovné nasadenie.
Jedna hodina sa teda veľmi ľahko môže zmeniť na dve. A jedna malá zmena na niekoľko hodín práce celého tímu.
Najdrahšie nie je samotné vykonanie zmeny
Môže sa to zdať paradoxné. Niekedy samotné vykonanie trvá 10 minút. Ale príprava na ňu zaberie ďalších 20. A potom prídu testy, nasadenie, komunikácia a prepnúť kontext.
A práve ten posledný prvok je často najviac podceňovaný.
Context switching - skrytý náklad malých úloh
Developer pracuje na veľkej funkcii. Má otvorený kód. Analyzuje problém. Je sústredený.
Zrazu príde správa: „Hej, len malá vec. Môžeš opraviť tlačidlo?”
Developer preruší prácu. Otvorí požiadavku. Skontroluje stránku. Hľadá miesto v kóde. Urobí zmenu. Testuje. Nasadí. Vracia sa k predchádzajúcej úlohe...
A potom si musí spomenúť: „Na čom som vlastne bol?”
To je práve context switching, teda prepínanie kontextu. A môže byť veľmi nákladné. Nie preto, že každá jednotlivá zmena vyžaduje veľa práce. Pretože každá zmena preruší myšlienkový proces.
Čím zložitejšia úloha, tým väčší náklad návratu k práci. Preto 10 mikro-úloh nie vždy znamená 10 × 10 minút. V praxi to môže znamenať omnoho viac.
Jedno tlačidlo nič; sto tlačidiel už proces
Predpokladajme, že firma pošle technickému tímu:
- 20 drobných zmien mesačne,
- každá trvá priemerne 45 minút.
To dáva: 15 hodín práce mesačne.
Pri sadzbe 200 € bez DPH: 3000 € bez DPH mesačne.
Ročne: 36 000 € bez DPH.
A hovoríme len o 20 drobných úlohách mesačne. Bez veľkých funkcionalít. Bez rozvoja produktu. Bez nových modulov. Bez integrácií. Bez dizajnu.
Len: „zmeňte”, „oprava”, „posuňte”, „pridajte”, „odstráňte”.
A teraz si predstavme organizáciu, v ktorej takýchto úloh je 50 mesačne. Alebo 100.
Škála začína vyzerať úplne inak...
Mikro-úlohy majú ešte jeden náklad — blokujú rozvoj
To je jeden z najdôležitejších prvkov tejto skladačky.
Ak vývojársky tím trávi 20 % času na drobných opravách, nemôže venovať tých 20 % rozvoju produktu. Znie to zrejme. Ale v praxi sa to často nevidí.
Firma sa pýta: „Prečo nová funkcia ešte nie je hotová?”
Developer odpovie: „Lebo sme mali veľa bežných tém.”
„Akých?”
„Opravy, drobné zmeny, aktualizácie, malé úlohy.”
Každá z nich bola malá. Ale spolu vytvorili obrovský blok práce. Je to trochu ako notifikácie v telefóne. Jedna notifikácia neprekáža. Desať už trochu. Sto?... Zrazu zistíme, že celý deň sme strávili reagovaním.
S mikro-úlohami je to podobné.
„Malá úloha” nie je vždy malá
Treba tiež pochopiť, že nie každá zmena je rovnaká. Zmena textu v CMS môže naozaj trvať pár minút.
Ale zmena textu v aplikácii môže vyžadovať:
- nájdenie komponentu,
- úpravu kódu,
- aktualizáciu prekladov,
- testy,
- prebudovanie aplikácie,
- nasadenie.
Zmena jedného poľa môže vyžadovať úpravy:
- front-endu,
- back-endu,
- databázy,
- API.
Zmena jedného prvku v systéme môže ovplyvniť iné prvky.
Preto otázka: „Koľko zaberie zmena tohto tlačidla?” bez znalosti architektúry systému často nemá zmysluplnú odpoveď.
Najprv treba skontrolovať. Až potom možno odhadnúť.
Prečo developer niekedy povie: „Musím to skontrolovať”?
To nie je vyhýbanie sa odpovedi. Často je to znak profesionality.
Dobrý developer by nemal sľubovať: „Jasné, päť minút.”
ak nevie, čo sa skrýva pod povrchom.
Mal by povedať: „Skontrolujem, kde je tento prvok používaný a dám vedieť.”
To môže trvať 10 minút. Ale tých 10 minút môže ušetriť niekoľko hodín problémov. Pretože najdrahšia zmena často nie je tá, ktorá trvá hodinu.
Najdrahšia je tá, ktorá:
- pokazí inú funkciu,
- spôsobí chybu na produkcii,
- vyžaduje nútený rollback,
- generuje ďalšie požiadavky,
- vyžaduje zásah viacerých ľudí.
Preto je analýza pred zmenou súčasťou práce, nie stratou času.
Ako môže klient znížiť náklady mikro-úloh?
Nejde o to prestať posielať malé zmeny. Malé zmeny sú normálnou súčasťou vývoja produktu. Ide o to, riadiť ich efektívne.
1. Zoskupujte drobné úlohy
Namiesto posielania:
„Zmeňte tlačidlo.”
„Ešte opravte nadpis.”
„A pri tom pridajte tento odkaz.”
„A ešte posuňte tento prvok.”
Lepšie ich zoraďte do jedného balíka.
Tím tak môže urobiť viac zmien počas jedného pracovného cyklu.
Menej prepínania kontextu.
Menej komunikácie.
Menej nasadení.
Nižšie náklady.
2. Stanovte priority
Nie všetko je urgentné.
Ak má každá vec status: URGENT
tak vlastne nič nie je naozaj urgentné.
Stojí za to rozdeliť úlohy na:
- kritické,
- dôležité,
- plánované,
- kosmetické.
Vďaka tomu môže tím pracovať efektívnejšie.
3. Zvážte, či potrebujete zmenu v kóde
Ak firma pravidelne mení:
- texty,
- obrázky,
- bannery,
- odkazy,
- oznámenia,
možno problém nie je v rýchlosti developera.
Možno problém je v architektúre.
Ak každá zmena obsahu vyžaduje programátora, stojí za to premýšľať o CMS alebo administračnom paneli.
Dobre navrhnutý systém by mal umožniť biznis tímu spravovať to, čo naozaj nevyžaduje zásah programátora.
Dobrý systém by mal odpovedať na otázku: kto by mal vykonať túto zmenu?
To je veľmi dôležité projektové pravidlo. Nie každá zmena by mala putovať k developerovi.
Ak marketing dokáže sám:
- zmeniť text,
- vymeniť obrázok,
- pridať článok,
- zmeniť poradie sekcií,
nemá zmysel zapájať programátora.
Developer by sa mal venovať tomu, čo vyžaduje jeho zručnosti.
Teda napríklad:
- tvorbe nových funkcií,
- rozvoju systému,
- integráciám,
- optimalizácii,
- bezpečnosti,
- architektúre,
- riešeniu technických problémov.
Inak firma platí programátorovi za prácu, ktorú by mohol urobiť používateľ systému.
Je to trochu ako zamestnať automechanika, aby natankoval auto. Vie to urobiť, ale potrebujeme to naozaj?
Kedy povedať: „Urobme to inak”?
Ak sa tá istá požiadavka objavuje pravidelne, stojí za to sa zastaviť a položiť otázku:
Prečo to musíme zakaždým robiť ručne?
Ak týždenne žiadame o zmenu toho istého prvku, možno by sme mali vytvoriť:
- nastavenie v CMS,
- konfiguráciu,
- admin panel,
- automatizáciu,
- mechanizmus self-service.
Jednorazový náklad na vytvorenie takéhoto riešenia môže byť vyšší. Ale neskôr môže každá ďalšia zmena stáť pár sekúnd namiesto hodiny.
To je rozdiel medzi: platením za každú zmenu a investíciou do systému, ktorý umožní zmeny vykonávať samostatne.
Mikro-úlohy a model spolupráce so softvérovým štúdiom
To je tiež dôležitá téma pre klientov.
Ak spolupráca so softvérovým štúdiom stojí výhradne na modeli: „nahlásime - oceníte - schválime - vykonáte”, každá drobná zmena môže generovať ďalší organizačný overhead.
Preto pri dlhodobej spolupráci často lepšie fungujú:
- balíky hodín,
- abonement na údržbu,
- stály tím,
- backlog úloh,
- pravidelné sprinty,
- stanovené okná nasadzovania.
To neznamená, že každý klient by mal zvoliť rovnaký model. Ide o prispôsobenie spôsobu spolupráce charakteru projektu.
Ak firma potrebuje jednu zmenu mesačne, rozsiahly proces môže byť zbytočný. Ak firma posiela 50 úloh mesačne, chýbajúci proces môže byť veľmi nákladný.
Treba účtovať každú zmenu?
To závisí.
V niektorých projektoch má zmysel presné účtovanie každej minúty. V iných môže generovať viac administratívy než úspor.
Preto stojí za to pozerať sa na spoluprácu šíršie.
Dôležitejšia otázka nie je: „Koľko stála tá jedna zmena?”
Lepšia otázka znie: „Koľko nás stojí spôsob, akým riadime všetky zmeny?”
Ak firma platí 200 € za jednu zmenu, ale vďaka tomu sa vyhne chybám a má istotu, že všetko funguje správne, môže to byť rozumný náklad.
Ak však každý mesiac platí niekoľko tisíc eur za desiatky podobných mikro-úloh, stojí za to zvážiť, či problém nejde vyriešiť systémovo.
Najdrahšie slová v IT?
Možno znejú: „To je len malá zmena.”
Nie preto, že malé zmeny sú zlé. Sú potrebné.
Digitálny produkt žije. Menia sa potreby zákazníkov. Mení sa trh. Mení sa marketing. Mení sa technológia. Zmeny sú prirodzené.
Problém nastane, keď organizácia nevidí ich súhrnný náklad.
Jedna malá zmena? - Nič veľkého.
Desať? - Stále málo.
Sto? - Už je to proces.
A ak takých procesov je niekoľko? Zrazu zistíme, že firma neutratuje peniaze na rozvoj produktu. Trávi ich na neustále opravovanie drobností.
Namiesto počítania tlačidiel, spočítajme čas
Dobre riadený vývoj digitálneho produktu nespočíva v tom, zakazovať klientovi nahlasovať malé zmeny.
Ide o to vedieť:
- ktoré zmeny naozaj vyžadujú programátora,
- ktoré možno urobiť samostatne,
- ktoré stojí za to automatizovať,
- ktoré treba zoskupiť,
- ktoré sú naozaj naliehavé,
- ktoré možno naplánovať,
- ktoré je lepšie vyriešiť systémovo.
Lebo niekedy najlepšia odpoveď na: „Opravte to rýchlo.”
nie je: „Dobre, spravíme.”
Ale: „Zamyslime sa, prečo to budeme musieť o mesiac znovu opravovať.”
Práve tu softvérové štúdio prestáva byť len vykonávateľom úloh. Začína byť technologickým partnerom. Pretože dobrý partner nielen realizuje ďalšie požiadavky.
Tiež pomáha vidieť, že niekedy najlacnejšia zmena nie je tá, ktorú spravíme rýchlejšie. Najlacnejšia je tá, ktorú už nebudeme musieť robiť po stýkrát.
A práve preto jedno tlačidlo „Opravte to rýchlo” môže stáť hodinu.
Ale dobre navrhnutý systém môže zabezpečiť, že ďalších sto takýchto zmien urobíte sami za pár minút.
Nie je to úspora na programátoroch. Je to investícia do lepšieho procesu, lepšej architektúry a múdrejšieho využitia času celého tímu.
