Pro většinu lidí je komunikace s ajťáky noční můrou – raději dvacet kliků než jeden telefonát s ajťákem… nebo vlastně… ajťáci se neradi baví po telefonu a jsou nepříjemní, když jim napíšu e-mail, tak nejspíš nepodepíšou, takže jediné co zbývá, je nahodit ticket a čekat. Následně si přes ticketing vyměníme dvacet zpráv, kdy se pokaždé dozvím, že chyba je u mě, a pak se to možná vyřeší, když se naštvaný ajťák konečně osobně staví.
Toto je takový klasický případ s IT podporou. Ale něco podobného se dá aplikovat i u programátorů. Zadáte programátorovi něco tak jednoduchého jako je web a buď se výsledku nedočkáte anebo vypadá úplně jinak, než jste zadali. Při následné komunikaci programátor odmítá schůzky – nebo je na nich nepříjemný/mlčenlivý, nezvedá telefony, na maily odpovídá se zpožděním a projekt nabírá zpoždění. Pokud vyměníte programátora, chvíli to funguje a dřív nebo později se dostanete do této fáze.
Ani jedna ze situací není u firem výjimečná. V první řadě, než budete číst dále, přečtěte si tento článek od Paula Grahama – Pracovní režim tvůrců a režim manažerů (v českém překladu na Pixy.cz).
Řeknu-li to hodně hrubě, komunikace s vaším programátorem/ajťákem nefunguje kvůli tomu, že ho zdržujete.
Na druhou stranu, já si komunikaci s IT specialisty užívám. Za prvé jsem sám trošku ajťák a za druhé obdivuji jejich vysoké zaměření na efektivitu. Pokud chcete lépe komunikovat s ajťáky, řiďte se těmito pěti body:
1) Jaké je zadání, takové je řešení!
U projektů v IT, které selhaly, bylo vždy obecné zadání. Jeden projekt byl například se zadáním “vytvořte mi web”, druhý byl se zadáním “vytvořte mi kontaktní formulář” další byl se zadáním “přidejte ikonky sociálních sítí na web”. Problémem všech těchto zadání je, že jsou extrémně obecná. U prvního se nejspíš pozastavil každý – “vytvořte mi web” – to je hodně obecné – bohužel i to se běžně zadává. Ale “vytvořte mi kontaktní formulář”? Co se na tom dá zkazit?
- V první řadě byste měli definovat, která políčka mají v kontaktním formuláři být: chci jméno, příjmení, e-mail, telefon a zprávu
- V druhé řadě musíte definovat, jaké mají být popisky nad poli: “Jméno”, “Příjmení”, “E-mailová adresa”, “Telefon”, “Chcete nám něco vzkázat”
- Specifikujte, která pole jsou povinná: e-mail a zpráva
- Tlačítko odeslat bude mít text “Poslat zprávu teď”
- Definujte chování formuláře: po kliknutí do políčka formuláře se rámeček formuláře vytuční a změní na žlutou barvu,
- Definujte chybové zprávy, když některé povinné pole není vyplněné: “Prosím, zadejte svoji zprávu”, “E-mailová adresa je neplatná, neobsahuje @ nebo tečku.”
- Definujte, kde se chybové zprávy zobrazí: “Chybová zpráva by měla být vpravo od políčka”
- Definujte, jaká má být děkovací zpráva nebo i děkovací stránka, pokud má po odeslání formuláře dojít k přesměrování
- Váš marketér bude chtít určitě formulář měřit – pošlete programátorovi i kódy, které má spustit po odeslání formuláře
- Kam se má formulář posílat?
- Chcete ukládat odpovědi z formuláře v databázi?
- Pošlete grafický návrh formuláře nebo alespoň návrh tužkou
A určitě vás napadají i specifikace dalšího projektu “přidejte ikonky sociálních sítí na web” – musíte specifikovat jaké sítě, v jaké barvě, v jaké velikosti, na jakém místě atd.
Možná si říkáte, že dost věcí je samozřejmých. Ale není. Vy jste majitelem/manažerem firmy a znáte firmu i její myšlení. I programátor, který s vámi spolupracuje roky, nikdy nebude mít takové pochopení firmy ani Vás. Není to hloupý člověk, naopak. Jenom nevidí klientům do hlavy. Pokud chcete pomoci s návrhem formuláře, konzultujte jej s UX specialistou. Nikdy neexistuje dost podrobné zadání.
2) Buďte při komunikaci vždy konkrétní
Pokud pošlete zadání ve stylu: “udělejte rámeček modrý nebo žlutý”, tak typický programátor neudělá ani jeden. Má dost práce na to, aby ještě přemýšlel o tom, jakou má udělat barvu. Pokud pošlete zadání “udělej kontaktní formulář, na nic se mě neptej, prostě ať je formulář”, tak programátor se koukne na formulář u posledního projektu, který realizoval a ten zkopíruje a spustí. Nebude řešit detaily. Ale do puntíku splní vaše zadání, takže z jeho pohledu (i z mého) si zaslouží zaplatit.
Zde vzniká nejvíce víceprací i nesrovnalostí v průběhu projektu – zadání není dostatečně specifikované. Nedávno jsem konzultoval projekt, kdy klient chtěl “zmigrovat web”. Ale z klientovy optiky, CRM navázané na web je stále web. Z optiky specialisty je to informační systém. Musím souhlasit s vývojářem, ale kdyby klient písemně definoval podrobně zadání, k tomuto by nedošlo.
3) Vždy mějte každé zadání písemně
Zadání pro IT specialisty vždy posílejte písemně. I když si s ajťákem zatelefonujete, i tak to dejte do e-mailu co nejpodrobněji nebo nejlépe si vytvořte s programátorem zeď v nějakém projektovém nástroji – ať už je to Trello, Asana nebo Google Tabulky (ano i to může fungovat, když se správně pojmenují sloupce).
Úkoly v těchto nástrojích definujte podrobně! Co nemáte písemně, to jste nikdy neřekli a ani to nemůžete chtít. IT specialisté jsou velmi inteligentní, ale mají paměť na jiné věci než na dlouhé příběhy řečené ústně. Nejlépe přímo v tomto nástroji i definujte po dohodě hodinové rozmezí. Když ho neurčíte, tak se můžete občas hodně divit. Doporučuji stanovovat rozmezí +-25 %. Netrvejte na přesně daných 23.5 hodinách, protože i vzhledem k článku od Paula Grahama, to ten vývojář zatím nemůže vědět. Většina ajťáků moc nemusí osobní nebo telefonickou komunikaci, písemná většinou vyhovuje. Jednoho programátora, s kterým spolupracuji 3 roky jsem ještě neviděl a pracovně fungujeme skvěle. A i toto je jeden ze způsobů jak…
4) Udržovat vývojáře spokojené a motivované
Bohužel, aktuálně je méně schopných programátorů než manažerů. Spíš firma dokáže nahradit manažera/koordinátora než vývojáře. Špatná zpráva je, že ten vývojář to ví taky. Vy jako dobří manažeři byste měli pracovat na tom, abyste nikdy nebyli závislí na jednom člověku/firmě, ale zatím je toto velmi vzácná situace.
Ačkoliv píšu, že programátor by měl dostávat konkrétní zadání, tak tím myslím konkrétní zadání z hlediska byznys požadavků. Nikdy nemluvte vývojáři do technologie. Naopak mu dejte volnou ruku a motivujte jej k zavádění nejnovějších technologií. Váš server nyní běží na PHP 5.6. Proč to neaktualizovat hned teď na PHP 7? Sice ten web běží a zdá se, že ještě dlouho bude, ale tím updatem získáte vyšší rychlost a už nyní jste připravení na novou verzi redakčního systému, která sice vyjde za rok, ale jste připraveni. A programátor může v nových řešeních využívat nové funkce. Někomu to nemusí znít logicky, ale toto je to, co programátoři chtějí. Chtějí projekty, na které mohou být hrdí. A potom se mění celý jejich přístup. Když programátor má tři požadavky do zítra a finanční odměna je +- stejná, který projekt si vybere? Ten který ho bude bavit. Nechte vývojáře pracovat na těchto projektech, i když o nich možná máte zatím pochybnosti. Nikdy neříkejte svému programátorovi – nový web musí být na šabloně Avada s WordPressem a pořádným pop-upem přes MailChimp. Už tímto zadáním jste odradili veškeré schopné vývojáře. Když ale řeknete: “Potřebujeme nový web, máme tento rozpočet, můžeme s ním pracovat, máme od webu tyto požadavky (podrobně specifikujte včetně modelů – klidně zmiňte i ten pop-up a co se vám líbilo na šabloně), navrhněte nejlepší řešení.” Dosáhnete mnohem více.
Samozřejmostí je odměna minimálně na úrovni tržních standardů.
Ale nikdy nezapomeňte…
5) Ajťák nikdy nesmí získat pocit, že je nenahraditelný
Když ajťák získá tento dojem, tak je to začátek konce. Zažil jsem situaci, kdy IT specialista tak dobře uchovával know-how a zároveň si zlepšoval podmínky (hlavně finanční), že firma při ukončení spolupráce přestavovala úplně celý web i CRM – obrovské náklady. Běžně se stává, že po odchodu IT specialisty/programátora nikdo nechápe, jak je to vlastně postavené. A běžně se také stává, že ajťák má jako jediný nejvyšší přístupy i s právem je měnit. Za prvé, buďte vždy majiteli nejvyšších přístupů do všeho, za druhé nechte vývojáře vést dokumentaci. Nemusí to být žádné elaboráty jako v korporátech, ale podobně schopný programátor by měl po prostudování pochopit, co tím chtěl autor říci. Nejlepší pro získání svobody je využívání modulárních redakčních systémů, kdy je stejné jádro a následně vývojáři “pouze” vytváří pluginy a upravují vzhled v šablonách. Tento vývojář ví, že se musí snažit, jinak by o tento zajímavý projekt, s nejlepší technologií, který má určitě jako referenci, mohl přijít.
Uvidíte, že při dodržování těchto zásad získáte ve svém IT specialistovi/programátorovi parťáky pro svůj byznys.
