Proč stavíme vlastní software, i když vyvíjíme pro klienty

Vlastní software je pohodlné ukazovat na obrázcích. O něco méně pohodlné je každý den v něm pracovat. Právě proto ho stavíme.

GlitchLab vyvíjí weby, aplikace a propojení systémů pro firmy. Vedle zakázek ale postupně vyvíjíme také nástroje pro vlastní provoz. Ne proto, abychom měli na webu více log. Potřebujeme řešit zakázky, komunikaci, dokumenty a návaznosti mezi nimi. A potřebujeme vidět, co se stane s dobrým nápadem po několika měsících běžného používání.

První obrazovka ještě nic nedokazuje

Navrhnout přehled zakázek je relativně přímočaré. Složitější je rozhodnout, kdo smí vidět finanční údaje, co se má stát s rozpracovaným formulářem a kde se pozná, že předání klientovi skutečně proběhlo.

V designovém návrhu může být každý stav krásně vyřešený. V reálné práci do systému někdo přinese nečekaný požadavek, otevře jej na úzkém notebooku, přepne do e-mailu nebo se vrátí ke starší zakázce. Tam začíná druhá polovina vývoje: úpravy, výjimky a údržba.

Při vlastním používání už se neschováme za větu „uživatel si zvykne“. Pokud něco stojí zbytečné kliknutí, platíme ho vlastní pozorností.

OS, Core a CMS nejsou tři hotové krabice

GlitchLab OS je náš postupně rozvíjený provozní systém. Pracujeme v něm se zakázkami, interní agendou a klientským portálem. Jednotlivé oblasti mají různou úroveň dokončenosti a dál je upravujeme.

GlitchLab Core představuje sdílený technický základ pro přístupy, oprávnění a provozní souvislosti aplikací. Pro návštěvníka webu to není produkt, který by si měl vybrat z katalogu. Je to část infrastruktury, na které stavíme.

GlitchLab CMS řeší správu webového obsahu. Tento Zápisník je současně dobrým testem jednoduché otázky: dokáže redakční systém bezpečně rozlišit rozepsaný text od skutečně publikovaného článku?

A AI Operátor? To je rozvíjený směr řízených automatizací. Nesnažíme se vydávat jej za hotovou univerzální službu. Zajímá nás, kde lze konkrétní proces zjednodušit, jak ověřit jeho výsledek a kdy musí rozhodnout člověk.

Co si přenášíme do klientských zakázek

Nejde o to přesvědčit každého, že potřebuje náš systém. Většinou ho nepotřebuje. Potřebuje vlastní řešení odpovídající jeho práci, nebo rozumnou úpravu toho, co už používá.

Z vlastní dílny si do takových projektů přenášíme několik návyků:

• Rozlišovat mezi tím, co dobře vypadá, a tím, co se dobře používá. Obě věci mají význam, ale nejsou totožné.
• Přiznat stav rozpracovanosti. Koncept, pilot a běžný provoz mají jiné nároky i jiná rizika.
• Navrhovat i změny po spuštění. Software se nepřestane vyvíjet předáním prvního odkazu.
• Dohodnout odpovědnost. Je potřeba vědět, kdo rozhoduje, kdo kontroluje a kdo řeší problém, když něco selže.

Vlastní nástroje nejsou argument samy o sobě

Počet modulů neříká, zda je systém dobrý. Stejně tak jeden hezký screenshot nepotvrdí, že řeší skutečnou potřebu.

Proto chceme postupně ukazovat spíš konkrétní rozhodnutí: co jsme změnili, proč původní řešení nestačilo a jaké omezení ještě zůstává. Někdy půjde o viditelnou novou funkci. Jindy o opravu nepříjemného chování, které by se na marketingový plakát nikdy nedostalo.

Vlastní software nám nepomáhá proto, že je náš. Pomáhá nám proto, že v něm musíme každý den žít.