BASAD.
Zpět na blog
8 min readBASAD Studios

Jak vybrat vývojáře nebo agenturu — na co si dát pozor

Většina špatných softwarových projektů selže kvůli špatnému partnerovi, ne špatné technologii. Praktický průvodce výběrem.

výběr agenturyvývojářispolupráceprojekt
Jak vybrat vývojáře nebo agenturu — na co si dát pozor

Většina softwarových projektů, které dopadnou špatně, neselže kvůli špatné technologii. Selžou kvůli špatnému partnerovi. Vývojáři, kteří přislíbí víc, než dokážou dodat. Agentuře, která nepochopila zadání. Freelancerovi, který projekt po třech měsících opustí. Tohle je průvodce, jak takové situace poznat předem — než podepíšete smlouvu a zaplatíte zálohu.

Portfolio: co skutečně hledat

Každý vývojář a každá agentura vám ukáže hezké screenshoty. Screenshoty nic neříkají o kvalitě kódu, o tom, jak spolupráce probíhala, ani o tom, jestli projekt funguje rok po spuštění.

Místo toho se ptejte konkrétně:

  • Na jaké technologii to běží? A proč zvolili právě tu? Pokud odpověď zní „protože ji umíme nejlépe", je to přijatelné. Pokud odpověď zní „protože je to nejmodernější", zpozorněte — moderní technologie není automaticky správná technologie.
  • Kdo to teď spravuje? Pokud stávající systém spravuje samotný dodavatel a klient nemá přístup ke kódu ani dokumentaci, je to varovný signál.
  • Mohu kontaktovat předchozího klienta? Seriózní dodavatelé nemají problém poskytnout reference. Pokud jsou všechny zakázky „pod NDA" nebo kontakt není možný, to samo o sobě není důvod k odmítnutí — ale zeptejte se proč.
  • Jak vypadal průběh projektu? Zda projekt skončil v termínu, v rozpočtu a bez sporů je informace, která vypovídá víc než finální produkt.

Příklad z praxe: Brněnská firma Technoprojekt s.r.o. vybrala agenturu na základě referenčního webu, který vypadal skvěle. Teprve po podpisu smlouvy zjistila, že zmíněný web vytvořil jediný vývojář, který mezitím z agentury odešel. Celý projekt musel být po půl roce restartován s novým dodavatelem.

Komunikace: červené vlajky při prvním kontaktu

První e-mail nebo první hovor odhalí o dodavateli víc, než si myslíte.

Špatná znamení:

  • Odpovídají vágně na konkrétní otázky ("to záleží na spoustě věcí, probereme to na schůzce")
  • Na nic se neptají — dostanete nabídku bez jediného upřesňujícího dotazu
  • Na vše okamžitě říkají ano — každý váš požadavek je "určitě bez problémů"
  • Nabídka přijde do 24 hodin na složitý projekt, který by si zasloužil analýzu
  • Mluví výhradně o technologiích, ne o vašem businessu

Dobrá znamení:

  • Kladou otázky, které jste nečekali ("Kdo bude systém používat?", "Jak to děláte teď?", "Co se stane, když to selže?")
  • Identifikují věci, které jste v zadání opomněli
  • Otevřeně říkají, co neumí nebo co by pro váš případ nedoporučují
  • Navrhují, jak zjistit detaily před tím, než dají finální cenu

Dodavatel, který se na nic neptá, buď vaše zadání nepochopil, nebo ho nezajímá. Obojí je problém.

Cena: co je moc levné, co je přiměřené

Cena je citlivé téma, ale platí jednoduché pravidlo: za vývoj softwaru na zakázku nelze platit ceny jako za komoditu.

Typ dodavateleOrientační hodinová sazbaTypické riziko
Offshore / nearshore (mimo ČR/SK)400–800 KčJazyková bariéra, časová pásma, nízká odpovědnost
Freelancer junior500–900 KčOmezenost, dostupnost, kontinuita
Freelancer senior900–1 500 KčKapacita, zastupitelnost
Malá agentura (3–10 lidí)1 000–1 600 KčPřetížení, fluktuace
Střední agentura (10+ lidí)1 400–2 200 KčOverhead, anonymní projekty

Pokud dostanete nabídku s hodinovou sazbou pod 500 Kč na webovou aplikaci vyvíjenou v Česku, buďte skeptičtí. Buď jde o offshore práci maskovanou jako lokální, nebo o vývojáře, který podhodnotí svou práci a projekt nedokončí.

Naopak vysoká cena automaticky neznamená kvalitu. Velké agentury mají velký overhead — projekt vedoucí, projektový manažeři, account manažeři. Za stejné peníze dostanete méně skutečného vývoje.

Praktický tip: Požádejte o rozpad ceny na konkrétní položky. Kolik stojí analýza? Kolik vývoj? Kolik testování? Kolik nasazení? Dodavatel, který odmítne rozpadnout cenu nebo není schopen vysvětlit, co za jednotlivé položky dostanete, je problematický partner.

Smlouva: co v ní musí být

Slovní dohody nestačí. Softwarové projekty jsou složité a bez písemné smlouvy se spory řeší velmi těžko. Tady jsou věci, bez kterých smlouvu nepodepisujte:

Vlastnictví zdrojového kódu. Kód, který platíte, musí být po dokončení váš. Explicitně. Některé agentury si ponechávají autorská práva a vy pak fakticky platíte za přístup k vlastnímu systému. Doložka musí znít jasně: „Veškerý zdrojový kód vytvořený v rámci tohoto projektu přechází do vlastnictví objednatele po úplném uhrazení ceny."

Předání dokumentace. Systém bez dokumentace je systém, který vás drží v závislosti na dodavateli. Smlouva musí specifikovat, co dokumentace obsahuje: technická architektura, popis API, návod na provoz, popis databázového schématu.

Podmínky maintenance. Co se stane po spuštění? Kdo opravuje chyby? Za kolik? V jaké době? Záruční lhůta na chyby (doporučuji minimálně 3 měsíce) by měla být ve smlouvě explicitně.

Eskalační mechanismus. Co se stane, pokud projekt neprobíhá podle plánu? Jak se řeší spory? Mechanismus by měl být popsán před tím, než ho budete potřebovat.

Příklad z praxe: Pražský e-shop Modexa.cz zadal vývoj mobilní aplikace freelancerovi bez písemné smlouvy. Freelancer dokončil 70 % projektu, pak byl nedostupný. Kód byl napsán tak, že ho žádný jiný vývojář nebyl schopen převzít. Ztráta: čtvrt milionu korun a šest měsíců času.

Discovery: agentury, které přeskočí analýzu, vás zklamou

Seriózní vývoj software začíná analýzou požadavků — discovery fází. Pokud dodavatel rovnou přeskočí na návrh řešení nebo rovnou na vývoj, je to problém.

Co by měla discovery fáze zahrnovat:

  • Zmapování stávajících procesů (jak to děláte teď a proč)
  • Identifikaci skutečných uživatelů systému a jejich potřeb
  • Prioritizaci funkcí — co je nezbytné pro spuštění, co může přijít later
  • Identifikaci rizik a nejasností
  • Technický návrh a hrubý odhad pracnosti

Discovery fáze stojí peníze — počítejte s 10–20 % celkového rozpočtu. Ale investice se vrátí: projekty s dobrou analýzou mají statisticky nižší překročení rozpočtu a výrazně menší počet konfliktů mezi klientem a dodavatelem.

Praktický tip: Pokud dodavatel nabídne, že discovery udělá zdarma jako součást obchodního procesu, buďte opatrní. Buď je analýza povrchní (jednohodinový workshop nestačí), nebo se náklady přesunou jinam. Kvalitní discovery nelze udělat zadarmo.

Freelancer vs. agentura vs. interní vývojář: kdy co

Žádná varianta není universálně lepší. Záleží na situaci.

SituaceDoporučená volba
Jednorázová webová aplikace, definované požadavkyFreelancer senior nebo malá agentura
Dlouhodobý produkt, průběžný rozvojMalá nebo střední agentura, nebo interní tým
Kritický systém s komplexní businessovou logikouStřední agentura nebo interní tým
Startup, rychlý MVP, nejistota v požadavcíchMalá agentura se zkušeností s MVP
Interní nástroj pro 5 lidíFreelancer
Projekt s citlivými daty nebo regulatorními požadavkyAgentura s explicitní zkušeností v dané oblasti

Interní vývojář dává smysl od momentu, kdy máte kontinuální vývoj v objemu 2 000+ hodin ročně. Pod tímto objemem je externista téměř vždy levnější — i když hodinová sazba je vyšší, neplatíte sick days, dovolenou, hardware ani softvér.

5 otázek, které položit na každém jednání

Tyhle otázky jsou efektivní přesně proto, že na ně neexistuje "správná" marketingová odpověď:

  1. „Jaký byl váš nejtěžší projekt za poslední rok a co se pokazilo?" — Dodavatel, který tvrdí, že se nic nepokazilo, buď lže, nebo nedělá dost složité projekty.

  2. „Kdo konkrétně bude na projektu pracovat a jak se řeší zastupitelnost?" — Chcete jméno a životopis, ne obecnou odpověď o "týmu zkušených vývojářů".

  3. „Jak řešíte situaci, kdy se požadavky změní v průběhu projektu?" — Každý projekt se změní. Chcete vědět, jestli mají definovaný change management process, nebo jestli to řeší ad hoc hádkami.

  4. „Co se stane, když projekt dokončíme a já přejdu k jinému dodavateli?" — Správná odpověď: "Předáme vám veškerý kód, dokumentaci a přístupy do všech systémů." Špatná odpověď: váhání nebo výhrada.

  5. „Můžete mi ukázat příklad dokumentace, kterou typicky předáváte po projektu?" — Žádejte konkrétní dokument, ne popis toho, co by hypoteticky mohl dokument obsahovat.

Červené vlajky: seznam varovných signálů

Pokud u potenciálního dodavatele vidíte tři nebo více z následujících, doporučujeme hledat dál:

  • Nabídka bez jakýchkoliv otázek k zadání
  • Neschopnost vysvětlit technické rozhodnutí bez žargonu
  • Reference, které nelze ověřit
  • Smlouva bez zmínky o vlastnictví kódu
  • Cena bez rozpadů na položky
  • Příslib termínu bez specifikace rozsahu
  • Kontaktní osoba se mění při každé komunikaci
  • Platební podmínky požadující velkou zálohu (nad 50 %) před analýzou
  • Negativní komentáře o předchozích klientech
  • Nekomunikují písemně — vše "probereme na schůzce"

Příklad z praxe: Jihlavská výrobní firma Kovotechna s.r.o. obdržela nabídku na ERP systém za výjimečně nízkou cenu — třetinu obvyklé tržní hodnoty. Dodavatel argumentoval „efektivními procesy a standardizovanými řešeními". Po podpisu smlouvy se ukázalo, že šlo o přizpůsobení hotového zahraničního systému s velmi omezenou lokalizací. Přidání každé české specifické funkce stálo extra a projekt nakonec přesáhl původní nabídku o 180 %.

CTA

V BASAD Studios začínáme každý projekt discovery fází — analýzou požadavků, zmapováním procesů a technickým návrhem, než napíšeme jediný řádek kódu. Smlouvu s jasným vlastnictvím kódu a předávací dokumentací považujeme za standard, ne za nadstandard. Pokud hledáte partnera na webovou aplikaci a chcete vědět, jak konkrétně přistupujeme k projektu, ozvěte se nám nebo se podívejte na naši službu webové aplikace.