Lekce 9 - Deset neúspěšných příběhů běžné IT firmy - 6.-10. příběh

V minulé lekci, Deset neúspěšných příběhů běžné IT firmy - 1.-5. příběh, jsme si uvedli příklady z praxe běžné IT firmy, které vedou k zadělání si na problém. Konkrétně jsme se zaměřili na prvních pět příběhů.

V dnešní lekci budeme pokračovat ve fail příbězích z praxe běžné IT firmy, aneb jak si bezpečně zadělat na průser. Příběhy a jejich poslání nám předal Eduard Hlava, kterému jsme už věnovali pozornost v lekci Deset neúspěšných příběhů běžné IT firmy - 1.-5. příběh. V tomto článku se nyní zaměříme na 6.-10. příběh. Tyto příběhy mají spojitost nebo dopad na klienta. A stejně jako prvních pět, tyto příběhy se skutečně staly. Nebo mohly stát.

Příběh 6 - Když je klient potížista - I s prudičema je třeba spolupracovat

Šestý Edův příběh poukazuje na to, že je někdy spolupráce s klientem opravdu náročná, a proto je dobré mít nastavená pravidla.

Příklad z praxe

Představte si firmu, kde je třeba 5 - 7 lidí. Každý měsíc z firmy musí odejít několik set tisíc korun na platy lidí. Bez ohledu na to, jestli něco dělají nebo ne, musíte je zaplatit. A teď se u každého klienta, u každé nové zakázky rozhodujete, jestli ten projekt budete dělat, nebo nebudete.

Tlak zodpovědnosti

Potkali jste určitě také spoustu klientů, kteří by se daly označit za těžké klienty. Když jste freelancer (na volné noze), jste v jiné roli, než když máte na starost X lidí a rozhodujete se, zda budete mít na platy.

Tehdy jsem mnohokrát vybral a začal spolupracovat s klienty, které můžeme označit za potížisty. A to jen proto, aby přinesli do firmy peníze a bylo na výplaty, obzvláště ve slabších letech.

Nátlak potížisty

Jeden z projektů, na kterém jsme dělali, byl vývoj komplexní video platformy pro klienta (budu o tom mluvit ještě v příběhu 10). Řešení pro streamování televize do mobilu, tabletu, set top boxu, apod. Nechávali jsme si z Číny dovážet krabičky s Androidem. Bylo to v době, kdy ještě nebylo O2 TV a podobné. Byl to super projekt, vznikl super produkt. Dodnes jsem na něj z hlediska výsledného produktu pyšný. Ale klient byl potížista. Byl to klient, který nám ve finále zkazil radost a naprosto nás otrávil. Začal nám psát e-maily s CAPS LOCKEM. Začal řešit úplný blbosti ve smyslu: "Tohle tlačítko má být jinak, a když to tak nebude, tak nedostaneme od investora peníze."

Tento toxický přístup nás přivedl až k situaci, kdy jsme si řekli, že na to nemáme nervy. Projekt jsme dodělali, zakonzervovali a šli jsme pryč.

Uvědomění

Nechci říct, abyste s klienty, kteří jsou obtížnější (možná až potížisty) nespolupracovali, ale nastavte si už od začátku tak jasná a ostrá pravidla, že je klient nepřekročí. A dokonce ani vy. Tady totiž převládlo mnohem více naše nadšení, dělat na něčem novém, být o pár kroků před ostatními, vymýšlet vlastní řešení a nevšimli jsme si, že jsme začali ohýbat vlastní pravidla, ustupovali jsme a nechali se vmanévrovat do kouta.

Příběh 7 - Odhady pracnosti - Optimistické odhady

Sedmý Edův příběh o odhadech pracnosti poukazuje, že optimistické odhady se obrátí buď proti vám, nebo proti klientovi.

Příklad z praxe

Teď jsem na straně vývojářů, abyste neměli pocit, že do nich šiju. Dovedu se vžít do role programátora, za kterým přijde projekťák nebo obchodník a chce po něm časový (tj. z toho vyplývající finanční) odhad za nějakou úpravu. Vývojář musel v té situaci dát ruce od klávesnice, zamyslel se a řekl nějaké číslo. Ano, teď trošku přeháním. Ale při běžném fungování firmy, kde je tisíce požadavků, je odhad většinou o tom, že ho dělá jeden člověk tak, že se zamyslí. A tímhle chci říct - buďte spíše pesimističtí, nenechte se natlačit do optimismu.

Viděno zpětně, když jsem byl v roli obchodníka, tak jsem potřeboval kolegy, kteří dělali odhady, přesvědčit (vmanipulovat) tak, abych to byl schopen prodat zákazníkovi. Příklad. Vývojář řekl, že potřebuje na realizaci 1 den. Tak jsem reagoval, že takovou jednoduchou úpravu nemůžu prodat za cenu 1 dne, to nám nikdy nezaplatí. A tak jsem se ho snažil natlačit, aby vymyslel jednodušší řešení, nějak to zjednodušil, atd. Ano, chceme najít nejvhodnější řešení. Ale ne vždy je tento přístup přínosný.

Uvědomění

Existuje tisíc možností, jak přesvědčit kolegu, aby se na odhad pracnosti díval optimisticky. Ale to se vždycky někde vrátí. Pokud jste vývojářem, nebo tím, kdo bude zakázku realizovat, tak pokud couvnete a řeknete, že to "tedy nějak zvládnete", tak se to ve finále otočí proti zákazníkovi. A proto není dobré být optimistou, když jde o odhady.

Příběh 8 - Odhady pracnosti - Tlačítko za 1 pracovní den

Osmý Edův příběh se taky týká odhadů pracnosti, kdy se vám klient snaží ukázat, že tomu (například tvorbě webu) taky rozumí a požadovaná změna nemůže být tak časově náročná.

Příklad z praxe

Pokud děláte weby a zákazník před 20 lety taky vyráběl nějaký web pro sebe, snaží se vám vysvětlit, že tomu rozumí. Taková ta věta "není možné, že jen změna tlačítka zabere celý pracovní den". Už jste něco podobného slyšeli?

Se změnou souvisí proces

I takové klienty jsme měli a u spousty klientů jsme na tuto hru přistoupili, hlavně abychom klientovi mohli vyjít vstříc. Vám to asi nemusím povídat. Chcete změnit tlačítko. Jedno obyčejné tlačítko. Jenže máte web ve více jazycích, musíte to otestovat na různých zařízeních, máte mobilní verzi, vývojové prostředí, testovací prostředí, máte nějakou produkci, musíte do toho zahrnout deploy změny, máte k tomu projekťáka, máte k tomu testera, prostě spoustu věcí kolem. Úprava je třeba na hodinu, ale je kolem mnoho dalších kroků, které se musí udělat. I změna tlačítka představuje komplexní proces.

Uvědomění

Mnohokrát se mi vymstilo, když jsem přistoupil na tuto hru klienta. Na to si dávejte pozor, nepřistupujte na to.

Příběh 9 - Když je klient Bůh

Devátý Edův příběh se opírá o přístup ke klientovi. Proklientský přístup je určitě důležitý, ale není zapotřebí ke klientovi přistupovat jako k Bohu.

Příklad z praxe

Pro mě byl vždycky klient na prvním místě. Vždycky jsem chtěl splnit první poslední. Chtěl jsem, aby byl klient spokojený, aby neměl důvod říct, že jsme něco zkazili, že někde něco nefunguje. Potřeboval jsem doručit bezchybný produkt.

Tohle zní na první pohled jako naprosto samozřejmé. Všichni přece chtějí, aby byl klient spokojen. Aby se vracel. Jenže, kde je hranice, kdy dodáte skvělý produkt a kdy to už přeháníte. Nebo… kdy toho začne klient zneužívat? Ať už vědomě, nebo nevědomky. Pak je to trápení.

Jenže ve firemním životě, to je ještě o něčem jiném. Nejsem to jen já, kdo chce doručit 100% kvalitu. Chce to i můj tým. Měl by to chtít i můj tým.

Uvědomění

Přiznám se, že jsem často na tým zapomínal. Vždy jsem se snažil vyjít vstříc klientovi. A zřejmě i v případech, kdy neměl pravdu. Mnohdy to ale bylo přes mrtvoly, když to přeženu. Jak jsme mluvili dříve, jde třeba o odhady, o příběh s e-learningem... Měli jsme mnoho projektů o tom, že jsem to přeháněl a snažil se klientovi vyjít vstříc víc, než je zdrávo. Ale málo jsem se ptal týmu, jak on to vnímá.

Příběh 10 - Vzhůru agilně dolů

Poslední desátý Edův příběh je zaměřen na to, jak lehce se dá sklouznout od toho, na čem se s klientem domluvíme.

Příklad z praxe

Už jsem zmiňoval projekt video platformy. Bylo to několik tisíc hodin práce. S klientem jsme se dohodli, že to budeme dělat agilně. Že pojedeme v týdenních iteracích. Na začátku připravíme koncept a analýzu, za kterou zaplatil tehdy cca 200 000 Kč. A následně, že tu cenu si bude určovat on sám podle toho, jaké bude mít požadavky. Součástí interního týmu měl být zástupce klienta.

Ale problém začal už v tom, že přestože řekl: "Jasně, pojedeme agilně.", zároveň chtěl vědět, kolik ho projekt bude ve výsledku stát. A to byl náš fail. My jsme řekli dobře, uděláme rozpočet. Ale udělali jsme rozpočet na základě nedostatečně detailní analýzy. A vznikl rozpočet. Dejme tomu, například v rozsahu 8-10 milionů. Jasně, že se pak se ukázalo, že to bylo příliš optimistické, podstřelené o desítky procent. Viz příběh o zbytečně optimistických odhadech. Ale ve chvíli, kdy klient dostal odhad, i když byl od-do, tak i přesto se to pro klienta stalo zdí, přes kterou nejel vlak.

Klient hnidopich

Dostali jsme se až do fáze, kdy jsme s klientem řešili jednu hodinu úpravy a on se ptal, proč tam tu hodinu budeme trávit. Teď, když to zmiňuji, tak tomu nevěřím, že jsme se do toho nechali zatáhnout. Měli jsme desítky požadavků o změnu a bavili jsme se o každém jednotlivém řádku. Vysvětlovali jsme mu, proč na tom strávíme 3 hodiny a jestli by to nešlo míň, proč tady půl hodiny apod. Tím spíše, když jsme se na začátku bavili, že projekt pojede agilně.

Nechali jsme se natlačit do toho, že jsme mu řekli cenu. A on pak samozřejmě chtěl, abychom tu cenu dodrželi. To znamená - tlačil na nás - ohledně kvality i termínů. Ale s cenou se hýbat nemělo.

Zásadní změny v projektu

Řeknu vám jeden příklad. Dělali jsme v tabletové verzi aplikace pro streaming televizí modul, který měl zobrazovaz seznam programů - několik dnů dopředu, několik dnů dozadu. A my řešili to, že první verze aplikace byla postavená tak, aby zvládla 15 televizních stanic. Což fungovalo. Velice dobře to fungovalo na tehdy průměrném tabletu. A pak přišel klient a řekl: "Jedu na výstavu, potřebuju tam 150 stanic".

Tak jsme je tam nahráli, ale v tu chvíli vznikl problém, že to nebylo plynulé. Tablet se zadýchával, zasekával. Nebylo to k tomu optimalizované. A tohle zadání, že musí být aplikace optimalizovaná pro 150-250 stanic, nebylo nikde napsané a nikdy to nikoho nenapadlo. Klient kvůli tomu prohlásil aplikaci za nefunkční. A my jsme byli s rozpočtem na konci.

Cesta do pekel

Jak nyní chcete vysvětlit klientovi, že refaktoring bude stát zhruba 100 000 Kč, to znamená předělání části aplikace. A představte si, že v tom projektu je takových bodů třeba 30-50. Věci, které během analýzy nemáte šanci odhalit. A klient vám to začne vracet: "Tady jste měli odhad, že tímhle strávíte X hodin, tak proč mi říkáte, že potřebujete dalších Y hodin na to, že to budete předělávat." Jenže už se těžko vysvětluje, že první verze bylo MVP (Minimal Value Product), první verze, která vyžaduje během vývoje nejednu revizi. Takže jsme začali agilně, ale skončili jsme tím, že jsme jeli čistým vodopádem.

Uvědomění

Nenechal bych se dnes už natlačit do toho, že budeme říkat cenu. Pokud po vás chce klient cenu, tak by to mělo být za naprosto striktních pravidel. Nebo do odhadu přidejte nulu, ať se s tím klient srovná. Bude to buď za 8 000 000 Kč nebo za 80 000 000 Kč. Něco mezi tím to bude určitě.

Shrnutí

Zaměřili jsme se na samé faily. Když si to teď po sobě čtu, cítím se jako naprosto neschopný majitel firmy a úplně jako nemožný člověk. Chci vám ale jen říct, že jsem vám ukázal 5 % těžkého života podnikatele a majitele firmy. Ale ono to není jen o těch failech, je to i o úspěších. Ale o těch třeba zase někdy příště.

A rada na závěr, kterou jsem opakoval ve firmě dnes a denně: Nikdy nic nepředpokládej. Nepředpokládej, že klient něco ví. Nepředpokládej, že odhad je správný, a že tě něco nepřekvapí. Nepředpokládej, že pokud tester nezaznamenal výstup testování, že to otestoval. Slepě něco předpokládat, to je cesta do pekel.