Zákazník náš pán. Alebo Minimum Viable Product?

Firmy zahľadené do seba ľahko skĺznu k riešeniam, ktoré považujú za minimálne a funkčné. Zákazník však môže mať na to iný pohľad. A pritom od správneho minimálneho riešenia ste vzdialení jednou otázkou.

O pushkách

Úspešný korporát s miliónom používateľov svojej mobilnej aplikácie sa rozhodol do aplikácie pridať push notifikácie. Jednoduchá zmena. Aspoň z pohľadu používateľa. No nie z pohľadu korporátu.

Za mobilnou aplikáciou stoji silný backend, ktorý vyvíja iný dodávateľ. Firma má silný ekosystém riešení, takže postaviť mobilnú aplikáciu nebolo až tak náročné.

Push notifikácie bola firma tak trochu nútená dopracovať do mobilky. Doteraz mali SMS riešenie, ktoré bolo v cenníku platené. Push notifikácia spôsobí, že firma čiastočne príde o príjem a navyše ešte musí investovať do vývoja pushiek. Ale čo už, náš zákazník náš pán.

Prvotný dizajn riešenia však ukazuje, že backend nie je stavaný na ideálny spôsob riešenia pushiek. Systém vedel odpovedať na request, ale nevie upozorniť pri zmenách potrebných údajov. Navyše údaje spracované v mobilke sú rôzneho charakteru, niektoré sú agregované a tak spraviť sledovanie zmien údajov a inteligentné notifikovanie o zmenách je poriadny zásah do backendu. A keďže backend robí dodávateľ, bude to drahé a ktovie kedy.

Núka sa potreba Minimum Viable Product.

Čo by tak mohlo byť MVP?

Zapínanie pushiek si vyžaduje konfiguráciu per klient a per inštaláciu aplikácie. Doteraz to nebolo potrebné, mobilná aplikácia tak nemala žiadnu konfiguráciu. Aj tu sa ponúka MVP riešenie.

Zapracovanie notifikácie si prirodzene vyžaduje vedieť identifikovať zmenu, aby pri notifikácii klient ťukol na správu a videl detail zmeny. Ale. Backend takúto informáciu z bezpečnostných dôvodov doteraz neposkytoval. Nechce predsa publikovať ID zmeneného objektu. A tak sa opäť núka MVP riešenie. Len aké….

Ako by ste túto situáciu riešili Vy? Dajte si minútku na zamyslenie.

Moje idey

Minimum Viable Product

Riešenie, ktoré schválili u klienta, bolo minimálne. Z ich pohľadu. S navrhovaným riešením boli všetci kľúčoví ľudia vo firme spokojní. Nebolo to úplne skvelé riešenie, ale spravia ho rýchlejšie ako dokonalé. A predovšetkým lacnejšie, pri výpadku poplatkov za SMS nie je na zahodenie.

Návrh riešenia MVP:

1. Klient si povolí push notifikácie vo web aplikácii. Nie v mobile. Vo web aplikácii je už konfigurácia profilu zákazníka, stačí to pridať tam. V mobile to nie je momentálne možné.
2. Backend pošle správu o zmene. Keďže nie je možné doručiť ID menených údajov z backendu, bude to všeobecná správa. Typu „Vo vašich údajoch nastala zmena.“.
3. Ťuknutím na správu sa spustí mobilná aplikácia.
4. Keďže nevieme čo sa zmenilo, zobrazí sa úvodný dashboard.

Funkčné, minimálne, najlacnejšie riešenie. MVP.

Počkajte! Minimum Viable Product?

Je to životaschopné riešenie?

Na otázku Agile mentora sa ľudia začali ošívať:

„Prečo do toho rýpe? My sme sa tomu venovali už toľko týždňov dizajnu. Vydupali sme aj zmenu na backend pred inými zmenami. Bojujeme o to, konečne máme možnosť to spraviť a dodať. Konkurencia ma pushky už dávno, nám to chýba. Aj zákazníci sa sťažujú, že ich doteraz nemajú. Konkurencia to ma riešené rovnako. A tu Agile mentor ide rozporovať?  Teraz? Nech si skúsi reálnu robotu!“

No Agile mentor nerozporuje. Iba položil otázku. To tím na ňu reaguje negatívne. Prečo?

Proces zodpovednosti ukazuje, že cesta k zodpovednosti začína popieraním. Možno preto reagujete takto intenzívne na otázku o životaschopnosti riešenia.

A možno sa bojíte priznať si pravdu. Že tak trochu cítite, že riešenie nie je životaschopné. Je to v poriadku. Je to súčasť hľadania zodpovedného riešenia.

Riešenie možno nie je minimálne životaschné pre klienta. A možno aj preto prejdete do druhého štádia procesu zodpovednosti, do obvinenia. Dokonca osobného obvinenia človeka, ktorého úlohou je pýtať sa otázky, meniť systém práce a predovšetkým myslenia. Človeka, ktorého ste si do firmy najali práve na túto prácu.

Správne odpovede nemáte ani vy, ani Agile mentor. Odpoveď má zákazník, používateľ. A od odpovede ste jeden telefonát, email, rozhovor ďaleko.

Paradoxne, ľudia v tíme boli tiež klientmi svojej firmy. Sami členovia tímu si priznali, že toto riešenie používať nebudú. Zdá sa im nelogické ísť do web verzie a nastaviť si pushky. Do web verzie sa neprihlásil už skoro rok. Mobilná aplikácia im postačuje. Nakoniec, prihlásenie si vyžaduje userid a špeciálny PIN. A v mobile to síce dávno zadali, áleeee teraz sa prihlasuje s biometriou. Hádať PIN kvôli pushkám? No way… Škoda času.

A aj tak, keď mi príde puška tak sa akurát dozviem o nejakej zmene? Potrebujem vedieť hneď čo sa zmenilo. Nemám čas spúšťať aplikáciu.

A aj tak, ak by aj. Zobrazí sa mi dashboard? Ten istý, ktorý sa zobrazí keď spustím aplikáciu v mobile?

Počkať!!! My teda robíme spustenie aplikácie cez pushky? To vážne? Za x*10k euro? To vážne?

Keď sa to láme

A sme tu. V momente kedy sa to láme. V momente kedy sa zahanbíte sami pred sebou. Máte možnosť buď kapitulovať a pokračovať s vašim ‚MVP‘ riešením, alebo to zmysluplne a zodpovedne napraviť. Doručiť nie MVP, ale Minimum Marketable Product.

Ďalšie detaily sa ukázali neskôr počas plánovania. Ono totiž nikto nerátal, že keď bude veľa pushiek o zmenách a teda veľa štartov aplikácie v podobnom čase, zobrazený dashboard spustí niekoľko náročných dotazov na backend, ktorý nebol stavaný na takýto peak v load. A Backend tak začne balansovať dotazy a spomalí odpovede. Užívatelia uvidia po ťuknutí na pushku pomalý štart. V simulácii dokonca začali hlásiť zacyklenie, padanie aplikácie. Čo spôsobilo, že apku začali používatelia reštartovať ručne. A to paradoxne prispelo k ďalšiemu loadu.

Našli ste svoje poučenie?

Na čo ste prišli pri zamyslení sa nad vašim prístupom, ktoré ste spravili niekde v strede článku? V čom ste sa mýlili? V čom mali byť iné?

O minimálnom produkte rozhoduje používateľ, zákazník má potvrdiť zmysluplnosť produktu.

Stačí sa spýtať klientov. A načúvať ľuďom, ktorí kladú otázky.

Odpovede má dnes kde kto. Len či je ten pravý…

Alebo sa zaraďte medzi najlepších Product Ownerov na Slovensku, ktoré absolvovali naše programy Product Ownership MasterMind: Stratégia produktu alebo Product Ownership MasterMind: Dodávka produktu.