Na co je třeba si dát pozor, než se pustíte do softwaru na míru..
Vždy je levnější a celkově lepší varianta si koupit již hotový produkt na to, co potřebuji. Na správu zákazníků a obchodní aktivity si vyberu nějaký CRM, na vedení projektů a úkolování lidí nějaký Task Management atp. Ta doba, kdy bylo potřeba si na tyto věci shánět programátora, je bohudík již dávno pryč a je to tak dobře, protože vymýšlet vymyšlené se vám nikdy nevyplatí.
Jsou ale situace, kdy řešíte nějakou hodně specifickou věc, kterou máte pouze ve vaší firmě, a pak dost často žádný takový produkt na trhu není a pak máte v podstatě dvě možnosti. Buď tuto specifickou věc nahradit něčím standardním, anebo si najít nějakého programátora, aby vám s tím pomohl.
Mít jasnou vizi je základ
Pokud už se do něčeho takového pustíte, tak je dobré si uvědomit, že to nikdy není běh na krátkou trať. Nejprve musíte přesně programátorovi vysvětlit, co potřebujete, pak on to naprogramuje a pak vy to budete používat. A protože se svět pořád mění a s tím i váš business, tak s největší pravděpodobností budete potřebovat i ten software časem upravovat.
Další věc, na kterou nesmíte zapomenout je, si dobře promyslet, kde bude vaše firma za rok, dva či pět let a jestli to, co chcete teď, bude pak ještě dávat smysl. Na toto většinou firmy zapomínají, protože jen řeší aktuální problém. Jenže pokud si toto hned na začátku nepromyslím, tak se mi to může potom ošklivě vrátit. Proč je to tak důležité?
Každý software má svoje kosti. Programátor musí vždy na začátku udělat některá základní rozhodnutí a od těchto základních rozhodnutí se pak odvíjí celá jeho další práce. U větších systémů pak tito lidé, kteří dělají tyto základní rozhodnutí, se nazývají softwaroví architekti. Ti definují kosti systému a s těmito kostmi pak už není za tak jednoduché pohnout, a když už se to musí udělat, tak to bolí jako zlomenina. Bolí to jak finančně tak i časově, protože je to většinou spoustu práce.
Proto je důležité, abych si na začátku hodně dobře promyslel, jak chci, aby to celé fungovalo. Toto nesmím za žádnou cenu podcenit. Samozřejmě ono se to lehce řekne, ale v praxi už to tak jednoduchý není a to ze dvou důvodů. Za prvé málo kdo z nás dokáže věštit budoucnost, aby dokázal odhadnout kam trh, či zákony půjdou a za druhé i když jsem majitel vizionář, tak se mi stejně asi nepodaří tomu programátorovi to vysvětlit tak, aby on tu moji vizi přesně pochopil. Programátoři hold přemýšlí jinak a s tím se nedá nic moc dělat. Co tedy s tím?
Dělá se to většinou tak, že sepíše na papír, jak to má celé fungovat. Tomu se říká funkční specifikace. Tady je nejlepší, když tento popis vytvoříte vy ve vaší firmě, protože vy máte tu vizi a vy v podstatě víte, co chcete. Ne každý je ale spisovatel a často krát je to spíš tak, že vám s tím musí někdo pomoci. Rozumný dodavatel softwaru se rád nabídne, že vám s tím pomůže. Ono je to totiž v jeho zájmu, mít dobré zadání pro programátory, protože si tím ušetří spoustu budoucích diskuzí či reklamací. Samozřejmě za tuto pomoc si řekne o nějaký ten peníz, ale tady doporučuji radši nešetřit, protože lámat pak kosti je vždy horší.
Dobrá rada nad zlato
A tady to důležitý. Tu funkční specifikaci, kterou získáte, je třeba hodně podrobně pročíst a zkontrolovat, že ta vize je tam přesně tak, jak chcete. Kromě samotné funkčnosti by tu také měly být specifikované případné bezpečností požadavky či výkonnostní požadavky. U firem, co nemají zkušenosti s dodavateli softwaru, doporučuji, aby si na pomoc vzali někoho nezávislého.
💡 Tip: Jako na smlouvu si berete právníka, tak na funkční specifikaci si vezměte softwarového konzultanta.
Nikdy se nezbavujte svého know-how
Schváleno. Naprogramováno. Nainstalováno. Máme hotovo. Právě, že nemáme! Instalací to nikdy nekončí.
Tady nejvíce firem udělá tu nejzásadnější chybu a to, že to pustí z hlavy. A co udělá softwarový dodavatel? Ten to pustí z hlavy také. Zakázka je hotová, má dalšího zákazníka, tak se věnuje jemu. Po roce či dvou, když najednou potřebujete nějakou úpravu v systému, tak najednou zjistíte, že ti vaši programátoři už u dodavatele nepracují a ti, co tam jsou, o vašich problémech nic nevědí. Kouknou do specifikace a začnou vám dávat nepříjemné otázky, na které vy budete muset umět odpovědět.
💡 Tip: Vždycky mějte ve firmě znalost o tom, jak a proč váš systém funguje.
To že vám někdo na začátku pomohl se zadáním pro programátory, je samozřejmě dobře, ale vy si to od tohoto člověka musíte převzít a držet nadále u vás ve firmě. Když to neuděláte, tak ono se ze začátku až tak moc nestane a programátoři si nějak poradí, jen jim to bude trvat více času, občas udělají něco jinak, než by bylo ideální, ale bude to fungovat. Problém nastává až časem a hlavně u velikých firemních systémů.
Předcházejte problémům velkých systémů
Velké systémy v korporacích trpí hlavně tím, že není nikdo, kdo by měl v hlavě, jak celý systém funguje. Běžná praxe je pak taková, že jednotliví lidé mají vždy na starost nějaký kousek a o tom vědí hodně, ale o zbytku neví skoro nic. Když se pak řeší nějaký problém, tak se musí všichni sejít a najít společně řešení. Problém nastává s tím, jak jednotliví lidé odcházejí a s nimi odchází i znalost. Všichni se sice snaží mít funkční specifikace, ale protože lidé jsou obecně líní, tak nikdy není všechno popsaný, jak by mělo být.
Chudáci programátoři jsou pak spíš detektivové, kteří musí pátrat, jak co vlastně musí udělat a kolikrát jim to pátrání zabere více času než samotné programování. U velkých systémů jsou pak ve stejné situaci také softwaroví architekti, kteří definují kosti systému. Lehce se pak stane, že systém nebude optimálně navrhnutý. Ze začátku se to třeba ni nepozná, ale jak běží čas a systém je víc zatížený, tak se to začne projevovat.
Dostaneme se do situace, že potřebujeme některé ty kosti zlomit a předělat jinak a to vždy bolí. Najednou nestíháte dodávat programátory na projekt, protože zjistíte, že potřebujete předělat polovinu systému. Když už se dostanete do takovéto situace, tak se už většinou nedá nic moc dělat.
Důležitá je hlavně prevence, která se dělá jedině tak, že někdo průběžně promýšlí a validuje, jestli jednotlivé funkčnosti systému fungují, jak mají a jsou v souladu s naší budoucí vizí. Dokud se architekti či programátoři budou mít koho zeptat, jak co má fungovat, tak to bude dobrý a vždy podstatně levnější, než když oni to budou muset zkoumat a prakticky si sami dělat zadání.
Nejhorší, co se vám může stát, je mít klíčový systém na míru, který potřebujete změnit a o kterém ani nevíte, jak přesně funguje. V takovém případě vám ani další tucet programátorů nepomůže, když jim nebudete umět říci, co mají dělat.
Získejte zdrojové kódy
Pokud si necháte od někoho něco naprogramovat, tak není vůbec od věci si od něho vzít i zdrojové kódy. Ne vždycky s tím bude dodavatel souhlasit, ale pokud vám to vaše vyjednávací pozice alespoň trochu dovolí, tak na tom trvejte. Jde hlavně o to, že firma, která vám dnes software dodává, tak tady zítra už být nemusí a pokud nebudete vlastnit zdrojové kódy, tak vám nikdo jiný už nepomůže.
V případě, že dodavatel dělá celou věc od začátku a jen pro vás, tak by neměl nikdy mít důvod vám nedát zdrojové kódy. Může se ale stát, že v rámci toho, co pro vás dělá, vám dodává ještě nějaký jiný jeho software a pak se mu úplně nebude chtít, dát zdrojové kódy jeho produktu do cizích rukou, aby se třeba nedostaly ke konkurenci.
Moje zkušenost je taková, že pokud se to rozumně ošetří ve smlouvě, tak by s tím neměl mít problém. Například do smlouvy můžete uvést, že tyto zdrojové kódy budete mít k dispozici jen v případě, že dodavatel už nechce anebo nemůže spolupracovat a jen v takové situaci je můžete využít a to jen pro vlastní účely a nikomu třetímu je nepředáte. Zdrojové kódy ani nemusíte mít u sebe, ale mohou být třeba v nějaké právní úschově, a dokud dodavatel dodává, tak k nim přístup nemáte.
Sepište smlouvu o dílo
Vždy se vyplatí sepsat smlouvu o dílo. Na internetu existuje spoustu doporučení, co by v takové smlouvě mělo být a tak se s tím tady nechci rozepisovat. Každopádně si na to vezměte právníka, co se na tento typ smluv specializuje.
Vždy si to pořádně otestujte před předáním
Ještě než podepíšete s dodavatelem smlouvu, tak si s ním dohodněte podmínky, jak se bude software předávat a kontrolovat, že všechno funguje. Tady doporučuji, aby finální otestování softwaru jste si vždy dělali vy sami a ideální je, aby to byl ten člověk, který bude mít pak celý systém na starosti i s funkční specifikací.
Nekontrolujte jen pozitivní scénáře. Je třeba také kontrolovat ty negativní, kde si ověříte, že když váš zaměstnanec někdy udělá chybu, tak si s tím následně dokážete poradit. Naprogramovat systém, který umí předcházet či následně řešit uživatelovi chyby, je vždy náročnější a když si chce dodavatel ušetřit práci, tak tady má na to prostor.
Kontrolujte licence a podmínky provozu
Dobře si vždycky ve smlouvě zkontrolujte, jestli se softwarem na míru dostáváte i takovou licenci, která vám umožní v budoucnu se softwarem nakládat, tak jak potřebujete. Pokud jste si vývoj zaplatili, tak není důvod, abyste byli něčím v budoucnu omezeni a pokud tam nějaké takové omezení je, tak chtějte vědět důvod, proč tam je.
Může se totiž stát, že dodavatel v rámci řešení použije něco, co podléhá licenci a nemůže vám to jen tak dát. Což může být v pořádku. Je ale třeba vždy o všech těchto omezeních vědět dopředu.
Také si dobře zkontrolujte, jestli provoz daného softwaru nebude pak vyžadovat nějaké dodatečné licence. Může se vám třeba stát, že software bude vyžadovat nějakou databázi, která není zadarmo, a vy budete muset platit další peníze, s čím jste původně nepočítali.