Tento text berte prosím jako referenci, ze které můžete vycházet. Trh s developery, technologiemi a vším okolo webu je velmi široký a není v silách jednoho článku podat vyčerpávající odpověď. Navíc jsou tu další a možná i mnohem důležitější věci - jak dobře si sednete s lidmi na druhé straně, zda ve vaší práci uvidí smysl apod. Můžete sehnat sebelepšího vývojáře, ale pokud si nebudete rozumět a nedokážete normálně komunikovat, na výsledku se to projeví.

Pokud navíc nejste opravdu technicky zdatní, programátor vás vždy dokáže "obelstít". Stačí mu najít hranici, kde už nedokážete jeho odpovědi zhodnotit. Spoustu věcí si také nemůžete reálně kontrolovat, takže musíte věřit jeho slovu. To staví do extrémně důležité pozice důvěru, kterou k developerovi chováte.

1. Jak starý je systém?

Vaše první otázka by měla směřovat na systém jako takový. Snad každá společnost má připravený nějaký základ, který dále ohýbá pro konkrétního zákazníka. Čím větší je připravená část, tím více funkcionalit dostanete v základu. Zeptejte se, jak staré je jádro systému a jak se vyvíjelo v čase. Získanou odpověď si musíte zasadit do kontextu - 10 let starý systém může být vyzkoušený a odladěný, pokud ale neprochází vývojem, omezí to použití moderních technologií. Pokud společnost na něčem pracuje teprve pár měsíců, je dobré zjistit příčinu - co dělali předtím a proč to opustili?

2. Použité technologie

Webové technologie se vyvíjí opravdu rychle a 2 roky stará věc již nemusí mít ani podporu bezpečnostních aktualizací. Zjistěte si, na jak starých verzích systém běží a především jak jsou řešeny aktualizace knihoven. Ty se týkají také bezpečnosti - průběžně se objevují opravy bezpečnostních děr a ty chcete mít určitě nainstalované.

Mnoho společností vám některé aktualizace nacení. Tomu se nedivte, je možné, že při přechodu na novou verzi bude nutné upravit kód a aplikaci otestovat. Normálně se to týká pouze větších upgradů, ale je dobré o tom vědět. Dobrý developer vás na nutnost pravidelné správy upozorní a řekne vám, jak obvykle probíhá.

3. Jádro systému (Framework)

V dnešní době je zvykem použití frameworku. Ve světě PHP jsou populární například Symfony, Laravel, nebo české Nette. Ty poskytují určitou kostru aplikace, doporučení pro programátory (něco jako směrnice) a obvykle také spoustu připravených balíčků od jiných programátorů. Použití frameworku je dobrá věc z mnoha důvodů:

• Pravděpodobně je napsali mnohem lepší vývojáři, než se kterými pracujete (čest výjimkám)
• Automaticky řeší věci, na které by váš programátor mohl zapomenout (bezpečnost apod.)
• Dovolují jednoduše použít balíčky od jiných vývojářů
• Poskytují určitou (nikoli však dostatečnou) záruku toho, že v kódu se vyzná i cizí programátor, který zná daný framework

Opět zde platí, že chcete používat co možná nejnovější verzi frameworku a mít vyřešené jeho aktualizace.

Pokud ale společnost staví vše na svém vlastním systému, mějte se na pozoru. Nemusí to být nutně problém, ale klade to na její programátory mnohem větší nároky a především riskujete, že žádný jiný vývojář se do systému nebude chtít angažovat. To může být velký problém ve chvíli, kdy se s developerem rozejdete. Použití frameworku ale samozřejmě automaticky neznamená, že aplikace bude napsaná dobře a že seženete jinou firmu, která bude ve vývoji pokračovat.

Říká se, že většinu problémů již někdo vyřešil před námi. Vývojáři proto často mají možnost stáhnout a použít balíček, který už napsal někdo jiný. Zeptejte se proto, zda to dělají. Velmi pravděpodobně dostanete kladnou odpověď, ale je dobré se ujistit, že váš programátor si vše nepíše sám (takového nechcete).

4. Zkušenosti

Dělal tým už někdy dříve projekt podobného rozsahu / ve vašem oboru? Zeptejte se na zkušenosti, problémy, které se vyskytly, řešení apod. Pokud je váš projekt důležitý, zkuste kontaktovat někoho i na straně klienta a vyptat se. S trochou štěstí dokážete zjistit, jak lidé u developera přistupují k řešení problémů, jak fungují a jestli je opravdu vše tak růžové, jak vám maluje projektový manažer nebo obchodník.

Pokud řešíte složitější web, zjistěte si také, jak seniorní vývojáře společnost má - jak dlouho pracují v oboru, jací jsou jako lidé apod. Chtějte také vědět, kteří lidé budou na vašem projektu pracovat - developer bude mít pravděpodobně více zakázek a je důležité, aby na vás nezbyl 1 junior.

5. Zastupitelnost

Pokud váš projekt tvoří 1 člověk, zastupitelnost je pravděpodobně nulová. Ale ani u větší společnosti to nemusí být nutně lepší - programátoři často dělají na projektech sami a výsledek je podobný. Chtějte vědět, kolik vývojářů se vám bude věnovat i s ohledem na předchozí bod. Vždy je lepší, pokud kódu rozumí více lidí. Pozor na různé role v týmu - například grafik vám pravděpodobně nic nenaprogramuje.

6. Code review

Tady se už dostanete blízko k vývojovým procesům. Code review označuje techniku, kdy vývojář něco naprogramuje a jeho kód musí projít, otestovat a schválit jiný programátor. U větších společností mohou schvalování dělat klidně 2 vývojáři. Jedná se o velmi užitečný návyk, který předchází řadě problémů. Jiný programátor vidí (nebo alespoň by měl) kód nezaujatě a často přijde na něco, co jeho kolegu nenapadlo. Stalo se vám už někdy, že jste napsali text, 3x si ho přečetli a stejně tam pak byla chyba? Váš mozek čte to, co jste chtěli napsat, nikoli to, co jste skutečně napsali. Stejně to funguje i u programování. Další výhoda je, že kódu bude rozumět více programátorů, což zlepší zastupitelnost v týmu.

Zeptejte se, jak developer přistupuje k tomuto tématu. Pokud nepoptáváte vyloženě freelancera (1 člověk), měla by být kontrola kódu standardem.

7. Testy

Problematika testování je velmi komplexní, v zásadě ale programátor kromě požadované funkce napíše i další kód, který ji "testuje". Když se později bude v systému něco upravovat, test zajistí, že se nerozbije jiná funkcionalita (nebo se vývojář dozví, že něco není v pořádku a může na to reagovat). To je alespoň teorie, v praxi to samozřejmě tak ideální a jednoduché není. Mít dobré testy je opravdu těžké a klade to vysoké nároky na znalosti programátorů / testerů. Testů je také mnoho druhů a ne každý vývojář umí psát všechny varianty. Ideální ale je, pokud projekt "chrání" co nejvíce typů testů.

Vaše první otázka by měla být, zda je tým zvyklý psát testy. Pozitivní odpověď neznamená automaticky kvalitnější výstupy, ale je to minimálně dobrý základ. Dále se zeptejte, co vše bude testováno. Obvykle není reálné mít testy pokrytou veškerou funkčnost projektu a vybírají se tak ty nejdůležitější části webu. Určitě chcete mít otestovány kritické věci typu zobrazení úvodní stránky, kategorií a detailu produktu, průchod objednávkou apod. Především u větších zakázek je zásadní, aby se testy spouštěly automaticky. V opačném případě je programátoři mohou ignorovat a pozbývají tím smysl.

Jako u všech bodů platí, že čím větší projekt řešíte, tím lepší testy byste měli požadovat. Pokud s nimi ale vývojáři nemají zkušenosti, nemá smysl je tlačit. Naučit se psát kvalitní testy vyžaduje čas a pokud s nimi tým začne od nuly, přinesou spíše mnoho hodin strávených navíc a žádné reálné problémy neodhalí. Pak musíte zvážit, zda vybrat jiného dodavatele, spolehnout se na manuální testování nebo prostě usoudíte, že se nejedná o tak důležitý projekt, aby bylo potřeba to řešit.

Buďte připraveni na to, že developer vám může automatizované testy přidat do kalkulace. Dobrý programátor obvykle testy píše sám, faktem ale je, že se může jednat o práci navíc. Na toto téma se vede mnoho diskuzí a nejčastější argument je o tom, že pokud vývojář testy nepíše, ušetří tím sice na začátku čas, ale o to více chyb se v aplikaci objeví později a o to více času je třeba na manuální testování. Čím rozsáhlejší projekt, tím se může objevit více neočekávaných závislostí. Představte si to tak, že programátor udělá změnu na detailu produktu, tester se ale pak musí proklikat celou objednávkou, protože nikde není záruka, že se tam něco nepokazilo.

8. Limity aplikace

Co aplikace nebude umět? Kde jsou její limity? Jaké změny už budou složité a drahé? Toto jsou velmi podstatné otázky. Nenechte se odradit typickými odpověďmi typu "Žádný limit tu není", "Když se domluvíme a specifikujeme to, naši vývojáři zvládnou vše" apod. Každý web má limity a není špatné o nich vědět. Bude vás to stát pravděpodobně čas a spoustu trpělivosti, protože žádný programátor vám otevřeně neřekne, co už nezvládne. Vysvětlete vývojářům, že se nesnažíte hodnotit kvalitu jejich práce, ale chcete mít co nejlepší obrázek o tom, co můžete čekat. Zeptejte se na konkrétní úkoly (například integrace skladových systémů, rozpoznávání barev či obličejů v obrázcích, složité filtrace a průvodci apod.) a otevřeně se o nich pobavte. Pokud máte dobrého developera, lidé se zkusí zamyslet nad vaším byznysem a přijít s vlastními věcmi.

Může se stát, že z této diskuze vypadnou zajímavé funkce, které můžete dále řešit a nakonec zahrnout do zadání. A pokud ne, budete mít alespoň dobrý obrázek, kam až vaše nová aplikace dosáhne.

9. Fungování týmu

Říkají vám něco pojmy jako je "Vodopád" nebo "Agilní vývoj"? Pokud ne, zkuste si o nich něco málo zjistit. Další otázka na dodavatele by se měla týkat právě tohoto.

Pojem "Vodopád" označuje tradiční přístup, kdy se napíše zadání, vývojáři pár měsíců programují a pak prezentují "hotový" produkt. Vy (jako zadavatel) tak vidíte až finální výsledek. Realita je pak taková, že se spousta věcí musí předělat / dopracovat - kvůli nepochopení zadání, rozdílné představě o chování některých funkcí apod. Výhoda tohoto procesu může být v tom, že máte dopředu danou částku a časový rámec za zakázku. Hodí se ale většinou spíše na malé a jednoduché projekty - čím větší web, tím se většinou objeví širší nůžky mezi očekávanou a naprogramovanou funkčností a následná jednání o úpravách stojí čas a peníze.

Agilní vývoj naopak stojí na velké interakci s vámi jako zadavatelem. Tým má daná časová okna (sprinty), která trvají třeba 14 dní. Vývojáři si určí úkoly, které by se v této době měly stihnout a na konci sprintu je možné je prezentovat. Vy tak můžete průběžně kontrolovat dodané výstupy a korigovat směr, kterým se vývoj ubírá. To je největší výhoda tohoto přístupu - nemusíte čekat na dokončení celého projektu a pak upravovat spoustu věcí. Vidíte průběžný vývoj a můžete na něj reagovat. Nevýhodu můžete spatřit v tom, že není přesně daný rozpočet ani čas dokončení projektu. To je ale vyváženo možností průběžně měnit zadání (například přidávat / ubírat funkce). Musíte být také technicky zdatný, protože můžete dostat k otestování věc, která není nastylovaná a je pak obtížné rozlišit, co je pouze vizuální drobnost a co je chyba od vývojáře. Tento přístup se obvykle hodí pro větší projekty. Velmi dobře se také využije, pokud potřebujete rychle otestovat nějaký nápad či aplikaci, u které není jistý úspěch.

Na tuto otázku není univerzální dobrá ani špatná odpověď. Vhodná metodika závisí především na velikosti zakázky, jejím typu (firemní prezentace o pár stránkách vyžaduje jiný přístup, než e-shop s inovativními funkcemi, které uživatelé nemusí ani umět použít), vašich zkušenostech a dalších faktorech.

10. Rozsah služeb

Uvědomte si, že nový web nestačí jen naprogramovat. Pokud chcete uspět, je vývoj někde uprostřed mnoha dalších činností, které musíte mít vyřešeny - strategii, použitelnost, uživatelské testování, marketing, obsah a texty (copywriting) a spoustu dalších. Pokud o těchto věcech nemáte tušení, běžte na školení strategického webdesignu, které vám otevře obzory.

A co to má společného s developerem? On by vám měl v těchto věcech pomoci a hlavně musí web vytvořit "dobře". A to není tak jednoduché a běžné. Vývojáři si často zjednodušují život (případně o některých věcech ani neví) a to se může projevit v úspěšnosti nového webu. Ptejte se proto, jestli má společnost experty na různé oblasti, jestli sledují novinky a jak je implementují.

Počítejte ale s tím, že budete muset developerovi prostě věřit, že svou práci opravdu udělá dobře. Pokud chcete mít jistotu, oslovte experta na každou oblast, aby vám pomohl definovat důležitá hlediska webu, ideálně je zanést do smlouvy a hlavně zkontrolovat.

11. Import dat a spuštění nového webu

Tento bod je úzce spojen s tím předchozím, kvůli jeho důležitosti jsem ho ale dal samostatně. Import dat ze starého webu (produkty, kategorie, články, uživatelé apod.) totiž není jen o naplnění nové databáze. Musíte si pohlídat například:

• URL adresy (nechte je stejné, pokud to není možné staré varianty přesměrujte)
• Import různých parametrů (titulky stránek, popisky obrázků apod.)
• Zachování uživatelských odběrů (hlídání dostupnosti a ceny)
• Kontinuita dat (například u Google Analytics, personalizace obsahu)
• Přihlašování již existujicích uživatelů
• Povolení indexování webu (a naopak zákaz indexace vývojového)
• A mnoho dalšího.

Na začátku by se vás developer měl ptát sám - jaká data budete chtít importovat, v jakém je máte formátu apod. Tohle budete nejspíš řešit i v kalkulaci a ve smlouvě. Vy si především zjistěte, zda dodavatel dokáže zachovat URL adresy a jak má zabezpečené spuštění webu. Na internetu naleznete mnoho seznamů, kterými se můžete inspirovat - například od Lukáše Pítry a Ondry Ilinčeva.

12. Komunikace

V tuto chvíli byste již měli mít dobrý obrázek o tom, jak se se společností komunikuje. Jsou otevření a ochotní? Zajímají se o váš projekt nebo chtějí jen podepsat smlouvu? Přicházejí sami s nápady a řešením? Nechají vás komunikovat s lidmi uvnitř týmu, nebo veškerou komunikaci schovávají za projekťáka / obchodníka?

To všechno jsou otázky, které pocitově dokážete ohodnotit. Čím větší a důležitější web děláte, tím více byste měli chtít, aby developer nebyl jen obyčejný dodavatel, ale spíše váš partner. U velkého projektu ostatně spolupráce neskončí za pár měsíců. Na rovinu přiznejte, že hledáte partnera, který se k problémům postaví otevřeně a férově (a buďte si jistí, že problémy dřív nebo později přijdou), a který dokáže hledat a navrhnout řešení. Na druhou stranu buďte připraveni občas slevit ze svých požadavků (především čas a peníze), abyste dospěli k nějaké shodě. I developer je přeci společnost, která vydělává peníze.

13. Zkušenosti se současným webem

Máte už současný web? Proč vám nedostačuje? Zeptejte se svých vývojářů, kde viděli problémy, jaké to byly, jak je řešili nebo proč se je nepovedlo řešit. Zde můžete získat nejen podklady pro novou aplikaci, ale i zpětnou vazbu - měli problémy i s vámi (myšleno komunikací, zadáním apod.)? Otázky na současný tým jsou samozřejmě podmíněné skutečností, že jste se nerozešli ve zlém.

Pokud získáte odpovědi, zamyslete se, jak podobným nedorozuměním v budoucnu předejít. Důležité věci ukažte i novému týmu a zkuste najít cestu, aby se podobné problémy neopakovaly. A pokud náhodou pokračujete se stejným týmem, zkuste si to projít i s ním, třeba komunikaci mezi vámi dokážete zlepšit.

14. Technický dozor

Jak už jste asi pochopili, tvorba nového webu není jednoduchá záležitost. Můžete se rozhodnout, že některé věci nebudete řešit nebo prostě budete svým vývojářům důvěřovat. Pokud ale chcete mít kontrolu, můžete si k projektu přibrat technický dozor. To by měl být člověk se širokým rozhledem, který bude kontrolovat práci developera. Rozsah práce se bude lišit dle velikosti projektu - od prosté kontroly těsně před předáním díla, přes průběžný dozor při vývoji až po náhled do zdrojových kódů a doporučení vývojářům.

Rozsah kontroly si musíte předem vyjednat nejen s tímto člověkem (může to být samozřejmě i více lidí na různé oblasti), ale především i s developerem. Ne každý vám dá přístup do zdrojových kódů, ne všude budou souhlasit s tím, že kvalitu jejich práce bude kontrolovat expert apod. Zde bude důležité i to, jak si nastavíte smlouvu.

Seznam otázek

Pojďme si shrnout nejdůležitější body, o které byste se měli zajímat:

• Jak starý je systém? Není příliš starý nebo naopak nevyzkoušený?
• Jsou vyřešeny aktualizace systému?
• Je použitý nějaký Framework?
• Má developer s podobným projektem zkušenosti?
• Potřebujete zastupitelnost lidí z týmu?
• Dělají programátoři code review?
• Jak velká část projektu je pokryta automatizovanými testy?
• Kde jsou limity aplikace?
• Používá tým agilní nebo vodopádový model vývoje? Který je pro vás vhodnější?
• Pomůže vám developer také s ostatními věcmi mimo programování?
• Dokážete zachovat URL adresy a zabezpečit bezproblémové spuštění nového webu?
• Jaký pocit máte z komunikace? Bude developer váš partner?
• Můžete využít zkušenosti, které jste nasbírali u současného webu?
• Vyplatí se vám domluvit si nezávislý dozor?

Závěrečné myšlenky

Tento článek určitě není vyčerpávající, mnoho témat je zjednodušených a každý váš projekt bude mít trochu jiné potřeby. Závěrem uvádím dalších pár věcí, na které je dobré myslet:

• Jsou zdrojové kódy vaše?
• Jak se zálohují data a jak je vyřešená jejich obnova? Je tento proces vyzkoušen?
• Máte ve smlouvě garanci dostupnosti?

V praxi těžko seženete tým, který splní všechny uvedené body, pokud nemáte opravdu štědrý rozpočet. Vždy musíte posuzovat nejen kvalitu, ale také náklady. Někde prostě nedávají určité kroky smysl, tak to mějte na paměti. A nakonec musím zopakovat, že nejdůležitější ze všeho, je právě důvěra. Přeji vám hodně štěstí při výběru vhodného developera.