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

Přijetí nástrojů třetích stran je pro vývojáře velkým krokem. Kromě funkčnosti je naše rozhodnutí založeno na mnoha dalších faktorech, jako je odhad, jak dlouho bude trvat integrace nebo jak snadné bude řešení implementovat.

Pojďme prozkoumat, proč si vývojáři nemusí vybrat váš produkt.

Počáteční očekávání

V roce 2018 jsem dostal příležitost implementovat třetí stranu REST API platební brány do naší firemní webové aplikace. S chutí jsem se do toho pustil, protože jsem dostal absolutní volnost při výběru poskytovatele. Tehdy se proces výběru třetí strany dal provést pouze googlováním. Našel jsem asi 30 řešení, která slibovala vyřešit můj problém. Nejdříve jsem se díval na bezplatné zkušební verze, freemium nebo placené předplatné. Hlavními rozhodujícími faktory však byly cena a uživatelsky přívětivý design. Později jsem si uvědomil svou chybu.

Složitost integrace a problémy s dokumentací

Našel jsem dostatečně dobré řešení. Zaregistroval jsem se, přihlásil a zahájil proces integrace. Byl mi poskytnut dokument ".doc", který sloužil jako průvodce (dokumentace). Krok za krokem jsem postupoval podle pokynů. I když byly pokyny někdy nejasné, podařilo se mi s pomocí starších kolegů vše zvládnout. S nadšením jsem očekával, jak bude vypadat výsledek mnohahodinového úsilí. Stiskl jsem F5 a bylo to, krásná platební brána... Ale nefungovala.

Dokumentace v podobě dokumentu ve Wordu byla 9 měsíců stará, takže jsem si říkal, že se tam možná nepromítly nějaké změny v produktu. Tato nesrovnalost vedla k četným neúspěšným voláním API a neplatnému zpracování dat, což dále ztěžovalo naše integrační úsilí. To, co bylo původně rozvrženo na pár hodin práce, mi zabralo celý den.

Špatná podpora vývojářů

Začněme s řešením problémů. Googlování, návody na YouTube, Reddit. Můj problém nic nevyřešilo, ale na to jsem byl zvyklý. Zavolal jsem na linku podpory, strávil jsem nějaký čas ve frontě a byl jsem přepojen na osobu "velmi ochotnou pomoci". Právě tam začal pracovat a s pomocí svých kolegů mi dokázal poskytnout pomoc, kterou jsem potřeboval. Konečně to fungovalo tak, jak mělo. Alespoň na nějakou dobu.

Omezená funkčnost

Po několika měsících chtěl náš zákazník získat další data. Znovu se obrátil na linku podpory a požádal o jejich poskytnutí v odpovědích. Strnulost jejich systému nám to neumožňovala. Bylo by to příliš nákladné. Nezbylo nám než začít znovu hledat jiné řešení, které jsme nakonec našli. Bylo dražší, ale fungovalo relativně lépe. I když třecí plochy při integraci byly téměř stejné. U tohoto poskytovatele jsme zůstali rok, dokud jsme nenarazili na jednoho z jeho konkurentů, který měl ke svému produktu API úplně jiný přístup.

Zkušenosti vývojářů

Konečně jsem ho našel! Jejich ekosystém API prošel během několika let rychlou změnou. Obsáhlá dokumentace s interaktivními koncovými body a příklady požadavků/odpovědí. Byly tam dokonce SDK (Software Development Kit) ve třech jazycích. To znamená, že jsem mohl používat svůj oblíbený jazyk JavaScript a navíc byla integrace hotová během několika minut, nikoli hodin nebo dnů.

Stačilo pár řádků kódu. Průvodci a nástroje byly aktuální. Množství času, které jsme ušetřili při implementaci a později při údržbě, pro nás změnilo pravidla hry. Konečně se někdo začal starat o čas vývojářů a radost z práce. Stejně jako UX dělá radost uživatelům. DevEx dělá vývojáře šťastnými.

"Nevíme, co nevíme." Toto rčení se hodně týká zkušeností vývojářů. Největším zlepšením je uvědomit si to a začít jednat s cílem odhalit třecí plochy a úzká místa.

Jak to udělat, se dozvíte v tomto článku.

Společnosti se obvykle potýkají s těmito problémy

1. Zastaralé technologie a technický dluh — Starší technologie, které nebyly modernizovány, vedou k rostoucímu technickému dluhu, což ztěžuje adaptaci.

2. Zastaralá použitelnost produktu — Základní prvky produktu, jako jsou rozhraní API, sady SDK a dokumentace, zaostávají za současnými normami, což snižuje hodnotu výrobku.

3. Opakující se úkoly snižující efektivitu — Mnoho úkolů se stále provádí ručně, což zvyšuje pracovní zátěž a vede ke zpožděním.

4. Manuální procesy — Nedostatečná automatizace pracovních postupů vede k chybám, což zvyšuje neefektivitu a vyžaduje přepracování.

5. Technický dluh v důsledku špatného plánování projektu — Bez strukturovaného zahájení projektu narůstá technický dluh, což ztěžuje údržbu projektů v průběhu času.

6. Nedostatečné definice úkolů — Špatně definované úkoly vedou ke zmatkům a neúplné práci, což zpomaluje pracovní postup.

7. Nedostatečný návrh systému a technická analýza — Nedostatečná technická analýza a zastaralé postupy návrhu systému brání optimální implementaci a rozšiřování.

Závěr

Ekosystém API prochází rozsáhlou změnou. Poskytovatelé služeb třetích stran se odlišují na základě kvality dokumentace, protože ta je dnes hlavním bodem rozhodování vývojářů, kteří mají za úkol integrovat rozhraní API. Poskytnout nám vše, co potřebujeme, neustále na jednom místě, abychom mohli dělat to, k čemu jsme byli určeni. Vyvíjet ta nejlepší možná řešení.

Zavádění nových technologií je povinné pro ty, kteří chtějí mít konkurenceschopné výrobky. Vybral jsem si levného a zastaralého poskytovatele, který se potýkal s problémy kvůli vlastnímu rigidnímu řešení. Pro jednotlivce, malé týmy a zejména pro firmy je nezbytné přijmout řešení, která nabízejí nástroje a pracovní postupy, které nám pomohou zbavit se opakujících se úkolů a zlepšit naše výsledky.

Tak se nám podaří překonat boje s neefektivitou nejen při vývoji, ale i při údržbě a zlepšování našich projektů.

---

Mohlo by vás také zajímat

• Co je Developer Experience a proč by vás měla zajímat? — Komplexní přehled DX a jeho přínosů.
• Síla DX: Jak Localazy zvýšila spokojenost zákazníků — Případová studie o zlepšení developer experience.
• Proč váš produkt potřebuje SDK — Důvody, proč byste měli zvážit vytvoření SDK pro váš produkt.