Vytíženost

Chtěl bych se vrátit ke knize Slack, o které jsem tu už psal. Tenkrát jsem si vybral kapitolu, která se mě tehdy docela dotýkala. Bohužel z ní nebylo vidět, o čem ta kniha je. A to je škoda, protože Slack je jedna z nejlepších knih, kterou jsem o managementu četl (ono jich zas tolik nebylo).

Název Slack by se dal podle slovníku přeložit jako časová rezerva, nevyužitý nebo dokonce flákat se. O tom všem to je – o potřebě určité volnosti. Jako příklad uvedu citaci

Vezměte si například sekretářku (Pamatujete si ještě sekretářky? Kdysi obvyklý prvek firemního života.) Práce sekretářky […] usnadňuje hladký průběh pracovního života manažera. Říkejme ji Silva.

Dobrá sekretářka je poklad […] Když je v práci Silva, všechno jde snadno. […] Teď si představte, že nastoupí konzultant s cílem snížit náklady. „Cože, co to je? Sekretářka? A co zrovna teď dělá?“ Sedne si se stopkami vedle jejího stolu. Nikoho nepřekvapí, že přijde na to, že Silva je zaměstnána jen 43% času. Ve zbytku doby se … je k dispozici. Je k dispozici dělat práci kterou zrovna teď potřebujete. To je to co je na Silvě tak skvělé. Když je něco potřeba, je okamžitě k dispozici.

Triumfální výraz se usadí na konzultantově tváři. Pokud je Silva zaměstnána jen 43% času, můžeme ušetřit 57% procent jejího času. Můžeme ji hodit do „poolu“ a alokovat 43% pro vás a 57% pro ostatní. […] Nebo se jí úplně zbavit a najmout brigádníka jen na těch 43%. […] Jaká úžasná efektivnost. Místo člověka který 57% času zahálel, máme někoho kdo pracuje 100% času. Povídejte mi o výkonnosti!

Problém je samozřejmě v tom, že teď plně využitá sekretářka jednoduše nereaguje tak rychle jako Silva. Tato nově výkonná osoba prostě nereaguje tak rychle na věci, které je potřeba udělat, protože má moc práce.

Platí něco podobného o programátorech? Když přijdete na to, že potřebujete 73% programátora, můžete hodit ten zbytek do „poolu“ k dispozici jiným manažerům? Když potřebujete 100% senior programátora, můžete počítat s tím, že ho budete mít na 100%? Co když bude potřebovat poradit nováčkovi, co když bude potřeba řešit něco na projektu na kterém už dávno oficiálně není? Co když bude potřeba pomoci s nabídkou pro nového zákazníka?

Představte si firmu, kde může manažer říci, „Já potřebuju Tondu jen na 50%, zbytek dávám k dispozici, ať si ho veme kdo chce“. Může to fungovat?

Podle mě ne. Za prvé, ten manažer ho nechce jen na 50%, on ho chce jen na 50% platit. Nevěřím, že pro něj bude práce přesně na 4 hodiny denně. Spíš bych tipoval, že víc.

Navíc mám pro vás jednu novinku, programátoři se nedají krájet. Když si z programátora ukrojím půlku, dostanu dvě půlky mrtvoly. Když to udělám jen obrazně, dopadne to jen o trochu lépe. Takže opakuji: 1 programátor – 0,5 programátora << 0,5 programátora. Platí rovnice, kterou se opět můžeme dočíst v knize (od které jsem se na moment trochu odchýlil, za což se všem postiženým omlouvám) Trest za přepínání úloh = čas potřebný pro přesun na novou úlohu + oprava chyb způsobených nevhodným přerušením v práci + čas pro opětovné se ponoření do úkolu + frustrace + ztráta vazby na tým

Takže jak to dopadne v naší hypotetické firmě, která umožňuje prodat dvě půlky programátora? Napadají mě dvě možnosti. Buď budeme potkávat na chodbách usínající programátory, kteří pracují na 150% procent. Nebo se prostě a jednoduše budou falšovat výkazy, tak aby to vypadalo, že máme dvě nezávislé půlky programátora.

Selects are IN

Today it will be short. I will write about one small Spring feature that I have discovered recently. It is another nice functionality of SimpleJdbcTemplate.

Imagine that you want to find all account with given account numbers. Since we want to gain maximal performance we want to do it in one SQL statement.

SELECT ACCOUNT_NUMBER, BALANCE FROM ACCOUNT WHERE ACCOUNT_NUMBER IN (?, ?)

Using Spring it is easy. The only trouble is, that I do not know number of account numbers beforehand. Therefore I do not know the number of question marks needed in the SQL query. Of course I can create the statement dynamically using string manipulation, but the code would be messy. Fortunately Spring comes to rescue. If I use named parameters in SimpleJdbcTemplate, Spring will automatically do everything for me. So the code will be nice and simple as it should be

	public List<Account> findAccounts(Set<String> accountNumbers)
	{
		return getSimpleJdbcTemplate().query(
				"SELECT ACCOUNT_NUMBER, BALANCE FROM ACCOUNT WHERE ACCOUNT_NUMBER IN (:accountNumbers)",
				ACCOUNT_ROW_MAPPER,
				Collections.singletonMap("accountNumbers", accountNumbers)
		);
	}

Nice, isn’t it? Source code can be found in SVN. More details are in the Spring documentation.

Pochod smrti

Dobrá zpráva je, že jsme vyhráli kontrakt. Špatná je, že jsme museli zkrátit rozpočet na polovinu, abychom porazili konkurenci.

Dostala se mi do rukou další zajímavá kniha. Je od pana Edwarda Yourdona a jmenuje se poeticky: Pochod Smrti (Death March). Ne nebojte, není to kniha o válečných hrůzách, je to horší. Jde o knihu pojednávající o hrůzách softwarových.

Pochod smrti je jednoduše takový projekt, jehož jeden parametr překračuje normu nejméně o polovinu. Tzn. plán byl zkrácen nejméně o polovinu, projektový tým byl zmenšen na polovinu, rozpočet byl snížen na padesát procent nebo rozsah funkcionalit a vlastností je dvojnásobný, než by byl za normálních okolností.

Ptáte se, jestli je nutné psát o takových výjimečných projektech knihu? Podle autora ano. Hned v úvodu se dozvíme, že

Projekty typu pochod smrti jsou normou, ne výjimkou.

Nechám na posouzení čtenářů jestli tomu tak opravdu je. Já nemohu soudit, protože jsem znám svým bezbřehým negativismem. V knize můžete narazit na zajímavé kapitoly o tom, proč k pochodům smrti dochází, proč se jich vůbec někdo účastní. Hodně zajímavé části jsou o politice softwarových projektů a o vyjednávání. Druhá polovina knihy mi v porovnání s první přišla méně zajímavá, je o procesech, jejich dynamice, plánování atp.

Obvykle přidávám do svých mini recenzí i výňatek, dnes tomu nebude jinak. Jde o výběr oblíbených vyjednávací her:

  • Zdvojnásob a kousek přidej – Toto je trik používaný na projektech už od dob pyramid, jestli ne dříve. Použijte jakoukoliv dostupnou techniku pro odhadování, potom „racionální“ odhad zdvojnásobte a přidejte kousek navrch.
  • Převrácené zdvojnásobování – Management si všiml předchozí techniky techniky a automatický snižuje všechny odhady na polovinu. Chudáci jsou pak ti projekťáci, kteří netušili, že se od nich očekávají zdvojnásobené odhady.
  • Uhodni číslo na které myslím – (moje oblíbená) Uživatel nebo manažer má „přijatelnou“ hodnotu pro rozpočet, plán a podobně, ale odmítá ji říci. Když je mu předložen odhad, řekne ne, což znamená „to je moc, hádej znovu“. Takto to pokračuje, dokud hádající netrefí správnou hodnotu. A protože to je odhad hádajícího, je za něj samozřejmě také zodpovědný.
  • Španělská inkvizice – Projektový manager přijde do místnosti plné hlavounů a naprosto netuší, že bude požádán o „prvotní odhad“. V tom se ho CEO zeptá: „Tak kdy čekáte, že bude systém hotov? Řekl jsem celému managementu, že bude online 13. března, nenecháte mě ve štychu, že ne?“ Pokud budete tak odvážní, že naznačíte, že 13. listopadu následujícího roku je víc realistický odhad, budete čelit výslechu několika inkvizitorů, zpochybňující váš intelekt, loajalitu a možná dokonce i vaši víru.
  • Nízká nabídka – Zákazník řekne, že dostal od konkurence mnohem výhodnější nabídku. To nás nutí k tomu tuto nabídku dorovnat a často ještě trumfnout. Tato strategie přímo vede k následujícím hrám.
  • Gotcha – (Mám tě, Naletěl) Tato hra je hrána jako pomsta projektového managera. I přesto že ví, že je projekt nerealistický, stejně ho přijme. Doufá v to, že až nastane čas čelit realitě (týden před termínem), bude už pro klienta pozdě z projektu vycouvat.
  • Čínské vodní mučení – Spíše než čelit riziku zrušení projektu, je lepší dávkovat špatné zprávy po malých kouscích. Projektový manager řekne, že se jedna část o malinko zpozdila, další taky o trošku. Kapku po kapce dávkuje špatné zprávy. Ani jedna kapka vás nezabije, kumulativní efekt ale může být smrtelný.
  • Skryté proměnné udržovatelnost a kvalita – Je to jednoduché. Dokáži dodat zákazníkovi nekonečné množství software v nulovém čase, pokud nemusí fungovat a být udržovatelný.

To je vše z vyjednávacích her. Jako obvykle jsem to trochu zkrátil a upravil, takže zájemci ať si to laskavě přečtou v originále.

Abych to shrnul, kniha je to celkem zajímavá, doporučoval bych ji hlavně projektovým managerům, kteří si myslí, že pochody smrti nastávají. I když Tanec s medvědy a Slack se mi líbily více. Programátorům a optimistům bych doporučil knihu, kterou čtu nyní, ale o té zas někdy jindy.