Otázky při pohovoru

Kolik je na světě ladičů pian?

Kolikrát za den se ručičky hodin překryjí?

Kolik golfových míčků se vejde do školního autobusu?

To jsou příklady otázek, které může uchazeč o práci dostat při pohovoru v Google.

Jsou to všechno otázky, na které dá práci odpovědět nebo je prakticky nemožné získat přesnou odpověď. Připomíná to otázky, které zmiňuje Joel Spolsky ve svém The Guerrilla Guide to Interviewing. U tohoto typu otázek není důležitá konkrétní odpověď, ale jak se uchazeč chová a jak hledá řešení. Zarazí se? Tápe? Usměje se a začne problém řešit? Postupuje metodicky? Jako hodnotitel musíte umět dobře pozorovat. Jste-li naopak v pozici uchazeče, je dobré nechat druhou stranu nahlédnout do vašeho postupu řešení, komentovat jednotlivé kroky, uvažovat nahlas.

V seznamu otázek se mi ještě libil jeden typ: Vysvětlete svému osmiletému synovci ve třech větách, co je databáze. Rozumět něčemu a navíc to dokázat srozumitelně a stručně vysvětlit je mimořádně důležitá schopnost. Ukazuje to, že člověk je schopen přemýšlet v různých úrovních abstrakce a rozlišit podstatné od nepodstatného.

Pozorování ze zkušební komise

Jednou nebo dvakrát za rok jsem externím členem zkušební komise u státních závěrečných zkoušek na katedře informatiky na ZČU. Už dávno neplatí, že by na podzim obhajovali diplomovou práci jen repetenti, i v tomto podzimním termínu byla třetina opravdu dobrých studentů. Nicméně i letos bylo při prezentacích diplomových prací k vidění několik klasických chyb. Vzpomenu-li si na předchozí státnicové termíny a na cvičné obhajoby, které pořádáme v Keriu pro "naše" diplomanty, "sortiment" chyb zahrnuje:

• Chyby ve struktuře - prezentace je moc dlouhá; student stráví moc času s teoretickým úvodem a nezbude mu čas na vlastní výsledky; vlastní výsledky nejsou jasně oddělené od ostatního obsahu nebo nejsou dostatečně "prodané".
• Srozumitelnost - prezentovaná schámata jsou moc složitá, u grafů chybí popis os, atd.
• Důvěryhodnost zdrojů - rozhodnutí, která jsou pro práci důležitá, nelze zdůvodňovat tím, co jsme si přečetli na nějakém publicistickém serveru; seznamu zdrojů v práci by studenti vůbec měli věnovat větší pozornost.
• Soft skills - chybějící oční kontakt, ruce v kapsách, za zády či v pozici "fíkového listu". Ten nedostatečný oční kontakt se dá omluvit (tréma dělá své), ale ruce v kapsách mi opravdu vadí - student přece předvádí výsledky několikaměsíční práce.

Na studentech je většinou znát, že jsou obstojní softwaroví inženýři, kteří umějí psát programový kód. S psaním textu už jsou na tom hůř, nemluvě o tom, jak dostává zabrat mateřský jazyk.

Myslím, že studentům našich technických vysokých škol by rozhodně pomohl předmět, který by obsáhl základy tvůrčího psaní a soft skills. A také by měli být nuceni více psát a prezentovat během celého studia.

Jeden citát

The thing is, the stuff that's for everybody is already sold to everybody. So you can't win by being more average than average, because that slot's taken.

-- Seth Godin, interview na UXPioneers

Neboli: Zboží, které je pro každého, se už každému prodává. Nemůžete zvítězit tím, že budete průměrnější než průměrní, protože tahle pozice je už obsazená.

To, že cesta do průměru je cesta nikam, bychom si asi měli v Čechách uvědomovat častěji. Čtou Setha Godina třeba v českých novinách?

Výčet klasických chyb

Dalším zajímavým čtením pro projektové manažery je Výčet klasických chyb při vývoji software od Steva McConnella. Uvedu aspoň ty, o kterých si myslím, že je na ně třeba dávat nejvíc pozor (a dovolím si trochu komentovat). Pro přehlednost je zachováno číslování z původního dokumentu.

1. Undermined motivation aneb podkopaná morálka. Rozhodně jeden z nejzávažnějších problémů, které se může vyskytnout. Když lidi nevěří tomu, co dělají, je zaděláno na hodně velké problémy.

5. Adding people to a late project aneb přidávání lidí na zpožděný projekt. Bez komentáře, tohle je klasika už od "starého" Brookse.

6. Noisy, crowded ofices aneb hlučné nebo přeplněné pracoviště. Kdo zažil, ví, jak to dokáže snížit produktivitu lidí.

9. Lack of effective project sponsorship aneb chybějící účinné sponzorství projektu. V tomto případě by se effective dalo přeložit i jako skutečné, protože o to tu jde: projekt bez skutečné podpory shora asi není myšlený vážně.

10. Lack of stakeholder buy-in aneb nedostatek zájmu o projekt od všech, kteří by se o něj zajímat měli - od vedení po koncové uživatele. Vlastně zobecněná chyba č. 9, nicméně v tomto případě opakování nevadí.

11. Lack of user input aneb chybějící vstupy od uživatelů. Ještě jednou stejné téma. Když se neúčastní ti, kteří to nakonec mají používat, čekejte problémy.

14. Overly optimistic schedules aneb příliš optimistické plány. Pokud jste četli The Chaos Report, víte, že přílišný optimismus rozhodně není na místě.

15. Insufficient risk management aneb nedostatečné řízení rizik. Projekty bez rizika neexistují, takže rozdíl je v tom, co s riziky děláte.

19. Wasted time during the fuzzy front end aneb mrhání časem v přípravné fázi projektu. V přípravné fázi opravdu nemusí být všechno jasné, ale to není výmluva, aby tato fáze trvala skoro věčně.

27. Code-like-hell programming aneb zběsilé programování. Tipnu si, že máte v týmu programátora (nebo takového alespoň znáte), který by dokázal naprogramovat chybějící modul tím správně šíleným tempem, třeba za jedinou noc. Jak dlouho se pak v dotyčném kódu budou opravovat chyby?

29. Feature creep aneb "vkrádání se" požadavků. Vždycky se objeví někdo, kdo se do projektu pokusí přidat "jen tuhle jednu malou fukci". Když si nedáte pozor, máte tam těch drobností za chvíli sto. To, co vám pomůže, je dělat důsledně change management. Ta trocha přidané byrokracie za to stojí.

Trocha ergonomie

Je docela příjemným zjištěním, že Microsoft se vcelku seriózně věnuje zdraví při práci s počítačem. Obrázky na uvedené stránce jsou dobrým přehledem hlavních ergonomických zásad pro uspořádání počítačového pracoviště.

První krok ke správnému posezu u počítače je ale mnohem jednodušší - sedět rovně. Motivace viz tento diagram.

Valčík s medvědy

Knihu Waltzing with Bears od pánů DeMarca a Listera bych označil za povinnou četbu pro všechny manažery, kteří řídí softwarové projekty. Je to kniha o managementu rizik a dovolím si ocitovat název druhé kapitoly: Management rizik je projektovým managementem pro dospělé.

Kniha je rozdělená do pěti částí, ale já bych ji rozdělil jednodušeji jen na část politicko-motivační a část technickou. Část motivační je o tom, proč management rizik používat, za jakých podmínek ho dělat a kdy se mu raději vyhnout. Pozornost se věnuje i tomu, jak celou věc prodat vedení, pokud ono samo řízení rizik na projektech nepožaduje. Důležitý koncept spočívá v tom, že na otázku "Jak dlouho bude projekt trvat?" nelze dát kvůli rizikům jednoduchou stoprocentně správnou odpověď. Tou správnou odpovědí je histogram, který uvede několik možných dob trvání, každou s příslušnou pravděpodobností.

Motivační úlohu má i zařazení kapitoly o projektu automatického zavazadlového systému na denverském mezinárodním letišti, jehož zásadní problémy a následná blamáž se sváděly na dodavatele SW, ale problémy ve skutečnosti začaly mnohem dříve ignorováním zřejmých rizik.

"Technická" část knihy se zabývá tím, jak rizika identifikovat a jak vyhodnotit jejich dopad na projekt a jeho realizovatelnost. Jsou prodiskutována jednotlivá základní rizika, která se u softwarových projektů vyskytují. Dostatek prostoru se věnuje tomu, jak vypočítat dopad materializace rizik na trvání projektu. Předkládaná metoda je velmi jednoduchá:

1. Vezměte optimistický časový odhad (lidé jsou v podstatě velmi dobří v optimistických odhadech).
2. Vynásobte optimistický odhad koeficientem odvozeným z toho, která rizika v dané části projektu hrozí a jakou pravděpodobnost každého rizika připustíte. Pokud nemáte žádnou představu, uvažujte například pravděpodobnost 50%.

Zmíněný násobící koeficient získáte podle tabulek, které jsou výslekem statistického výzkumu autorů. Jde-li například o riziko chyby v plánování a připouštíte pravděpodobnost takové chyby 50%, násobící koeficient je 1.39. Když se nad tímto číslem zamyslíte, znamená, že chyb "do mínusu" je velmi málo. Podle statistiky většina chyb v plánování projekt prodlouží.

Vaše situace je snazší, pokud už máte nějaká data z vašich dřívějších projektů a můžete z nich extrapolovat pravděpodobnosti rizik následujícího projektu. Knihu doprovází jednoduchý Monte Carlo simulátor realizovaný v Excelu, který umožňuje získat histogram možných dob trvání projektu.

Nebudu recenzi dál protahovat. Asi jste už poznali, že se mi "Waltzing with Bears" opravdu líbí. Můj závěr zní: kniha si zaslouží pomyslných pět hvězdiček z pěti a rozhodně stojí za přečtení.