To si takhle děláte softwarový produkt. Možná ho nabízíte jako službu (SaaS), možná se instaluje u vašich zákazníků. To je celkem jedno. Vždy přijde doba, kdy jeden z vašich významných zákazníků přijde s požadavkem na speciální funkci pro něj. Pojďme se podívat jaké máte možnosti se s tím vypořádat a na co si dát pozor.
Pátrejte
Ze všeho nejdříve je potřeba se podívat, jestli náhodou požadovaná funkcionalita už ve vašem produktu není, nebo se dá kýženého výsledku dosáhnout nějak jinak v rámci vašeho produktu. Pokud je to tento případ, bude potřeba doplnit dokumentaci nebo tréninkové materiály.
Ale předpokládejme, že to tak není a je potřeba to vyvinout. Spolu s vaším produktovým týmem se musíte hluboce zamyslet a případně si promluvit s vašimi dalšími zákazníky. Je tento požadavek unikátní pouze pro jednoho zákazníka? A i kdyby byl, není to náhodou něco, co by mohli chtít i zákazníci další? Pokud dojdete k závěru, že to je něco co byste chtěli do vašeho produktu přidat, je to v pořádku. Zařaďte požadavek do fronty, přiřaďte prioritu a postupujte jak jste zvyklí.
Častěji ovšem dojdete k závěru, že to je skutečně vhodné pouze pro jednoho zákazníka a nikdo jiný to nevyužije. To je ta obtížnější varianta.
Raďte
Jako další krok byste se měli snažit to zákazníkovi rozmluvit. Tento krok je potřeba zdůraznit a po dočtení tohoto článku doufám pochopíte proč. Snažte se porozumět, čeho se snaží ve výsledku dosáhnout. Navrhněte jim jiné postupy, které povedou ke srovnatelnému výsledku. Nebojte se doporučit konkurenční produkt, pokud víte že existuje a požadavek splňuje. Zákazník určitě ocení vaši upřímnost. Vysvětlete mu, že tuto funkcionalitu ve vašem produktu nechcete a jaké k tomu máte důvody.
Vyvíjejte
Pokud výše uvedené selže, a ono často selže, začne další fáze. Začne obvykle tak, že vám zákazník řekne, že je ochoten zaplatit vývoj požadované funkcionality a požádá vás o odhad, kolik to bude stát. V tuto chvíli máte v zásadě tři možnosti, jak to řešit, všechny špatné.
Možnost 1: Zapracujte to
“Nejlehčí” je prostě to vzdát a požadovanou funkcionalitu do produktu přidat. Za předpokladu, že jste ji tam nechtěli, ji bude potřeba pro ostatní zákazníky skrýt, aby nepřekážela. Ale pořád tam bude, možná navždy. To znamená, že ji budete muset udržovat. Bude vás v budoucnu brzdit, protože ji budete muset v každé nové verzi testovat a opravovat. Bude zvyšovat komplexitu produktu a ztěžovat zacvičování nových vývojářů. Bude vyžadovat refaktoring nebo bude akumulovat technický dluh. Protože ji bude používat jen jeden zákazník, bude trvat dlouho než se vychytají všechny chyby.
Když budete odhadovat náročnost tohoto řešení, musíte toto všechno zahrnout do kalkulace. “Pravidlo palce” v takovém případě může vypadat tak, že nechte vaše vývojáře odhadnout čas potřebný na vyvinutí funkce a následně ho vynásobte deseti. Docela šílené, ale odpovídá praxi. Ale to ještě není zdaleka všechno. Takto spočítáte pouze přímé náklady na vývoj. Co ale náklady ušlé příležitosti? Váš tým bude pracovat na této funkci, místo aby vyvíjel to, co jste chtěli vyvíjet. Kolik vám to mělo přinést za svou životnost peněz? Pokud to děláte dobře, mělo by to být minimálně pětkrát nebo desetkrát tolik, kolik jste do toho investovali v nákladech. Toto vše by se mělo do kalkulace ceny zahrnout. Ještě pořád je váš zákazník ochoten zaplatit?
Možnost 2: Forkněte to
Dejme tomu, že si uvědomujete, že přidání funkce do produktu vás bude v budoucnu zatěžovat, jak jsme si ukázali v první možnosti. Druhou možností je vytvořit kopii projektu (fork) a požadovanou funkci implementovat tam, bez ovlivnění hlavního produktu. To je celkem snadné. Pořád vás to bude stát vývojovou kapacitu a náklady ušlé příležitosti, ale aspoň si tím nezaplevelíte svůj produkt. Pokud se jedná o SaaS, bude potřeba vytvořit vlastní infrastrukturu a kopii tam nainstalovat a provozovat. Pokud máte všechno zautomatizováno, ani to by neměl zásadní problém.
Určitě hledáte, kde je to ale. Nebojte se, je tam. Vytvořením kopie jste vytvořili nový, samostatný produkt. To znamená, že do něj nebudou přidávány žádné nové funkce ani opravy chyb z hlavního produktu, aniž by je někdo ručně nepřenesl. To stojí peníze a čas. Pokud si to dopředu nevyříkáte se zákazníkem, budou předpokládat, že to budete dělat a platit. Navždy. Proto je potřeba zákazníkovi říct, že dostává produkt tak jak je s přidáním nové požadované funkcionality, ale to je vše. Pokud budou chtít dostávat nové funkce a opravy chyb, budou za to muset platit. Opět platí, jsou na to připraveni?
Možnost 3: Modularizujte to
Zdánlivě nejelegantnější řešení je učinit váš produkt modulárním a izolovat zákaznickou funkcionalitu do zákaznického modulu. Možná už tam z poloviny jste, pokud máte dobře navrženou architekturu. Může to být buď systém interních modulů jako součást softwarové instance (jak to dělá třeba Wordpress), nebo můžete zpřístupnit zákazníkovi vaše jádro pomocí API a nechat je vytvořit si požadovanou funkcionalitu vlastními silami.
Nicméně, pokud nejste jasnovidci nebo jste neměli velkou kliku při návrhu, rozčlenění do modulů zřídkakdy přesně sedne na požadovanou funkcionalitu. Ani API nebude obsahovat přesně ty funkce, které zrovna zákazník bude potřebovat. Takže stejně bude na vaší straně potřeba nějaká práce na úpravy a někdo ji bude muset zaplatit.
Pokaždé když budete vydávat novou verzi jádra, bude potřeba testovat napojení modulů. Pokud dojde ke změnám, které nebudou zpětně kompatibilní, což se dozajista stane, povedete se zákazníky nekonečnou diskusi na téma kdo za to může a hlavně kdo zaplatí nutné změny v jejich modulu nebo API klientovi. Vzhledem k tomu, že tu změnu zákazník zpravidla nechtěl, bude se bránit za úpravy platit.
Čím více zákaznických modulů takto vznikne, tím bude situace horší.
Závěr
Jak jste asi pochopili, nejsem fanoušek zákaznického vývoje v rámci standardního produktu. Rozumím tomu, proč ho zákazníci požadují a částečně i proč to výrobci softwaru dělají. Je těžké říkat ne zákazníkům, zvlášť pokud jsou pro vás významní. Pokud jste startup s penězi na posledních pár měsíců provozu, je lákavé si pár měsíců přidat tím, že vám zákazník zaplatí zdánlivě slušnou sumu. Jak jsem se snažil popsat v tomto článku, ta suma ovšem zřídkakdy pokryje náklady.
Nejsmutnější na tom všem je, že tuto úžasnou funkcionalitu často zákazník po pár měsících přestane používat, nebo v horším případě nikdy ani nezačne. Fakt, že zákazník byl jediný, kdo to po vás chtěl, by vám mělo také něco napovědět.
Ale to ještě pořád nejsme u konce. Když jednomu zákazníkovi takto vyhovíte, zvykne si na to a bude podobné zacházení očekávat i v budoucnu. A modlete se, aby to neřekl jinému vašemu zákazníkovi, protože v tu chvíli se vám otevře komnata, kterou otevřít nechcete. Politika.
Takže to prostě nedělejte. Tedy pokud opravdu, ale opravdu nemusíte. V tom případě si to ale nechte skutečně zaplatit.
Comments