Dizajn riešení zákopovou metódou

Článok z blogchainu: zákopová metóda.

Dizajn riešení reprezentuje proces bádania (exploration), hľadania alternatív riešení pre identifikovaný problém alebo príležitosť.  Ak sa chcem vydať na cestu hľadania inovatívnych možnosti riešenia (strana ponuky), nemôžem riešiť symptómy, povrchové zistenia o správaní (potencionálneho) zákazníka, ale potrebujem ísť do hĺbky a potrebujem zasadiť problém/príležitosť do širšieho kontextu. Potrebujem pochopiť potreby/túžby (needs/wants) (stranu dopytu).

V akom komplexnom systéme s akými zavislosťami sa nachádzam? Bremeno už existujúcich prepojení nie je jednoduché prekonať, alebo to nie je ani mojim cieľom. To implikuje, či adresujem riešením lokálny alebo globálny problém.

Inovácia spočíva v aplikovaní zmeny na existujúce komplexné systémy alebo celkovom reštarte daného systému (a tu sa nebavíme len o IT systémoch ako takých), ktorou potrebu zákazníka doručím.

Teória JTBD

Nechcem byť na úvod príliš metafyzický, ale trocha teórie nikdy nezaškodí, tak chcem upriamiť tvoju pozornosť na teóriu Jobs to be done (JTBD).

A Job to be Done describes the “better version of myself”. It answers the question of personal progress: “How are you better since you started using service or product?” Competition for a JTBD is defined from the customer’s perspective, and is a zero-sum game: When customers hire a new solution for a JTBD, they always fire something else.

Zdroj: https://medium.com/@milez/jtbd-in-a-nutshell-34ad97acddf6

Teória  JTBD pomenováva, že zákazník používa (zamestnáva) vždy jedno riešenie na svoj (customer) job. To znamená, že treba odkryť,  čo je tým "jobom", a aké riešenia môže naň zákazník zamestnávať. Riešenie jobu nemusí byť nevyhnutnie práve jedno riešenie, môže ísť aj o kombináciu. Niektorý zákazník je pri riešení svojho jobu spokojný s jednoduchým riešením. Resp. toto riešenie je niečo, čo plní jeho očakávanie.

V knihe When coffee and kale compete, referuje Alan Klement príklad s inovátorskou ideou, ktorá mala za cieľ priniesť chladničku do vidieckych oblastí Indie - chotuKool. Táto idea však narazila na to, že toto relatívne lacné riešenie, narazilo na skutočnú konkurenciu, ako zákazník riešil svoj job. Nepotreboval chladničku, ktorá sa by sa nerozbila aj napriek častým výpadkom elektriny (nič nezvyčajne, že elektrika nejde aj 8hodín denne), kedže jeho job kvalitne obslúžili:

• nákup potravín na okamžitú spotrebu
• pot-in-pot
• chladenie v jame

Provotné princípy a širší kontext

Operujeme vo svete, ktorý je tvorený výšivkou komplexných systémov s veľkým počtom závislostí. Ako návrh riešenia problému/príležitosti sme naklonení ohýbať už existujúce nám známe riešenia. Napríklad pomocou aplikovania téorie obmedzení (theory of constrains) sa snažíme optimalizovať existujúci systém, aby výnos z neho bol vyšší (vyššia produktivita práce, vyšší zisk). Je dôležité myslieť out of the box. Čo sa ľahko povie, ale už ťažšie realizuje.

Leveling up too many times on the bigger context can quickly get meta-physical quickly where you start questioning the meaning of life. But most innovators don’t level up at all.

Zdroj: https://blog.leanstack.com/what-is-a-job-to-be-done-jtbd-21304ce7441b

Je potrebné si uvedomiť, že joby môžu na seba nadväzovať (chaining), alebo sú základom pre vznik ďalšich jobov (stacking) na štýl Maslowovej pyramídy potrieb. Je vždy dobré sa pokúšať odhaliť úplne prvotné joby, vrátiť sa k prvotným princípom na ktorých staviam a vyhnúť sa hľadaniu riešenia analógiou (takto som to videl, takto sme to už robili, takto to robí konkurencia). Nemusíme vždy nevyhnutne hľadať fundamentálne princípy (že sa dostanem svojimi prečo?, až k otázke zmyslu života). Avšak aplikovanie takéhoto prístupu zvyšuje pravdepodobnosť, že riešenie bude inováciou.

Toto len ako malá pripomienka, že existujú metodólogie/teórie, o ktoré je sa možné systematicky oprieť, podľa nich postupovať. Ďalšou, ktorá je tu s nami už nejaký piatok, je aj Outcome driven innovation.

Job story (Jobs To Be Done)

Pointa prečo to tu cele spomínam je to, že pre hľadanie vhodného riešenia (strana ponuky) je potrebné, čo najlepšie identifikovať, čo sa chystám adresovať (strana dopytu). Aby som sa vrátil z oblakov späť na zem, pre zdokumentovanie strany dopytu je vhodné použiť job story.

When _ [role context]__ , I want to ____ [because] ____ , so I can _____ .

• When - situácia, ktorú zvyčajne upresňujem na rolu, používateľa
• I want to - motivácia, ktorú môžem doplniť dodatočnými silami (because)
• so I can - očakávaný výsledok, benefit

Bázu základných informácií pre nabootovanie do job story,  ďalšie odporúčania, si môžeš rozšíriť  knihou od Alana Klementa When coffee & Kale compete (voľne dostupnou vo formáte PDF).

Zdokumentovanie potrieb/túžob pomocou job story, ktoré sa realizuje pomocou dotazovania (interview) zákazníka, vytvorí materiál, ktorý je základom pre hľadanie riešenia. Táto dokumentácia nie je riešením (je zadaním pre hľadanie riešenia).

Jednu aplikáciu na mieru, prosím

Či s použítim nejakej metodiky (JTBD) alebo bez, ak pochopíme zákazníkovú potrebu, tak skúsme nutkanie na všetko vytvárať aplikáciu na mieru zvážiť nasledovné prístupy. Ponuka totiž nie je len o tejto možnosti.

Áno, všetko má svoje plusy a mínusy. Len toľko, že si je dobré prejsť touto otázkou, či potrebujem hneď aplikáciu na mieru. V dobách google search-u nájsť na svoj problém riešenie je paradoxne náročné (veľa možnosti, mála dôvera voči nim, ako ich prepojiť?!).

Inžiniering alternatív

Keď sa už rozhodneme ísť prístupom, ktorý nám viac uvoľní ruky (platforma, aplikácia na mieru) je vhodné aplikovať vedomý krok v dizajnovom procese, v rámci ktorého sa riešiteľ zaväzuje, že bude navrhovať, hľadať vždy aj alternatívne riešenia. Nejde o to produkovať N nezmyselných možností, keď je zrejmé, že existuje práve jedna. Zdanie však môže klamať, ak do procesu zaradím tento krok, tak si vždy kriticky položím otázku, či som sa do prvého riešenia (návrhu) príliš nezaľúbil.

Excel, Access, no-code, low-code

Internety  začínajú v poslednej dobe žiť aktívnejšie low-code/no-code prístupom k tvorbe aplikácii. Niektorá z týchto platforiem sa isto stane ťahúňom pre biznisové aplikácie (a budem tajne dúfať, alebo lepšie googliť, že vznikne aj nejaká open source odnož, ktorú bude možné rozbehať na vlastnej infraštruktúre - myslím samozrejme IaaS/PaaS, nie on-premises).

V ideálnom prípade sú výsledkom procesu dizajnu riešení:

• zrevidované ciele
• zdokumentované potreby vo forme job stories
• hi level alternatívy riešenia

Vízia sa zhmotní do alternatív riešenia, ktoré dokážu naplniť ciele. Pochopenie cieľov a požiadaviek je nevyhnutným predpokladom, aby požiadavky na automatizáciu, biznisové aplikácie, zmenu procesov, boli v súlade s očakávaniami, a bolo možné vyhodnotiť ich (ne)splnenie.  Sú to všetko strategické rozhodnutia, ktoré ovplyvňujú životný cyklus softvérového riešenia zvyčajne na niekoľko rokov. Táto strategická fáza je kritická, aby sa realizácia zámeru podarila dľa očakávaní.