Jsem vývojář a dělám svou práci! Proč se mě ptáš na jakousi vizi?

Poslední dobou jsem několikrát při diskuzích se zákazníky a přáteli narazil na situaci, že lidé z produkce tvořící produkt nebo udržující IT službu netuší a ani neřeší, co přesně zákazníkovi za hodnotu tato služba/produkt dávají a proč by se měli starat o jeho/její vizi…Ještě horší je, když to neřeší či neví, ani jejich nadřízený (team leader, service manager, projekťák, …) nebo vlastník produktu.

Proč je neznalost vize, strategie problém a proč by to vůbec mělo lidi z produkce zajímat? „Já jsem přece vývojář a neřeším manažerské a byznysové věci. To ať si řeší manažeři, já jen dělám svoji práci!“ Varianty na takové věty slýchám jako nejčastější odpověď vývojářů a specialistů. Stejný člověk potom křičí: „Jak může být zákazník nespokojený, vždyť my doručujeme přesně co on chtěl!“ Ale je to opravdu to, co zákazník potřebuje pro podporu JEHO denní činnosti? O tlaku na vyšší produktivitu a sekání nákladů nemluvě, někde ušetřit musíme, když zákazník nechápe, za co platit a tak neustále tlačí na snížení ceny. Jak jsem tedy schopný dodat přesně to, co zákazník potřebuje, když ani nevím, co vlastně v tom svém byznysu denně dělá a jak moji službu/produkt používá?

Jako odpověď, jestli by měli vývojáři a maintenance lidi vědět a řešit, jaká je vize produktu nebo služby by mohly stačit následující otázky:

• Podle čeho se rozhodujete jestli nový požadavek na změnu přijmout nebo zamítnout?
• Podle čeho navrhujete architekturu produktu/služby?
• Vůči čemu děláte denní návrhová rozhodnutí?
• Na základě čeho se rozhodujete jestli fixnout incident co nejrychleji a nebo radši prodloužit dobu jeho řešení, aby se neopakoval?

Vývojáři i maintenance lidé si mnohdy stěžují na nadmíru práce, přetížení, zavalení operativou… Jedna z příčin těchto problémů je ale výše zmíněná chybějící vize, na základě které se denně rozhodujeme. Když mám jasnou vizi produktu, upřesněnou základními byznys scénáři, které podporujeme, včetně základních funkčností aplikace, pak je zřejmé, že protichůdnou vlastnost neschválíme a držíme si konzistentní jádro zdrojového kódu.

Pokud vizi nemáme, je pak zřejmé, že schválíme i druhotné funkčnosti a také funkčnosti, které mohou být protichůdné původnímu podporovanému byznys scénáři! Právě to se běžně děje! Děláme všechno všem, protože nikdo neví, co vlastně produkt je a nikdo ani nechce říct zákazníkovi NE, protože ANO na vše znamená AKTUÁLNÍ příjem. Exponenciálně narůstající složitost kódu v takovou chvíli nikdo neřeší. Nepotřebné či protichůdné funkčnosti ale nejen komplikují zdrojový kód, ony také zesložiťují testování, hledání a navození chyby, nemluvě o použitelnosti z pohledu koncového uživatele. Tato zesložitění a komplikace nás stojí čas a způsobují tedy výše zmíněné přetížení.

Co s tím? Jak aspoň částečně odstranit tento problém? Stačí se chvíli zastavit, říci si následující a začít odmítat protichůdné nebo nedůležité funkčnosti. Co si tedy ujasnit s vlastníkem produktu a zákazníky?

• Kdo je náš zákazník? Napište si role, persony typických uživatelů. Jaké jsou jejich typické denní úkoly, problémy, potřeby, co oni vnímají jako pomoc, hodnotu? Pokud chcete doručit opravdovou hodnotu, pak nemůže být výsledkem tohoto kroku „všichni“.
• Jak a k čemu používá naši službu/náš produkt (z pohledu byznysu a byznys řečí! ;))
• Pobavte se se zákazníkem, co on vnímá jako hodnotu a je ochoten za ni platit?To, co vnímáte jako hodnotu vy, může být jím vnímáno jako nutnost, jako nezbytná součást služby. Nejdelší seznam funkčností není vždy to nejlepší. Jen jedna implementovaná funkčnost, která přesně naplňuje potřebu je vždy více.
• Napište nebo nakreslete základní byznys scénář(e) a sdílejte je s týmem.
• Definujte základní a prioritní funkčnosti vašeho produktu naplňující tyto byznys scénáře.
• Naučte se říkat NE na ty požadavky, které jdou mimo váš rozptyl (ale analyzujte je, zda nestojí za to, pozměnit vizi produktu novým, žádaným směrem).
• Neustále (v rozumných intervalech) vizi aktualizujte podle změn na trhu, vašeho směřování a potřeb zákazníků.

Vývojář, IT specialista, tester, databázista, specialista Service Desku, prostě kdokoliv v denní IT produkci a vývoji se musí o vizi a potřebu (hodnotu) pro zákazníka zajímat, jinak není schopen doručit zákazníkovi to, co opravdu potřebuje. IT už dávno není přidanou hodnotou ale naopak nezbytností řídící většinu podnikání firem. Čím lépe a více bude IT podnikání zákazníka podporovat, tím více bude zákazník vnímat firmu jako proaktivní, což je buzzword zmiňovaný nespokojenými zákazníky už roky (teď aspoň konečně víme, co tím zákazníci myslí).

Pokud se i přesto rozhodnete, že vás zákazník a jeho potřeby nezajímají, pak se musíte smířit s menším platem, neustálým tlakem na cenu, hrozbou propuštění a také s méně zajímavou prací.

Aktualizace z 15.4. 2014 (na základě diskusí k článku na sociálních sítích): v článku popisuji nutnost znalosti potřeby zákazníka, ne řešení, jak tuto potřebu naplnit. Řešení samozřejmě zákazník většinou nezná, jeho nalezení je právě úkolem nás, ITíků. A znalost potřeby neovlivňuje to, zda zákazník je nebo není 1000km daleko, ale to, jak se snažím tuto potřebu zjistit. Důležité je vědět, co vlastně dělá náš zákazník. Je to slévárna, banka, lékárna, pojišťovna? A k čemu tam uživatelé vlastně ten náš produkt používají? Samozřejmě je nelepší je vidět při práci, ale pokud je zákazník v USA a tým v Indii, pak stačí pozorovat podobnou firmu, jinou banku či výrobní firmu.

Jako příklad toho, kdo se zákazníků na nic neptal a nedělal marketingové výzkumy je uváděn často Steve Jobs, ale tady je nutné zmínit že on měl (ať už vědomě nebo nevědomě) obrovskou znalost potřeb svých zákazníků, proto se jich nemusel ptát.

Článek je také cílený na rozvoj a dodávání hodnoty u již existujících produktů a služeb (tzv. sustaining innovation), nehovoříme o vytváření nových produktů, služeb, kde neznáme přesně cílovou skupinu ani byznys model (tzv. disruptive innovation). Ale i v případě těchto nových, průlomových inovací (disruptive innovation) ověřujeme myšlenku s trhem, s uživateli a upravujeme směr našich myšlenek – viz metoda Lean startup.