Projektový Underground

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.

Víme, že pro úspěch realizace projektů neexistuje žádný kouzelný vzorec. Projekt řídíme na základě našich zkušeností, typu projektu, rizik, požadavků zúčastněných stran, zdrojů a omezení. Leckdo funguje tak, že jakmile zjistí nebo uslyší o nové technice, která funguje, vyzkouší ji a pokud se osvědčí, do svého projektového řízení je začlení.

Jedním z velkých problémů s projektem, se kterými se setkáváme, je nalezení optimálního tlaku na členy týmu, aby doručovali úkoly včas, ale nebyli ještě demotivováni nepřiměřeným nátlakem. Příliš velký tlak často dusí, příliš malý tlak vede k nedostatku zájmu a nedostatečné výkonnosti.

V březnovém čísle PM network (2019) se na toto téma v článku Right Mix rozepsal Felix Meyer. Podle jeho článku je zpracován i následující text.

Pro nedávný projekt implementace správy bankovních účtů, který se konal na konci roku 2018, jsem tento problém vyřešil mícháním technik, které vznikly ve výrobním světě (společná verze kanbanu), a technikami používanými při vývoji softwaru (setkání standup ) vytvořit úspěšný koktejl.

COLLABORATIVE KANBAN

Klasický kanban (doslovně znamená „značka“ nebo „billboard“) umožňuje výrobním týmům vizualizovat úrovně zásob ve výrobě podle objednávek zákazníků tak, aby mohli reagovat na změny v poptávce. Jedním z klíčových výhod kanbanu je to, že mapování úkolů spouští akci.

Řada výrobců nástrojů pro správu projektů nabízí vizuální elektronickou podobu kanbanu, která doplňuje plán projektu. Ze seznamu se stávají úkoly projektu.

V mém projektu zavedení nástroje kanban pro spolupráci přineslo několik výhod:

• Vylepšená transparentnost úkolů pro manažera projektu i členy týmu (co se děje nebo je třeba ještě udělat).
• Jasná komunikace o termínu každého úkolu.
• Flexibilita při vytváření nových položek pro seznam, pokud se stávající úkoly musí rozpadnout nebo se objevují nové položky.
• Lepší sledovatelnost a dokumentace na všech stupních pracovního cyklu.
• Schopnost členů týmu aktualizovat obsah kanban karet, takže kolegové a projektoví manažeři jsou informováni o aktuálním stavu.Dostupnost pro všechny členy týmu bez ohledu na jejich fyzickou polohu.

Stojí za to prozkoumat různé kanbanové nástroje a vzít na vědomí, jak vysokou flexibilitu nabízejí (např. zda můžete definovat vlastní kategorie, závislosti a vlastnictví, zda můžete získat automatické připomenutí e-mailem s termíny a zda se můžete integrovat s Ganttem a přehledy).

REQUIRED STANDUPS

Samotné nástroje však nemohou vyřešit všechny problémy. Pro tento projekt jsem také nastavil týdenní setkání. Na tuto techniku se spoléhají při vývoji softwaru – pravidelně rekapitulují úkoly, na kterých se pracuje, aby spolu diskutovali o zjištěných problémech, vytvořili tak problémy sdíleným a aby se na tento úkol zaměřili všichni.

Jakkoliv standupy okamžitě přinesly větší orientaci na projekt, zjistili jsme, že určité nastavení základních pravidel (ground rules) je činí ještě účinnějšími:

• Standupy se konaly jednou týdně, v pondělí, a nikdy nebyly přeplánovány.
• Účast byla povinná pro všechny členy týmu, s výjimkou pokud absence byla plánována předem.
• Položky nebo úkoly v tabuli Kanban musely být aktualizovány před standupem.
• Informace byly krátké, takže každý člen projektu měl omezený čas, aby rychle shrnul klíčové úspěchy a neúspěchy a zmínil, na jakých úkolech bude během týdne pracovat.
• Další témata byla diskutována mimo schůzku.

Pohledem zpátky si uvědomuji, že jsme mohli udělat některé věci lépe – mít časoměřič na setkáních a využívat více možností nástroje – například barevné kódování karet Kanban. Ale obecně jsme zjistili, že mix obou technik vedl k dobře informovanému a spolupracujícímu projektovému týmu. Pomohl vytvořit větší transparentnost a nastavit správnou rovnováhu mezi tlakem a plněním úkolů.

Komentář editora: nejde o nic teoreticky nového – je to určitá forma komunikace v týmu. Ale podle mých zkušeností by tato kombinace konkrétních praktik mohla v korporátech docela dobře fungovat.