Tim Lister - spoluautor knih

• "Lidský faktor. Úspěšné projekty a týmy“ (původní kniha se nazývá „Peopleware“)
• „Valčík s medvědy: Řízení rizik v softwarových projektech“
• „Adrenalinem poblázněný a zombifikovaný vzorci. Vzorce chování projektových týmů"

Všechny tyto knihy jsou klasikou ve svém oboru a byly napsány společně s kolegy v Cech Atlantických systémů. V Rusku jsou jeho kolegové nejznámější - Tom DeMarco и Petr Hruška, který také napsal mnoho slavných děl.

Tim má 40 let zkušeností s vývojem softwaru, v roce 1975 (žádný z těch, kdo tento habrapost napsali, se letos nenarodil), byl Tim již výkonným viceprezidentem společnosti Yourdon Inc. Nyní tráví čas konzultacemi, vyučováním a psaním, s občasnými návštěvami se zprávami konferencí po celém světě.

Speciálně pro Habra jsme udělali rozhovor s Timem Listerem. Bude zahajovat konferenci DevOops 2019 a my máme spoustu otázek ohledně knih a dalších. Rozhovor vedou Michail Druzhinin a Oleg Chirukhin z programového výboru konference.

Michael: Můžete říci pár slov o tom, co teď děláte?

Tim: Jsem hlavou Cechu atlantických systémů. V Cechu je nás šest, říkáme si ředitelé. Tři v USA a tři v Evropě – proto se Cech nazývá Atlantik. Jsme spolu tolik let, že je prostě nespočítáš. Všichni máme své speciality. S klienty pracuji poslední desetiletí nebo více. Moje projekty zahrnují nejen řízení, ale také nastavení požadavků, plánování a vyhodnocování projektů. Zdá se, že projekty, které špatně začínají, většinou špatně končí. Proto se vyplatí dbát na to, aby byly všechny aktivity skutečně promyšlené a koordinované, aby se spojily nápady tvůrců. Stojí za to přemýšlet o tom, co děláte a proč. Jaké strategie použít k dokončení projektu.

Již řadu let poskytuji poradenství klientům různými způsoby. Zajímavá je například firma, která vyrábí roboty pro operace kolen a kyčlí. Chirurg neoperuje zcela samostatně, ale využívá robota. Bezpečnost je zde, upřímně řečeno, důležitá. Ale když zkusíte probrat požadavky s lidmi, kteří jsou zaměřeni na řešení problémů... Bude to znít divně, ale v USA ano FDA (Federal Drug Administration), která licencuje produkty, jako jsou tito roboti. Než něco prodáte a použijete na živé lidi, musíte získat licenci. Jednou z podmínek je ukázat své požadavky, jaké jsou testy, jak jste je testovali, jaké jsou výsledky testů. Pokud změníte požadavky, musíte celý tento obrovský testovací proces absolvovat znovu a znovu. Našim klientům se podařilo zahrnout vizuální design aplikací do svých požadavků. Měli screenshoty přímo jako součást požadavků. Musíme je vytáhnout a vysvětlit, že většinou všechny tyto programy nevědí nic o kolenou a kyčlích, všech těch věcech s kamerou atd. Potřebujeme přepsat dokumenty požadavků tak, aby se nikdy nezměnily, pokud se nezmění některé opravdu důležité základní podmínky. Pokud vizuální design není v požadavcích, aktualizace produktu bude mnohem rychlejší. Naším úkolem je najít ty prvky, které se zabývají operacemi kolena, kyčlí, zad, vytáhnout je do samostatných dokumentů a říct, že to budou základní požadavky. Udělejme izolovanou skupinu požadavků na operace kolena. To nám umožní vytvořit stabilnější sadu požadavků. Budeme mluvit o celé produktové řadě, nikoli o konkrétních robotech.

Udělalo se hodně práce, ale i tak se dostali do míst, kde předtím trávili týdny a měsíce opakovaných testů bez smyslu a potřeby, protože jejich požadavky popsané na papíře se neshodovaly s reálnými požadavky, pro které byly systémy stavěny. FDA jim pokaždé řekl: vaše požadavky se změnily, nyní musíte vše zkontrolovat od začátku. Kompletní překontrolování celého produktu zabilo podnik.

Existují tedy úžasné úkoly, kdy se ocitnete na samém začátku něčeho zajímavého a hned první akce stanoví další pravidla hry. Pokud se ujistíte, že tato raná aktivita začne dobře fungovat jak z manažerského, tak z technického hlediska, je šance, že skončíte se skvělým projektem. Ale pokud tato část vypadla z kolejí a někde špatně, pokud nemůžete najít základní dohody... ne, není to tak, že by váš projekt nutně selhal. Ale už si nebudete moci říct: „Zvládli jsme to skvěle, všechno jsme udělali opravdu efektivně.“ To jsou věci, které dělám při komunikaci s klienty.

Michael: To znamená, že spustíte projekty, uděláte nějaký výkop a zkontrolujete, že koleje jdou správným směrem?

Tim: Máme také nápady, jak poskládat všechny dílky skládačky dohromady: jaké dovednosti potřebujeme, kdy přesně jsou potřeba, jak vypadá jádro týmu a další takové zásadní věci. Potřebujeme zaměstnance na plný úvazek nebo můžeme zaměstnat někoho na částečný úvazek? Plánování, řízení. Otázky typu: Co je pro tento konkrétní projekt nejdůležitější? Jak toho dosáhnout? Co o tomto produktu nebo projektu víme, jaká jsou rizika a kde jsou neznámé, jak se s tím vším vypořádáme? Samozřejmě v tuto chvíli někdo začne křičet „A co agilní?!“ Dobře, všichni jste flexibilní, ale co s tím? Jak přesně projekt vypadá, jak ho pojmete tak, aby vyhovoval projektu? Nemůžete jen tak říct, že „náš přístup se vztahuje na cokoli, jsme Scrum tým!“ To je nesmysl a nesmysl. Kam se chystáte dál, proč by to mělo fungovat, kde je smysl? Učím své klienty přemýšlet o všech těchto otázkách.

19 let agile

Michael: V Agile se lidé často snaží nic nedefinovat dopředu, ale rozhodovat se co nejpozději s tím, že jsme příliš velcí, nebudu přemýšlet o celkové architektuře. Nebudu myslet na spoustu dalších věcí, místo toho zákazníkovi dodám něco, co funguje právě teď.

Tim: Myslím, že agilní metodiky počínaje Agilní manifest v roce 2001 otevřela tomuto odvětví oči. Ale na druhou stranu nic není dokonalé. Jsem pro iterativní vývoj. Iterace má ve většině projektů velký smysl. Ale otázka, na kterou musíte myslet, zní: jakmile je produkt venku a v provozu, jak dlouho vydrží? Je to produkt, který vydrží šest měsíců, než bude nahrazen něčím jiným? Nebo je to produkt, který bude fungovat mnoho a mnoho let? Samozřejmě nebudu jmenovat, ale... V New Yorku a jeho finanční komunitě jsou nejzákladnější systémy velmi staré. To je úžasné. Podíváte se na ně a pomyslíte si, kdybyste se mohli vrátit v čase, do roku 1994, a řeknete vývojářům: „Přišel jsem z budoucnosti, z roku 2019. Vyvíjejte tento systém tak dlouho, jak budete potřebovat. Udělejte to rozšiřitelné, myslete na architekturu. Vylepšovat se pak bude více než pětadvacet let. Pokud budete vývoj o něco déle odkládat, ve velkém schématu věcí si toho nikdo nevšimne!“ Když odhadujete věci z dlouhodobého hlediska, musíte zvážit, kolik to bude celkově stát. Někdy dobře navržená architektura za to opravdu stojí a někdy ne. Musíme se rozhlédnout a zeptat se sami sebe: jsme pro takové rozhodnutí ve správné situaci?

Takže představa typu „Jsme pro agilitu, zákazník nám sám řekne, co chce získat“ – to je super naivní. Zákazníci ani nevědí, co chtějí, a ještě víc nevědí, co by mohli dostat. Někteří lidé začnou uvádět historické příklady jako argumenty, už jsem to viděl. To ale technicky vyspělí lidé většinou neříkají. Říkají: "Je rok 2019, toto jsou příležitosti, které máme, a můžeme úplně změnit způsob, jakým se na tyto věci díváme!" Místo toho, abyste napodobovali stávající řešení, dělali je o něco hezčími a učesanějšími, někdy musíte vyjít ven a říct: „Pojďme úplně znovu objevit to, co se tady snažíme dělat!“

A nemyslím si, že většina zákazníků dokáže o problému takto přemýšlet. Vidí jen to, co už mají, to je vše. Načež přicházejí s požadavky jako „udělejme to trochu jednodušší“ nebo co obvykle říkají. Ale nejsme číšníci ani servírky, takže můžeme přijmout objednávku, ať to dopadne jakkoli hloupě, a pak ji upéct v kuchyni. Jsme jejich průvodci. Musíme jim otevřít oči a říct: hej, máme tady nové příležitosti! Uvědomujete si, že můžeme skutečně změnit způsob, jakým se tato část vašeho podnikání dělá? Jedním z problémů Agile je, že odstraňuje povědomí o tom, co je příležitost, co je problém, co vůbec musíme udělat, jaké dostupné technologie jsou pro tuto konkrétní situaci nejvhodnější.

Možná jsem tady přehnaně skeptický: v agilní komunitě se děje spousta úžasných věcí. Mám ale problém s tím, že lidé místo definování projektu začnou rozhazovat rukama. Tady bych se zeptal - co děláme, jak to uděláme? A nějak magicky se vždy ukáže, že klient by měl vědět lépe než kdokoli jiný. Klient ale nejlépe ví, až když si vybere z věcí již někým postavených. Pokud si chci koupit auto a znám velikost svého rodinného rozpočtu, pak rychle vyberu auto, které vyhovuje mému životnímu stylu. Tady vím všechno lépe než kdokoli jiný! Upozorňujeme ale, že auta už někdo vyrobil. Nemám ponětí, jak vymyslet nové auto, nejsem odborník. Když vytváříme zakázkové nebo speciální produkty, je třeba vzít v úvahu hlas zákazníka, ale už to není jediný hlas.

Oleg: Zmínil jste Agilní manifest. Potřebujeme jej nějak aktualizovat nebo revidovat s ohledem na moderní chápání problému?

Tim: Nedotkl bych se ho. Myslím, že je to skvělý historický dokument. Chci říct, je takový, jaký je. Je mu 19 let, je starý, ale ve své době udělal revoluci. Udělal dobře, že vyvolal reakci a lidé si o něm začali šeptat. V roce 2001 jste s největší pravděpodobností ještě nepracovali v oboru, ale tehdy všichni pracovali podle procesů. Software Engineering Institute, pět úrovní modelu úplnosti softwaru (CMMI). Nevím, jestli vám takové legendy hlubokého starověku něco říkají, ale pak to byl průlom. Zpočátku lidé věřili, že pokud budou procesy správně nastaveny, problémy se samy vypaří. A pak přijde Manifest a říká: "Ne, ne, ne - budeme založeni na lidech, ne na procesech." Jsme mistři vývoje softwaru. Chápeme, že ideální proces je fata morgána, to se nestane. V projektech je příliš mnoho idiosynkrazie, myšlenka jediného dokonalého procesu pro všechny projekty nedává žádný smysl. Problémy jsou příliš složité na to, abychom tvrdili, že na všechno existuje jen jedno řešení (ahoj, nirvána).

Netroufám si hledět do budoucnosti, ale řeknu, že lidé nyní začali více přemýšlet o projektech. Myslím, že Agile Manifesto je velmi dobrý v tom, že vyskočí a řekne: „Hej! Jste na lodi a vy sami řídíte tuto loď. Budete se muset rozhodnout – univerzální recept pro všechny situace nenavrhneme. Jste posádkou lodi, a pokud jste dostatečně dobří, můžete najít cestu k cíli. Před vámi byly jiné lodě a po vás budou další lodě, ale přesto je vaše cesta v jistém smyslu jedinečná.“ Něco takového! Je to způsob myšlení. Pro mě to není nic nového pod sluncem, lidé pluli dříve a budou plout znovu, ale pro vás je to vaše hlavní cesta a já vám neřeknu, co přesně se s vámi stane. Musíte mít dovednosti koordinované práce v týmu, a pokud je opravdu máte, všechno půjde a dostanete se tam, kam jste chtěli.

Peopleware: O 30 let později

Oleg: Byl Peopleware revolucí stejně jako Manifest?

Tim: Peopleware... Tom a já jsme napsali tuto knihu, ale nemysleli jsme si, že se to stane takhle. Nějak to rezonovalo s představami spousty lidí. Toto byla první kniha, která říkala: vývoj softwaru je činnost velmi náročná na člověka. Navzdory naší technické povaze jsme také komunita lidí, kteří budují něco velkého, dokonce obrovského, velmi složitého. Nikdo nemůže vytvořit takové věci sám, že? Takže myšlenka „týmu“ se stala velmi důležitou. A to nejen z pohledu managementu, ale i pro technické lidi, kteří se sešli, aby řešili opravdu složité hluboké problémy s hromadou neznámých. Pro mě osobně to byla obrovská zkouška inteligence během celé mé kariéry. A tady je potřeba umět říct: ano, tento problém je víc, než dokážu sám zvládnout, ale společně můžeme najít elegantní řešení, na které můžeme být hrdí. A myslím, že právě tato myšlenka rezonovala nejvíce. Myšlenka, že část času pracujeme sami, část času jako součást skupiny a často o tom rozhoduje skupina. Skupinové řešení problémů se rychle stalo důležitou součástí komplexních projektů.

Navzdory skutečnosti, že Tim přednesl obrovské množství přednášek, jen velmi málo z nich je zveřejněno na YouTube. Můžete se podívat na zprávu „The Return of Peopleware“ z roku 2007. Kvalita samozřejmě ponechává mnoho přání.

Michael: Změnilo se něco za posledních 30 let od vydání knihy?

Tim: Můžete se na to dívat z mnoha různých úhlů. Sociologicky vzato... kdysi, v jednodušších dobách, jste se svým týmem seděli v jedné kanceláři. Můžete si být každý den nablízku, popíjet spolu kávu a diskutovat o práci. Skutečně se změnilo to, že týmy lze nyní rozmístit geograficky, v různých zemích a časových pásmech, ale stále pracují na stejném problému, což přidává zcela novou vrstvu složitosti. Může to znít oldschoolově, ale není nic jako komunikace tváří v tvář, kdy jste všichni pohromadě, pracujete společně a můžete zajít za kolegou a říct, podívejte, co jsem objevil, jak se vám to líbí? Osobní rozhovory poskytují rychlý způsob přechodu k neformální komunikaci a myslím, že by se to mělo líbit i agilním nadšencům. A také mám obavy, protože ve skutečnosti se svět ukázal jako velmi malý a nyní je celý pokrytý distribuovanými týmy a je to všechno velmi složité.

Všichni žijeme v DevOps

Michael: I z pohledu programového výboru konference máme lidi v Kalifornii, v New Yorku, Evropě, Rusku... v Singapuru zatím nikdo není. Rozdíl v geografii je poměrně velký a lidé se začínají ještě více rozšiřovat. Pokud mluvíme o vývoji, můžete nám říci více o devops a bourání bariér mezi týmy? Existuje představa, že všichni sedí ve svých bunkrech a nyní se bunkry hroutí, co si myslíte o této analogii?

Tim: Zdá se mi, že ve světle nedávných technologických průlomů má devops velký význam. Dříve jste měli týmy vývojářů a administrátorů, pracovali, pracovali, pracovali a v určitém okamžiku se objevila věc, se kterou jste mohli přijít za administrátory a rozjet ji do výroby. A tady začala konverzace o bunkru, protože admini jsou tak trochu spojenci, alespoň ne nepřátelé, ale mluvili jste s nimi, až když bylo vše připraveno k výrobě. Šli jste za nimi s něčím a řekli: podívejte, jakou aplikaci máme, ale mohli byste tuto aplikaci uvést na trh? A nyní se celý koncept doručování změnil k lepšímu. Myslím tím, že tu byl nápad, že můžete rychle prosadit změny. Můžeme aktualizovat produkty za běhu. Vždy se usmívám, když se na mém notebooku objeví Firefox a říká: Ahoj, aktualizovali jsme váš Firefox na pozadí, a jakmile budete mít chvilku, nevadilo by vám kliknout sem a my vám dáme nejnovější verzi. A já si říkal: "Ach jo, zlato!" Zatímco jsem spal, pracovali na dodání nového vydání přímo na mém počítači. To je úžasné, neuvěřitelné.

Ale tady je potíž: máte tuto funkci s aktualizací softwaru, ale integrace lidí je mnohem obtížnější. Na klíčovém projevu DevOops chci říci, že nyní máme mnohem více hráčů, než jsme kdy měli. Když si vzpomenete na všechny zúčastněné v jednom týmu…. Mysleli jste to jako tým a je to mnohem víc než jen tým programátorů. Jsou to testeři, projektoví manažeři a spousta dalších lidí. A každý má svůj pohled na svět. Produktoví manažeři jsou úplně jiní než projektoví manažeři. Správci mají své vlastní úkoly. Stává se poměrně obtížným problémem zkoordinovat všechny účastníky tak, aby si i nadále uvědomovali, co se děje, a nezbláznili se. Je třeba oddělit úkoly skupiny a úkoly, které platí pro všechny. To je velmi obtížný úkol. Na druhou stranu si myslím, že je to všechno mnohem lepší než před mnoha lety. To je přesně ta cesta, na které lidé rostou a učí se chovat správně. Když děláte integraci, chápete, že by nemělo docházet k žádnému podzemnímu vývoji, takže software na poslední chvíli nevyleze jako jack-in-the-box: jako, podívejte se, co jsme tady udělali! Myšlenka je taková, že budete schopni provádět integraci a vývoj a na konci se rozjedete úhledným a iterativním způsobem. To všechno pro mě hodně znamená. To umožňuje vytvořit větší hodnotu pro uživatele systému a pro vašeho klienta.

Michael: Celá myšlenka devops je přinést smysluplný vývoj co nejdříve. Vidím, že svět se začal stále více zrychlovat. Jak se takovým zrychlením přizpůsobit? Před deseti lety tohle neexistovalo!

Tim: Každý chce samozřejmě stále více funkcí. Není třeba se hýbat, stačí naskládat další. Někdy dokonce musíte zpomalit, aby další přírůstková aktualizace přinesla něco užitečného – a to je zcela normální.

Představa, že musíte běžet, běžet, běžet, není nejlepší. Je nepravděpodobné, že by někdo chtěl takto žít. Chtěl bych, aby rytmus dodávek udával vlastní rytmus projektu. Pokud jen vytvoříte proud malých, relativně bezvýznamných věcí, všechno to nedává žádný smysl. Namísto bezmyšlenkovité snahy vydat věci co nejdříve, stojí za to prodiskutovat s hlavními vývojáři a produktovými a projektovými manažery strategie. Dává to vůbec smysl?

Vzory a antivzory

Oleg: Obvykle mluvíte o vzorcích a antivzorcích, a to je rozdíl mezi životem a smrtí projektů. A teď do našich životů vtrhne devops. Má nějaké vlastní vzory a anti-vzory, které mohou projekt zabít na místě?

Tim: Vzory a anti-vzory se vyskytují neustále. Něco k povídání. No, je tu věc, které říkáme "lesklé věci". Lidé mají opravdu rádi nové technologie. Jednoduše je hypnotizuje lesk všeho, co vypadá cool a stylové, a přestávají se ptát: je to vůbec nutné? Čeho dosáhneme? Je to spolehlivé, má to nějaký smysl? Často vidím lidi, abych tak řekl, že jsou na špici technologií. Jsou hypnotizováni tím, co se děje ve světě. Ale když se blíže podíváte na to, jaké užitečné věci dělají, často tam prostě nic užitečného není!

Právě jsme diskutovali se svými soudruhy, že letos je výročí, padesát let od přistání lidí na Měsíci. Bylo to v roce 1969. Technologie, která lidem pomohla se tam dostat, není ani technologie z roku 1969, ale spíše z roku 1960 nebo 62, protože NASA chtěla použít jen to, co mělo dobrý důkaz spolehlivosti. A tak se na to podíváte a pochopíte - ano, a byly pravdivé! Teď ne, ne, ale dostáváte se do problémů s technologií jednoduše proto, že se na všechno příliš tlačí, prodává se ze všech trhlin. Lidé odevšad křičí: "Hele, jaká věc, to je nejnovější, nejkrásnější věc na světě, vhodná úplně pro každého!" No, to je ono... většinou se z toho všeho vyklube jen návnada a pak se to musí všechno vyhodit. Možná je to všechno proto, že už jsem starý muž a dívám se na takové věci s velkou dávkou skepse, když lidé dojdou a říkají, že našli jediný, nejsprávnější způsob, jak vytvořit nejlepší technologie. V tu chvíli se ve mně probudí hlas, který říká: "Jaký nepořádek!"

Michael: Opravdu, jak často jsme slyšeli o další stříbrné kulce?

Tim: Přesně tak, a to je obvyklý běh věcí! Například... zdá se, že se to už stalo vtipem po celém světě, ale tady se často mluví o technologii blockchain. A v určitých situacích vlastně dávají smysl! Když opravdu potřebujete spolehlivé důkazy o událostech, že systém funguje a že nás nikdo nepodvedl, když máte bezpečnostní problémy a všechny ty věci smíchané dohromady – blockchain dává smysl. Ale když říkají, že Blockchain nyní zamete celý svět a smete vše, co mu stojí v cestě? Sni víc! Jedná se o velmi nákladnou a složitou technologii. Technicky složité a časově náročné. Včetně čistě algoritmicky, pokaždé, když potřebujete přepočítat matematiku, s nejmenšími změnami... a to je skvělý nápad - ale pouze pro určité případy. Celý můj život a kariéra byly o tom: zajímavé nápady ve velmi konkrétních situacích. Je velmi důležité přesně pochopit, jaká je vaše situace.

Michael: Ano, hlavní „otázka života, vesmíru a vůbec“: je tato technologie nebo přístup vhodný pro vaši situaci nebo ne?

Tim: Tato otázka již může být projednána s technologickou skupinou. Možná dokonce přivést nějakého poradce. Podívejte se na projekt a pochopte – uděláme nyní něco správného a užitečného, ​​lépe než dříve? Možná se bude hodit, možná ne. Ale hlavně, nedělejte takové rozhodnutí standardně jen proto, že někdo vyhrkl: „Blockchain zoufale potřebujeme! Právě jsem o něm četl v časopise v letadle!“ Vážně? Není to ani vtipné.

Mýtický „devops inženýr“

Oleg: Nyní všichni implementují devops. Někdo si přečte o devopsech na internetu a zítra se na náborovém webu objeví další volné místo. "devops inženýr". Zde bych vás rád upozornil: myslíte si, že tento termín „devops engineer“ má právo na život? Existuje názor, že devops je kultura, a něco zde nesedí.

Tim: Tak a tak. Nechte je tedy okamžitě vysvětlit tento pojem. Něco, aby to bylo jedinečné. Dokud neprokážou, že za takovým volným místem je nějaká jedinečná kombinace dovedností, nekoupím ho! Chci říct, no, máme pracovní název, „devops engineer“, zajímavý titul, ano, co dál? Pracovní názvy jsou obecně velmi zajímavá věc. Řekněme „vývojář“ – co to vůbec je? Různé organizace znamenají úplně jiné věci. V některých firmách kvalitní programátoři píší testy, které dávají větší smysl než testy psané speciálními profesionálními testery v jiných firmách. Tak co, jsou teď programátoři nebo testeři?

Ano, máme názvy pracovních pozic, ale pokud se budete ptát dostatečně dlouho, nakonec se ukáže, že všichni řešíme problémy. Jsme hledači řešení a někteří mají určité technické dovednosti a někteří jiné. Pokud žijete v prostředí, kam DevOps proniklo, zabýváte se integrací vývoje a administrace a tato činnost má nějaký docela důležitý účel. Ale když se vás zeptají, co přesně děláte a za co jste zodpovědní, ukáže se, že lidé všechny tyto věci dělají od nepaměti. „Jsem zodpovědný za architekturu“, „Jsem zodpovědný za databáze“ a tak dále, jak vidíte – to vše bylo před „devops“.

Když mi někdo řekne svou pracovní pozici, moc ho neposlouchám. Je lepší nechat ho, aby vám řekl, za co je vlastně zodpovědný, umožní nám to mnohem lépe porozumět problému. Můj oblíbený příklad je, když člověk tvrdí, že je „projektový manažer“. Co? To nic neznamená, pořád nevím, co děláš. Projektový manažer může být vývojář, vedoucí týmu čtyř lidí, píšící kód, vykonávající práci, který se stal vedoucím týmu, kterého sami lidé mezi sebou uznávají jako lídra. A také projektový manažer může být manažer, který řídí šest set lidí na projektu, řídí další manažery, je zodpovědný za sestavování harmonogramů a plánování rozpočtů, to je vše. To jsou dva naprosto odlišné světy! Ale jejich pracovní název zní stejně.

Otočme to trochu jinak. V čem jsi opravdu dobrý, máš hodně zkušeností, máš na to talent? Za co převezmete odpovědnost, protože si myslíte, že úkol zvládnete? A tady hned někdo začne zapírat: ne, ne, ne, vůbec nemám chuť se projektovými zdroji zabývat, není to moje věc, jsem technický frajer a rozumím použitelnosti a uživatelským rozhraním, ne Chcete-li vůbec řídit armády lidí, nechte mě jít do práce.

A mimochodem, jsem velkým zastáncem přístupu, ve kterém tento druh oddělení dovedností funguje dobře. Kde mohou technici rozvíjet svou kariéru, jak daleko chtějí. Stále však vidím organizace, kde si technici stěžují: budu muset jít do projektového řízení, protože to je v této společnosti jediný způsob. Někdy to vede k hrozným výsledkům. Nejlepší technici nejsou vůbec dobří manažeři a ti nejlepší manažeři neumí zacházet s technologiemi. Buďme k tomu upřímní.

Teď po tom vidím velkou poptávku. Pokud jste techie, vaše společnost vám může pomoci, ale bez ohledu na to, co potřebujete, opravdu potřebujete najít svou vlastní profesní dráhu, protože technologie se neustále mění a spolu s nimi musíte znovu objevit sami sebe! Za pouhých dvacet let se technologie mohou změnit nejméně pětkrát. Technologie je zvláštní věc...

"Odborníci na všechno"

Michael: Jak se lidé mohou vyrovnat s takovou rychlostí technologických změn? Roste jejich složitost, roste jejich počet, roste i celkové množství komunikace mezi lidmi a ukazuje se, že se nemůžete stát „odborníkem na všechno“.

Tim: Že jo! Pokud pracujete v technice, tak ano, určitě je potřeba si vybrat něco konkrétního a ponořit se do toho. Některé technologie, které vaše organizace považuje za užitečné (a možná budou skutečně užitečné). A pokud vás to už nezajímá - nikdy bych nevěřil, že to řeknu - no, možná byste se měli přesunout do jiné organizace, kde je technologie zajímavější nebo pohodlnější ke studiu.

Ale obecně ano, máte pravdu. Technologie rostou ve všech směrech najednou, nikdo nemůže říct: „Jsem expert technolog ve všech technologiích, které existují. Na druhé straně jsou houbaři, kteří technologické znalosti doslova nasávají a jsou do nich blázni. Pár takových lidí jsem viděl, doslova dýchají a žijí tím, je užitečné a zajímavé s nimi mluvit. Studují nejen to, co se děje uvnitř organizace, ale obecně, mluví o tom, jsou také opravdu cool technologové, jsou velmi uvědomělí a cílevědomí. Prostě se snaží zůstat na hřebeni vlny, bez ohledu na to, co je jejich hlavním zaměstnáním, protože jejich vášní je pohyb technologií, propagace technologií. Pokud najednou takového člověka potkáte, měli byste s ním zajít na oběd a probrat různé cool věci u oběda. Myslím, že každá organizace potřebuje alespoň pár takových lidí.

Rizika a nejistota

Michael: Vážení inženýři, ano. Pojďme se dotknout řízení rizik, dokud máme čas. Tento rozhovor jsme zahájili diskusí o lékařském softwaru, kde chyby mohou vést k hrozným následkům. Pak jsme mluvili o lunárním programu, kde náklady na chybu jsou miliony dolarů a možná i několik lidských životů. Teď ale v oboru vidím opačný pohyb, lidé o rizicích nepřemýšlejí, nesnaží se je předvídat, ani je nepozorují.

Oleg: Pohybujte se rychle a rozbijte věci!

Michael: Ano, pohybujte se rychle, lámejte věci, další a další věci, dokud na něco nezemřete. Jak by měl nyní z vašeho pohledu přistupovat průměrný vývojář k učení řízení rizik?

Tim: Udělejme zde hranici mezi dvěma věcmi: riziky a nejistotou. To jsou různé věci. Nejistota nastává, když nemáte v daném okamžiku dostatek dat k tomu, abyste dospěli ke konečné odpovědi. Například, když se vás někdo ve velmi rané fázi projektu zeptá „kdy dokončíte práci“, pokud jste docela čestný člověk, řeknete: „Nemám tušení“. Prostě to nevíš a to je v pořádku. Ještě jste nestudovali problémy a neznáte tým, neznáte jeho dovednosti a tak dále. To je nejistota.

Rizika vznikají, když již lze identifikovat potenciální problémy. Taková věc se může stát, její pravděpodobnost je větší než nula, ale menší než sto procent, někde mezi. Kvůli ní se může stát cokoli, od zpoždění a zbytečné práce, ale dokonce až po fatální výsledek pro projekt. Výsledek, když řeknete - chlapi, složíme deštníky a odejdeme z pláže, nikdy to nedokončíme, je po všem, tečka. Předpokládali jsme, že tato věc bude fungovat, ale vůbec to nefunguje, je čas přestat. To jsou situace.

Problémy se často nejsnáze řeší, když se již objevily, když se problém odehrává právě teď. Ale když je problém přímo před vámi, neděláte řízení rizik, ale řešení problémů, krizový management. Pokud jste hlavní vývojář nebo manažer, jistě vás zajímá, co by se mohlo stát, že by to vedlo ke zpoždění, ztrátě času, zbytečným nákladům nebo zhroucení celého projektu? Co nás přiměje zastavit se a začít znovu? Když všechny tyto věci fungují, co s nimi budeme dělat? Existuje jednoduchá odpověď, která platí pro většinu situací: neutíkej před riziky, pracuj na nich. Podívejte se, jak můžete vyřešit rizikovou situaci, zredukovat ji na nic, změnit ji z problému v něco jiného. Místo toho, abychom řekli: dobře, problémy vyřešíme, jakmile nastanou.

Nejistota a riziko by měly být v popředí všeho, co řešíte. Můžete si vzít plán projektu, předem se podívat na určitá kritická rizika a říct: musíme se s tím vypořádat hned, protože pokud se něco z toho pokazí, na ničem jiném nebude záležet. Neměli byste se starat o krásu ubrusu na stole, pokud není jasné, zda můžete uvařit večeři. Nejprve je potřeba identifikovat všechna rizika přípravy lahodné večeře, vypořádat se s nimi a teprve poté myslet na všechny ostatní věci, které reálnou hrozbu nepředstavují.

Znovu, v čem je váš projekt jedinečný? Pojďme se podívat, co může náš projekt rozjet. Co můžeme udělat, abychom minimalizovali pravděpodobnost, že se to stane? Obvykle je nemůžete jen tak 100% neutralizovat a s čistým svědomím prohlásit: „To je ono, už to není problém, riziko je vyřešeno! Pro mě je to známka chování dospělých. To je rozdíl mezi dítětem a dospělým – děti si myslí, že jsou nesmrtelné, že se nic nemůže pokazit, všechno bude dobré! Dospělí přitom sledují, jak tříleté děti skáčou na hřišti, sledují pohyby očima a říkají si: „ooh-ooh, ooh-ooh“. Stojím poblíž a připravuji se zachytit, když dítě spadne.

Na druhou stranu, důvod, proč mám tento obchod tak rád, je ten, že je riskantní. Děláme věci a ty věci jsou riskantní. Vyžadují dospělý přístup. Samotné nadšení vaše problémy nevyřeší!

Dospělé inženýrské myšlení

Michael: Příklad s dětmi je dobrý. Pokud jsem obyčejný inženýr, pak jsem rád, že jsem dítě. Jak ale přejít k dospělejšímu myšlení?

Tim: Jedním z nápadů, který funguje stejně dobře jak u začátečníka, tak u zavedeného vývojáře, je koncept kontextu. Co děláme, čeho chceme dosáhnout. Co je na tomto projektu skutečně důležité? Nezáleží na tom, kdo jste na tomto projektu, zda jste stážista nebo hlavní architekt, každý potřebuje kontext. Potřebujeme přimět každého, aby přemýšlel ve větším měřítku, než je jeho vlastní práce. "Vyrábím svůj díl a dokud můj díl funguje, jsem šťastný." Ne a zase ne. Vždy stojí za to (aniž bych byl hrubý!) lidem připomínat kontext, ve kterém pracují. Čeho se všichni společně snažíme dosáhnout. Představy, že můžete být dítětem, pokud je s vaším dílem projektu vše v pořádku – prosím, nedělejte to. Pokud vůbec protneme cílovou čáru, projedeme ji pouze společně. Nejste sami, jsme všichni spolu. Kdyby všichni lidé v projektu, staří i mladí, začali mluvit o tom, co přesně je pro projekt důležité, proč společnost investuje peníze do toho, čeho se všichni snažíme dosáhnout... většina z nich se bude cítit mnohem lépe, protože uvidí, jak jejich práce koreluje s prací všech ostatních. Na jednu stranu rozumím dílu, za který osobně zodpovídám. Ale k dokončení práce potřebujeme i všechny ostatní lidi. A pokud si opravdu myslíte, že jste skončili, máme na projektu vždy co dělat!

Oleg: Relativně řečeno, pokud pracujete podle Kanbanu, když narazíte na úzké hrdlo nějakého testování, můžete skončit s tím, co jste tam dělali (například programování) a jít pomáhat testerům.

Tim: Přesně tak. Myslím, že nejlepší technici, když se na ně podíváte pozorně, jsou tak trochu svými vlastními manažery. Jak to mohu formulovat...

Oleg: Váš život je váš projekt, který řídíte.

Tim: Přesně tak! Myslím tím, že přebíráte zodpovědnost, rozumíte problému a přicházíte do kontaktu s lidmi, když vidíte, že vaše rozhodnutí mohou ovlivnit jejich práci a podobně. Není to o tom jen sedět za stolem, dělat svou práci a vůbec si neuvědomovat, co se kolem vás děje. Ne ne ne. Mimochodem, jedna z nejlepších věcí na Agile je, že navrhli krátké sprinty, protože takto je stav věcí všech účastníků jasně pozorovatelný, vidí to všechno dohromady. Mluvíme o sobě každý den.

Jak se dostat do řízení rizik

Oleg: Existuje v této oblasti nějaká formální znalostní struktura? Například jsem vývojář Java a chci porozumět řízení rizik, aniž bych se stal skutečným projektovým manažerem díky vzdělání. Nejspíš si nejdřív přečtu McConnellův „How Much Does a Software Project Cost“ a pak co? Jaké jsou první kroky?

Tim: První je začít komunikovat s lidmi v projektu. To poskytuje okamžité zlepšení kultury komunikace s kolegy. Musíme začít tím, že vše otevřeme ve výchozím nastavení, místo abychom to skryli. Řekni: to jsou věci, které mě trápí, to jsou věci, které mě drží v noci vzhůru, dnes jsem se v noci probudil a řekl si: můj bože, na tohle musím myslet! Vidí ostatní totéž? Měli bychom jako skupina reagovat na tyto potenciální problémy? Musíte být schopni podpořit diskusi na tato témata. Neexistuje žádný předem připravený vzorec, podle kterého pracujeme. Není to o výrobě hamburgerů, ale o lidech. „Vyrobit cheeseburger, prodat cheeseburger“ vůbec není naše věc, a proto tuto práci tak miluji. Líbí se mi, když vše, co manažeři dělali, se nyní stává majetkem týmu.

Oleg: Mluvil jste v knihách a rozhovorech o tom, jak lidem záleží více na štěstí než na číslech v grafu. Na druhou stranu, když týmu řeknete: přesouváme se do devops a nyní musí programátor neustále komunikovat, může to být daleko mimo jeho komfortní zónu. A v tuto chvíli může být, řekněme, hluboce nešťastný. Co dělat v této situaci?

Tim: Nevím přesně, co mám dělat. Pokud je vývojář příliš izolovaný, nevidí důvod, proč se práce dělá, jen se podívá na svou část práce a potřebuje se dostat do toho, čemu říkám „kontext“. Musí přijít na to, jak spolu všechno souvisí. A samozřejmě nemám na mysli formální prezentace nebo něco podobného. Mluvím o tom, že s kolegy potřebujete komunikovat o práci jako celku, a ne jen o její části, za kterou zodpovídáte. Zde můžete začít diskutovat o nápadech, společných dohodách, aby do sebe vaše práce dobře zapadala, a jak společně řešit společný problém.

Aby jim pomohli přizpůsobit se, často chtějí poslat techniky na školení a diskutují o školení. Můj přítel rád říká, že výcvik je pro psy. Existuje školení pro lidi. Jedna z nejlepších věcí na učení jako vývojář je interakce se svými vrstevníky. Pokud je někdo v něčem opravdu dobrý, měli byste ho sledovat při práci nebo si s ním o jeho práci promluvit nebo tak něco. Nějaký konvenční Kent Beck neustále mluvil o extrémním programování. Je to legrační, protože XP je tak jednoduchý nápad, ale způsobuje tolik problémů. Pro některé je dělání XP jako nucení se svléknout před přáteli. Uvidí, co dělám! Jsou to mí kolegové, nejen uvidí, ale i pochopí! Hrozný! Někteří lidé začínají být vážně nervózní. Ale když si uvědomíte, že toto je nejlepší způsob, jak se učit, všechno se změní. Úzce spolupracujete s lidmi a někteří tomu tématu rozumí mnohem lépe než vy.

Michael: To vše vás ale nutí vystoupit ze své komfortní zóny. Jako inženýr musíte vystoupit ze své komfortní zóny a komunikovat. Jako řešitel problémů se musíte neustále dostávat do slabé pozice a přemýšlet o tom, co by se mohlo pokazit. Tento typ práce je ze své podstaty navržen tak, aby obtěžoval. Vědomě se dostáváte do stresových situací. Většinou před nimi lidé utíkají, lidé jsou rádi šťastnými dětmi.

Tim: Co se dá dělat, můžete vystoupit a otevřeně říct: „Všechno je v pořádku, zvládnu to! Nejsem jediný, kdo se cítí nepříjemně. Proberme různé nepříjemné věci, všichni společně, jako tým!“ To jsou naše společné problémy, musíme se s nimi vypořádat, víš? Myslím, že idiosynkratičtí geniální vývojáři jsou jako mamuti, zmizeli. A jejich význam je velmi omezený. Pokud neumíte komunikovat, nemůžete se dobře zapojit. Proto jen mluvte. Buďte upřímní a otevření. Je mi moc líto, že je to někomu nepříjemné. Dokážete si představit, před mnoha lety existovala studie, podle které není hlavním strachem ve Spojených státech smrt, ale hádejte co? Strach z veřejného vystupování! To znamená, že někde jsou lidé, kteří raději zemřou, než aby vyslovili nahlas kompliment. A myslím, že stačí, když máte nějaké základní dovednosti v závislosti na tom, co děláte. Mluvit, psát – ale jen tolik, kolik je ve vaší práci skutečně potřeba. Pokud pracujete jako analytik, ale neumíte číst, psát ani mluvit, tak bohužel nebudete mít v mých projektech co dělat!

Cena komunikace

Oleg: Není zaměstnávání takto odcházejících zaměstnanců z různých důvodů dražší? Koneckonců, místo práce neustále chatují!

Tim: Měl jsem na mysli jádro týmu, a ne jen každého. Pokud máte někoho, kdo je opravdu skvělý v ladění databází, miluje ladění databází a bude pokračovat v ladění vašich databází po zbytek svého života a je to, v pohodě, pokračujte. Ale mluvím o lidech, kteří chtějí žít v samotném projektu. Jádro týmu zaměřené na rozvoj projektu. Tito lidé spolu opravdu potřebují neustále komunikovat. A to především na začátku projektu, kdy probíráte rizika, způsoby, jak dosáhnout globálních cílů a podobně.

Michael: To platí pro všechny účastníky projektu bez ohledu na specializaci, dovednosti nebo způsob práce. Všechny vás zajímá úspěch projektu.

Tim: Ano, cítíte, že jste dostatečně ponořeni do projektu, že vaším úkolem je pomoci projektu uskutečnit. Ať už jste programátor, analytik, návrhář rozhraní, kdokoli. To je důvod, proč každé ráno chodím do práce a to je to, co děláme. Jsme odpovědní za všechny tyto lidi bez ohledu na jejich dovednosti. Toto je skupina lidí, kteří konverzují pro dospělé.

Oleg: Ve skutečnosti, když mluvíme o hovorných zaměstnancích, snažil jsem se simulovat námitky lidí, zejména manažerů, kteří jsou požádáni, aby přešli na devops, vůči této zcela nové vizi světa. A vy jako konzultanti byste si měli být těchto námitek vědomi mnohem lépe než já jako vývojář! Podělte se o to, co manažery nejvíce trápí?

Tim: Manažeři? Hm. Nejčastěji jsou manažeři pod tlakem problémů, potýkají se s potřebou urychleně něco uvolnit a provést dodávku a podobně. Sledují, jak neustále o něčem diskutujeme a dohadujeme se, a vidí to takto: rozhovory, rozhovory, rozhovory... Jaké další rozhovory? Vraťte se do práce! Protože mluvit jim nepřijde jako práce. Nepíšete kód, netestujete software, zdá se, že nic neděláte – proč vás neposlat, abyste něco udělali? Vždyť dodání je už za měsíc!

Michael: Jdi napsat nějaký kód!

Tim: Zdá se mi, že se nebojí o práci, ale o nedostatek viditelnosti pokroku. Aby to vypadalo, že se blížíme k úspěchu, musí nás vidět, jak mačkáme tlačítka na klávesnici. Celý den od rána do večera. To je problém číslo jedna.

Oleg: Míšo, o něčem přemýšlíš.

Michael: Promiň, ztratil jsem se v myšlenkách a zachytil se mi flashback. To vše mi připomnělo zajímavou rally, která se stala včera... Včera bylo příliš mnoho rally... A všechno to zní velmi povědomě!

Život bez platů

Tim: Mimochodem, pro komunikaci není vůbec nutné organizovat „rallye“. Chci říct, že nejužitečnější diskuse mezi vývojáři probíhají, když spolu jen mluví. Vejdete ráno s šálkem kávy a je tam pět lidí a zuřivě diskutují o něčem technickém. Pro mě, když jsem manažerem tohoto projektu, je lepší se jen usmát a jít někam za svým podnikáním, ať to proberou. Už jsou zapojeni v maximální možné míře. To je dobré znamení.

Oleg: Mimochodem, ve své knize máte hromadu poznámek o tom, co je dobré a co špatné. Vy sám některé z nich používáte? Relativně řečeno, nyní máte společnost a společnost, která je strukturována velmi neortodoxním způsobem...

Tim: Neortodoxní, ale toto zařízení nám naprosto vyhovuje. Známe se už dlouho. Věříme si, hodně jsme si věřili, než jsme se stali partnery. A například nemáme vůbec žádné platy. Prostě pracujeme, a třeba když jsem vydělával peníze od svých klientů, tak všechny peníze šly na mě. Poté organizaci platíme členské příspěvky a to stačí na podporu samotné společnosti. Navíc se každý specializujeme na něco jiného. Pracuji například s účetními, vyplním daňová přiznání, dělám pro firmu nejrůznější administrativní věci a nikdo mi za to neplatí. James a Tom pracují na našem webu a také jim nikdo neplatí. Dokud budete platit své poplatky, nikoho nenapadne říkat vám, co musíte udělat. Například Tom nyní pracuje mnohem méně než kdysi. Nyní má jiné zájmy, některé věci nedělá pro Gildu. Ale dokud bude platit své poplatky, nikdo za ním nepřijde a neřekne: "Hej, Tome, jdi do práce!" Je velmi snadné jednat s kolegy, když mezi vámi nejsou peníze. A nyní je náš vztah jednou ze základních myšlenek ve vztahu k různým specialitám. Funguje to a funguje to velmi dobře.

Nejlepší rada

Michael: Když se vrátíme k „nejlepší radě“, říkáte něco svým klientům znovu a znovu? Existuje představa o 80/20 a některé rady se pravděpodobně opakují častěji.

Tim: Kdysi jsem si myslel, že kdybyste napsal knihu jako Valčík s medvědy, změnilo by to běh dějin a lidé by se zastavili, ale... No, podívejte, firmy se často tváří, že je u nich všechno v pořádku. Jakmile se stane něco špatného, ​​je to pro ně šok a překvapení. „Podívejte, testovali jsme systém a neprošel žádnými testy systému, a to jsou další tři měsíce neplánované práce, jak se to mohlo stát? Kdo ví? Co by se mohlo pokazit? Vážně, věříš tomu?

Snažím se vysvětlit, že byste se kvůli současné situaci neměli příliš zlobit. Musíme si o tom promluvit, skutečně pochopit, co se mohlo pokazit, a jak zabránit tomu, aby se takové věci v budoucnu stávaly. Pokud se problém objeví, jak s ním budeme bojovat, jak jej potlačíme?

Pro mě to všechno vypadá děsivě. Lidé se potýkají se složitými, nepříjemnými problémy a nadále předstírají, že když budou jen držet palce a doufat v to nejlepší, to „nejlepší“ se skutečně stane. Ne, takhle to nefunguje.

Procvičte si řízení rizik!

Michael: Kolik organizací se podle vašeho názoru zabývá řízením rizik?

Tim: Co mě pobuřuje, je, že si lidé prostě sepíší rizika, podívají se na výsledný seznam a jdou do práce. Ve skutečnosti je pro ně identifikace rizik řízením rizik. Ale zní mi to jako důvod se zeptat: dobře, existuje seznam, co přesně změníte? Musíte změnit své standardní sekvence akcí s ohledem na tato rizika. Pokud je nějaká nejobtížnější část práce, musíte se s ní poprat a teprve potom přejít k něčemu jednoduššímu. V prvních sprintech začněte řešit složité problémy. To už vypadá jako řízení rizik. Lidé však obvykle nemohou říci, co změnili po sestavení seznamu rizik.

Michael: A přesto, kolik z těchto společností se podílí na řízení rizik, pět procent?

Tim: Bohužel to říkám nerad, ale je to velmi nepodstatná část. Ale víc než pět, protože jsou opravdu velké projekty a ty prostě nemohou existovat, pokud neudělají alespoň něco. Řekněme, že budu velmi překvapen, pokud to bude alespoň 25 %. Malé projekty obvykle na takové otázky odpovídají takto: pokud se nás problém dotkne, pak ho vyřešíme. Poté se úspěšně dostanou do problémů a zapojí se do řešení problémů a krizového řízení. Když se snažíte vyřešit problém a problém není vyřešen, vítejte v krizovém managementu.

Ano, často slyším: „Problémy vyřešíme, jakmile nastanou“. Určitě budeme? Opravdu se rozhodneme?

Oleg: Můžete to udělat naivně a jednoduše zapsat důležité invarianty do charty projektu, a pokud se invarianty rozbijí, stačí restartovat projekt. Ukazuje se to velmi pimbucké.

Michael: Ano, stalo se mi, že při spuštění rizik se projekt jednoduše předefinoval. Pěkné, bingo, problém vyřešen, už se neboj!

Tim: Zmáčkneme resetovací tlačítko! Ne, takhle to nefunguje.

Keynote na DevOops 2019

Michael: Dostáváme se k poslední otázce tohoto rozhovoru. Přicházíte na další DevoOops s klíčovým slovem, mohl byste zvednout oponu tajemství o tom, co budete vyprávět?

Tim: Právě teď šest z nich píše knihu o kultuře práce, nevyřčených pravidlech organizací. Kultura je určena základními hodnotami organizace. Lidé si toho většinou nevšimnou, ale jelikož jsme dlouhá léta pracovali v poradenství, jsme zvyklí si toho všimnout. Vstoupíte do společnosti a doslova během pár minut začnete cítit, co se děje. Říkáme tomu "příchuť". Někdy je tato vůně opravdu dobrá a někdy je to, no, ups. Věci se u různých organizací velmi liší.

Michael: I já pracuji léta v poradenství a rozumím dobře, o čem mluvíte.

Tim: Ve skutečnosti jedna z věcí, o kterých stojí za to mluvit na keynote, je, že ne vše určuje společnost. Vy a váš tým jako komunita máte svou vlastní týmovou kulturu. Může to být celá společnost, nebo samostatné oddělení, samostatný tým. Ale než jsi řekl, tady je to, čemu věříme, tady je to, co je důležité... Nemůžete změnit kulturu, dokud nepochopíte hodnoty a přesvědčení, která stojí za konkrétními činy. Chování je snadné pozorovat, ale hledání přesvědčení je obtížné. DevOps je jen skvělým příkladem toho, jak se věci stávají stále složitějšími. Interakce jsou jen čím dál složitější, vůbec se nestávají čistšími ani jasnějšími, takže byste se měli zamyslet nad tím, čemu věříte a o čem všichni kolem vás mlčí.

Pokud chcete dosáhnout rychlých výsledků, je tu pro vás dobré téma: viděli jste společnosti, kde nikdo neříká „nevím“? Jsou místa, kde člověka doslova mučíte, dokud nepřizná, že něco neví. Každý všechno ví, každý je neskutečně erudovaný. Oslovíte jakoukoli osobu a on musí okamžitě odpovědět na otázku. Místo toho, abych řekl: „Nevím“. Hurá, najali partu erudovaných! A v některých kulturách je obecně velmi nebezpečné říkat „nevím“, lze to vnímat jako projev slabosti. Existují i ​​organizace, ve kterých naopak může každý říct „nevím“. Tam je to zcela legální, a když někdo na otázku začne blbnout, je úplně normální odpovědět: "Nevíš, o čem mluvíš, že?" a udělat z toho srandu.

V ideálním případě byste chtěli mít práci, kde byste mohli být neustále šťastní. Nebude to jednoduché, ne každý den je slunečno a příjemně, někdy je potřeba tvrdě pracovat, ale když začnete bilancovat, ukáže se: wow, to je opravdu úžasné místo, cítím se tu dobře pracovat, jak emocionálně, tak intelektuálně. A jsou společnosti, kam jdete jako konzultant a okamžitě si uvědomíte, že jste to tři měsíce nevydrželi a hrůzou byste utekli. To je to, o čem chci ve zprávě mluvit.

Tim Lister dorazí s keynote „Postavy, komunita a kultura: důležité faktory prosperity“na konferenci DevOops 2019, která se bude konat 29. – 30. října 2019 v Petrohradě. Vstupenky si můžete zakoupit na oficiálních stránkách. Čekáme na vás v Devoops!

Zdroj: www.habr.com