Každý z nás potřebuje dobré zadání. Výsledek je jenom tak dobrý, jak dobré bylo zadání.
Říká se tomu zadání, protože podle toho jde zadat práci. Bůh ví proč si pod tím někteří představí brief v e-mailu.
A tak si často zadání musíš vytvořit sám, protože klient neví, jak to má vypadat.
Když prodáváš vývoj nebo copywriting, klient si od tebe chce objednat vývoj nebo texty. Nechce žádné zadání, které navíc stojí ranec.
Tak to zadání často vytvoříš zadarmo, protože netušíš, jak to prodat.
Zadarmo to dělat nechceš. Ale když nevíš, jak to prodat, zadarmo to nakonec uděláš.
Nebo budeš bez zadání. Teď nevím, co z toho je horší.
— “Takže jestli to dobře chápu, vy my pošlete nabídku na vývoj, teprve až navrhnete, co to všechno má umět. Ačkoliv jsem to popsal v mailu.”
— “To se mi ještě nestalo, abych za nabídku musel platit.”
Historky z mailboxu.
* * *
Nacenit vývoj moc dobře nejde, když nevíte, co přesně budete dělat. Když je to na míru, nejde to ani rámcově, protože prostě neznáte vývojářské detaily. Ano, můžete postupovat s “nějakým” rozpočtem a doufat, že se to pod rukama programátorů nerozsype.
Nebo taky ne, protože třeba nechcete tak moc doufat.
A klient možná taky nechce doufat.
Takže jsme u toho, že zadání je významná součást vývoje.
A že to není práce na 3 hoďky u kafe.
Když děláte zadání zadarmo, dá se čekat, že klienta zobchodujete někde jinde.
A jestli nemáte plán, jak na to, tak je tenhle přístup prostě jenom hloupý. Sorry.
— “Placené zadání znamená, že dostaneš naši expertízu, ne prodejní akci.”
Vývojářské firmy používají často vendor-lock — tedy předražený provoz/support/rozvoj, protože nedokázaly prodat zadání a musí si zahojit odvedenou práci na začátku.
A to je časem semele. Negativní pověsti se ale šíří skrz celý vývojářský obor hlava nehlava.
❌ Proto tomu vůbec nefandím.
* * *
Často to zadání balíte do ceny zakázky.
Když to není v nabídce vidět, nebude do toho nikdo kecat. Snadná cesta.
Ale tvoje nabídka za vývoj (vč. zadání) bude logicky dražší než ostatní, což nechceš, takže tam napíšeš malou cenu. A to se ti pak hezky vymstí.
❌ Za mě další slepá cesta.
* * *
Naším společným nepřítelem je neznalost u klientů. Na rovinu — design a vývoj software je dost mladý obor na to, aby kdejaký Pepa věděl, co to obnáší. A že brief v pár větách se líbí možná tak řediteli, ale nejde podle toho naceňovat ani vyvíjet.
Tvorba zadání může být klidně 50 % celé práce.
Tyto postupy mi to všechno usnadňují.
Začínáme
První kontakt:
- musím zjistit rozpočet projektu
- zhodnocení, jestli je to pro nás (chceme to dělat a umíme to udělat)
- zjistit očekávání klienta (jestli je reálné, kde vnímá největší hodnotu)
- příprava půdy pro tvorbu zadání — postup, proč se to tak dělá a co z toho má
- ukázka, jak to bude probíhat — podle ukázky si klient udělá lepší představu, jestli to s vámi chce podstoupit
- výstupem je dohodnutý rámcový rozpočet a rozsah spolupráce
Druhé jednání — hlubší konzultace:
Na prvním jednání jsme zjistili, že to umíme, klient má dostatečný rozpočet, chceme spolu pracovat a souhlasí s našimi postupy. Jdeme dál:
- potřebujeme hlubší vhled do problému,
- forma workshop/konzultace (Brno-většinou osobně, jinak remote; pokud je to velká zakázka a klient vyžaduje osobně, souhlasím)
- placené/neplacené – to záleží, ale obecně cokoliv nad půlden práce 1 člověka zadarmo neděláme
- obvykle si nic moc nepřipravujeme, necháme si otevřít obzor a uvést do problematiky
- nezbytné pro sestavení přesnější nabídky na tvorbu zadání
Klíčové je, strávit víc času JEN tam, kde to dává smysl. Kvůli tomu musím odfiltrovat z hlubší konzultace neperspektivní poptávky, stejně by to byl jen ztracenej čas a nakonec by to nedopadlo. Nebo je vyřídím rychle, když to jde (a NĚKDY to určitě jde).
* * *
Rozpočet — otázka na rozpočet je pro dost lidí hotové peklo na zemi.
Ptám se na to ideálně v první polovině jednání. Čím dýl s otázkou vyčkáváte, tím spíš nedostanete odpověď. Srabům nikdo nevěří.
Takový to:
“Víte, a kdybych se mohl zeptat ještě na závěr — jaký tak na to zhruba máte rozpočet?”
To si ani nezaslouží komentář…
Ale lidi neví, kolik ty weby stojí. Někdy vám rozpočet neřeknou, protože si myslí, že mají málo a nechtějí vypadat jak chudáci. Jindy to super-strategicky tají v domnění, že získají levnější nabídku.
Rozpočet totiž není nikdy dost velký. Zvlášť v digitálu. Prošustrovat se dá kde co.
Takže budeme pro jistotu počítat s tím, že všichni mají prostě malý rozpočet.
Zásadní je zjistit, jak malý.
Každý ví, kolik za projekt chce nebo může utratit i když to nechce říct. Vždycky jsme na to přišli. I když třeba zezadu okolo potoka.
Dotazy na předchozí weby.
Když rozpočet nezjistím přímo, položím několik otázek, podle kterých si udělám představu, jak na tom s rozpočtem pravděpodobně je:
- Jaké předchozí weby jste realizoval? — sleduju jejich rozsah, použité technologie, kdo to dělal
- Jak to probíhalo? — sleduju jaký byl proces, jaké činnosti se prováděly, jak dlouho to trvalo
- Kolik vás stál ten současný web? — potvrdím si, jestli se mi odhad povedl (někdy odpoví, někdy neodpoví nebo cenu schválně sníží)
Za všemi těmi taktikami potřebuju jenom znát rozpočet, abych věděl, jestli můžu pracovat.
Dá to trochu dřiny, ale šetří to můj i jeho čas — kdybych zpracoval drahou nabídku na luxusní digitální dílo, obratem ji hodí do koše. Takových nabídek už jsem dřív nachystal.
Cenová kotva.
Obchodníci rádi používají princip cenové kotvy. Funguje to tak, že první nabídka je absurdně vysoká, což způsobí lehký šok. Všechny další nabídky jsou pak úleva. Ale hlavně – v takové situaci nedává žádný smysl tajit rozpočet.
Jdeme dál — jestli spolu chceme pracovat a jestli si rozumíme.
- zhodnotit klientovo očekávání — je to reálné, umíme to, může to tak být?
- zhodnotit naše možnosti — je to proveditelné, jsou rizika v normě?
- rozumíme si — budeme spolu chtít pracovat, dokážeme se dohodnout?
Zhodnocení očekávání klienta.
Na konci práce vás klient možná vůbec nebude hodnotit podle kvality výstupu (ano, bylo by to racionální), ale podle postupu.
Hodně lidí hodnotí naši práci podle toho, zda se splnilo jejich očekávání od průběhu. Že jsme nezapomněli zohlednit, na co oni chtěli pamatovat a různé jiné irelevantní faktory.
Sice to vůbec nedává smysl, ale zažil jsem to mockrát.
Tak si dejte bacha, abyste dopředu zjistili, na čem mu záleží a co od toho očekává.
“Nám se nejvíc líbilo, že jste si vyslechli všechno, co jsme chtěli říct a dali to nějak dohromady.”
“Všechny naše, a mnohdy i velmi všetečné dotazy, byly vždy plně zodpovězeny.”
“Po celou dobu spolupráce jsme měli přehled o tom, kam celá práce směřuje. Vždy to bylo v souladu s naší představou.”
Někdy je to skoro víc terapie než design.
Lukáš Porsche, přednáška na SEO jako Brno.
* * *
Příprava půdy pro tvorbu zadání.
Není to o ničem jiném než vysvětlení, proč se to tak dělá, jak to probíhá, jak to vypadá.
A především — k čemu mu to bude dobré.
- jistota, že si v detailech fungování rozumíme
- je to možné přesně nacenit
- dostatečně specifický popis do smlouvy
- vývojářské zadání, které bude jednoznačné a mohou podle něj vývojáři postupovat bez větších zádrhelů
Dobré zadání je takové, podle kterého můžete poptat cenové nabídky od dodavatelů, aniž by bylo riziko, že si zadání vyloží různě. Nabídky tedy budou srovnatelné.
Kvalitně připravené zadání přitahuje zájem těch nejlepších vývojářů.
Šetří to čas. Tvorbu pořádného zadání stačí podstoupit jen jednou. Nemusíte se pak trápit s každým dodavatelem ve výběrku nad těmi stejnými otázkami.
... není to složité, ale musíte jim to vysvětlit, protože lidi to neznají.
* * *
Na první schůzce toho poznáte hodně, jenom nesmíte čučet do zdi.
Každý nechcete dělat s každým. Věřím, že i mě občas odmítnou kvůli nesympatiím. Občas i kvůli tomu dotazu na rozpočet.
To je v pohodě.
Tady to furt můžete zarazit a nestrávíte s tím moc času. Doprava na schůzku a 2 hodiny konzultace. Minimum času.
Otázky, které často řešíme a jak
Známe rozpočet, ale neřekneme vám ho.
→ pravděpodobně chcete ušetřit, tak vydělte rozpočet dvěma a budeme vymýšlet rovnou levnější řešení
→ zjistěte si jej jinými dotazy; když za předchozí řešení zaplatil 100 tis., tak nové pravděpodobně zásadně jiné nebude
→ dejte klientovi rovnou nějaké 3 varianty řešení; třeba se zařadí sám, kde mu to vyhovuje
→ berte to jako varovný signál; nemusíte jít do každé zakázky
Chceme vědět, kolik to bude celé stát dopředu.
→ odveďte třeba workshop, po kterém přesněji odhadnete cenu; moc vás to nestojí a možná vám to bude pro odhad stačit
→ dejte si do nabídky dostatečnou rezervu; 20 %, 50 %, 100 % … každý to má jinak
→ vyhodnocujte projektová rizika - pomůže vám to rozhodnout se jestli to má smysl
→ berte to jako varovný signál; každý projekt není na pevnou cenu připravený
Nechceme platit za dodání nabídky na vývoj.
→ nejednejte o nabídce na vývoj, ale o nabídce na tvorbu zadání; největší klacky si často házíte do cesty sami
→ striktně rozdělujte projekt na dvě části — každá se samostatnou smlouvou o dílo, tedy i cenou
→ specifikujte si průběžné výstupy, které budou mít pro klienta hodnotu - nechce platit za workshop, ale rád zaplatí za použitelné výstupy z workshopu; hodnota, kterou si klient dokáže představit = neplatí za vzduch
→ ano, opět to můžete brát jako varovný signál
* * *
To je mých pár tipů, jak prodávat tvorbu zadání na vývoj.
Všechno, o čem tady píšu, jsem si osobně vyzkoušel. Něco mi fungovalo líp, něco hůř. A u některých metod se prostě jen cítím líp.
Třeba vám to pomůže.
Nemůžete ignorovat podstatu dobrého výsledku – dobré zadání.
Nemá smysl se tomu vyhýbat. Je potřeba brát to tak, jak to je. Zázrak se nestane.
Všichni chceme lepší digitální svět.
