Projektový Underground

Ve světě je kontrolní seznam (checklist) jako dokument velice rozšířen a to
v různých oblastech většinou usilujících o zajišťování kvality. V Čechách jeho užívání v praxi je o poznání menší a v literatuře se téměř neobjevuje. V německy mluvících zemích se užívá i synonym „Fragenkatalog“, ale i tam je v praxi rozšířen pojem checklist.

Osobně jsem s ním byl konfrontován prvně v Čechách při návštěvě filiálky McDonald‘s. Najednou se po místnosti, za plného provozu, pohyboval muž, který občas nahlédl do papírů, rozhlížel se a dělal si poznámky. Moji pozornost vzbudil, když si nasadil bílé rukavičky a cosi hledal na běžně nedostupném místě. Právě probíhal audit s kontrolním seznamem, konkrétně vizuální kontrola usedlého prachu.

Co je kontrolní seznam a k čemu slouží?

Kontrolní seznam je seznam otázek k určitému tématu. Jeho použití je systematické pokládání otázek a hledání odpovědí. Cílem je zjistit momentální stav nějaké situace, systému nebo třeba výrobku.

Užití v praxi je rozšířené a dá se objevit hlavně v oblasti organizační, vědecké a při zajišťování kvality. Jeho používání se najde nejen v oborech jako technika, medicína, letectví nebo marketing, ale i mimo ně.

Pomocí kontrolního seznamu se zjišťují slabá místa a nedostatky ve firmách, a proto je užívá audit. Jindy podporuje výběr produktu. Kontrolní seznam slouží při hledání potenciálního rizika, nebezpečí nebo příčiny poruchy. V medicíně se kontrolním seznamem zjišťuje připravenost před a po operaci, jindy se hledají chyby v dokumentech. Jeho užití se rozšířilo i do privátní sféry a tak jsou známy kontrolní seznamy pro organizaci svatby, při stěhování nebo při plánování dovolené.

Kontrolní seznam jako pomůcka má určitou analogii s testovacím protokolem. V obou případech se systém přezkušuje a hledají se potenciální slabiny. Výsledky získané podle kontrolního seznamu se dokumentují, stejně jako je tomu s testovacím protokolem.

Kontrolní seznam je univerzální pomůcka, která je i nositelem know-how. Vytváří se často v týmu, nebo je minimálně týmem odsouhlasena, třeba v nějakém workshopu.

Otázky v kontrolním seznamu jsou strukturovány a soustřeďují se na jedno téma, jako třeba „Kontrola dokumentu“. Na otázky v kontrolním seznamu by měla následovat jednoznačná odpověď a sice „ano“ nebo „ne“.

Kvalita kontrolního seznamu závisí na zkušenosti autora a způsobu odsouhlasení. Ověřený kontrolní seznam je velice účinný při rutinních úlohách, ty se totiž dají kontrolovat nebo i delegovat.

Užitím v praxi se získávají zkušenosti a kontrolní seznam je třeba modifikovat, tedy novými otázkami se doplní a jiné se vyloučí.

Až budete mít na programu nějaký racionalizační workshop, tak zkuste navrhnout kontrolní seznam. Než však začnete nějaký kontrolní seznam tvořit, tak se podívejte na internet, určitě tam najdete inspiraci pro svoji práci.

Ivan Valíček, i.valicek@bluewin.ch

V srpnovém čísle PM network vyšla anketa na téma „Jak nastavíte hranice se sponzorem, který podléhá mikromanagementu?“ Přinášíme výsledky a doporučení:

HLEDEJTE SPOLEČNÉ CÍLE

Dokonalý rovnovážný bod neexistuje a obecně je mnohem lepší sponzor hodně zapojený než nedostatečně zapojený. Zachovejte proto se sponzorem důvěryhodný vztah: neváhejte vysvětlit, proč se určité věci dělají určitými způsoby. Využijte příležitosti, kdy zapojení sponzora může pomoci vyřešit obtížný problém. Neskrývejte se před sponzorem, protože to situaci jen zhorší. Koneckonců, oba máte na mysli stejný konečný cíl.

ZÍSKÁNÍ DŮVĚRY

Zásadní je stanovit si očekávání hned od prvního dne. Všem zúčastněným by mělo být jasné, jaké budou jejich role a odpovědnosti – a jaké komunikační kanály budou použity. Rád zajišťuji týdenní komunikaci se sponzory, abych shrnul pokrok a ukázal přírůstek hodnoty z projektu. Jakmile je sponzor spokojen s výsledky, začne důvěřovat týmu a projektu a nevidí potřebu mikromanagementu.

ZÁKAZNICKÁ KOMUNIKACE

Pravidelné osobní sezení se sponzorem projektu je skvělý způsob, jak diskutovat
o jakýchkoli problémech, žádostech a obavách. Také je dobré sdílení projektových poznámek pomocí nástroje pro spolupráci – je to skvělý zdroj projektových informací pro kontrolu vlastníkem. Doporučuji také vyhledat radu od „poradců“ vlastníka – zkuste identifikovat takové osoby abyste zjistili, existují-li nějaké další strategie nebo taktiky, které lze použít k posílení pracovního vztahu.

KROK K PLÁNU

Styl zapojení sponzora závisí na mnoha různých faktorech, z nichž mnohé mohou být zřejmé během analýzy stakeholderů:

• Jaké jsou motivy sponzora pro mikromanagement? Byl sponzor nedávno povýšen z projektového manažera na liniového manažera? Stalo se
  v minulosti něco, co ovlivnilo důvěru sponzora v projektového manažera, aby dodal dohodnutý rozsah v dohodnutém čase a rozpočtu?
• Jaké organizační zvyklosti jsou ve společnosti? Je tento způsob práce snad součástí metodiky řízení projektů společnosti?

Žádná instrukce nebude vyhovovat každé situaci, ale analýza zúčastněných stran a prostředí je krok správným směrem. A ujistěte se, že dokumentujete své dohody
v komunikačním plánu projektu.

NASTAVTE OČEKÁVÁNÍ

Chcete projevit uznání zájmu sponzora, ale také vyjádřit respekt k jeho drahocennému času. Navrhuji tedy předem se dohodnout, na jakých schůzkách se sponzor účastní a jaké komunikace bude sponzorovat – zdůraznit, že bude vždy znát relevantní aspekty. Dobrým nástrojem pro tento účel může být velmi krátké shrnutí komunikačního plánu s jasnou maticí odpovědností a účasti sponzora.

ORGANIZACE

Během nedávného projektu jsme měli manažery z různých míst a s různou odpovědností. Bylo naplánováno mnoho společných setkání, které sice uspokojily všechny, ale bylo to ve výsledku kontraproduktivní. Obrátili jsme se na ně proto
s tím, že jsme vytvořili plán řízení projektu se zvláštním zaměřením
na zainteresované strany, rozsah a řízení komunikace. Mimo jiné jsme vytvořili interní zasedání řídícího výboru pro klíčové zúčastněné strany a sdíleli jsme zápisy z jednání a zprávy o pokroku, takže každý měl přístup k důležitým informacím. Zlepšením komunikační struktury jsme snížili úroveň mikromanagementu a pomohli jsme vybudovat důvěru v tým, přičemž odborníci se mohli soustředit
na analýzu a řešení klíčových příčin problémů.

Každý den vzniká v pracovním procesu velké množství dokumentů a to různého druhu jako emaily, protokoly, ale i nabídky, koncepty, smlouvy, standardy, atd.

Všeobecně usilujeme o kvalitu dokumentů, ale i zde je rozdíl. Ten je dán autorem, adresátem, účelem nebo uživatelem.

Existuje řada dokumentů a to nejen technických, kde cílem je nejvyšší kvalita, tj. dokumenty bez chyb. K těmto patří studie, koncept, design, nabídka, specifikace, smlouva, návod na obsluhu, reglement, norma, standard, zákon, atd.

V praxi je rozšířená metoda čtyř očí, tj. dokument kontroluje ještě druhá osoba. Jiná varianta integruje do kontrolního procesu více osob a to neformálním způsobem.

Rozšířená praxe je dát nový dokument do oběhu a vyčkat poznámek nebo připomínek oponentů. Samozřejmě dosáhneme lepšího výsledku, ale ne zdaleka nejlepšího, který je v praxi očekáván.

Teprve metoda jakou je “Formální Technická Review”, která je provedena formálním způsobem, nám umožňuje najít a analyzovat další chyby.

Mnohdy se ji říká „Filtr na hledání chyb”, protože množství nalezených chyb se dá doslova nastavit. Variabilní je výběr autora, expertů a též rozsah kontrolního seznamu (checklistu) nebo přidělení částí kontrolního seznamu na jednotlivé experty (obr. 1).

Obr. 1

Princip metody FTR vychází ze standardu IEEE 1028-2008. Původně je určena pro IT, dá se však modifikovat a použít pro technickou i netechnickou dokumentaci, která vyžaduje nejvyšší jakost. Nutno zdůraznit, že jde o metodu málo rozšířenou, spíše neznámou, která čeká na svoje objevení a hlavně uplatnění mimo IT.

FTR je proces, který probíhá ve fázích: plánování, příprava, review, vyhodnocení a závěrečná opatření.

Každá fáze je jasně definována a každý účastník procesu má přiřazenou roli:

 autor, manažer, moderátor, expert a zapisovatel (obr. 2).

                  Obr. 2

Důležitou pomůckou je kontrolní seznam upravený pro dokumentaci, která bude podrobena review. V rámci přípravy s ním pracuje každý expert. Kontrolní seznam obsahuje stěžejní otázky k dokumentu a tímto určuje expertovi i oblast pro přezkoušení textu.

V tomto bodě má FTR analogii s klasickým testem nějakého produktu, totiž checklist odpovídá testovacímu protokolu (obr. 3).

           Obr. 3

 Schůze expertů, vlastní review, probíhá efektivně, každý účastník je obeznámen se zvyky a pravidly, které během review dodržuje. Pravidla pro review jsou stanovena tak, že přispívají ke zvýšení kvality dokumentu a k efektivnímu průběhu schůze.

Metoda FTR umožňuje nejen objevit a vyhodnotit chyby, ale též zde dochází k didaktickému efektu, kterým je vytváření a předávání know-how účastníky schůze (synergie).

Všechny nálezy jsou on-line vizuálně dokumentovány. To zaručuje správnou interpretaci protokolu. Ke každému nálezu je přiřazen druh chyby a to na základě kritérií. Podle výsledku review se rozhodne, zda stačí jen kontrola autorových změn/řešení, nebo zda se provede review znovu. O tom nerozhoduje autor, ale zadavatel review (manažer) na základě výsledků v protokolu.

Metoda “Formální Technická Review” je vhodná pro veškeré druhy dokumentace, tj. i pro netechnickou a jednoznačně zajišťuje nejlepší kvalitu dokumentů. Proces odsouhlasení dokumentů se zkrátí i o více jak 50%. Důležité je, aby všichni účastníci FTR tuto metodu znali nejen teoreticky, ale i prakticky. Nejlepší způsob je školení s praktickým příkladem na vlastním dokumentu. FTR se v praxi osvědčilo, a navíc díky její formálnosti dostanete nový pohled i na jiné druhy schůzí.

Ivan Valíček

i.valicek@bluewin.ch

Na motivy článku Why Agile May Be Fragile připravil Ota Krátký

Medializace a „zbožnění“ agilních firem a organizací potřebuje poodhalení podstaty agility už jen proto, aby podstata a základní hodnoty agilního přístupu zůstaly zachovány pro budoucnost.

V opakujícím se cyklu se poradenské společnosti usilovně snaží najít ten pravý lék na neduhy velkých (i menších) společností. Cyklus je vždy téměř stejný: zpočátku se zdá, že nové praktiky, přístupy, procesy fungují skvěle, jsou masivně nasazovány a je jim poskytována velká publicita. Firmy a organizace všech velikostí a typů jsou intenzivně povzbuzovány k nasazování. Poté se na veřejnost dostanou zprávy o selhání nového „léku“ u prominentních firem a nastává změna z prvotní zamilovanosti do fáze rozčarování, že kouzla nefungují.
A cyklus se opakuje, „zázrak“, který nefungoval je nahrazen novým.
Nicméně použití selského rozumu k nastavení přístupů, procesů, praxe, které by mohly fungovat velmi dobře je pro některé firmy a organizace a především pro jejich vedení a poradenské a konzultační či „koučinkové“ firmy všeho druhu a velikostí natolik nepřípustné a nemoderní, že je takové řešení odmítnuto -> Dítě je vylito s vaničkou.

Jak bylo nastíněno a je dosti pravděpodobné a toho se obáváme, že aktuálně nejnovější agilní přístup je a budepoužíván mnohými poradenskými společnostmi na jejich webech k akcím – „Zjistěte, jak jste agilní“ nebo „Jak vám s agilitou pomůžeme“. Je to příkaz doby, ať pro nadnárodní firmu z rychloobrátkového obchodu či národní banku – stát se agilní. Druhým agilním příkazem doby je nutnost využít či vytvořit týmy samoorganizující se proto, aby se firmy staly agilními. Pravděpodobnost úspěchu však nikdo nezaručí.

Aby bylo jasno, zcela určitě nechci zpochybňovat snahu a úsilí společností, které jsou efektivní a inovativní (což by mělo být výsledkem „agility“). Zde jen poukazuji na problém výzkumů na některých školách nabízejících MBA jako jsou například výzkumy: „Organické vs. mechanistické struktury“ „exploration vs. Exploita on“(více zde: https://en.wikipedia.org/wiki/Exploitation_of_labour) „ambidexterity“ (pro laiky: https://en.wikipedia.org/wiki/Ambidextrous_organization) čili schopnost firmy vyhovět obchodním požadavkům a současně se průběžně adaptovat na měnící se podmínky okolí.
V podstatě souhlasím s problematikou a vím, jak je obtížné dosáhnout trvale efektivity a být dosti inovativní a kolik různých řešení může být v odlišných a rychle se měnících podmínkách.

Nicméně pokročme dále: Jsem příznivcem agilního přístupu jako řešení určitých druhů a okruhů problémů v některých případech, jako jsou například nový produkt, jeho funkce nebo i nové zásady řízení. Agilní přístup využívá rychlé, paralelní a nenákladné iterace řešení problémů. Pokud ve vaší firmě či organizaci jsou některá oddělení, skupiny, které mohou využít tento přístup a způsob řešení problémů, pak může být agilní přístup tím pravým pro vás. Dokonce lze prohlásit, že všechny problémy, u nichž se hledá nové, komplexní řešení mohou být řešeny s vysokou pravděpodobností úspěchu agilním přístupem. Na druhou stranu je potřeba říci, že ne všechny problémy lze řešit agilními praktikami. Význam agilního přístupu je ještě nižší, pokud s organizace pokouší agilní přístup využít ve snaze o zvýšení spolehlivosti v oblasti s dobře popsanými a pochopenými procesy jakým může být například hromadná výroba.

Rád bych varoval před použitím agilních přístupů a myšlení nad rámec možných oblastí, kde lze agilitu využít. Nechci však s vaničkou vylít i dítě ;-))

Jak a kde agilita vznikla?

Agilní přístup vznikl jako způsob vývoje v „softwarovém průmyslu“ jako SCRUM se svými základními principy vysoce autonomních a nezávislých týmů, pracujících na dílčích částech většího a komplexního problému. Na rozdíl od zkostnatělých a byrokratických procesů týmy dostaly ve SCRUMu svobodu „sprintu“, čili značné výhody práce v souběžných směrech řešení s velmi malým celkovým pohledem na celý problém. Vzájemné závislosti práce týmů jsou v SCRUMu řešeny častými schůzkami a opravy a předělávky jsou brány jako součást iterativního procesu vývoje. Po dokončení svého úkolu na řešení problému může být tým rozpuštěn nebo využit na další projekt. Když vše funguje dobře, přináší to značný mix autonomie, okamžitého a měřitelného výsledku a sounáležitosti pracovníků s týmem.

Myšlenka stojící za rozšířením agilního přístupu do mnohých další společností a organizací je prostá, stejně jako vývojářské společnosti i ony stojí před úkolem rychle najít řešení úkolů, jak být rovnostářský a současně, jak vyhovět potřebám udržet motivaci pro znalostní pracovníky, jimiž vývojáři a nejen oni jsou. Přesně toto je argument pro zdánlivě správný krok – agilní přístup, agilní transformaci. Nicméně lze rychle najít 3 problémy, které jsou s tímto argumentem spojeny:

• Potřeba zahodit „staromódní“ organizaci práce a strukturu společnosti je v jednotlivých sektorech velmi odlišná. Ne všechny společnosti intenzivně potřebují změnu způsobu práce a jejich struktury a řízení tak intenzivně, jako ve vývoji softwaru.
• Není jistota, že agilní přístupy fungují stejně efektivně i mimo softwarové společnosti.
• Je velmi málo příkladů i v sektoru softwarových společností, že lze účinně rozšířit agilní přístup na celou organizaci

Zrychlení s využitím rychlého souběžného vývoje je chimérou i za předpokladu, že některé malé části by mohly být zpracovány souběžně. Výrobní technologie jsou velice rozdílné a tím i jejich schopnosti dekompozice. Neexistuje racionální důvod věřit, že úroveň možností dekompozice v oblasti přírodních věd, výzkumu a vývoje či vývoje nového výrobku v rychloobrátkovém průmyslu je téměř stejná jako při vývoji softwaru. Softwaroví architekti obvykle pečlivě připravují práci i specifikací rozhraní pro paralelní práci a při používání pravidel pro správný návrh a programování lze souběžný vývoj použít. Pro softwarový vývoj bylo štěstím, že pracuje s technologiemi, umožňujícím takovouto transparentnost – s kódem, kde je možno celkem dobře vidět, co dělá. Pro ostatní, z jiných odvětví, je nutná velká obezřetnost. Dokonce se objevuje myšlenka, že není-li organizace nucena ke změně, její fungování, ziskovost je ve výhledu dobrá, není nutno dlouhotrvající  a náročnou změnu na agilitu podstoupit.
Je celkem možné, že nastane den, kdy výkonné činnosti pro velkou část odvětví lidské činnosti budou automatizovány a místo nás je budou vykonávat roboti nebo umělá inteligence a tím se lidé budou moci soustředit na výzkum či hledání nových řešení. Tato změna, posun umožní podstatně více se spolehnout na počítačové simulace než na často velmi nákladné reálné prototypování. Až tento den nastane, je možné, že agilní přístupy budou běžné pro všechny společnosti a všechny jejich části.
Tento den zdaleka nenadešel.

Kde je možno využít agilní přístup?

Uvážím-li všechny předchozí informace, je tedy agilní přístup pro nás přínosem? Ano, ale buďme obezřetní! Myslím si, že je vhodným postupem, začít s agilním přístupem v odděleních, částech organizace zabývajícími se vývojem softwaru a rozšiřovat jej v soustředných kruzích okolo. Poté opatrně a pomalu evangelizovat a rozšiřovat do dalších částí společnosti, které mají podobné vlastnosti jako vývojáři softwaru. Například to může být  – vývoj produktu,  – vznik firemních vizí, idejí – řešení technických problémů.
Nicméně můžete udělat podstatně více než jen doufat či odhadovat, že agilní přístup je tím pravým pro vás. Jedním z cvičných nástrojů může být „gamifikace“ čili hra trvající několik hodin i dnů, kdy pro splnění stejných úkolů sestavíme ze zaměstnanců společnosti 2 týmy – jeden klasicky strukturovaný, hierarchický a druhý – agilní a při jejich práci sledujeme, jak pracují, jak komunikují, jak se zadáním pracují a jaké mají výsledky a proč. Například na INSEAD institutu se tím zabývá Maria Guadalupe, připravující i kurzy jak být agilní tím správným způsobem. Lze také získat více informací z domácí produkce (https://courtofmoravia.com/).

Výzva k autonomii

Lze se domnívat, že příslib či vidina autonomie práce a organizace bez hierarchického členění a tím povzbuzení k vyššímu pracovní zapojení zaměstnanců může být důležitým faktorem pro stále se zvětšující zájem o agilní přístupy práce. Nicméně, jak jsme uvedli výše, prozatím se náš názor na agilitu nemění. Do dnešních dnů není znám žádný robustní, široce použitelný mechanismus pro škálování spolupráce mezi členy organizace vzájemně na sobě pracovně závislých mimo hierarchického uspořádání Jistě lze najít mnoho lepších způsobů delegování práce a odpovědnosti, více lepších způsobů než „org chart“ pro návrh hierarchie a mnoho pokusů zmírnit rozdíly mezi pozicemi na různých úrovních, na druhou stranu více stupňová organizace společnosti se zdá stále být tou nejvhodnější pro absolutní většinu případů. Při zjišťování existují-li úspěšné výjimky (a není jich mnoho) ukazuje, že agilní transformace a přístup funguje za některých výjimečných okolností. Myšlenka, že můžeme vzít existující soubor zaměstnanců a výrobní technologie a plynule je reorganizovat do nehierarchické samořídící se struktury, nemá v tomto bodě téměř žádnou podporu ani důkaz, který by ji podpořil. Vřele si přejeme, aby to tak nebylo, byli jsme přívrženci nových myšlenek a rovnosti sami také. A my všichni bychom se určitě měli snažit najít robustní a škálovatelnou alternativu k hierarchii, protože preference autonomie a nesouhlas s nerovností jsou důležitými a široce drženými hodnotami. Je však nepravděpodobné, že by Agile v současném stavu bylo řešením.