Subscription Development: vývoj e-shopu za měsíční paušál

E-shop, který roste, potřebuje vývoj pořád. Nový filtr v kategorii, úprava košíku, napojení dalšího dopravce, export pro účetní, oprava po aktualizaci šablony. Žádný z těch úkolů není velký projekt. Dohromady ale dají desítky hodin měsíčně. Když na každý z nich čekáte na novou nabídku, schválení a volný termín vývojáře, rozvoj e-shopu se zpomalí na tempo e-mailové komunikace.

Vývoj za měsíční paušál tento problém řeší jinak: máte předem rezervovanou kapacitu, jednu roadmapu a jednoho partnera, který zná váš kód. V článku vysvětlíme, jak takový model funguje, čím se liší od hodinové spolupráce a fixního projektu, na co si dát pozor ve smlouvě a kdy se naopak nevyplatí.

Tři modely spolupráce na vývoji

Vývoj e-shopu se v praxi objednává třemi způsoby. Každý má své místo, žádný není univerzálně nejlepší.

Fixní projekt dává jistotu ceny, ale jen tehdy, když víte přesně, co chcete. U e-shopu, který se mění podle sezóny, marketingu a dat, to platí málokdy. Time & material je flexibilní, ale dodavatel vás zařadí do fronty podle volné kapacity. Paušál kombinuje obojí: víte, kolik zaplatíte, a zároveň můžete měnit, na čem se pracuje.

Jak funguje fond hodin

Základem paušálu je měsíční fond hodin. Dohodnete se na velikosti kapacity a dodavatel ji pro vás drží. Do fondu se obvykle počítá:

• vývoj nových funkcí a úpravy stávajících,
• opravy chyb a drobná údržba,
• analýza a odhad pracnosti větších požadavků,
• testování a nasazení,
• konzultace k technickým rozhodnutím.

Důležité je, jak se s fondem pracuje v průběhu měsíce. Dobrý dodavatel průběžně ukazuje čerpání, ne až ve vyúčtování. Když se blíží vyčerpání, řeknete si, co se přesune do dalšího měsíce, nebo jestli fond jednorázově navýšit.

Převod nevyužitých hodin

Tady vznikají nejčastější nedorozumění. Existují tři běžné varianty:

1. Hodiny propadají. Pro dodavatele nejjednodušší, pro vás nevýhodné v klidnějších měsících.
2. Omezený převod. Část nevyužitých hodin přejde do dalšího měsíce, obvykle s limitem na počet hodin nebo dobu platnosti.
3. Neomezený převod. Zní dobře, ale dodavatel pak nemůže plánovat kapacitu a po několika měsících vznikne „dluh hodin“, který nejde najednou vybrat.

Rozumným kompromisem bývá omezený převod. Dodavatel drží kapacitu, na kterou se může spolehnout, a vy o hodiny nepřijdete kvůli jednomu slabšímu měsíci. Ať zvolíte cokoliv, mějte pravidla ve smlouvě černé na bílém.

Roadmapa a prioritizace

Paušál bez roadmapy se rychle změní v drahou frontu drobností. Kdo píše nejvíc e-mailů, dostane nejvíc hodin. Proto je průběžná roadmapa stejně důležitá jako samotný vývoj.

Jak roadmapu stavíme v praxi:

1. Sběr požadavků na jedno místo. Marketing, sklad, zákaznická podpora i majitel zapisují požadavky do jednoho seznamu, ne do různých e-mailů.
2. Odhad pracnosti a dopadu. U každého úkolu odhadneme hodiny a řekneme, co přinese: tržby, úsporu času, nižší riziko výpadku.
3. Pořadí podle dat. Úprava košíku, kterou prochází každý zákazník, má jinou váhu než kosmetická změna v patičce. Pomůžou data z analytiky a přehled KPI, které by měl sledovat každý majitel e-shopu.
4. Měsíční plán s rezervou. Část fondu necháváme na nečekané opravy, aby urgentní chyba nerozbila celý plán.
5. Průběžná změna priorit. Když se situace změní, roadmapa se upraví. To je hlavní výhoda proti fixnímu projektu.

Součástí roadmapy by mělo být i postupné splácení technického dluhu. Pokud ho odkládáte, každá nová funkce stojí víc hodin. Podrobněji to rozebíráme v článku o technickém dluhu e-shopu.

Testování a nasazení bez výpadků

Rychlost vývoje nesmí jít na úkor stability. Změna nasazená v pátek odpoledne bez testu je nejrychlejší cesta k víkendovému výpadku. U paušální spolupráce proto trváme na několika pravidlech:

• Testovací prostředí. Změny se nejdřív ověřují mimo produkci, na kopii e-shopu s realistickými daty.
• Verzování kódu. Každá změna je dohledatelná a dá se vrátit zpět.
• Kontrola integrací. Úprava v e-shopu může rozbít napojení na ERP, dopravce nebo feed. Po nasazení kontrolujeme REST API volání i webhooky, na kterých provoz stojí.
• Plánované okno nasazení. Nasazujeme v době, kdy je nejmenší provoz a tým je k dispozici pro případnou opravu.

U pronajímaných platforem, jako je Shoptet nebo Upgates, se část vývoje řeší přes doplňky, šablony a API a nasazení je jednodušší. U open source řešení typu WooCommerce přibývá starost o aktualizace jádra, pluginů a serveru. Postup nasazování popisujeme v článku CI/CD pro e-shop.

Jak poznat dobrého dodavatele

Paušál je dlouhodobý vztah. Než podepíšete, projděte si tento checklist:

• Transparentní čerpání. Vidíte, kolik hodin padlo na který úkol, průběžně, ne jen na konci měsíce.
• Měsíční přehled s dopadem. Nejen seznam úkolů, ale i to, co změny přinesly nebo mají přinést.
• Jasná pravidla převodu hodin a postup při jejich překročení.
• Reakční doba na běžné požadavky je ve smlouvě. Kritické výpadky se často řeší samostatnou prioritní linkou.
• Vlastnictví kódu a přístupů. Kód, repozitář i přístupy k serveru patří vám. Při ukončení spolupráce je musíte dostat bez problémů.
• Výpovědní lhůta, která vás nedrží roky u dodavatele, se kterým nejste spokojení.
• Zkušenost s vaší platformou. Vývojář, který zná Shoptet, nemusí rozumět Magentu, a naopak.

Kdy se paušál nevyplatí

Paušál není pro každého. Nevyplatí se, když:

• Potřebujete jeden větší projekt a pak klid. Migrace nebo redesign se lépe řeší jako samostatný projekt s jasným rozsahem. Paušál může navázat po spuštění.
• Požadavky přicházejí nahodile a zřídka. Pokud potřebujete vývojáře párkrát ročně, hodinová spolupráce vyjde levněji.
• Nemáte na straně e-shopu nikoho, kdo rozhoduje o prioritách. Paušál bez zadavatele se nevyčerpá smysluplně.
• E-shop běží na platformě, kterou plánujete brzy opustit. Investujte raději do přípravy replatformingu než do rozvoje starého systému.

Jednoduché pravidlo: pokud máte vývojové požadavky většinu měsíců v roce a přesto čekáte týdny na nabídky, paušál vám nejspíš ušetří čas i nervy.

Jak to děláme v Převeďshopu

Náš program Subscription Development je alternativa k jednorázovým vývojovým zakázkám. Za měsíční paušál máte k dispozici vývojářskou kapacitu na průběžné zlepšování e-shopu podle aktuálních priorit. Obsahuje:

• dedikovanou vývojovou kapacitu ve formě fondu hodin, který využijete podle měnících se priorit,
• průběžnou roadmapu postavenou na datech, ne na náhodných požadavcích,
• testování a nasazení bez výpadků produkce,
• měsíční přehled toho, co bylo odvedeno a jaký to má dopad na byznys.

Nevyužité hodiny lze podle dohody převést do dalšího měsíce v omezeném rozsahu. Priority můžete měnit i v průběhu měsíce. Na požadavky reagujeme do 1 pracovního dne. Cenu stanovujeme podle velikosti fondu hodin a připravíme ji po konzultaci podle rozsahu.

Pokud nepotřebujete jen vývoj, ale i technické a ecommerce vedení, podívejte se na Ecommerce Care, kde přebíráme roli externího CTO a ecommerce manažera. Rozdíly mezi oběma přístupy popisuje i článek Externí CTO pro e-shop.

Kdy nám zavolat

Ozvěte se, když:

• čekáte na vývojové úpravy týdny, protože každá potřebuje novou nabídku,
• máte víc drobných dodavatelů a nikdo nedrží celkový přehled o kódu,
• chcete e-shop rozvíjet pravidelně, ale nevíte, jak velkou kapacitu potřebujete.

Začneme krátkou konzultací, projdeme seznam požadavků a odhadneme, jaký fond hodin dává smysl. Pokud zatím není jasné, v jakém stavu je kód a integrace, doporučíme nejdřív audit. Kontakt najdete na stránce Kontakt, případně volejte na +420 723 000 173.