neděle 26. února 2012

Techniky pro prevenci softwarových chyb

... aneb chyby se začnou bát vás!

Chyba, defekt, štěnice, brouk, bug, fail, fault, mistake. Tato slova nám nezní moc libozvučně. Ve své práci vynakládáme nemalé úsilí na jejich deratizaci. V tomto průřezovém článku jsem se zaměřil na několik preventivních technik. Zdravotní pojišťovny ví, že prevence je levnější než léčba. Stejně tak si i zkušení vývojáři uvědomují, že čím dříve se chybu podaří diagnostikovat, tím bude její odstranění levnější. Legrace končí, pokud se chyba dostane až do provozního prostředí.

Chyby na sebe berou mnoho podob. Může se jednat o pád aplikace na neošetřenou chybu některé z komponent, sémantickou nefunkčnost aplikace (chybný výpočet, nesprávná data) nebo nesplnění nefunkčního požadavku na systém - pomalost, porušení zabezpečení, neškálovatelnost, apod. Chyby mají různou závažnost a některé dokáží způsobit hodně velkou škodu. Na míře chybovosti je závislé vnímání vaší aplikace uživateli. Je to výrazný faktor úspěšnosti celého vašeho snažení.

Pište čistý kód

Krysy žijí v kanálech a švábi v místech, kde je nepořádek a neuklízí se. Softwarové chyby to mají podobně. Více se objevují v kódu, který nedodržuje metodiku "čistého kódu". Jaký kód je čistý? Kód, který je čitelný, přehledný, dodržuje kódovací standardy, je správně strukturovaný, používají se v něm vhodné názvy, má správné úrovně abstrakcí v metodách, apod. K technikám čistého kódu se možná dopracujete praxí nebo rychlejším způsobem, přečtením výborné knihy Čistý kód od Roberta C. Martina.

Čistý kód podporuje efektivnější ladění. Pokud např. dodržujete pravidlo, že každá metoda má právě jeden výstupní bod (příkaz return), je snadnější rozmístit ladící body. Pokud správně strukturujete kód třídy na menší metody a nemícháte více úrovní abstrakce do jedné metody, navigace je rychlejší a případné problémové místo najdete snáze.

Důsledkem aplikace pravidel čistého kódu je především dobrá čitelnost kódu, která snižuje riziko "ukrytí" zákeřných programových chyb už v prvotní fázi psaní kódu.

Dobrý objektový návrh

Chybný objektový návrh dokáže hodně zavařit a čím později si chyby uvědomíte, tím více práce si přiděláte. Dobře navržený systém respektuje pravidla návrhové metodologie SOLID a dalších dobrých návrhových praktik. Rozsáhlejší systémy, které nerespektují dobrý návrh jsou problematicky udržovatelné a vysoce rizikové při jakémkoliv pozdějším zásahu do kódu. Říkáme, že jsou křehké. Zanesení chyby je vysoce pravděpodobné.

Neobjevujte kolo a naučte se využívat návrhové vzory. Buďte si jistí, že problém, který řešíte, už měly zřejmě stovky vývojářů před vámi. A návrhový vzor je efektivním řešením tohoto typu problému. Jsou popsány desítky vzorů pro vznik objektů, pro zachycení struktury mezi objekty, pro řízení chování, pro implementaci jednotlivých vrstev aplikací (datová, obchodní logika, prezentační, ...) a další.

Díky dobrému návrhu zoptimalizujete i další preventivní techniky popsané v tomto článku. Například bez Inversion of Control a programování proti rozhraní (ISP) byste psali problematicky jednotkové a integrační testy.

Naučte se i antivzory (antipatterns), špatné techniky návrhu. Jejich znalost vás již dopředu bude varovat před chybnými kroky, které by vás jinak stály vyšší chybovost, čas a prostředky.

Refaktorizace kódu

Rekaftorizace kódu je změna struktury kódu, která nemá vliv na jeho celkovou funkčnost. Znalost refaktorizačních technik patří mezi základní dovednosti vývojáře. Příkladem refaktorizačních technik je přejmenování (proměnné, metody, třídy), vyjmutí části kódu do samostatné metody nebo třídy, změna pořadí argumentů metody, apod. Nezbytností je, aby vaše IDE podporovalo refaktorizační techniky. Nebojte se refaktorovat vždy, když budete mít pocit, že se kód zlepší.

S využitím refaktorizace dosáhnete čistého kódu a dobrého návrhu. Snížíte složitost částí kódu. Platí pravidlo, že co je složité, je náchylné k vyšší chybovosti. Dobrý vývojář dokáže i složitý problém implementovat přehledně a "jednoduše".

Hezký popis refaktorizačních technik je k dispozici na serveru SourceMaking.

Revize kódu (Code Review)

Promluvili jste si někdy o svém kódu s kolegou? Bavili jste se, proč jste použili zrovna takovou implementaci? Uvědomili jste si při tom, že by problém šlo vyřešit lépe nebo jste dokonce objevili chybu? Výborně! Pak jste použili techniku revize kódu. Když se na váš kód podívá někdo jiný, je to téměř vždy ke prospěchu věci.

Kdy provádět revizi kódu? Ideální by bylo během nebo těsně po vlastní implementaci. Revize kódu je jedním ze základních aspektů párového programování (Pair Programming). Dvojice společně vyvíjí kód a revize probíhá neustále. Pokud neaplikujete párového programování, můžete nastavit povinnou revizi kódu při umisťování změn na server. Revizi můžete také provádět v rámci celého vývojového týmu na pracovních poradách.

Jak je revize kódu efektivní? Záleží na úrovni zkušeností vývojáře a "revizora". U začínajících vývojářů budou revize častější a revizorem by měl být zkušený pracovník. Při revizi kódu vytvořeného zkušeným vývojářem nemusí být objeveno mnoho chyb, ale celý proces může posloužit k tomu, že posluchačům budou předány zkušenosti a praktické rady. Technik revizí kódu je více a liší se svojí formálností, obsazením revizního týmu a způsobem evidence nalezených defektů.

Revize kódu má však i svá rizika. V posuzování práce někoho jiného musíte být opatrní, abyste dotyčnému neublížili před ostatními. Chybně provedená veřejná revize může způsobit konflikty. Měli byste vždy vývojářům, jejichž práce bude revidována, vysvětlit účel a přínosy pro něj i ostatní.

Statická analýza kódu

Analýza kódu, která je prováděna bez nutnosti spouštění programu. Jedná se o soubor preventivních technik, které mají odhalit defekty a problémová místa ve vašem systému. Jak se problémová místa poznají? Například podle složitosti. Jak již bylo uvedeno výše, u složitě kódované části aplikace je pravděpodobnější, že vývojář zanesl nebo přehlédl chybu.

Problémová místa vám pomáhají určit softwarové metriky orientované na kód a na návrh tříd. Uvedu pár příkladů:

  • Cyclomatic Complexity vyjadřuje složitost části programu (např. metody) co do množství větvení a cyklů. Tyto programové konstrukce zvyšují počet možných cest provádění programu. Vysoké číslo indikuje komplikovaně napsané složité metody, které je problematické pokrývat testy. Řešením je metodu rozbít do více menších metod.
  • Line Count vyjadřuje množství řádků kódu v metodách. Dlouhé metody jsou nepřehledné a dělají zřejmě více než jednu věc (pro danou úroveň abstrakce). Použitelnost takových metod je problematická, stejně jako pokrytí testy. Řešením je opět refaktorizace do více metod.
  • Objektové metriky jako Weighted Method Count (celková složitost metod ve třídě), Depth of Inheritance Tree (počet předků třídy) a Coupling Between Objects (provázanost mezi objekty) mohou indikovat problémy v objektovém návrhu.

Údaje získáné z metrik, by měl vyhodnocovat vedoucí vývojář. Nástroje pro statickou analýzu jsou u komerčních IDE k dispozici ve vyšších edicích. Pokud máte k dispozici nástroje, které metriky zobrazují přímo v kódu, naučte se je vyhodnocovat a vaši práci podle nich přizpůsobovat již během vlastní implementace.

Mezi techniky statické analýzy patří také validace kódu podle pravidel definovaných pro zdrojový kód. Tato technika zvýší přehlednost a čitelnost kódu. Každý vývojový tým by si měl na začátku projektu zadefinovat kódovací standardy a zvolit nástroj, který bude na dodržování dohlížet. Jak lze využít StyleCop si můžete přečíst v příspěvku Jak psát lepší kód s využitím StyleCopu.

Volba technologií

Správnost volby technologií může mít na chybovost zásadní vliv. Rozsáhlejší projekt využívá velké množství technologií a nástrojů. Relační databázový systém, vývojové prostředí, programovací a značkovací jazyky, validační frameworky, perzistentní framework, základ pro služby, prezentační frameworky a komponenty, apod. Vybírejte technologie prověřené a odzkoušené (pozor na poslední releasy), které se dobře používají a mají perspektivu (abyste si je nemuseli vyvíjet v budoucnu sami :). Rozhraní dobrých komponent je snadno použitelné, intuitivní a dobře zdokumentované. Důležitá je také testovatelnost.

Automatizované testování

Testování je technika dynamické analýzy kódu. Psaní testů by podle metodologie Test-Driven Development (TDD) mělo předcházet vlastní implementaci. Zkuste si tento přístup zažít a uvidíte, že se vám zalíbí. A pokud ne, vězte, že testy stejně musíte napsat. Jinak se pro vás stane prvotní vývoj a především pozdější zásahy do produkčního kódu noční můrou. Testy jsou indikátory chybových stavů. Vývoj aplikací bez pokrytí testy provozují pouze hazardéři ;)

První typ testů, který napíšete, budou jednotkové testy (unit test). Základní logika jednotkového testu je jednoduchá. Voláte metodu instance testované třídy s určitými vstupy a validujete výstupy. Pokud výstupy neodpovídají předpokladům, test selže a je nutno hledat chybu v implementaci. Lze prohlásit, že vyšší pokrytí testy lépe pojistí váš kód. Ale je také nutno dodat, že testy se nesmí psát jen z formality, ale musí být správně cílené na problémové situace. O špatných technikách psaní jednotkových testů si můžete přečíst v příspěvku Jak nepsat jednotkové testy.

Pokud je test napsaný tak, že "vidí" do implementace, mluvíme o white-box testování. Pokud je testovaný kód pro test černou skříňkou, hovoříme o black-box testování. Oba přístupy mají své opodstatnění. Pomocí "bílého" testování snáze pokryjete všechny cesty provádění. "Černé" testování zase zosobňuje naivní přístup klientské strany, který může přinést nečekané způsoby volání.

Vyšší formou testů jsou integrační a systémové testy. Validují interakci více objektů a funkcionalitu větších celků. Pamatujte, že požadavky na kvalitu kódu testů jsou stejně přísná jako na vlastní testovaný (produkční) kód. Kód testů budete udržovat stejně dlouho jako produkční kód. Zjednodušeně shrnuto, testy by měly běžet krátkou dobu, na libovolném "kompatibilním" počítači, měly by po sobě uklidit a neměly by být na sobě vzájemně závislé.

Snažte se co nejvíce testů zautomatizovat, určitě se vám práce vyplatí. Bez automatizace nejsou některé typy testů vůbec proveditelné. Těžko se shání několik stovek uživatelů na zátěžové testy, kteří by v jednom čase začali používat a zatěžovat vaši aplikaci :)

Zautomatizovat se dá i interakce s uživatelským rozhraním vaší aplikace. Volba nástrojů závisí na technologii prezentační vrstvy.

Ruční testování

Jedná se o pracnější formu validace funkcionality vaší aplikace, která má však stále svoje opodstatnění. Šikovný tester je vynalézavější než vaše automatizované testy a objeví situace a scénáře, které jste nepředpokládali. Ještě vynalézavější jsou však uživatelé, proto se také uvolňují nefinální beta verze :)

Automatizace buildů

Vytvořte a nakonfigurujte buildovací server pro týmový vývoj. Po každém vrácení změn na server spouštějte build průběžné integrace (Continuous Integration), který pohlídá, aby vrácená změna nerozbila integritu projektu. Vývojář získá okamžitou zpětnou vazbu, že jeho změna může zablokovat práci celého týmu.

Užitečné jsou i buildy pro zajištění kvality. Jsou spouštěny v pravidelných cyklech, například každou noc a jejich úkolem je provádět statickou i dynamickou analýzu kódu. Provádějí se validace kódu, vyhodnocují se metriky, spouští testy. Výsledky se následně vyhodnocují a sjednávají se nápravná opatření.

Výhodou automatického buildování je i rychlé vytváření průběžných testovacích verzí a jejich nasazení do testovacího prostředí.

Prototypování

Někdy je obtížné již v ranných fázích vývoje přesně specifikovat způsob realizace cílových požadavků na systém. Víme sice, co chceme udělat, ale nejsme si jisti, jak bude vypadat například uživatelské rozhraní naší aplikace. Prototyp je funkčně zjednodušený základ (předobraz, demoverze) vyvíjeného systému. Měl by vzniknout relativně rychle a slouží k průběžné revizi požadavků. Prototyp můžete předvést investorovi a získat zpětnou vazbu. Prototyp je vyvíjen v cyklech. V každém cyklu jsou zapracovány získané připomínky.

Pokud používáte prototypování správně, můžete získat efektivní nástroj pro řízení a směrování projektu. Vyhnete se chybám, které by byly jinak objeveny až později a jejich řešení by bylo nákladné. Pro vývojáře je někdy tvorba prototypu neoblíbenou činností. Může se totiž stát, že celý prototyp se zahodí jako nevhodné řešení a začne se vytvářen nový. Pořád to však méně bolí než složitě předělávat systém v pozdní fázi implementace.

Revize výstupů v předimplementačních fázích

Většina vývojových metodik rozděluje vývojový cyklus na fáze specifikace požadavků, analýza, návrh, implementace, testování, nasazení a údržba. V každé fázi vznikne určitý výstup. Například v první fázi specifikace požadavků vytvoříte požadavky na systém. Pokud jsou sestaveny chybně a zjistíte to až v okamžiku předávání software zákazníkovi, vyvstává velký problém. Příslušná část aplikace se musí předělat a rozsah víceprací může být značný. Stejně tak chyby v analýze nebo návrhu vás mohou přijít hodně draho.

Proto je vhodné podobně jako revidujete implementační kód, revidovat co nejdříve všechny předimplementační výstupy. Taková revize má svůj formalismus a pokud ji uděláte kvalitně, můžete objevit již v ranné fázi závažné chyby. Pokud máte malý vývojový tým, požádejte kolegu, aby si po vás dokumenty s požadavky, analýzou a návrhem přečetl.

Motivace lidí

Některé z výše uvedených technik selhávají, pokud je používá člen týmu s nedostatečnou motivací pro dosahování kvality. Revize se dají odbýt, testy se dají napsat jen aby se dosáhlo vyššího pokrytí, při psaní kódu lze ošálit statickou analýzu neúčelnou kompatibilitou s validačními pravidly.

Členové vašeho týmu musí být motivováni finančně i nefinančně, aby pro ně bylo přirozené a prioritní zajišťovat vysokou kvalitu svojí práce.

neděle 12. února 2012

Jak nepsat jednotkové testy

... aneb pozor na lháře, křiklouna a místního hrdinu

Uvádím seznam nejfrekventovanějších antivzorů (špatných technik) pro psaní jednotkových testů. Vyvarujte se jich a Vaše testy budou v dobré kondici ;-)

  • Lhář (The Liar). Jednotkový test, který prochází pro každý testovací případ. Optimismus nás však přejde, pokud se podíváme blíže na implementaci testu a zjistíme, že ve skutečnosti požadovanou vlastnost netestuje.

  • Nadměrná příprava (Excessive Setup). Test, který potřebuje rozsáhlou přípravu ještě před samotným spuštěním testovaného kódu. Stovky řádků a velké množství objektů, které test vyžaduje, způsobí, že je obtížné ověřit testovanou funkcionalitu. Test může selhat z mnoha jiných příčin, než z vlastní chyby v testovaném kódu.

  • Obr (The Giant). Jednotkový test, který pokrývá velké množství testovacích případů a je v rozsahu stovek až tisíců řádků. Přestože validně testuje testovaný kód, jedná se zřejmě o jednotkový test nad božským objektem (God object). Tedy chybný návrh třídy, která v sobě slučuje více zodpovědností.

  • Imitátorna (The Mockery). Používání mock objektů je v mnoha případech dobré a šikovné. V některých případech však mohou vývojáři ztratit kontrolu sami nad sebou a nadměrným používáním mock, fake a stub objektů potlačit vlastní testovanou funkcionalitu. Dochází pak spíše k testování dat, které vracejí jednotlivé mock objekty. Definice mock objektů je navíc velmi křehká a může být snadno rozbita a chybně způsobí selhání testu. To je samo o sobě proti principům TDD. Příliš mnoho závislostí a komplikované vazby na další třídy může indikovat testování božského objektu. V takovém případě by měla být testovaná třída refaktorována nebo by mělo být jedno volání nahrazeno sekvencí více volání metod s menším rozsahem funkcionality. Každé dílčí volání by pak mohlo být otestováno samostatně a není nutné znovu testovat celou sekvenci jako celek.

  • Inspektor (The Inspector). Inspektor je jednotkový test, který ví příliš mnoho o vnitřní struktuře testovaného kódu. Je napsán na míru z důvodu 100% pokrytí kódu. V případě, že je testovaný kód refaktorován a přestože se jeho validita nemění, tzn. měl by procházet, začne test neprocházet. To vynutí současnou změnu i v jednotkovém testu.

  • Velkorysé zbytky (Generous Leftovers). Jeden jednotkový test vytvoří data, která jsou někde persistována (uchována). Jiný test tato data využívá pro svoje vlastní (původnímu testu neznámé) účely. Pokud je takový "test-generátor" spuštěn později nebo pouze částečně, dochází chybně k selhání v testu, který je na něm závislý.

  • Místní hrdina (The Local Hero). Test je napsaný tak, že obsahuje závislosti na prostředí, ve kterém byl vyvinut. V případě, že je spuštěn v těchto podmínkách, pak v pořádku prochází. Pokud se však test spustí v jiném prostředí, selže.

  • Hnidopich (The Nitpicker). Test, který prověřuje kompletní výstup, přestože významná je pouze část vrácené informace. Pokud se změní nevýznamová část vrácené informace, začne test chybně selhávat. Takové testy jsou typické při testování webových aplikací.

  • Tajemný lovec (The Secret Catcher). Na první pohled takový test vypadá, že nic netestuje, neboť nemá žádné asserty. Ovšem v tomto případě platí rčení, že "ďábel je ukryt v detailech". Test předpokládá, že v případě selhání vyvolá testovaný kód výjimku, kterou zachytí a zpracuje testovací framework. Řešením by mohlo být odchycení výjimky do proměnné určitého typu a porovnání na null hodnotu. Nebo můžete použít atribut ExpectedException.

  • Ulejvák (The Dodger). Jednotkový test, který testuje několik méně podstatných aspektů testovaného kódu a vyhýbá se otestování chování zásadního. Obvykle z důvodu vyšší složitosti takového otestování.

  • Křikloun (The Loudmouth). Jednotkový test nebo sada testovacích případů, které posílají na konzoli velké množství testovacích, ladících nebo protokolovacích zpráv, i v případě, že testy procházejí. Jedná se obvykle o pozůstatky ručního ladění. Tyto nevýznamné zprávy znepřehledňují výsledký protokol o výsledku spuštěných testů.

  • Nenasytný lovec (The Greedy Catcher). Jednotkový test, který zachytí výjimku a "polkne" ji včetně trasování zásobníku. Tuto výjimku někdy nahradí informačně méně hodnotnou zprávou. Někdy dokonce chybu pouze zaloguje a test nechá projít.

  • Řadič (The Sequencer). Jednotkový test, jehož procházení je závisle na určitém pořadí assertů, u kterých by na pořadí záležet nemělo.

  • Skrytá závislost (Hidden Dependency). Hodně podobný "Místnímu hrdinovi". Test přepokládá, že před jeho spuštěním jsou připravena data, na kterých je závislý. Pokud tomu tak není, test selže. Vývojář obdrží omezenou informaci o problému a je nucen projít velké množství kódu a zjistit problém se závislými daty. Například starší .dll knihovny mohou být závislé na ini souboru, který řídí jejich chování. Je obvykle složité dopátrat se vlastní příčiny selhání testu a této skryté závisloti.

  • Výčet (The Enumerator). Jednotkový test s testovacími případy, které se jmenují podobně. Např. TestMethod1(), TestMethod2(), ... V tomto případě není možné z názvů testovacích případů určit jejich význam. V případě selhání je vývojář nucen procházet přímo zdrojový kód testu a snažit se pochopit jeho význam.

  • Cizinec (The Stranger). Testovací případ, který nepatří do jednotkového testu. Ve skutečnosti testuje jiný typ objektu, který je využíván a vrácen testovaným objektem.

  • Kazatel operačního systému (The Operating System Evangelist). Jednotkový test, který se opírá o specifické prostředí nebo vlastnosti operačního systému. Příkladem může být assert v testovacím případě, který ověřuje sekvenci znaků pro nový řádek a předpokládá Windows konvenci. Takový test selže při spuštní na Linuxu.

  • Úspěch zaručen (Success Against All Odds). Test, který byl napsán nejdříve tak, aby prošel, místo aby selhal. Naneštěstí pak takový testovací případ prochází i v situacích, kdy by měl selhat.

  • Jízda zadarmo (The Free Ride). Namísto vytvoření nové metody testovacího případu pro otestování další vlastnosti nebo funkcionality, se přidá pouze nový assert k již existujícím.

  • Jedinečný (The One). Kombinace několika vzorů, zejména "Jízdy zadarmo" a "Obra". Test obsahuje jeden testovací případ, který testuje celou sadu funkcionalit testovaného objektu. Obvyklým ukazatelem je to, že testovací metoda se jmenuje stejně jako jednotkový test.

  • Vykukující kocour (The Peeping Tom). Test, který skrze sdílené zdroje vidí na výsledná data jiných testů. Na základě těchto dat může test selhat, přestože testovaný systém je pro testovací případ validní. Toto se běžně stávalo ve FitNesse, kde se používaly statické členské proměnné pro uchování kolekcí, které nebyly korektně vyčištěny po proběhnutí testu. Tento problém se objevoval neočekávaně při některých bězích testů. Vzor známý také jako "Nezvaní hosté" (The Uninvited Guests).

  • Pomalé dloubnutí (The Slow Poke). Jednotkový test, který běží neúnosně pomalu. Když jej vývojář spustí, může si zajít do koupelny nebo zakouřit. V nejhorším případě jej může spustit na konci šichty před odchodem domů.

  • Štastná cesta (Happy Path). Test probíhá pouze po hladké, bezproblémové cestě. Netestuje hraniční hodnoty a výjimky.

  • Podřadní občané (Second Class Citizens). Testovací kód není tak dobře refaktorovaný jako testovaný kód, obsahuje duplicity a je špatně udržovatelný.

  • Spoutaní řetězem (Chain Gang). Dvojice testů, které musí být spuštěné v určitém pořadí. Například jeden test nastaví globální stav systému (globální proměnná, databázová data) a druhý test je na tomto stavu závislý. Např. u databázových testů se může stát, že pokud není provádění uzavřeno ve chráněném bloku a test selže, není po testu korektně uklizeno.

  • Bezejmenný test (The Test With No Name). Test, který byl vytvořen, aby reprodukoval nalezenou chybu a jeho autor nepovažoval za důležité vymyslet mu významové jméno. Namísto posílení (rozšíření) existujícího testu, je vytvořen nový test s názvem TestProChybu123. Po dvou letech, kdy tento test začne selhávat, musíte do systému pro sledování chyb a hledáte Chybu123, abyste pochopili účel tohoto testu.

  • Spáč (The Sleeper). Test, který selže v určitou dobu nebo po určitém datu. Jedná se často o nekorektní kontrolu hraničních hodnot při testování kódu, který pracuje s objekty typu Date nebo Calendar. Problémový může být také běh o půlnoci. Chyba je na straně kódu testu.

Informační zdroje

Článek jsem sestavil ze dvou níže uvedených zdrojů a dokořenil jej vlastními vsuvkami. Může se stát, že se mi nepodařilo trefit ideální český ekvivalent pro název některého antivzoru. Navrhněte lepší, rád upravím.

úterý 7. února 2012

Pár fíglů od Steva Jobse ...

... aneb Jak vybudovat firmu podobnou Apple

Je potřeba na začátek zdůraznit, že potřebujete garáž! Vážně, garáž je pro začínající projekty hodně důležitá. Bez ní to budete mít opravdu těžké ;) Jo a taky potřebujete někoho podobného Stevu Jobsovi! Troufáte si někdo? Možná by Vám mohlo zvednout šanci na úspěch, pokud byste od mala vyrůstali v Sillicon Valley a potkávali zapálené inženýry v Palo Alto. Pokud jste náhodou adoptovaní, lépe se Vám bude hledat motivace dokázat světu, že původní rodiče udělali chybu, když se Vás vzdali. No tak, nebuďte tak upjatí a zkuste nějaký halucinogen, abyste se trochu odvázali a dokázali dohlédnout do budoucnosti dál než ostatní ...

Přátelé, musím k Vám být upřímný. Každému to nevyjde. Přesněji, skoro nikomu to nevyjde. Bohužel. Nedá se nic dělat! Pokud Vás však zajímá, jak se vlastně Stevu Jobsovi povedlo vybudovat aktuální technologickou firmu číslo jedna, mohl by Vás tento článek zajímat. Pokud budete pozorní a přemýšliví, určitě se dozvíte něco, co sami s výhodou použijete.

Obklopte se schopnými lidmi

"Například Woz byl člověk asi tak padesátkrát lepší než průměrný inženýr. Ten mohl pořádat mítinky ve své hlavě. Mac tým byl pokus sestavit tým ze samých takových lidí, z áčkových hráčů. Lidi říkají, že to spolu nemůžou vydržet, že nebudou schopni spolupracovat, nesnesou se. Ale já zjistil, že áčkoví hráči nemají problém pracovat s jinými áčkovými hráči, ale nedovedou pracovat s hráči céčkovými."

Pro Jobse bylo osudové setkání se Stevem Wozniakem. Kromě školních legrácek a ptákovin sestrojili "modrou krabičku", kterou byli schopni ovládat miliardovou infrastrukturu telekomunikačního obra AT&T a volat zadarmo po celém světě. Wozniak je také označován za posledního člověka, který dokázal sám sestrojit celý počítač (Apple I). Samozřejmě v garáži!

Jobs dokázal do svojí firmy nalákat významné manažery a designéry ze slavných firem jako byly Xerox, Intel, Hewlett-Packard, Motorola, Pepsi, apod. Pečlivě vybíral lidi i do nižších technických pozic. Proslulé jsou jeho přijímací pohovory, během kterých dostával zájemce do prekérních situací a sledoval, jak si s ní poradí. Jen si představte sami sebe, pokud by se Vás někdo na přijímacím pohovoru zeptal "V kolika letech jsi přišel o panictví?" nebo "Bral jsi LSD?".

Vybíral špičkové lidi, kteří nebyli příliš upjatí a dokázali si prosadit svůj názor. Jak sám říká, chtěl se vyhnout "explozi mamlasů" neboli zamoření společnosti průměrnými zaměstnanci.

Soustřeďte se na inovaci

"Mám svoji teorii o tom, proč došlo k úpadku ve společnostech jako je IBM nebo Microsoft. Ty společnosti odváděly skvělou práci, inovovaly a získaly v určité oblasti monopol nebo skoro monopol a posléze se pro ně kvalita produktů stala méně důležitou. Společnosti si začaly vážit dobrých obchodníků, protože to jsou ti, kteří mají moc rozhodovat o tržbách, ne inženýři a designéři."

Apple je dnes považována za nejvíce inovativní firmu. Jobs si může právem připisovat zásluhy v oblastech, ve kterých jeho produkty způsobily revoluci. Macintosh byl první počítač určený pro domácnosti s grafickým uživatelským rozhraním, Pixarovské animáky nastartovaly éru digitální kinematografie, iPod změnil způsob, jakým uživatelé začali konzumovat multimediální obsah, iTunes Store vzkřísil zkomírající hudební průmysl, iPhone byl průkopníkem v dotykových chytrých telefonech, App Store umožnil prodávat malým vývojářům aplikace pro miliony uživatelů, iPad nabídl platformu pro digitální deníky, časopisy, knihy a video. A mnoho dalších.

Jobs věřil, že dlouhodobě budovat firmu lze pouze v případě, že se bude investovat do inovací. Pro firmu Apple se inovace stala prioritou a součástí celofiremní kultury. Jobs nutil lidi kolem sebe "Myslet jinak". Součástí pravidelných porad byly dlouhé diskuze na téma budoucnosti produktů.

Spoléhejte na intuici

"Naším úkolem je číst to, co ještě nebylo napsáno."

Musíte se pokusit pohlédnout do budoucnosti, abyste dokázali přijít s novátorským produktem. Jobs se nespoléhal na marketingové průzkumy. Tušil, že jeho geniální schopnosti spočívají v tom, že dokáže odhadnout, co bude za několik let hitem. Tento hit pak jednoduše vytvořil. Byl jako stopař, který zavětří odkud vítr vane, chytí stopu a už ji nepustí.

Dobrá intuice se projevila i při jeho působení ve firmě Pixar. Už to vypadalo, že oddělení animovaných filmů Walta Disneyho nemůže pořádně vydělávat. V těžkých letech investoval velké peníze do krátkých filmů. Celé jeho snažení vyústilo ve vytvoření Příběhu hraček - prvního celovečerního animáku, který vydělal na tu dobu astronomických 362 miliónů $. Další filmy studia Pixar pak obchodní zisk ještě znásobily.

Vytvořte jednoduchý, ale dokonalý design

"Náš pokrok spočívá v eliminaci, v odstraňování nadbytečného."

Design je jedním z nejvýraznější znaků produktů Apple. Jobs byl ovlivněn duchovním učením Zenu, které zvýrazňovalo jednoduchost. Dokázal zjednodušování dovést až na maximální hranici. Výrobky zjednodušoval tím, že odstraňoval tlačítka, software zjednodušoval tím, že eliminoval funkce a rozhraní zase eliminací možností. Astronom Jan Kepler již dříve prohlásil, že příroda miluje jednoduchost a jednotu. Jobs dokázal, že podobně to mají i uživatelé jeho výrobků.

Jobs dokázal propojit všechna vývojová oddělení, designéry i inženýry v jeden integrovaný fungující celek. V Apple se nejdříve navrhl design, např. počítačová skříň ve tvaru zenové krychle, a podle něho se pak musela přizpůsobit technika. Je jasné, že nejvíc nadávali technici, co že to zase ti designéři vymysleli. Jako jeden chudák inženýr, jehož úkolem bylo vyvinout myš, která by pohybovala kurzorem plynule do všech směrů. Když se vyjádřil, že něco takového nejde, druhý den už v Applu nepracoval.

Jobs byl designem posedlý a stávalo se, že prototyp výrobku byl mnohokrát přepracováván. Nechtěl dělat kompromisy i za cenu toho, že se oddálil termín uvedení do prodeje. Jako u iPhonu, jehož design byl po devíti měsících vývoje kompletně přepracován. V těžkých dobách firmy Apple se stal právě design zachráncem firmy. Na trhu s počítači, který byl zaplaven levnými šedými krabicemi (rozuměj počítači) firem Dell, Compaq a H-P, si dokázal Apple udržet dostatečný cílový segment tak, aby přežil.

Už jste si někdy rozbalovali něco od Apple?

Integrujte hardware, software a služby

"Lidé nám platí za to, že pro ně integrujeme věci, protože sami nemají čas to řešit. Chcete-li vytvářet skvělé produkty, musíte integrovat, propojovat hardware se softwarem a správou obsahu. Chcete-li proniknout na nové území, tak to musíte udělat sám. Chcete-li, aby Vaše produkty byly otevřené jinému software či hardware, musíte se přinejmenším částečně vzdát své vize."

Bill Gates svůj operační systém Windows prodal velké spoustě výrobců hardware a tím dosáhl toho, že prakticky ovládl trh s osobními počítači. Věřil, že v otevřenosti je budoucnost. Steve Jobs naopak podporoval princip uzavřeného systému. Díky své touze po dokonalosti nechtěl cizím firmám prodat licenci na svůj operační systém, aby byl provozován na levném a nekvalitním hardware. Tím se jeho počítače typu Macintosh staly nekompatibilní se zbytkem (Windows) světa.

Jobs se však nenechal odradit od své vize dokonale odladěného systému od jedné společnosti. Postupně vylepšoval všechny aspekty produktů a dokázal nabídnout inovativní technologie a služby, kvůli kterým uživatelé rádi na jeho platformu (do jeho zahrádky) přešli. O správnosti vize svědčí i obchodní vývoj Microsoftu a Apple. V roce 2000 měl Apple pouze dvacetinovou tržní hodnotu oproti Microsoftu, v roce 2010 se obě firmy srovnaly a v roce 2011 již byl Apple o 70% hodnotnější firmou než Microsoft.

Za Jobsův mistrovský kousek je považováno vytvoření iTunes Store - obchodu s digitální hudbou. Podařilo se mu přesvědčit největší hudební vydavatelství a hudební hvězdy, aby začaly svoji hudbu prodávat uživatelům platformy iPod. V té době panovala skepse, že lidé nebudou mít o takovou placenou službu zájem. Realita však překonala všechna očekávání. Miliontá skladba byla prodána po šesti dnech od zprovoznění služby, 10 miliard skladeb bylo staženo již za sedm let provozu, tedy v roce 2010.

To co udělal Microsoft v 80-tých letech na poli osobních počítačů, to udělala firma Google s operačním systémem mobilních zařízení. Vyvinula Android, jehož licenci prodala mnoha výrobcům chytrých telefonů. Vlna Android zařízení zaplavila svět. Objevil se levný systém dostupný pro široké masy. Tato zařízení však mají v mnoha případech problémy s kompatibilitou. Je to daň za velké množství permutací verzí Androidu, modelů telefonů a aplikací.

Nakonec přeci jenom Jobs vpustil externí vývojáře do svého systému. V rámci obchodu s aplikacemi App Store umožnil prodávat aplikace nezávislých vývojářů i zavedených firem. Stanovil však přísnou posuzovací proceduru, kterou musí každá aplikace projít. Chtěl se vyvarovat tomu, aby se platforma iOS zaneřádila viry a nekvalitním obsahem, který by degradoval uživatelský dojem z celého systému. Cítil morální zodpovědnost za obsah jeho služeb a proto do AppStore nikdy nepustil pornografii a bránil se i politickým materiálům.

Zaměřte se na priority

"Rozhodnutí, co nedělat, je stejně důležité, jako rozhodnutí, co dělat."

Když se Jobs nadchl pro nějaký výrobek, dokázal odfiltrovat nepodstatné problémy od těch podstatných. To mu umožnilo soustředit se na řešení těch problémů, které byly pro úspěch rozhodující. Když Jobse vyštípali z Apple a pak jej zase přemluvili, aby se vrátil, vyráběl Apple velké množství různě nekvalitních výrobků. Tržby klesaly a firma se pohybovala ve spirále smrti. První co Jobs udělal, byla revize výrobní produktové řady. Sestavil čtyři kvadranty (Zákaznický a Profesionální) x (Desktop a Přenosný) a v každém kvadrantu ponechal pouze jeden produkt. Stmelil rozklížené vývojové týmy a soustředil energii do vývoje těchto čtyř produktů. Dalším krokem bylo zrušení smlouvy s Hewlett-Packard a opuštění trhu s tiskárnami v roce 1997.

Důkazem správnosti této strategie je aktuálně vysoká prodejnost mobilních telefonů iPhone. V současnosti je Apple největším výrobcem chytrých telefonů na světě, v podstatě s jedním vícegeneračním modelem. Podíl iPhone na zisku v segmentu chytrých mobilů je kolem 73%.

Musíte umět zákazníky zpracovat

"Je důležité přesvědčit lidi o naší velikosti tím, že na ně uděláme pozoruhodný dojem, zvlášť při představení nového produktu."

Uvádění nových produktů byla Jobsova silná parketa. Pečlivě připravený scénář a schopnost vygradovat atmosféru způsobovala téměř davové šílenství. Dokázal také zapůsobit na vlivné reportéry prestižních magazínů, kteří za získání exkluzivity udělali Jobsovi pořádnou reklamu a správně zahřáli nedočkavé uživatele.

Jobs spoléhal na sílu médií a investoval do reklamy obrovské sumy. Na každé reklamní kampani se aktivně spolupodílel a projevoval i zde svoji touhu po perfekcionismu. Díky tomu mohli vytvořit reklamní spot na uvedení Macintoshe, který se vysílal během finále Super Bowlu - v nejdrahším reklamním čase. Reklama s běžící kladivářkou pak byla jedním magazínem vyhlášena za nejlepší reklamní spot všech dob. Ve svých reklamách si také Jobs drze troufnul spojit svoje produkty s největšími osobnostmi lidských dějin (Einstein, Gándhí, Picasso).

Při prezentaci svých produktů se zaměřoval na svůj obchodní cíl - na uživatele a na jejich kreativitu a zkušenost s produktem. Na této myšlence byla vybudována síť kamenných obchodů Apple Stores. Jobs věřil, že obchod je nejmocnější fyzickou prezentací značky. Každý z obchodů Apple Store je architektonické umělecké dílo, navržené podle Jobsových představ o minimalistickém designu tvořeném obvykle skleněnými prvky.

Musíte být upřímní ke svým kolegům (podřízeným)

"To je moje práce říkat na rovinu, když je něco na hovno, a ne to lakovat na růžovo."

Pokud chcete stvořit něco fenomenálního, musíte po sobě i po ostatních vyžadovat maximální nasazení. Jobs dokázal lidi ve svém okolí namotivovat tak, že překonávali svoje limity. Byl na ně zároveň velice tvrdý. Pod jeho vedením panovala nulová tolerance k nevýkonnosti. Fénování zaměstnanců patřilo k běžným komunikačním technikám. U Jobse nefungoval filtr mezi mozkem a jazykem, který by zjemňoval ostré výpady proti kolegům. Když se však s odstupem času zeptáte členů vývojového týmu Mac na spolupráci s Jobsem, dostanete odpověď, která vás může překvapit. Období spolupráce s Jobsem pro ně bylo nejúžasnější etapou jejich profesního života.

Zdvořilí a vlídní vůdcové, kteří mají starost, aby se někoho nedotkli, většinou nedovedou tak účinně prosazovat změny.

Pár vět na závěr

Život Steva Jobse je samozřejmě plný chybných rozhodnutí a špatných investic. Nezdary zažívá mnoho lidí, kteří se rozhodnou riskovat a vzít zodpovědnost do vlastních rukou. Je to normální. Ve výsledku však Jobs obstál takovým způsobem, že vytáhl garážovou firmu do čela smečky technologických gigantů.

Myšlenky a citace uváděné v tomto článku pocházejí ze životopisné knihy Steve Jobs od Waltera Isaacsona. Musím přiznat, že kniha na mě udělala velký dojem a donutila mě přemýšlet nad některými věcmi v nových souvislostech. Téměř 700 stran je nabitých zajímavostmi z doby, kdy se rodily velké věci. Z doby, kdy proti sobě stáli dva velikáni počítačového věku narození v roce 1955, oba bez dokončeného vysokoškolského studia - (otevřený) Bill Gates a (uzavřený) Steve Jobs.

Pokud máte čas, určitě si ji přečtěte, ať už jste nebo nejste fanouškem Jobse. Nebo už jste ji četli? Líbila se Vám?

Budu rád, pokud zanecháte komentář. Povzbudíte tím autora do dalšího psaní ;-) Nebo možná odradíte ;-)