Jsme komponentní firma. Buďte taky! Aneb žehrání nad kvalitou programování

Víte, co se mi na podnikání dneska líbí? To, že máte možnost poskládat si všechno ve firmě po libosti, nemusíte se dusit s něčím, co potřebujete a přitom dělat nechcete. Jsme komponentní firma.

Když se po revoluci dával na podnikání můj otec, musel si všechno, první a poslední, zařídit sám. Akorát ten záznamník k telefonu mu dělala matka, která seděla doma a přijímala vzkazy, pro které si pak táta z budky na rohu volal. Dokonalý časy, táta tomu říkal „mobil s retranslací“.

Když jsem vyprávěl o tom, jak jsme si zařídili call-centrum, pár lidí brblalo, že to je pěkně drahá věc. Jenže není. Dneska si můžete zařídit profesionální službu za rozumné peníze. Samozřejmě musíte trochu umět s kalkulačkou, abyste věděli, zda se vám profi služba rentuje, jenže my, když jsme se rozhodli, že potřebujeme provolat několik tisícovek kontaktů, tak na to za prvé musíme mít návod, co těm lidem budeme říkat a za druhé lidi na telefonu, kteří to zařídí. Jenže copak si budu ve firmě budovat místnost, kam nacpu desítku študáků a ústřednu? To se mi nechce. Jednoduše chvíli googluju na webu a za chvíli najdu pár firem, které dělají call-centra. Řeknete si, jak se mají představovat, jaký mají mít viditelný číslo, vytvoříte návod, co mají dělat. A jak zaplatíte. Zda za čas, za kus, za zásek… to je na vás a na vybalancování vaší touze po kontrole, důvěře a zvýšené ceny, když platíte rovnou za akci. 

Snažíme se používat komponenty. Někdy se tomu říká outsourcing, jenže tohle slovo se tak zprofanovalo, že radši používám to slůvko komponenty, které jsme si přinesli z komponentního programování. I vývoj je u nás komponenentní. Výsledkem každého programování musí být samostatně použitelná komponenta, která je u nás v repository zdokumentovaná a připravená k použití, takže když se u nás dělá zakázka, skládají se komponenty na hromadu, propojují se přes vstup/výstup. A tenhle přístup se snažíme používat i kdekoliv jinde, nejenom v programování. Snažíme se sehnat komponentu, která nám umožní docílit patřičného výsledku a neřešit věc ve vlastní režii. Je milé, že to jde.
Už jsem taky mluvil o tom, že máme něco, čemu říkáme trojdušní systém. 

Každá komponenta u nás má tři nutné součásti. 

Nejdříve prvotní Analýzu, tedy to, jak má vypadat a co má dělat. Co má být výsledek. Definuje se, jak má výsledek vypadat. Například taková komponenta export nabídky shopu pro Zboží má za výsledek XML feed, ve kterém jsou všechny položky z eshopu vystavené pro slíznutí Zbožím. K analýze nám připadá i obchodní uplatnění takové komponenty, tedy například to, že nás stojí vývoj 5 menday (MD), k čemuž si umíme přiřadit cenu a jak četně je poptávána.

Druhou součástí komponenty je definovaný Průběh, kdy si říkáme, kdo kdy co udělá nejenom při tvorbě komponenty, ale při jakémkoliv dalším použití. Víme, kdo se o komponentu stará, aby nezastarala, kdo má právo rozhodnout, zda se smí prodávat dále a za kolik, jaké jsou možné modifikace v ceně či za cenu a jak se věc implementuje klinetovi. Při dodávce si prostě komponentu i s Průběhem stáhne programátor z repozitory a naváže na ni věci, které na ni potřebuje navázat. Pokud komponentu dává na námi podporované systémy, má ji vřazenou do systému za minutu, stiskne tlačítko a fakturační systém ví, že vše proběhlo, jak mělo.

Třetí součástí je Test. U každé komponenty je definovaný výsledek z Analýzy a ten může Test otestovat. Ověříme, zda výsledek se dostaví dle očekávání. V případě programu se u nás opravdu programuje i kód, který otestuje, zda komponenta odevzdává výsledek. V případě banálního exportu pro Zboží prostě testovací kód komponenty ověří, zda výsledný XML soubor je validní, obsahuje počet zboží tolik, kolik je v eshopu a má strukturu požadovanou seznamákama plus se provede za definovaný čas. 

Vypadá to možná absurdně, jestli sami prgáte v péhápků „velký šopy“, ale tohle nám maximálně šetří čas. Většina programování nakonec totiž je vytváření mnohokrát vytvořeného. U nás se nikdy neprogramoval unikátní systém řízení jaderné elektrárny, ale zato musíme jako Baťa cvičky sekat propojení na karetní systémy třeba. A k tomu potřebujeme, aby vše proběhlo rychle, hladce, bez chyb. Každá komponenta se sama zkontroluje, nehledají se zbytečné chyby a pokud jo, rychle se najdou, protože z výsledku testů vidíme, v které komponentě to bude. Je to něco, jako diagnostika v autoservisu – připojíte auto na diagnostiku a hned víte, kde je základní problém, ten pak řešíte. 

Co zákazníky hodně sejří, je bezradnost vás jako dodavatele. Když vidí, že vůbec netušíte, kde jste chybu udělali. Pravda je, že kucí kodeři, kteří k nám nastupují, jsou vyvalení, když jim repository odmítne kód s tím, že není definovaná testovací rutina, ačkoliv to mají na každým školení a jejich šéf jim to zdůraznil několikrát. Nechápou, proč se plýtvá jejich „drahý myšlenkový čas“ na to, aby se vymyslelo a nakódovalo testování. 

Ale pak, když vždycky viděj, jak u klienta jen zavoláme komponenty s testovacím výstupem a za minutu víme, že bug je v tom, že někdo nechal bránu nastavenou na švédské koruny, zatímco komponenta předpokládá česky, to je strašně milý překvapení.

Trochu se nám ve firmě navíc rozbujely kontesty, kdy se analytici předhánějí s kodery, kdo líp vymyslí testování. Poněkud jsme to podpořili, protože nám nějakou chvíli lidi reptali, proč se má dělat testování tímhle způsobem. Že prej stačí, aby si nějakej elév sedl za browser a proklikal to, jestli „to“ funguje. Jenže co je to „to“. Takhle to nešlo. Nejde. 

A tak jsme nejdříve vlastní lidi buzerovali, pak jsme začali povzbuzovat soutěživost. Aby je bavilo si hrát s testama. 

Co jsme tím ztratili? Zhruba polovinu času kodérů, teda zhruba tolik, co stejně bezúčelně proflákají. Naopak jsme získali spokojenější klienty, kteří mají dojem, že tak trochu víme, co děláme. A taky klidnější průběh zakázky, protože poměrně přesně víme, kdy doděláme, co děláme a kdy vyřešíme chyby, co jsme si tam zavlekli.

Zkuste to taky. Zjistíte, že zákazník je příjemně šokován tím, že produkt, který mu odevzdáváte, je otestovaný a funkční. Původně očekával, že mu na reklamačku odpovíte, že je to chyba jeho zadání, najednou zjistí, že není, co reklamovat. Bude se mu míň třást ruka při podpisu finální faktury do účtárny. A to je to, o co gou pro nás.

Takže, buďte komponentní. Využívejte komponenty, které jsou dostupné. A vybudujte si vlastní trojdušní systém, abyste kontrolovali, jak efektivně je používáte.

Ve výsledku zjistíte, že kontrola kvality je důležitá, ale musíte ji vymyslet tak, aby přínos z ní nebyl menší, než náklady na ni. Aby chaotické odstraňování chyb nebylo levnější, než lpění na výstupní kontrole. A to není lehký. Snad se s tím potýkáme dobře. 

PS: Proč tomu říkáme trojdušní systém? Protože u nás ve firmě nad každou tou částí bdí jeden dobrý Duch: Spolubydlič nad Analýzou, Kemal nad Provedením a já nad Testem, protože tahle naše část je základ práce našeho oddělení. No a my jsme ti Duchové, co to tu mají na starosti. Proto trojdušní systém. Ale přiznávám, že jsme to vymysleli totálně nakalený, když náš velkej klient (totálně nadrátovanej) chtěl vědět, jak tomu našemu systému říkáme – to se zrovna dozvěděl, že firmu řídíme metodou Karban :)