WD-40 pre softvérove projekty: job story

WD-40 pre softvérove projekty: job story

Myslím, že ste sa už stretli s tvrdením, že vlastne zákazníci nevedia, čo potrebujú. Respektíve ich návrh na riešenie je krátkozraký.

If I had asked people what they wanted, they would have said faster horses.(Vraj) výrok Henry-ho Forda.

Inak povedané. Nechcem sa zákazníkov (používateľov) pýtať,  čo by potrebovali - aké riešenie navrhujú, ale pochopiť podstatu ich problému - situáciu v ktorej sa nachádzajú.

Dnes opäť o teórii Jobs-to-be-done (JTBD), ktorá pomáha lepšie odhaliť motivácie, kontext a kauzalitu, vďaka čomu dokážem lepšie adresovať riešenie (inovovať).

All I want for xmas is progress

Každý človek má potrebu napredovať. Stať sa lepšou verziou samého seba. Samozrejme naše životné hodnoty a skúsenosti definujú, čo si pod týmto napredovaním (progress) každý predstavíme.

Teória JTBD sa snaží empiricky odhaliť "práce" (jobs), pre ktoré ako zákazníci "zamestnávame" (hire) konkrétne riešenia.

Napredovanie (progress)

Aby sme príčiny (ne)záujmu o naše produkty (služby) neodhalovali náhodne (gut feeling, pokus/omyl), ale skôr k tomu pristúpili ako inžinieri, môžeme aplikovať túto teóriu.

Typy customer jobov

Práce (jobs) je možné rozdeliť do 3 základných kategórií:

  • funkčné (functional) - chcem niečo konkrétne dosiahnuť
  • emocionálne (emotional) - chcem sa nejako cítiť
  • sociálne (social) - chcem byť nejako vnímaný ostatnými

Čo bráni napredovaniu?

Pri zamestnaní nového riešenia na môj job som vystavený 4 rôznym silám, ktoré ovplyvňujú, či chcem zamestnať nové riešenie. Sily možno rozdeliť do dvoch kategorií:

I. Motivujúce:

  • push - aktuálna situácia, problém, ma tlačí do hľadania nového riešenia (narodenie dieťaťa)
  • pull - samotné riešenie ma magnetizmus, atribúty, ktoré ma priťahujú (napríklad chcem nové auto, aj keď to staré stále slúži)

II. Demotivujúce:

  • obavy (anxieties) - pre zmenu riešenia si často kladiem otázky, čo sa stane ak, zmením
  • zvyky (habits) - moje návyky ma udržujú v status quo

Narodenie dieťaťa je spúšťačom, ktorý ma tlačí hladať nové riešenia pre moju situáciu. Napríklad začnem sa pozerať po väčších autách, keďže mám problém poskladať kočík do svojho kabrioletu.
Pri narodení dieťaťa sa zvyčajne rýchlo zbavujeme svojich pôvodných zvykov, lebo situácia je taká intenzívna, že aj naše pôvodné obavy sa teraz presmerujú úplne na inú úroveň.

It’s really an engineer’s way of looking at the market.
http://jobstobedone.org/radio/unpacking-the-progress-making-forces-diagram/

Všetko, čo mi bráni adaptovať nové riešenie na môj job sa prejavuje demotivujúcimi silami (obavami a zvykmi). Pre to, aby som zákazníkovi, nove riešenie "predal", potrebujem adresovať aj tieto sily.

Ak som napríklad projektový manažér, ktorý rieši migráciu nejakého systému na iné riešenie, môžem sa obávať o to, ako prebehne migrácia. Svedomitý riešiteľ sa preto bude proaktívne pýtať, alebo ponúkať riešenie na to, z ktorých nástrojov dokáže migráciu zabezpečiť už dnes, alebo ak je aktuálny systém neznámy, proaktívne bude túto obavu adresovať.

Job story

Job story zápis vymyslel Alan Klement spolu s ľudmi so spoločnosti Intercom. Predpis je nasledovný:

(role/context) When (in situation) I want to (motivation) so I can (outcome)

Konrétne príklady:

(som matka) Keď sa mi narodí dieťa chcem maximum podpory od štátu, a aby to bolo bez okolkov, a ja som sa mohla venovať dieťaťu.
(som dispečer)  Keď vznikne nová objednávka na vyzdvihnutie zásielky na odoslanie chcem vedieť o tých, ktoré je problém zrealizovať, aby som mohol proaktívne kontaktovať odosielateľa.

💡Persóny ako point in time snapshoty nie sú veľmi osožné. Rozhodovanie o "zamestnaní" riešenia nie je definované primárne mojimi atribútmi (muž, do 40 rokov, VŠ vzdelanie, zapadné Slovensko). Je definované situáciami, v ktorých sa nachádzam, je postupne formované na časovej osi (timeline).
Job story služia ako efektívny spôsob zachytenia potreby, ktorú majú (budúci) používatelia nášho riešenia. Pre dizajn riešenia zachytávajú kontext, kauzalitu a motivácie.

Hľadanie jobu

Nie nevyhnutne platí, že pre adresovanie jobov (hľadanie riešenia) musíme začať "na začiatku".

Môžeme mať aj super nápad na riešenie, ktorý vybublal na svetlo sveta vďaka našim doterajším skúsenostiam a vedomostiam.
Dodatočné zarámcovanie voči jobu nám však pomôže často neskôr v rozhodovaní, čo do súboru funkcionalít (riešenia) pridať, alebo nie. Na čo sa máme sústrediť, aby sme adresovaný job ešte lepšie obslúžili.

Toto je jedno z riešení, ktoré odporúčam aplikovať pre udržanie projektu v dobrej kondícii.

Na aktualizácie ohľadom víťazstiev, alebo zásadnejších prekážok odporúčam udržiavať pulz projektu pomocou tlkotov (heartbeats). Tlkoty sú krátke písomne aktualizácie, ktoré sa týkajú projektu. Ak sa nič nedeje, tak tlkot napíše na pravidelnej báze (týždennej, obtýždennej) projektový manažér, ale nič nebráni aj inému členovi tímu prispieť. Je to ekvivalent steny facebookovej stránky venovanej výhradne projektu a vecí s ním súvisiacich.

Aký sú joby, ktore riešenie "tlkot" adresuje? Tu sú dva konkretné príklady, ktoré je možné s riešenia vyčítať:

Keď som členom projektového tímu, chcem mať k dispozícii všetky aktualizácie pre kľúčové informácie, aby som vedel robiť správne rozhodnutia podľa aktuálneho kurzu projektu.
Keď mám novú kľúčovú informáciu hodnú zdieľania, mám skúsenosť, že email je čierna diera, v ktorej to zapadne, chcem ju oznámiť tímu, aby ju zobrali na vedomie.

Situáciu je možné ešte okoreniť takto:

Keď skončím meeting s klientom, šoférujem v aute, neviem písať, iba rozprávať, a mám novú kľúčovú informáciu hodnú zdieľania, chcem ju oznámiť   tímu, aby ju zobrali na vedomie.

A ako je (už len pre refenciu) možné zapísať už konkrétny návrh riešenia formou user story - predpis: As a (user) I want (result) so that (benefit)?
Kde tu osolené akceptačnými kritériami (viď odrážky).

As project manager I want to share information with my team so that they stay informed

As project manager I can set priority of information to ensure that cricital one are acknowledged

As project's team member I want to be aware with all critical information about project
- email notification is not expected solution
- stream of all critical information in chronological (DESC) order

As project't team member I'm able to confirm "message received" for  critical information distribution

As project manager I'm aware of all team members which not yet confirmed "message received"

Používať job story pomáha tomu, aby som kontext, motivácie a kauzalitu efektívne zdokumentoval pre seba, aj ostatný tím pre hľadanie riešenia. Vďaka tomu sa pri hľadaní riešenia zodpovie veľa otázok, riešenie sa nasmeruje na adresovanie tých najviac vypuklých trápení. A odpovie aj na obľúbenú na otázku: prečo sme to takto urobili? 😄

Show Comments