Přejít k navigační liště

Zdroják » Různé » Jaké potřebuji zadání?

Jaké potřebuji zadání?

Články Různé

Možná řešíte stejný problém. (Možná ne.) Jaké zadání potřebuji dostat? Co by mělo splňovat takové ideální správné zadání? Pojďme se na to podívat.

Text vyšel původně na autorově webu.

V poslední době často řeším, jaké bych chtěl dostávat zadání. Došel jsem k tomu, že správné zadání má mít právě tyto dvě části:

  1. Popis problému, který potřebujeme vyřešit.
  2. Business metrika, kterou změříme, že se to povedlo.

Zní to jednoduše, ale nám se to ne a ne podařit. Pojďme se na to podívat postupně. Místo popisu problému stále dostáváme řešení.

Místo:

„zákazník netuší, co má udělat na registračním formuláři“

dostáváme:

„tlačítko ‚Odeslat‘ zvýrazněte červenou barvou“.

Místo:

„potřebujeme ušetřit výdaje na ministerstvech“

dostáváme:

„postavte vládní čtvrť v Letňanech“.

I když se mi zdá rozdíl mezi popisem problému a řešením zjevný, lidi z nějakého důvodu prostě nejsou schopni se u popisu problému udržet a stále sklouzávají k řešení. Než se podíváme na důvody, proč to tak bývá, řekněme si, proč nechci přicházet k hotovému řešení.

Připravené řešení

Když dostanu připravené řešení, tak s ním často nesouhlasím. Často totiž nedává technicky nebo dokonce logicky smysl. Napadl mě následující příklad, představte si, že navrhujete auta a přijde vám požadavek – do okna spolujezdce vyrobte uzavíratelný otvor o průměru 18,7 cm.

Pokud se vám něco podobného stane, máte v podstatě jenom dvě špatné možnosti. Můžete to řešení napadnout a říci, že je potřeba vymyslet jiné. Nebo můžete sklapnout podpatky, udělat to podle zadaného řešení, i když nechápete, proč to děláte, a technicky vám to nedává smysl.

Změna zadaného řešení je často hrozně politicky složitá, spoustu lidí na něm strávilo spoustu času, dohodlo se na tom několik vrstev managementu, už se to slíbilo zákazníkovi a teď nějaký hloupý programátor přijde s tím, že by to dělal jinak? Proč se sakra ptáš, na to jaký problém tím chceme vyřešit? Prostě udělej v okně spolujezdce otvor o průměru 18,7 cm a přestaň klást hloupé otázky. Víš kolik času jsme strávili rozhodováním, jaký má být poloměr té díry? Že to nejde? Tvoje práce je tyto drobné technické detaily řešit.

Pokud najdeme odhodlání navrhované řešení zpochybnit, potřebujeme nejdřív zjistit popis problému. Proč by chtěli mít díru v okénku? Naštěstí se můžeme někoho zeptat. „Proč chtějí díru v okně spolujezdce?“ „No, náš důležitý zákazník chce vozit dlouhé tyče, do auta se jim nevejdou, tak je chtějí držet rukou podél auto venku z okénka. Ale když mají otevřené okénko, tak jim dovnitř fouká.“ (XY problem).

V těchto okamžicích si vzpomenu na strýčka Boba, který říká, že profesionál se pozná podle toho, že umí říci zákazníkovi „ne“. Takže profesionálně řeknu „ne“ a jsem označen za negativního. Nicméně je to pro mě lepší než druhá alternativa, udělat něco, co nedává smysl.

Abych to shrnul, pokud mě stavíte k hotovému řešení, nutíte mě buď vám to řešení rozbít nebo udělat něco, co firmě dříve nebo později uškodí. U díry v okénku se ty škody dají celkem slušně vysvětlit, dopad kupení hacků na hacky v složitém programu se vysvětluje podstatně hůř.

Řešení od neprogramátora

Tady arogantně předpokládám, že řešení, které přijde od neprogramátora, musí být špatně. Často špatně je, a to ze dvou jednoduchých důvodů:

  1. Programátoři často bývají jediní, koho napadne se ptát, co se bude dít v okrajových případech. Co se stane, když vypadne připojení v internetu v tomto okamžiku. Jak napravíme data, když operátor do tohoto políčka napíše špatné číslo. Co budeme dělat, když se k tomuto odkazu dostane zlý hacker. Co se stane, když držíte rukou tyč venku z okna a nabouráte? Programátoři se na takovéto otázky ptají, protože musí, potřebují to pro svoji práci. Pamatuji jen pár neprogramátorů, kteří měli podobné uspořádání mysli.
  2. Druhý důvod souvisí. Software je celkem složitá věc, chování nejen v okrajových případech bývá komplikované a nikdo nemá šanci si zapamatovat, jak se vlastně ta vaše aplikace chová za všech okolností. To je ale informace, kterou nutně potřebujete vědět, když vymýšlíte změny. Programátor se může podívat do kódu, kde to v lepším případě zjistí. Lidi, kteří neumí číst kód, nemají šanci se těmto důležitým informacím dostat.

Nicméně předpokládejme na chvíli, že máte superanalytika, který všechna tajemná zákoutí vaší aplikace udrží v hlavě nebo v dokumentaci a donese vám perfektní řešení. I tak je to špatně. Když neznám problém, který řeším, tak pracuji naslepo, nevím proč dělám to, co dělám, měním se v robota (nebo lumíka).

Když hádám, který problém řeším, můžu to uhodnout špatně a tím pádem to naimplementovat špatně. Když nechápu, proč chtějí díru v okénku, tak ji pravděpodobně udělám na špatném místě, takže skrz ni ruka ani prostrčit nepůjde.

Nevýhod hotových řešení je víc, nezbývá mi tu na ně ale místo, takže si je doplňte za domácí úkol. Pojďme se teď radši zamyslet, proč je tak těžké se udržet u popisu problému.

Tichá pošta

U nás se to děje především kvůli tiché poště. Obchodník řeší se zákazníkem jeho problém. Zákazník už má samozřejmě v hlavě nějaké řešení. Obchodník si pak sedne s produktovým manažerem, kde si buď řešení potvrdí nebo vymyslí lepší. Proberou to se zákazníkem, ten jim to schválí, vytesá se to do kamene a teď už jen zbývá to naimplementovat.

Tento scénář má mnoho variací. Místo zákazníka může být management, místo produktového manažera analytik, místo tesání do kamene je obvyklejší grafický návrh, ale všechny ty scénáře mají jedno společné. K lidem, kteří to budou dělat, a kteří celému systému obvykle rozumí nejvíc, se to dostane, až když je to celé vymyšlené.

Řešení hledá problém

Abych se netrefoval jen do cizích řad, tohle se děje často vývojářům. Máme v hlavě řešení, ale nemáme k němu problém. Nemusí to být zrovna vládní čtvrť, může to být nejnovější knihovna nebo jiný hype. Pokud jste někdy ve vaší firmě slyšeli „musíme najít něco, na co bychom použili strojové učení“ tak víte o čem mluvím. U nás to většinou skončí tím, že zkusíme napsat popis problému, který bychom strojovým učením mohli vyřešit. Poté většinou zjistíme, že se daný problém dá řešit lépe nebo že ten problém vlastně nemáme.

Vymýšlení řešení je přirozené

No a to nejtěžší na konec. Lidská mysl je stoj na řešení problémů. Je tak tak dokonalá, že když žádný problém nemá, tak problémy vymýšlí, aby měla co řešit. Je hrozně těžké se udržet u popisu problému. Je těžké říci „můj problém je takový a takový“, je pro nás přirozenější říci „chci to a to“. Je těžké říci „nerozumím tomuto formuláři“, říkáme „měli byste prohodit tato dvě políčka“. Každý chce přispět svým nápadem, takže se udržet u popisu problému je opravdu náročné, i když lidi přesvědčíme, že je to nezbytné.

Hra na závěr

Zkuste si následující hru, podívejte se do vašeho backlogu a spočítejte, kolik je tam lístečků s popisem problému a kolik čistě s popisem řešení. U těch popisů řešení zkuste zformulovat popis problému. U kolika z nich to dokážete? U kolika z nich si nejste jisti? U těch, u kterých to dokážete, zkuste narychlo vymyslet alternativní řešení. Kolik z nich bude lepších, jednodušších, levnějších?

Komentáře

Subscribe
Upozornit na
guest
9 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Martin Hassman

Při čtení mě napadlo jedno slovo a to slovo micromanagement. Není to sice přesně ono, ale důležitá část popsaného problému se v něm skryje. Kdo neví, doporučuji najít některý z článků popisujících, proč je micromanagement zlo.

Petr

Vždy zdůrazňuji všem od zákaznické linky až po programátora, ať se ptají Proč? A to tak dlouho, až od návrhu řešení zákazníka dojdou zpět k prvotnímu problému. A od něj má smysl teprve se odrazit a začít přemýšlet.

fos4

Zajímavé čtení.. má zkušenost je taková že u jednoduchých a banálních problémů, kde je nutné přesně zadání (např. změn barvu submit v druhém kroku košíku na #ffccaa) většinou napíšou pouze musíme změnit barvu submitu – programátor není analytik, grafik apod. aby mohl říci že tady se více hodí zelená, nebo modrá apod.

Naopak u složitých (a technických) problémů se lidé snaží popsat řešení a pak dopadá katastrofálně, neznají všechny ty okrajové části, řeší si jen ten „svůj problém“ nehledě že se rozbije vše okolo.

S článkem víceméně souhlasím, ale ještě bych to rozdělil na ty „jednoduché úkoly“, které programátor nemůže řešit (ale často se to na něj jen přehodí), a ty „složité“, kde je programátorům dáváno řešení které je nesmyslné a nesplnitelné. Prostě je to naopak než by to mělo být…

Tim

Problém: Zaměstnanec sedí v imagináriu, kde nejsou technické prostředky pro ukončení tasku a je nutné kontaktovat někoho z human resources na druhé straně budovy, aby co nejdříve zajistil hmotný support (lze volně přeložit jako „vyrábí artefakt, došel papír, nutné kontaktovat hajzlbábu“).
Je mi jasné, že dostanu spoustu tvůrčích řešení:
* Mobilní appka synchronizovaná přes cloud
* Heuristický algoritmus (strojové učení, konečně ho někde použijeme, jupí) zpracovávající face recognition, den v týdnu a jídelní lístek z kantýny
* Intercom do všech míst, nejlépe to nejdražší od Cisca. Samozřejmě s kamerou!
Co ve skutečnosti chceme: dát na stěnu čudlík, od něj natáhnout drát vedoucí k vhodně umístěné žárovce hnědé barvy…

Martin Hassman

Nemyslím, že úloha “zatelefonovat kolegovi, aby mi přinesl…” je typickou pro IT oddělení. 8-) Popsané mi přijde spíš jako korporátní problém.

Ondra Medek

Tak to jste vynalezl kolo. Prostě SCRUM user story INVEST https://www.agilealliance.org/glossary/invest

Jaroslav Týc

Nejde o to jestli něco vynalezl, ale jak nám to předal. Přišel na to sám, popsal to svými slovy, přidal své zkušenosti a příběh a sdílel to s ostatními, čehož si cením a čte se mi to mnohem líp, než heslovitý, technický manuál z agile aliance.
Takže máš pravdu, ale já jsem rád, že nic takového autora článku nezastavilo.

Martin Hassman

👍 Díky, dobře napsáno.

Radim Polášek

Zadání problému přirozeně musí být zadání, ne řešení. Ale pokud nějaký uživatel, který to bude používat, používá jako zadání nějaké řešení, je vhodné toto řešení od uživatele při vstupní konzultaci vzít a přiložit k zadání jako návrh.
Pokud totiž bude návrh uživatele přehlížen a uživatel dostane „silou vnucené“ jiné řešení, má uživatel sklon považovat své odmítnuté řešení za lepší než to vnucené a to vnucené řešení všemožně znevýhodňovat , torpédovat, hledat důvody, proč to vnucené řešení nepoužívat a všemožně ho upozaďovat atd. Což může nakonec dopadnout tak, že se zpracované řešení takzvaně „neujme“ a náklady a energie na ně tak byly vynaloženy zbytečně.
Návrh toho řešení , pokud se během zpracování projektu důvodně ukáže, že není vhodné, je pak možné s reálným zdůvodněním zapsaným do dokumentace projektu vyřadit a použít vhodnější řešení.
Přirozeně potřebuje to, aby zpracovatel projektu – programátor ty informace o reálném zadání projektu bezpodmínečně měl. Aby jeho práce měla smysl, musí si tedy ty informace umět vydobýt. V krajním případě neoficiálně, ale musí je mít. Nemůže zůstat jen ten „poslední vzadu“, který dělá to, co mu ostatní řeknou.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.