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

Pro nezávislé i projektové úkoly.

Implementace MBO v organizaci je podmíněna nasazením nástroje, který pomůže s nutnou formalizací. Pro smysluplné sjednávání a monitorování úkolů je nutný nástroj, který to podporuje. Teoreticky to lze provádět i v papírové podobě, ale nedává to smysl - jednak se to neosvědčilo a především potřebné efekty lze dosáhnout nejspíš pouze digitální cestou.

Zadání má být formalizované + jeho sjednání formalizovaně interaktivní.

To znamená:

  • 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ů. 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

Sjednání má přibližně tyto kroky a náležitosti.

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

Zadavatel vytváří záměr a předává realizátorovi následující informace.

  • Zadavatel (garant záměru).
  • Realizátor.
  • Důvod = rozpad 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.
  • Hodnota - užitek v NPV (net present value - čistá současná hodnota).
    Odhad, popř. fiktivní hodnota dle metodiky.
  • 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 - 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.

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 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).

Monitoring

Většina úkolů by měla být tak 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čený.

  • Při plánovaném zahájení (popř. krátce předtím).
    • Realizátor i zadavatel mají být upozorněni.
    • Realizátor potvrdí nebo přeplánuje zahájení.
    • Zadavatel by si měl (dle významu aj.) zkontrolovat, že práce na úkolu byla skutečně zahájena.
  • 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ě v případě 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 se přiblížilo jejich dosažení.
    • Odhadne (a zadá) zbývající práci.
    • Případně aktualizuje očekávané datum dokončení.
    • 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.
  • 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 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í tyto lidi 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 dostačující - 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).

Ukončení úkolu

Úkol 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ů.
  • Jakmile je úkol splněn, zadavatel si musí převzít výsledek.
  • Do záznamu úkolu zadá hodnocení.

Rozumíte své práci. My také.

Baví nás to. Máme radost, když věci fungují. Rádi sdílíme zkušenosti.

Cena: Přiměřená

Chci vědět víc

Umíme odhadnout potenciál spolupráce. Vy také. Dohodneme se.
Rádi bychom poprosili ty, komu připadnou informace uváděné v metodice užitečné nebo sporné či mají jiné zkušenosti či mohou doplnit chybějící zdroje, aby se ozvali. Rádi budeme spolupracovat na dalším zlepšování nebo propojíme naše stránky s vašimi.