Rychlá zpětná vazba je o co tu jde

vítejte u poslechu podcastu you Build it Jan Podcast o všem co potřebujete vidět když chcete provozovat globální internetovou službu tématem vás provázejí Láďa a Vilda

you Build It You Run it je filozofie která nevznikla ve vákua snaží se vyřešit konkrétní problémy a v tomhle díle se pobavíme trošku o historii a taky o dalších možnostech a jejich výhodách nebo nevýhodách Vildo když nás někdo poslouchá začal pracovat v oboru v posledních 10 letech a setkal se jen s def fobs nebo pracuje jen v malém týmu vůbec netuší Proč se vlastně o tomhle přístupu bavíme Můžeš popsat jak vývoj běžně vypadal dřív vynikající otázka moje oblíbený téma ale já možná začnu úplně hodně radikálně historickou vsuvkou o tom jak vlastně se vývoj softwaru jako takovej začal ten začal vlastně Kdysi dávno ve spojení s hardwarem a to nejcennější byl ten hardware a software byl jenom jako taková věc k tomu a vlastně jako koneckonců to je vlastně Jak vzniknul celej Open Source je právě protože dří si člověk koupil hardware a pak si to doprogramovat jak potřeboval Takže měl všechno k tomu postupem času jsme se dostali do bodu že se začal v software prodávat zvlášť ale ještě jsme neměli internet Ještě jsme neběželi software jako službu a tak dále

a tam se používala spousta různejch technik jako kde třeba byl vývojový tým kterej to vyvinul pak byl pak se přišlo na to že je potřeba nějakej tým k udělá nějakou kontrolu kvality takže to se bavíme o tom že byl testing a a pak se to za za materiál zabalilo takzvanej shrink rap software se tomu říká a prodávala se krabice s cdk s

disketami vlastně že jo A tam z tý doby je třeba já teď J jsem si vzpomněl na výbornou knížku mythical Man month která vlastně mluví o tom jak se ten vývoj pohyboval a že vlastně bylo něco co se dodneska říká takzvanej Waterfall model kdy se všechno nad designoval předem a pak se podle toho plánu to všechno udělalo a zjistilo se že půlka věcí jsme na ně nepomysleli druhá zabralo To šestkrát tolik času a bůhví jaký další komplikace a vlastně na to třeba byla reakce takzvanej takzvaný agilní Manifesto který se snažilo to eh vlastně přistoupit tomu a řešilo to ale z pohledu jako m dodáváme software na cdk takže my potřebujeme Nějakou zpětnou vazbu nějakým způsobem něco dodáváme myslím že v dnešní době ten artefakt tohodle toho je skram kterej nevím jak moc už s tím má společnýho každopádně v momentě kdy se začal objevovat služby jako na internetu provozovat se bavíme v 90 že jo třeba tak v těch 90 letech tak vlastně bylo to tak že ono to furt kopírovalo tenhleten model Takže člověk

měl vývoj ten vývoj to někam dál a dostalo to nějaký qa zase zase nějaký testeři a pak to dostalo takzvaný Operations který to vlastně jako nasadili a někde běželi a mezi těmahle těma třema silama v podstatě byla hrozně obtížná komunikace tole ten e že jo tole je vlastně ten tradiční přístup řekněme kterej se začal měnit a postupně přá přišlo vlastně jakoby nějaká filozofie devops kdy najednou jako přesně ten Development je nějakým způsobem ty výři jsou z zas zastoupený v tom e tom běhu nějakým způsobem máme tady pak několik různejch přístupů že jo třeba jako je Google kterej prosazuje svoje SR což je vlastně iterace nad tou částí Operations kterou se snaží zase vlastně posunout víc do vývoje aby zautomatizovat spoustu věcí tak aby bylo potřeba míň lidí protože tradiční Operations většinou znamená Potřebuju dělat víc potřebuju víc lidí a vlastně to you Build It You Run It s tím přišel že jo S TM tím heslem přišel Amazon nebo AVS teda teď nevím jestli to byla m nebo AVS AVS už ještě už A kde vlastně ta podstata

tví v tom že vývojáři mají těsnej kontakt s produkcí a tím pádem dostávají rychlou zpětnou vazbu o tom co vyrábějí zároveň AVS prosazuje velikost týmu takzvané Two pizza teams je kde vlastně nakrmíte dvouma pizama celej tým takže to trošku dává představu o tom jak velkej ten tým má být a přesně k Tom mu to ild IT unun docela sedělo vlastně k tý jejich filozofii Já třeba vlastně jak mám možnost se teď bavit s lidma který jako v tom v tom avsu třeba hodně dlouhou dobu pracovali Tak můžu říct že vlastně ono to má tam je ohromná právě voda výhoda v tom že vlastně člověk vydělí jak tradičně měl ten jakoby vývoj ten produktový vývoj nebo když to vezmem do extrému tak je nějakej produktový tým kterej vymýšlel ten produkt pak to někdo vyvíjel pak to někdo testoval a pak to někdo jako provozoval a vlastně tady je snaha tohleto všechno zrušit a mít jeden tým který dělá všechno Já osobně moje zkušenost s tím je taková že je to naprosto perfektní pro přístup pro situace kdy já potřebuju rychlou zpětnou

vazbu já potřebuju vědět co se děje a potřebuju na to rychle reagovat a příkladem jsou právě většina těhletěch různejch vlastně software Z Service je ukázkovej kde vlastně já když vidím problém můžu ho opravit a do hodiny je všechno opravený pro všechny Fantastický to je úplně perfektní a v momentě kdybych tam měl nějakej systém Právě takhle těch dalších jako vrstev tak se bavíme o tom že fix jednořádkový fix se můžem bavit 14 dní tejden měsíc já nevím no přesně jako to jsou mý zkušenosti vlastně s tím když já jsem ještě začínal jako vývojář v lmc tak vlastně přesně jak byly ty separátní oddělení Tak kluci z produktu napsali ty dokumenty ve Wordu že jo popsali tu tu tu co chtějí vyvíjet a já když jsem se k tomu jako Developer dostal to bylo třeba tři měsíce po tom co oni to napsali já dojdu za nima protože jsem to nechtěl číst jsem byl trochu línej a ptám se jich a jak jak to mysleli a oni řekli No to už nechcem My chceme něco úplně jinýho a vlastně tím

že jsem byl třeba jeden z mála developerů kterej aktivně za nima chodil a ptal se tak jsme potom doručili něco co dávalo smysl ale kdybych jenom to vzal to co jsem dostal ten dokument tak jsem vytvořil něco co vlastně vůbec nikdo nepotřebuje a pro to vlastně když potom se změnilo to Paradigma a ten produkt se víc napojil s tím developmentem a vlastně Přešli jsme s qa vlastně že lidi jsme integrovali do Development týmu tak to dávalo smysl protože přesně na tom sasu bylo vidět že ta zpětná vazba rychle od zákazníků k tomu produktu dává obrovskej smysl a zároveň i ty lidi z toho produktu každým dnem mluvěj se zákazníkama a tak vlastně otesává i ty svoje změny ve svý hlavě a potřebujou to v nějakým rozumným měřítku dostávat do toho produktu protože ty požadavky se fakt měněj a někdy hodně často závisí na konkrétních zákazník A může to bejt ten týden i úplně něco jinýho No teď J jsem si vzpomněl na doby mapy.cz kdy jsme dělali spoustu vlastně vývoje kterej probíhal tak že mě to lokálně nějak f

fungovalo Já jsem udělal nějakou binárky a za nějakej čas bůhví kolik nikdy jsem vlastně nevěděl ani jako kdy to nasadí kdo jestli něco co je potřeba nebo není potřeba nebo vlastně jsem jako fakt se pohyboval v totální tmě tak pak Já si vzpomínám že jsem přesně dostal report že je tam někde nějakej bug a trvalo trvalo mi jako přijít na to co se děje jako fakt dlouho Bavím se třeba 14 dní jsem to tam různě honil po všech čertech simul kdeco abych na to přišel a výsledek byl No ta chyba v tý současný verzi už není to byla ta předchozí jo tak jenom taková ukázka toho jak jak jak vlastně když ta zpětná vazba trvá dlouho jako do jakých absurdních situací se člověk může dostat Přesně tak bildu Probrali jsme trošku Waterfall z rychlíku opravdu a s příchodem Agila scamu se začal přístup měnit naštěstí právě to produktový řízení tlačilo na zlepšení tý zpětný vazby O tom jsme se tady bavili dneska existují různé přístupy který se dají uplatnit podle týmu Podle stylu práce jak dneska třeba

vidíš svůj pohled na skram z hlediska vývojáře na rovinu Já jsem skram nikdy nechápal mě vždycky přišel absurdní Ačkoliv jsem velkej fanoušek toho agilního manifesta tak myslím si že to bylo mrtvý už když to vzniklo ale myslím si že že vlastně jsme ty zkušenosti který jsme s tím udělali ukazujou že to opravdu vzniklo v kontextu výroby softwaru pro CD a ne pro něco co běží kontinuálně a je pravda že teď už jsou i třeba nový nápady jak to dělat třeba z basecampu ten Shape Up já můžu říct že třeba v oci vlastně scram nepoužíváme ačkoliv to agilní přístup máme a je vlastně otázka pak třeba hodně populární je kanban eh že jo a máme určitě jako dalších teď každej si to nějakým způsobem uzpůsobuje ty tý tý svojí situaci A Eh Já si totiž nemyslím že vlastně existuje způsob kterej funguje úplně pro všechny a chtěl bych tím všem jako říct Heleď ten Nebojte se vlastně jako si to přečíst A pak říct no todleto nám nedává smysl tuhletu část dělat nebudem a tuhletu část dělat budem

a já třeba můžu říct že eh moje současná Zkušenost je taková že Uděláme nějakej plán tohleto bysme chtěli udělat do tří tejdnů takže to je náš sprint ten je zrovna teď tři tejdny a příště bude No my potřebujem udělat todle to bude trvat tak 14 dní tak máme sprint 14 dní a nemáme jako rigidní sestavu já teda se přiznám že vůbec ten název sprint je komickej protože nikdo nespra furt že jo ale to je jen tak na okraji ještě vlastně Láďo ty ty jsi pro sá práce vždycky pr zoval kamban který jsem já hrozně Krč zmínil a myslím si že by stálo za toho rozebrat trošku víc protože to je asi nej mě nejbližší způsob jak organizovat práci určitě kanban vlastně pochází z automobilový výroby vymysleli ho v Toyotě a to je způsob vlastně že máte nějakej společnej Board a řídíte priority vlastně pro ten tým nějak operativně Já jsem to dělal tak že vlastně My jsme měli backlock Podobně jako ve scamu kde byly všechny věci co jsme chtěli udělat ale právě díky kanbanu jsme limitoval počet věcí

co co na kterých pracujeme podle počtu lidí v týmu a vlastně každý ty t den jsme řídili priority jo že my jsme neplánovali sprinty Nedělali jsme nic jakoby že bysme ohodnocovat tsky a podobný věci který vlastně jsou ryze umělý v tom v tom scamu ale jediný co já jsem potřeboval je každotýdenní říct jaký je Progres těch věcí na který lidi dělaj a jestli se nezměnily priority protože právě v operativním řízení jako je Sar Vy chcete mít dedikovaný čas na nějaký dlouh ější věci chcete aby tohle bylo třeba 60 70 % jejich práce a zbytek je nějakej toil nějaká nějaká věci právě co co jsou incidenty a další věci spojený s produkcí nechcete aby tohle přerůstala 50 % Jo a musíte řídit trošku priority Protože přijde Security incident přijde nějaká věc tak nemůžete říct teď 14 dní já na ničem nedělám Ne ty tam priority se měněj ale musí na to bejt nějakej systém a a dobře to fungovat A tohle se mi osvědčilo a v tomhletom případě Jak jak se dá zabránit tomu aby se nestalo

to že skončím jenom v pekle e neustálý změny e kvůli incidentům no Tam je právě důležitý aby eh vlastně tam ta část tý plánovaný práce vždycky byla aby se eh dedikoval nějak Time boxoval ten čas těch lidí a já myslím že to je hodně o těch manažerech vždycky e o tý prioritizaci těch věcí a mít správně nastavený priority umět prosazovat věci že je potřeba zpracovávat věci na technickej dluh aby se rozvíjela ta automatizace kolem věcí aby se dobře udělalo to pos mortem a ty věci se naplánovali dlouhodobě který přinesou úsporu vlastně na tom na tý toju na tý práci která je ad hoc tím že vylepšíš vylepší se monitoring vylepší se nástroje s kterýma pracujete a je opravdu je vždycky problém u lidí nebo v týmech co jsem viděl který nemají manažery který nemají zkušenosti s těma věcma a neumějí to správně prioritizovat a často ty

vývařiště dělat a že to má tu prioritu často to vidím že že v některejch týmech třeba ty fičury mají prostě vždycky přednost před technickým dluhem ale to dlouhodobě prostě nef funguje a je potřeba to řídit rozumně a není to jednoduchý no no část problému je určitě v tom že e za featury se dostává velkej e velká pochvala a přídavky a já nevím co Promotion a pod promy a tak dále A za to že to běží perfektně a nikdo si nestěžuje tak to vůbec nikoho nezajímá že jo To je taková jako já jsem teďko nevím kdo Někdo mi ale říkal že vlastně ta práce kterou děláme my někdy při tom běhu To jsou takový e bradavický stříci prostě nikdo neví a když to funguje Funguje Nikdo se nestará a je pravda že tohle jsem se snažil třeba jako manažer hodně prosadit že právě všichni ve velkejch firmách znají Performance review každoroční tam se bodujou věci na ten postup na další level jako vývojář a právě třeba věci kolem automatizace rozvoje tý produkce tam nebyly bodovaný ty lidi který na tom strávili

enormní množství času vylepšili to pro ten tým nedostali zpátky tu pozornost kterou měli a často i kvůli tomu potom odešli a já jsem hodně třeba zespoda tlačil na to aby aby to mělo stejnou úroveň jako jako ty fičury a doufám že se to časem posunulo protože tahle práce je stejně důležitá ba důležitější často protože to prostě je vidět potom v těch nákladech a v bezpečnosti a v dalších věcech Já si myslím že to hodně souvisí i s tím mentálním modelem který ještě furt jako svým způsobem je starej zdob toho klasickýho vývoje kdy to bylo tak že já jsem dodal feature My jsme to pak jako že jo prodalo se to a byli jsme a bylo to báječný ale teď je to jako já jsem udělal feature která na té výbornej článek na na US nixu kterej by možná stál za to tady linknet eh na téma eh právě jakože My hrozně ceníme když se něco vykopne a už nikdo nezkoumá jak to přistálo přesně jestli to někdo používá jestli to vůbec někdo používá jestli to jako jak moc tahleta

věc zhoršila běh celýho toho systému třeba e často moje Zkušenost je taková že nová feature znamená Wow zatíží se nám databáze jako vo tolik moc že my máme Najednou 10krát tolik incidentů a je to jako Měli bysme to ocenit nebo co je špatně že jo to je jenom taková jako něco na zamyšlenou E Vildo Zkusme ještě probrat you Build It You Run it Eh z toho pohledu kdy to dává nejvíc smysl kdy podle tebe To dává smysl a kdy je to komplikovaný nebo to jakoby z nějakejch důvodů vlastně nejde a musí se udělat nějakej kompromis jak tohle vidíš Já osobně si myslím že to jde skoro vždycky a jenom je to o tý míře jak moc to všechno jako sadím přesně jak je to jak jsme se bavili o tom scrumu nebo těhletěch různejch agilních metodách kdy já si něco vyberu něco ne Tak todleto je stejný v podstatě vynechám li vývoj software kterej probíhá na ve stylu jako já něco vyrobím a pak to dodám a skončil jsem jo typuju jako prodávám to na CD nebo

downloadu nějaký Installer Tak když vynechám todleto tak si myslím že je jako že to člověk chce vlastně vždycky do nějaký míry a teď Samozřejmě jsou zkomplikovaný prostředí který mají nějaký regulatorní požadavky že jenom nějaký vybraný lidi můžou mí přístup nějaký jiné a tak dále s tím třeba mám bohatý zkušenosti teďko s oci kde to takhle je A tam volíme vlastně jakoby takovej SR přístup kde máme lidi který jsou ta first line of Defense jakoby ta stoj v tý první linii protože ty jediný můžou s tím pracovat a jejich zpětná vazba pak ovlivňuje vývoj protože u nich sledujeme přesně to jak moc jakoby když udělá udělá změnu jak moc to padá jak moc moc velký efekt to má na běh a tím pádem i když ten tým jako takovej Nemůže už v tom daným místě tu věci dělat a předává to někomu Tak ten někdo zároveň jako úzce spolupracuje a vlastně dělá tu informaci zpátky velice rychle abysme právě měli tu tu zpětnovazební smyčku co nejkratší ale tady bych zmínil že tady vlastně i ten člověk co pracuje třeba v

tom federálním regionu je vlastně zaměstnanec oci Není to nějaká třetí strana vlastně že jo Ne ne ne ne To jsou furt je to furt jakoby jeden tým jako že jo to je to ale je to právě organizačně vlastně uzpůsobený tak že tam kde běžný vývojáři nemůžou tak tam si to jakoby přebere přebere vlastně jakoby nějakej SR inženýr který pracuje který má třeba na starosti několik služeb který má spaci úzce který nějakým způsobem třeba spolu souvisej jakože vezmem příklad observable bility je vlastně jakoby máme monitoring Jo alerting a logy tuhletu část prostě vlastně pracujou si tam pár inženýrů který se o to starají který tím pádem mají úzký vazby znají lidi znaj ten znají ty projekty a tím pádem jsou schopný třeba velice rychle zase D dodávat zpátky Jako zpětnou vazbu Hele todle takhle děcka ne jo To zároveň mají ty prověrky aby mohly pracovat vlastně třeba v US nebo v Uka regionu pro vládu že jo nebo i v EU že jo to tak jak Jo jo vždyť jo vlastně v EU teď teď nově taky

a určitě to bu zač až bude nějakej vládní Cloud tady v Čechách tak určitě to taky musí bejt e nějakej člověk kterej má přístup a je prověřenej to bude asi všude stejný já ještě vím že třeba jeden z argumentů kterej byl jakoby proč proč to jako vlastně nedělat je jakoby nějakej finanční nebo ve smyslu jakože to je nákladná věc že že najednou Operations dělá jako strašně moc lidí e Já si myslím že to možná dávalo smysl dřív tenhle Argument teď j o něm už zdaleka nejsem tak přesvědčenej obzvlášť třeba eh s tím množstvím různejch nástrojů který máme mám pocit že ve skutečnosti ty extra náklady s tím spojený třeba s tím že nějakej trénink pro vývojáře vývojáři se nevěnují vývoji a věnujou se eh nějakým opravám a tak dále tak ve skutečnosti nedělají nejsou tak obrovskou položkou protože jako když mám dedikovaný lidi na na na na na Operations Tak já je potřebuju jako fakt vytížit aby se mi to vyplatilo a skutečnost říká že většinou to je víc je to mnohem náhodně jší a už to tak úplně

nefunguje a je jednodušší v podstatě ty náklady rozložit mezi všechny inženýry co mám a možná možná věnovat nějakou jakoby část na podporu jako vývoje nástrojů že jo koneckonců mám pocit že Platform Engineering je teďko jako baz vrt pořádnej Tak to je v podstatě takovej jako snaha že jo To to nějakým způsobem akceptovat určitě a k tomu vlastně když se to tak veme Tak ty náklady na ten oncol jsou fixní protože máte jenom 247 a v chce když máte nějakou sadu pokrytí tak vlastně si přesně řeknete a jestli se to rozloží mezi pět lidí nebo Jeden člověk má tu samou dobu ten náklad je stejnej Vildo to Už se blížíme pomalu ke konci e nějaký ten příklad kde si myslíš že to má super smysl že tam s tím Začneme hned od začátku Já si myslím že že pokavaď dělám jakýkoli sáz tak tím mám začít jako začnu to dělat hned takhle jako v rovnou jakože já mám pocit teda že vlastně ty nej když je člověk když člověk začíná je to malej Startup Tak to

je v podstatě jediná varianta kterou má ale pak bych s ní měl zůstat právě No já si myslím že nejtěžší je vlastně s tím zůstat když rychle vyrostete jo opravdu když když jsou dneska startupy který přijímaly stovky lidí jako ročně teď už to zase Díky krizi trošku eh zas loff fu Jou stejně rychle jako přijímali ale Eh tak je to asi nejtěžší protože prostě když přijmete 100 lidí tak vy je na onboard jete do onkol to je prostě těžký to chce čas když přijímáte pomalu lidi vlastně po pár lidech do týmu Tak to pomalu vstřebá Ta kultura a je to potřeba vlastně začlenit ty lidi do toho týmu v tom týmu Ta kultura toho onkol musí bejt zažitá ty lidi to přeberou a uměj já si pamatuju že často nám říkali lidi že vlastně ten onkol nechtěj že to nefunguje že v jejich předchozí firmě to nešlo a potom když přišli třeba do apiary a viděli jak ta kultura kolem toho je tak to vzali za svý a automaticky vlastně fungovaly a fungovaly dobře a potom se divili

někteří třeba junioři co u nás začínali že když odešli s apiary jak to jinde nefunguje Já bych řekl že na většině míst jsem zatím viděl eh se to neumí dělat úplně dobře no to je moje zkušenost protože to furt často bejvá jako druho řada nebo bůhví kolikátá priorita a a tím pádem vlastně se tomu nevěnuje péče já jako na jednu stranu Jasně Je to svým způsobem náklad z mýho pohledu Dobře dobře udělaná tahleta část těch jakoby toho běhu většinou znamená že je dobře udělanej i ten zbytek určitě A já si myslím že tam je vždycky důležitý ten provoz je pro ty stávající zákazníky koukat na ně že oni když si tu službu jednou koupili tak ji chtěj mít spolehlivou koukat na to aby vlastně ten běh byl bezproblémový a oni taky ty vývojáři potom ocení že když je to dobře udělaný tak mají třeba jeden incident za týden a nemají jich pět denně a úplně jinak ten onkol vnímá člověk který měl jednou za rok incident a nebo někdo kdo nemůže poslední tři tejdny spát kvůli

tomu že ho každej večer co má on Call něco vzbudilo Já myslím že ještě tam je jeden Faktor na kterej jsme možná tak trochu zapomněli a to je jako taková nějaká jako dospělost tý firmy jo já když vezmu nějakej začátek prostě tak vlastně jako hejbat se jako Move Fast Break Things nebo jak to maj možná funguje jo ale to je ve Facebooku ne No doufám že už to tak nedělaj nebo já nevím já myslím že jo jo ale eh Spíš jsem chtěl říct že to možná dává smysl na začátku se agresivně soustředit na to abych já vůbec jako dodal něco co dává smysl a že mi to občas padá a že že to jako ne úplně skvěle funguje je vlastně úplně v pořádku protože zároveň moj zákazníci taky tak trochu počítají s tím že to je hele my do toho jdeme My jsme tady early adopter jako my víme že to bude jako hrozný možná na začátku ale v momentě kdy začnete bejt úspěšný tak možná se stáváte eh dodavatelem elektřiny to znamená jako vy jste vy už o vás nikdo

nechce vědět nikdy vám se budou platit peníze a chceme aby to fungovalo a už nás vůbec nic nezajímá a a Třeba tahleta změna taky je si myslím fakt náročná poznat chvíli kdy jako hele my už Si nemůžem dovolit to rozbíjet tak často určitě určitě právě být komoditou jako je dneska prostě Facebook sociální sítě eh vyhledávače jako je Google je opravdu těžký A mít prostě ty čtyři pět devítek je obrovsky drahá věc ale zároveň naprostá nutnost jo přesně tak díky moc všem za E za poslech a dřív ještě než se rozloučíme tak Láďa má pár novinek zase jo založili jsme maston účet you Build It You runit fos toon org link dáme do popisku podcastu kde bysme rádi Uvítali vaši zpětnou vazbu určitě se nám ozvěte pokud byste chtěli něj něaký téma abysme probrali v dalších epizodách My máme spoustu nápadů co co probrat akorát právě se jak to seřadit co dřív to byste nám hodně pomohli právě kdybyste nám napsali Tak jo díky moc Láďo a těším se zase se všema brzo naslyšenou brzo naslyšenou

[Hudba]