Jak popsat vaše firemní potřeby ITčkáři

Proč na způsobu komunikace záleží

Proč je dobrá komunikace důležitější, než si myslíte?

• Špatné zadání = špatné řešení. Pokud vývojář dostane nepřesné nebo nejasné informace, bude improvizovat. Výsledek? Software, který možná technicky funguje, ale neřeší to, co jste očekávali.
• Nejasnosti vedou ke zdržením. Čím více otazníků během vývoje, tím více dodatečných úprav a posouvání termínů.
• Každý vývoj něco stojí. A každá nepřesnost nebo změna v zadání znamená dodatečné náklady.

Dobrá zpráva: Nepotřebujete mluvit „jejich“ jazykem

Vývojář nepotřebuje od klienta technické zadání. Potřebuje porozumět reálným potřebám firmy. A ty dokážete nejlépe popsat vy prostřednictvím konkrétních situací, problémů a očekávání.

Položte si například tyto otázky:

• Kde v každodenní práci vzniká nejvíce zdržení?
• Které činnosti se opakují a mohly by být automatizované?
• Jaké chyby se často opakují a kvůli čemu vznikají?
• Které informace potřebujete mít vždy rychle a spolehlivě k dispozici?

Technologie řeší problémy, ale jen ty, které zná

Software se nerodí z kódu, ale z porozumění. Pokud dokážete pojmenovat, co ve firmě nefunguje ideálně a co by mělo být jinak, jste připraveni komunikovat se softwarovým partnerem efektivně i bez IT slovníku.

Nejčastější komunikační nedorozumění mezi firmou a ajťáky

Jednou z nejčastějších příčin, proč vývoj softwaru neprobíhá hladce, je odlišné vnímání toho, co bylo řečeno a co bylo pochopeno. Firma řekne jednu věc, vývojář si představí druhou a výsledek často nesplní očekávání ani jedné strany.

Firma: „Chceme to jako Excel, ale hezčí.“

Vývojář: „Má jít o vizuální editor s tabulkovým rozhraním? Nebo o databázi s propojeními mezi údaji? Má se to synchronizovat s existujícím Excelem?“

Výsledek: Dodané řešení nepokrývá to, co si firma představovala, protože původní zadání bylo příliš vágní.

Firma: „Chceme jednoduché CRM.“

Vývojář: „Jednoduché jako na záznam kontaktů? Nebo i s procesem prodeje, fakturace, podporou?“

Výsledek: Dodaný systém buď neumí to, co firma očekávala, nebo je příliš komplexní a zbytečně předražený.

Kde vznikají nejčastější nedorozumění?

• Vágnost a nepřesnost: Termíny jako „jednoduchý“, „rychlý“, „jako Google formulář“ mohou mít pro každého jiný význam.
• Přílišná techničnost: Firmy se snaží mluvit „řečí vývojářů“ a používají pojmy, kterým nerozumějí a často je používají i nesprávně.
• Chybějící kontext: Vývojář ví, co má software dělat. Ale často neví proč to firma potřebuje a právě to může být klíčové.
• Zamlčená očekávání: „To jsme považovali za samozřejmost.“ věta, která se objeví vždy, když už je pozdě.

Jak těmto problémům předejít?

Popisujte problémy, které chcete vyřešit, ne technická řešení.

• Namísto: „Chceme REST API s výstupem JSON.“
• Zkuste: „Potřebujeme, aby náš sklad uměl načíst data z fakturačního systému.“

Vysvětlete kontext používání:

• Kdo bude systém používat?
• Kdy a jak často?
• Jaké údaje jsou pro vás nejdůležitější?

Nebojte se přiznat, co nevíte. Ajťáci jsou zvyklí klást doplňující otázky. Důležité je, abyste byli otevření a konkrétní.

Nejde o to, abyste se naučili „mluvit jako ajťák“. Cílem je naučit se mluvit o vaší firmě, procesech a problémech tak, aby jim vývojář rozuměl a dokázal je přeměnit na funkční řešení.

Začněte problémem, ne funkcí

Jedním z největších rozdílů mezi úspěšným a problematickým softwarovým projektem je způsob, jakým firma formuluje své požadavky. V praxi totiž velmi často zaznívá věta typu: „Potřebujeme tlačítko X,“ „Chceme modul Y,“ „Udělejte nám aplikaci na Z.“ To však není zadání, to je jen představa řešení. A ta může být (často nevědomky) nesprávná, neefektivní nebo zbytečně drahá.

Zkušený vývojář nepotřebuje vědět, jaké tlačítko chcete, ale proč ho chcete.

Proč jsou „funkční zadání“ slepou uličkou

Když firma začne popisem konkrétních funkcionalit, dostává se do role designéra řešení, aniž by měla technický nebo procesní nadhled. Výsledkem bývá software, který sice splňuje „seznam přání“, ale neřeší skutečný problém nebo ho řeší jen částečně.

Typické následky takového přístupu:

• software je zbytečně složitý,
• obsahuje funkce, které se v praxi nepoužívají,
• vznikají dodatečné úpravy, které projekt prodražují,
• uživatelé mají pocit, že systém „je proti nim“.

Správný začátek: popište realitu, ne řešení

Mnohem efektivnější je začít tím, co se ve firmě děje dnes a co nefunguje ideálně. Ajťák potom dokáže navrhnout řešení, které je jednodušší, levnější a často i technicky čistší než to, co byste si navrhli sami.

Porovnání z praxe:

❌ „Chceme aplikaci na správu zaměstnanců.“
✅ „Každý měsíc trávíme dva pracovní dny ručním zpracováním docházky. Data se přepisují z papírů do Excelu a často vznikají chyby. Potřebujeme tento proces zrychlit a zpřehlednit.“

❌ „Potřebujeme export do PDF.“
✅ „Zákazníkům posíláme nabídky manuálně a často používáme staré verze dokumentů. Chceme mít jistotu, že dostanou vždy aktuální a správnou nabídku.“

Ve druhém případě ajťák chápe cíl. A když rozumí cíli, umí navrhnout řešení, které ho splní nejen na papíře, ale i prakticky.

Pomůcka pro firmy: klaďte správné otázky

Než začnete mluvit o softwaru, zkuste si odpovědět na tyto otázky:

• Který proces nám dnes zabírá nejvíce času?
• Kde vznikají chyby, které nás stojí peníze nebo nervy?
• Které činnosti dělají lidé opakovaně a manuálně?
• Kdo se systémem pracuje každý den a co mu na práci nejvíce překáží?
• Co by se muselo změnit, abychom řekli: „Tohle funguje lépe než dosud“?

Tyto odpovědi jsou pro ajťáka cennější než jakýkoli seznam technických funkcí.

Změna pohledu, která šetří čas i rozpočet

Když se firma přestane ptát „jaké funkce chceme“ a začne se ptát „jaký problém chceme vyřešit“, mění se celý průběh projektu. Zadání je jasnější, řešení jsou cílenější a vývoj se méně „nafukuje“.

Software má sloužit byznysu, ne naopak. A prvním krokem k tomu je pojmenovat problém jazykem reality, ne technologie.

Jak připravit vstupy pro ajťáka

Bez dobrého zadání ani ten nejlepší ajťák neudělá dobrý software.

Mnohé firmy vstupují do softwarového projektu s velmi vágní představou o tom, co vlastně potřebují. Namísto toho, aby si nejdříve ujasnily, jaké procesy chtějí zlepšit a proč, začnou s popisem „technických“ požadavků, které však často neodrážejí skutečné potřeby byznysu.

Pokud chcete, aby vám vývojář rozuměl, nepotřebujete ovládat programování. Potřebujete mít jasno ve svých procesech. A umět je srozumitelně popsat.

Co si připravit před prvním setkáním

1. Seznam procesů, které chcete řešit

Nemusíte je rozepisovat podrobně. Stačí uvést, jaký je jejich účel, jak probíhají a proč vás zajímají.
Příklad:

• Evidence objednávek od zákazníků
• Vystavování faktur
• Správa reklamací
• Skladová evidence

2. Kdo tyto procesy vykonává a jak to probíhá dnes

Často se zapomíná na lidi, kteří se systémy pracují denně. Z jejich pohledu se ukáže, co v realitě funguje a co ne.

• Kdo daný proces vykonává? (např. obchodník, účetní, skladník)
• V čem to dnes dělá? (např. Excel, papír, e-mail)
• Co ho při tom zdržuje, co musí řešit ručně?

3. Problémy a zpoždění, které vás trápí

Toto je nejdůležitější část zadání. Zaměřte se na realitu, ne hypotézy:

• Kde vznikají chyby nebo překlepy?
• Které úkony se opakují a zabírají příliš mnoho času?
• Co nejčastěji způsobuje zdržení nebo nespokojenost klientů?

4. Cíle: co se má zlepšit, zrychlit nebo zjednodušit

Tady nejde o popis řešení, ale o očekávaný efekt:

• Chceme, aby fakturace trvala minuty, ne hodiny
• Chceme snížit počet chyb v objednávkách
• Potřebujeme mít přehled o stavu zakázek na jednom místě

Proč se to vyplatí

Pokud tyto informace připravíte předem, získáte:

• rychlejší návrh řešení (vývojář nemusí dodatečně zjišťovat detaily),
• přesnější odhad ceny a času,
• menší riziko nedorozumění a dodatečných nákladů,
• systém, který řeší reálné problémy, nejen ty, o kterých jste si „mysleli“, že je máte.

Komunikace s vývojářem není o technologii, je o procesu. Když mu dáte jasný pohled na svou každodenní realitu, pomůže vám navrhnout řešení, které bude funkční, jednoduché a smysluplné. Výsledný software potom nebude „technologický projekt“, ale nástroj, který vaši firmu skutečně posune dopředu.

Nemusíte vědět „jak“, stačí vědět „co“ a „proč“
Vaším úkolem není navrhnout software, ale vysvětlit, co má vyřešit a proč je to pro vás důležité.

Jednou z častých chyb ve firmách, které zadávají vývoj softwaru, je snaha přijít rovnou s vlastním řešením. Řeknou například: „Chceme modul X s tlačítkem Y, které generuje dokument Z.“ Takový přístup ale často vede ke zbytečně komplikovanému, neefektivnímu systému, protože návrh řešení není váš úkol.

Vaším úkolem je popsat realitu. Čím přesněji dokážete ajťákovi vysvětlit, co potřebujete a proč to potřebujete, tím lepší řešení pro vás dokáže navrhnout.

Co byste měli vědět (a říct)

Zaměřte se na tyto tři otázky:

Co má software dělat?
Například: „Chceme mít přehled o všech přijatých objednávkách, kdo je vyřizuje a v jakém jsou stavu.“

Pro koho je určený?
Například: „Se systémem bude pracovat skladník a obchodní oddělení. Potřebují se rychle dostat k informacím o objednávce.“

Proč je to důležité?
Například: „Dnes se tyto informace ztrácejí v e-mailech, což způsobuje chyby a zdržení. Zákazníci jsou pak nespokojení.“

Jak to vysvětlit, když si nejste jistí?

Pokud nemáte jasno ve formulacích, nemusíte panikařit. Výbornou pomůckou je popsat konkrétní pracovní den nebo typickou situaci.

Zkuste se zamyslet:

• Co přesně dělá konkrétní zaměstnanec?
• S jakými nástroji pracuje?
• Co mu funguje dobře a co ne?
• Kdy se cítí frustrovaný nebo zdržovaný?

Příklad z praxe:
„Naše účetní každý měsíc ručně kopíruje údaje o přijatých objednávkách z e-mailu do fakturačního systému. Zabere jí to celý den. Navíc se často stane, že se něco splete a faktura se musí opravovat. Chceme, aby se tyto údaje přenášely automaticky.“

Takový popis říká vývojáři mnohem více než věta: „Potřebujeme propojit e-mail s fakturačním systémem.“

Nemusíte znát technologická řešení, integrační protokoly ani názvy databází. Stačí, když víte, jaký problém řešíte, koho se týká a proč vás trápí. Vývojář je tu od toho, aby našel způsob, jak vám pomoci, ale bez vašich vstupů to nebude systém pro vás, ale pro někoho jiného.

Jak má vypadat dobré zadání?

1. Pojmenování problému
   Popište, co dnes nefunguje, zdržuje nebo zbytečně komplikuje práci.
2. Kontext
   Vysvětlete, jak proces probíhá dnes, kdo s ním pracuje a proč je to problém.
3. Cíl
   Řekněte, co by se mělo změnit a jaký přínos od toho očekáváte.

Porovnání: vágnost vs. konkrétnost

❌ „Potřebujeme digitální transformaci.“
Takové zadání nic neříká o tom, co má software konkrétně řešit.

✅ „Chceme zautomatizovat schvalování objednávek, které dnes probíhá přes e-mail a trvá někdy i 3 dny. Potřebujeme, aby schvalovatel dostal upozornění a dokázal jedním kliknutím rozhodnout, zda objednávku schválí.“
Toto už ajťákovi napoví, jaký proces má software nahradit, kdo s ním bude pracovat a co má být výsledkem.

Další příklady dobře formulovaných zadání:

✅ „Dnes musíme faktury vystavovat ručně na základě údajů z Excelu. Rádi bychom měli jednoduchý formulář, kde obchodník vyplní údaje a systém automaticky vygeneruje fakturu.“

✅ „Chceme, aby měl obchodní tým přístup k přehledu všech aktuálních zakázek na jednom místě. Momentálně jsou roztroušené v e-mailech a každý si je vede po svém.“

✅ „Potřebujeme, aby si zaměstnanci mohli přes systém požádat o dovolenou a vedoucí ji mohl schválit bez e-mailování tam a zpět.“

Praktická pomůcka: Jednoduchá struktura zadání

1. Co řešíme?
   Krátký popis problému nebo překážky v současném procesu.
2. Kdo s tím pracuje?
   Kdo jsou uživatelé? Jaké mají dovednosti? Co od systému očekávají?
3. Jak to funguje dnes?
   V čem je aktuální systém nebo způsob nevyhovující?
4. Co chceme dosáhnout?
   Jaký je cíl, ideálně vyjádřený i v čase nebo úspoře práce.

Nepotřebujete připravit specifikaci jako pro veřejné zadávání. Stačí, když dokážete jasně vysvětlit:

• co vás dnes brzdí,
• koho se to týká,
• a co má být výsledkem.

Ajťák vám pomůže přeložit tyto požadavky do technického řešení, ale dobré zadání je vaše vstupenka k tomu, aby výsledek opravdu fungoval.

Jasná komunikace šetří čas, peníze i nervy

Dobré softwarové řešení nevzniká jen u klávesnice programátora. Začíná se ve firmě při jasném pojmenování problémů, otevřené komunikaci a konkrétních cílech. Nemusíte ovládat technickou terminologii, umět psát specifikace ani znát rozdíl mezi backendem a frontendem. Co však potřebujete, je umět odpovědět na otázky jako:

• Co nám dnes způsobuje zdržení nebo chyby?
• Kde se v procesech ztrácí čas nebo přehled?
• Co by nám v práci výrazně pomohlo?

Pokud tyto odpovědi znáte, můžete být výborným partnerem pro ajťáka. Ne proto, že mu řeknete jak něco udělat, ale proto, že mu řeknete proč to potřebujete. Právě v tom spočívá klíč ke kvalitnímu výsledku.

Shrnutí hlavních bodů:

• Nezačínejte řešením, ale problémem.
• Nepopisujte funkcionalitu, popište realitu své každodenní práce.
• Připravte si vstupy: procesy, zodpovědné lidi, hlavní překážky.
• Buďte konkrétní a věcní, ne techničtí.
• Udržujte průběžný dialog během vývoje.

Dobrý ajťák vás nikdy nebude hodnotit podle toho, zda mluvíte „správným IT jazykem“. Naopak ocení, když znáte svou firmu, umíte pojmenovat, co vás brzdí, a máte jasnou představu, kam se chcete posunout. Díky tomu bude i samotný software nejen funkční, ale skutečně užitečný.