Systém podpory řízení pomocí úkolů

Formalizované ≠ formální

Zadání ani podpora/sledování/kontrola plnění úkolu nesmí být formální. Potřebujeme mít především jistotu, že zadavatel i realizátor mají na mysli totéž. Že to, co se udělá, bude to, co potřebujeme.

• Zadání probíhá formou interakce mezi zadavatelem a realizátorem
  • Zadavatel předá požadavek/-y.
  • Realizátor vrátí návrh. 
  • Zadavatel jej vyhodnotí a pokud je to potřeba, upřesní požadavky a vyžádá si úpravu návrhu formou připomínek.
• Jestliže takto vznikne platné zadání (včetně plánu práce), realizátor na něm ve sjednaném čase začne pracovat a vykazovat postup.
• Zadavatel má možnost jej sledovat, případně si osobně ověřit realitu.

Pro užívání systému je nutné mít definovaný proces = povinnosti uživatelů & současně jej implementovat v podobě workflow (tedy dat a pravidel pro záznam a zpracování informací a automatizaci zapojení lidských účastníků pracovního postupu). Tedy jasnou metodiku a dle možností využivat šablony, z nichž si každá nese soubor specifických doporučení pro daný typ úkolu.

Základní podoba sjednání a realizace úkolu

Sjednat a uskutečnit mimořádnou práci má přibližně tyto kroky a náležitosti.

• Formulovat zadání - identifikace úkolu a jeho náležitostí.
• Navrhnout řešení.
• Posoudit návrh.
• Pracovat na úkolu a monitorovat jeho průběh.
• Převzít výsledky a vyhodnotit plnění.

Nejedná se o rutinní činnost. Není potřeba součinnost nikoho dalšího. Nalezení způsobu a realizace by nemělo trvat dlouho. Je nutno používat tento mechanismus pro aktivity, na které se hodí.

Zadání - interpretace záměru a účastníků

Zadavatel vytváří úkol/zadání a předává realizátorovi následující informace.

• Zadavatel (garant záměru).
• Realizátor.
• Důvod = rozpad & interpretace požadavků nadřazených záměrů/úkolů.
• Záměr
  Popis užitku, který organizace získá, pokud bude úkol splněn a využit. Důvod, proč je potřeba danou práci dělat. Realizátor musí správně pochopit tuto součást zadání - jelikož by to mělo být tak, že on je nejvhodnějším člověkem pro řešení dané potřeby, jeho hlavním úkolem je najít ten nejlepší způsob (čím lze žádoucího efektu dosáhnout). 
• Hodnota - užitek onoho záměru v NPV (net present value - čistá současná hodnota).
  Odhad, popř. fiktivní hodnota dle metodiky. Nákladový limit. Měla by již být známa. Používá se jako kritérium, zda zamýšlený účel dává smysl - pokud cena jeho řešení výrazně přesahuje hodnotu, je potřeba přehodnotit strukturu nadřazeného záměru (viz později, samostatně + vysvětlení, jak funguje nákladový limit).
• Limitní termín - zcela fatální termín (po kterém již nemá výsledek úkolu žádnou hodnotu) - může a nemusí být zadán (stejně hodnota) - výhodnější je nedávat jej realizátorovi v prvním kole k dispozici a řešit případný konflikt při interaktivním upřesnění návrhu řešení.
• [Skrytá] Předběžné výstupy.
• [Skrytá] Odhad limitu spotřeby kapacity. Popř. pravděpodobnost.

Poslední dvě skupiny údajů slouží k porovnání s tím, co bude navrhovat realizátor (detailně metodika).

Realizátor zadání prostuduje, případně si ověřuje a doplňuje informace a poté k zadání vytvoří návrh řešení.

Realizátor navrhne řešení

Interpretuje požadavek a pokusí se navrhnout (specifikovat) žádoucí výstup a postup.

• Požadavek na upřesnění (vrací zadavateli - nutno zabránit nekorektnímu vracení - tedy podporovaný je jeden dotaz, aby se zabránilo zdržení). Záleží na nastaveném režimu, zadavatel by měl být ve stanoveném čase po předání zadání k dispozici, aby bylo možno upřesňovat zadání interaktivně.
  • Důvodu.
  • Záměru.
  • Užitku.
  • Návrhy na spojení / rozdělení / součinnost úkolů.
• Návrh výstupů.
  Popis, díky čemu by měly být dosaženy cíle záměru (jak přispěje to, co má být úkolem vytvořeno/získáno).
  Návrh akceptačních kritérií - definice vlastností výstupů a postupů, jak budou ověřovány.
• Návrh postupu včetně termínů, popř. zdrojů (vstupů).
  Rozpad úkolů do pracovních bloků kalendáře (tedy max. půldny). Dle možností s uvedením dílčího výstupu na konci bloku.
• Spotřebu kapacity.

Zadavatel posoudí návrh.

Zadavatel vyhodnotí navrhovanou interpretaci

Ověří, jak realizátor pochopil a zda navrhuje přiměřené řešení.

• Pokud považuje návrh řešení za dostatečný, potvrzuje (fixuje - hodnoty se uloží jako sjednané):
  • Termín zahájení.
  • Rozsah práce (spotřebu kapacit).
  • Výstupy a jejich akceptační kritéria
  • Termín ukončení & rozsah časové a kapacitní rezervy (vůči limitu).
• Pokud s navrženými paramety či postupem nesouhlasí, měl by se s realizátorem spojit a zeptat se na důvody/vysvětlení těch údajů, keré se mu nezdají. Případná upřesnění doplní (nebo požádá realizátora, aby to udělal, ale musí si to zkontrolovat, takže…) Komunikace nemusí být formalizovaná, je ovšem nutno její závěry zaznamenat.
  • Když některá část návrhu neodpovídá záměru, připomínkuje ji s komentářem, jaké rozdíly a jejich pravděpodobné příčiny vidí (např. navrhovaný výstup je nedostatečný nebo předimenzovaný - v takovém případě nejspíše nebyl požadavek dostatečně přesný a je nutno jej doplnit).
  • Po zadání všech připomínek předá úkol zpět realizátorovi k upřesnění návrhu. To by mělo proběhnout velmi rychle (obratem) a pokud se neobjeví další nejasnost, úkol schválí.
  • Nemělo by to (až na výjimky) probíhat opakovaně - to by byl důkaz neochoty nebo neschopnosti se domluvit (nevhodný zadavatel či realizátor).

Podle schváleného zadání realizátor udělá, co je potřeba.

Monitoring

Většina úkolů by měla být natolik krátkodobá, že by neměly vyžadovat násobný dohled. Ale iniciální ověření, že se na plnění začíná pracovat, je silně doporučeno (nutné).

• Při plánovaném zahájení první činnosti úkolu (popř. krátce předtím).
  • Realizátor i zadavatel mají být upozorněni (workflow/kalendář).
  • Realizátor potvrdí nebo přeplánuje zahájení.
  • Zadavatel by si měl (dle významu a situace) zkontrolovat, že práce na úkolu byla skutečně zahájena (dle zkušeností, např. v polovině nebo na konci prvního pracovního bloku).
• Při provedení každého samostatného bloku práce (doporučeno je, aby blok práce byl v rozsahu nejvýše půl člověkodne; blok je celistvá posloupnost činností, která znamená kvalitativní změnu na stavu zamýšlených výstupů, rozhodně při dosažení některého z definovaných dílčích / postupných výsledků) realizátor:
  • Vykáže bezprostředně provedený objem práce (mělo by se to vázat k aktivnímu kroku v plánu práce).
  • U jednotlivých výstupů dílčích kroků identifikuje, nakolik jsou hotové.
  • Odhadne (a zadá) zbývající práci (spotřebu kapacity i termín dílčího kroku).
  • Případně aktualizuje očekávané datum dokončení úkolu (pokud přeplánuje dílčí kroky).
  • Pokud je potřeba změnit postup, upřesní či doplní. Drobné změny by měla krýt časová/kapacitní rezerva.
  • Pokud změna postupu přesahuje sjednané limity nebo se ukázalo, že není možné dosáhnout potřebných vlastností výstupů, vyžádá si revizi úkolu.
• Na základě pravidel lze automatizovat vyhodnocení zejména toho, nakolik se mění podíl zbývajícího času a práce a podle toho případně upozornit na rostoucí riziko nesplnění v termínu.
• Zadavatel může být vyzván k (nepovinné) průběžné kontrole (u déletrvajících úkolů). Každopádně má úplný přehled o tom, kdy a jaké údaje do systému realizátor zadával. Současně musí být k dispozici aktuální rozpis prací - aby se dalo dle potřeby ověřit, jak práce postupuje.
• Zadavatel má možnost plnění úkolu přerušit / odebrat (např. nemoc realizátora). Předání rozpracovaného úkolu na někoho jiného je samostatné téma.

Je dobré chápat evidenci průběhu plnění tak, že především pomáhá realizátorovi, aby měl (sám pro sebe) doložený stav plnění úkolu a mohl tedy v případě potřeby přeorganizovat své ostatní povinnosti atd. Velmi důležité je v této souvislosti podpora a technické podmínky pro rozpis prací.

Velmi zajímavým tématem je, jak stimulovat realizátora, aby se snažil splnit úkol co nejdříve (rozumí se bez ohledu na plánované ukončení nebo limit). Většinou to záleží na organizaci práce/času. Což je oblast, ve které je žádoucí spolupracovníky podporovat. 

Možná by jako ukazatel (relativně nezávislý a přijatelně efektivní) mohl sloužit poměr mezi skutečně spotřebovaným časem a skutečně spotřebovanou kapacitou. To vypovídá o schopnosti se úkolu věnovat. Samozřejmě je téma, jak stimulovat k tomu, aby spotřeba kapacity byla co nejnižší. To by zase mohl pokrýt vztah mezi hodnotou výstupů a kapacitou (produktivita). To sice už není tak jednoznačné (hodnota se bude obvykle stanovovat poměrně obtížně), ale mělo by to být přijatelné - logicky je nutné již na začátku učit hodnotu řešení - ta určuje limity čerpání zdrojů (mohla by plést s přínosem záměru, na což je potřeba dávat pozor). 

Je to celé moc zajímavé a stojí zato se věnovat jak technikám a nástrojům, tak dovednostem lidí.

Práci je nutno převzít a vyhodnotit.

Ukončit úkol

Sledování úkolu končí automaticky tím, že již není potřeba vykonat žádnou práci.

• Počítá se s tím, že datum ukončení se průběžně aktualizuje. To slouží přípravě zadavatele na převzetí výsledků.
• Pokud se blíží limitní termín, je zadavatel upozorněn na stav práce (kolik zbývá).
• Jakmile je úkol splněn, zadavatel si musí převzít výsledek. K čemuž je automaticky vyzván.
• Do záznamu úkolu zadá hodnocení. Což je realizátorovi automaticky zpřístupněno.

Rozumný systém tohoto typu má řadu zajímavých funkcí a neomezené možnosti rozšiřování. 

Bez jasně definovaných procesů (povinností lidí) je úplně k ničemu.