Proč se vývojáři rozhodnou nepoužívat váš produkt?

Nasadit nástroj třetí strany je pro vývojáře velký krok. Kromě toho, jestli vůbec funguje, vážíme i to, jak dlouho integrace zabere a jak bolestivá implementace bude. Když se to nepovede, jdeme jinam.

Tady je skutečný příběh o tom, proč vývojáři od produktu odejdou a co mě nakonec přesvědčilo.

V roce 2018 jsem dostal za úkol napojit do firemní webové aplikace REST API platební brány od třetí strany. Pustil jsem se do toho s chutí, protože jsem měl úplnou volnost ve výběru poskytovatele. Tehdy se třetí strana vybírala jediným způsobem: googlením. Našel jsem asi 30 řešení, která slibovala, že můj problém vyřeší. Díval jsem se na zkušební verze, freemium i placené předplatné, ale rozhodla nakonec cena a líbivý design. Později jsem zjistil, že to byla chyba.

Našel jsem řešení, které vypadalo dostatečně dobře. Zaregistroval jsem se, přihlásil a začal s integrací. Návod, který jsem dostal, byl soubor .doc a postupoval jsem podle něj krok za krokem. Pokyny byly místy nejasné, ale s pomocí starších kolegů jsem se jimi prokousal. Po hodinách práce jsem zmáčkl F5 a byla tam: krásná platební brána. Jenže nefungovala.

Ten wordovský dokument byl devět měsíců starý, tak jsem si řekl, že se do něj asi nepromítly nějaké změny v produktu. Ten nesoulad způsobil neúspěšná volání API a neplatné zpracování dat a táhl celou integraci ke dnu. To, co jsem si odhadl na pár hodin, mi zabralo celý den.

Pustil jsem se tedy do hledání řešení. Googlení, návody na YouTube, Reddit. Nic z toho můj problém nevyřešilo, na což jsem byl ostatně zvyklý. Zavolal jsem na podporu, chvíli čekal ve frontě a dovolal se k někomu „velmi ochotnému pomoct“. Zrovna tam nastoupil, a s pomocí kolegů mi nakonec dal, co jsem potřeboval. Konečně to fungovalo, jak mělo. Aspoň na čas.

Po pár měsících chtěl náš zákazník v odpovědích API víc dat. Zase na podporu. Jejich systém byl příliš rigidní, aby to umožnil, a změnit to by bylo moc drahé. Nezbylo nám než hledat jiné řešení, a našli jsme ho. Bylo dražší a fungovalo o něco líp, i když tření při integraci bylo skoro stejné. U toho poskytovatele jsme zůstali rok, než jsme narazili na jednoho z jeho konkurentů, který měl ke svému API produktu úplně jiný přístup.

A bylo to. Jejich ekosystém API se za pár let rychle proměnil. Dokumentace byla důkladná, s interaktivními endpointy a příklady požadavků i odpovědí. Měli dokonce SDK ve třech jazycích, takže jsem mohl použít svůj oblíbený JavaScript. Integrace zabrala minuty, ne hodiny nebo dny.

Stačilo pár řádků kódu. Návody i nástroje byly aktuální. Čas, který jsme ušetřili při implementaci a později při údržbě, pro nás všechno změnil. Konečně se někdo začal starat o čas vývojářů a o radost z práce. Stejně jako dobré UX dělá radost uživatelům, dobrý DevEx dělá radost vývojářům.

„Nevíme, co nevíme.“ Tohle rčení k vývojářské zkušenosti sedí. Největší krok vpřed je si to přiznat a začít hledat třecí plochy a úzká místa.

Jak na to, se dozvíte v tomhle článku.

Tyhle vzorce vývojáře odhánějí:

Ekosystém API se mění. Poskytovatelé třetích stran se dnes odlišují kvalitou dokumentace, protože to je první věc, kterou vývojář při zadané integraci posoudí. Dejte nám všechno, co potřebujeme, na jednom místě a pořád, ať můžeme dělat to, kvůli čemu tu jsme: stavět ta nejlepší řešení, jaká umíme.

Zavádět nové technologie není volitelné, pokud chcete konkurenceschopný produkt. Já jsem si vybral levného a zastaralého poskytovatele, který se pořád potýkal s vlastním rigidním systémem. Pro jednotlivce, malé týmy a hlavně pro větší firmy je krokem vpřed sáhnout po nástrojích a postupech, které zabijí opakovanou práci a zvednou kvalitu výstupu. Tak porazíte neefektivitu nejen při vývoji, ale i při údržbě a vylepšování toho, co jste postavili.