Firmy se mě často ptají, jaký online nástroj na řízení práce si mají vybrat. Přibližně polovina z nich řeší, jestli je pro ně Asana vhodná. Četli například nějaký článek, bavili se s bývalým kolegou, měli ve firmě konzultanty a ti jim doporučili Asanu.

„Viděli jsme, že má Asana timeline, to přesně potřebujeme…“

Můj přístup je někdy překvapí. Raději jim Asanu rozmluvím, než aby se za půl roku čertili, že to není to pravé. Firmy se při výběru online nástroje na řízení práce nerozhodují podle relevantních kritérií. Rád bych v tomto článku rozebral, proč to tak je a jak si myslím, že by to firmy měly dělat správně.

Pokud vás nezajímá celý kontext článku, ale chcete znát jen ověřená kritéria, přeskočte rovnou na část článku, kde kritéria popisuji.

Část první – problém

Problém 1: Nejasná definice nástrojů na řízení práce

Složitost rozhodování je dána velkým množstvím nástrojů, které můžete zvažovat. Všimněte si, že záměrně mluvím o online nástrojích na řízení práce. Běžně se můžete setkat s označením jako např. nástroje na projektové řízení, procesní řízení, na vedení úkolů apod. Podle mě jsou tyto škatulky zavádějící. Co je pro jednu firmu seznam úkolů, může být pro druhou opakující se proces a pro třetí jednorázový projekt. Často se setkávám s tím, že se v článcích srovnávají jablka a hrušky. A protože platí, že jak o věcech mluvíme, tak o nich i přemýšlíme, začnu u definic.

Osobně vidím dvě možné definice pojmu online nástroj na řízení práce, které budou vhodné pro téma rozhodování se o výběru:

Široká definice: jakýkoliv online nástroj, který využíváme se záměrem spolupracovat. V tomto případě je důležitější záměr, spíše než nástroj. Třeba WhatsApp tedy může být nástroj na řízení práce, pokud tak s ním vědomě pracujeme.

Má úzká definice: jakýkoliv nástroj, který využíváme se záměrem spolupracovat a umožňuje 1) jasně přiřazovat zodpovědnost (plnitel, termíny, priority) a 2) udržovat si nad prací přehled (možnost plnit úkoly, zpracovávat upozornění apod.). Z této mé definice vypadne třeba Slack, který je sice díky milionu integrací fajn jako notifikační centrum, ale zkuste tam někdy někomu zadat úkol. Nejen, že si ho dotyční nemají kam uložit, ale vy navíc nedohledáte, že jste úkol zadali nebo jestli ho splnil.

S mou definicí nemusíte souhlasit. I já procházím vývojem. Pryč jsou doby, kdy mi přišel článek, který má tendenci srovnávat tak odlišné nástroje jako třeba Asana, Trello a Slack jako vrchol amatérismu (ty články jsou pořád špatné, ale už alespoň chápu proč). Lidi tam venku totiž uvažují spíše v rovině té širší definice a mně trvalo, než jsem to pochopil a naučil se mezi nimi přepínat. Dál se budu držet té širší definice – ač je mi to osobně vzdálené, bude to praktičtější.

Problém 2: Samozvaní odborníci na nástroje

Při výběru nástroje se často odrážíme od názorů dalších lidí, aniž bychom zhodnotili relevanci jejich názorů. A nemyslím si, že by vám chtěl bývalý kolega nebo konzultant z marketingové agentury poradit blbě. Jen často 1) neznají vaše potřeby, 2) automaticky předpokládají, že jsou jejich potřeby shodné s těmi vašimi a 3) když chválí nebo hanobí konkrétní nástroj, neuvádí, zda v nástroji opravdu reálně pracovali nebo si jen na měsíc pustili trial zdarma.

Když vezmu svou zkušenost s Asanou, první smysluplné insighty přišly po více než roce práce na vlastních projektech. Něco, co bych nazval jako zkušenosti, přišlo až po dalších dvou letech práce, kdy už jsem zároveň dělal první školení. A pořád nacházím oblasti, kde bych mohl znát kontext využívání nástroje ve firmě mnohem lépe. Proto zatím neškolím jiný nástroj na řízení práce než Asanu. Po dvou letech osobních zkušeností teď začínám s Notionem, který sice nevnímám jako přímého konkurenta Asany, i když spadne i do úzké definice.

Tento problém mají řešit weby typu Capterra nabo G2 Crowd. Ale sám jsem při pročítání recenzí trochu skeptický – co když je to jen další varianta „s nástrojem XY se nám dobře pracovalo”?

Jsem tedy zastánce jiného řešení, ač je složitější – firma by se měla umět rozhodnout sama, podle kritérií, která jsou pro ni relevantní. Podklady ať klidně sbírá od dalších firem nebo konzultantů, musí však zvážit, do jaké míry vychází doporučení z jejich potřeb.

Problém 3: Deklarované vs. opravdové potřeby

Už tedy víme, že firma nejdříve potřebuje poznat své potřeby. O tom, jaké otázky si má položit, bude poslední část článku. V této části chci upozornit, že existuje velký rozdíl mezi tím, co říkám, že potřebuji a co doopravdy potřebuji. Zrovna tady se mi hodí moje výzkumnické alter ego z Makevisionu.

Abych to demonstroval, rozhodl jsem se vytvořit takový ukázkový slovník, který překládá nejčastější deklarované potřeby do opravdových potřeb. Ukázky vycházejí z reálných potřeb, ale fakticky jsou smyšlené a veškeré podobnosti jsou pouze náhodné… To zmiňuji proto, byste se v těch případech našli.

Deklarovaná potřeba	Opravdová potřeba
Potřebujeme wiki	Potřebujeme někde zaznamenávat informace, např. o tom, jak pracujeme.
Potřebujeme integrované měření času	Klient po nás chce pravidelně reporty a my nemáme, jak mu dokázat, co všechno jsme udělali (= že fakturujeme férově).
Potřebujeme gannt.	Projekťák si na začátku potřebuje vizualizovat plán projektu, dál už s tím ale nepracuje.
Potřebujeme, aby šly v nástroji zasílat zprávy.	Polovina lidí ve firmě používá Skype, protože se potřebují dohodnout, kdy půjdou na oběd, druhé polovině to vadí, protože neví, co se ve firmě děje.
Potřebujeme šablony projektů.	Projekty vytváříme tak jednou za měsíc, úplně v pohodě si vystačíme s možností vytvořit kopii projektu.
Potřebujeme, aby šel nástroj X integrovat s aktuálně využívaným nástrojem Y.	Nástroj Y využíváme jen proto, že jsme nevěděli, že lze stejnou potřebu řešit i v nástroji X.
Potřebujeme k úkolům zadávat počáteční datum.	Potřebujeme jen mít přehled o větších úkolech, ale fakticky by nám pomohlo, kdybychom si je rozdělili do menších kroků s dílčími deadliny.
Potřebujeme zadat jeden úkol více lidem, budou přece spolupracovat.	Potřebujeme vědět, jak lépe delegovat práci konkrétním lidem, místo skupině.

Pro další čtení tohoto článku stačí, když si uvědomíte, že existuje propast mezi deklarovanou potřebou a opravdovou potřebou.

Část druhá – řešení

Potřebujete poznat potřeby lidí ve firmě a pak se podle nich dokázat rozhodnout. Pokud jste ve vedoucí roli nebo máte výběr nástroje na starosti a nemáte v plánu brát ohled na potřeby dalších lidí v týmu, ani nemusíte číst dál. I když dobře poznáte své vlastní potřeby, takový domeček z karet se vám sesype při prvních snahách o implementaci nástroje do týmu (to je minimálně na další samostatný článek).

Myslím, že řešení se nachází na škále mezi 1) metodou pokusů a omylů a 2) důsledným ověřením potřeb.

Extrém 1: Metoda pokusů a omylů

Metoda pokusů a omylů nemusí být vždy špatná. Všimněte si ale, že záměrně píšu v množném čísle. Pokud byste chtěli jít cestou pouze tohoto extrému, musíte být vytrvalí, protože těch pokusů a omylů bude mnoho. Navíc to lze jen s miniaturním týmem, který je navíc velmi tolerantní. Pokud máte v týmu čtyři a více lidí, po třetím nástroji je to přestane bavit.

Tento přístup staví na tom, že si prostě vyberete první nástroj a zkoušíte, jak se vám s ním pracuje. A pak další a další. A počítáte, že vám časem nějaký zůstane. Zní to šíleně? Upřímně, já sám jsem se takhle propracoval k Asaně. Mně samotnému trvalo cca čtyři roky práce s Outlookem, papíry (Getting Things Done styl), Remember the milk (pamatujete někdo?), Pivotal Trackerem a Basecampem, než jsem si uvědomil, že mám nad výběrem nástroje trochu přemýšlet.

Aby pro vás tato metoda fungovala a nezvrhla se pouze v testování dalších a dalších naleštěných nástrojů, je potřeba si brát ponaučení. A otázky jsou pořád stejné – v poslední části článku se k nim dostanu.

Extrém 2: Důsledné ověření potřeb

Posuňme se teď k druhé straně škály, k extrému, který stojí na důsledném ověření potřeb. Co konkrétně to obnáší? Ideální postup by vypadal takhle:

• Pobavím se s klíčovými stakeholdery o tom, co má vůbec být cílem změny nástroje a podle čeho budeme hodnotit úspěch.
• Navrhnu předpokládaný postup, než bychom bezhlavě jeli od začátku do konce. Cestou se totiž leccos naučíte a možná bude třeba cestu změnit.
• Zkoumám aktuální způsoby práce a potřeby týmu, který bude s vybraným nástrojem pracovat. Někdy je prostor na stručný dotazník, jindy je fajn udělat sérii rozhovorů nebo dokonce výzkumnou diskuzi v Nautie. V této fázi je prostor na zúžení seznamu vhodných nástrojů.
• Navrhujeme s pracovním týmem řešení. Např. vezmeme vybrané nástroje, vytvoříme v nich pilotní projekty, pobavíme se o tom, jak by se s nástrojem mohlo pracovat.
• Zhodnotíme práci v nich, zhodnotíme negativa a ty zase ověříme u lidí.
• Na základě toho se finálně rozhodneme a naplánujeme implementaci.

Přijde vám to složité? Ano, je – bavíme se totiž o extrému a extrém je správný málokdy. Samozřejmě, čím více poznáte potřeby vašeho týmu, tím lépe. Ale trvá to déle. Hloubku poznání je potřeba přizpůsobit velikosti týmu. Nebo velikosti firmy, úsilí, které chcete výběru věnovat, kapacit a nástrojů. A když vám nebudou kapacity stačit, pozvete si někoho zvenku. Ideální řešení pro firmu o deseti lidech bude prostě jiné než řešení pro 25 nebo 50 lidí.

Teď se hodí malá rekapitulace: Popsali jsme problémy, které souvisí s výběrem nástroje pro řízení práce: problém definice, samozvaných odborníků a deklarovaných vs. opravdových potřeb. A navrhl jsem řešení ve formě škály, jejíž dva extrémy jsem popsal. Zbývá poslední část článku – nejčastější otázky, které potřebujete zodpovědět, abyste mohli dobře poznat své potřeby a nastavit si správná rozhodovací kritéria.

Část třetí: Kritéria pro rozhodování

Abyste se dostali ke kritériím, podle kterých budete posuzovat vhodnost konkrétního nástroje, potřebujete poznat své potřeby. A k tomu slouží následující otázky. Tento přehled vznikl postupně během mých konzultací a školení a určitě není kompletní. Ale pomůže vám se odrazit.

1 – Typ práce

Odpovídá nástroj typu práce v naší firmě? Hledáme obecný nebo specializovaný nástroj?

Většinou zjednodušeně rozlišuji mezi prací, která má formu projektu (jednorázově od začátku do konce), procesu (dokola se opakující práce) nebo má práce povahu dílčích nezařazených úkolů. Kombinace těchto tří věcí se objevuje ve většině firem, se kterými pracuji. Poměr se samozřejmě může lišit.

U „obecných” (tzv. general-purpose) nástrojů na řízení práce platí, že většinu práce zvládnete odřídit v jakémkoliv nástroji. Když ale jako firma spadáte do oboru, který s sebou nese specifické řízení práce (opravdové projektové řízení, agilní vývoj, …), možná potřebujete specializovaný nástroj. Sami používáme téměř na všechno Asanu, jen třeba na vývoj výzkumného nástroje Nautie používáme Gitlab a jako CRM Pipedrive.

Budete nástroj využívat na každodenní řízení práce?

Někdy je nástroj jen doplněk. Pokud se budou členové týmu ve firmě, kde školím, připojovat do Asany třeba jen jednou týdně, skoro vždy rozmlouvám placenou verzi Asany.

2 – Prostředí okolo nástrojů (toolstack)

Hledáme jeden nástroj na vše, nebo nám nevadí víc nástrojů?

Věřte nevěřte, existují lidi, kteří si neujíždí na tom, že používají patnáct nástrojů. A já je chápu. Jeden nástroj může být levnější, přehlednější, ale třeba nebude tak praktický. Typický příklad je CRM – můžete ho mít v Excelu, Airtablu, Notionu nebo využívat specializovaný Pipedrive.

Jenže když se rozhodnete pro Pipedrive, budete mít dva systémy na úkoly (Pipedrive má Acitivity, což jsou úkoly). My to řešíme tím, že je máme přes Integromat propojené. Chcete to tak mít?

Jaké další nástroje využíváme? Zapadne vybraný nástroj mezi ostatní?

Rozhodnutí se neděje ve vzduchoprázdnu a vždy musíte zvážit, jaké další nástroje používat a zda je (reálně) potřeba je integrovat. Jen pro demonstraci – používáte G Suite, nebo spíš Office365? Pokud Office365, pak možná oceníte integraci dalších nástrojů v balíku, ať už je to Planner nebo Teams. Ale přiznám se, že mě osobně nenapadá jiný důvod, proč bych Planner nebo Teams zvažoval.

V této otázce je také potřeba hledat překryvy. Pokud se některé nástroje budou překrývat, bude to znamenat, že si budeme muset ve firmě říct, jak se co využívá.

Vyžadujete nějakou zásadní integraci?

Dnes je běžné, že se nástroje integrují navzájem. Je ale potřeba rozlišovat, zda jde o integrace nativní, nebo přes služby jako Integromat nebo Zapier. Nativní integrace jdou většinou do hloubky, ty druhé využívají veřejné API. Na veřejné API se můžete spolehnout, ale už to vyžaduje, že vám aplikace někdo propojí a bude spravovat. Nativní integrace je bez práce.

3 – Zvyklosti v týmu

Preferujete spíše synchronní nebo asynchronní typ komunikace?

Rozdíl je jednoduchý – někde si lidé píší přes chat, telefonují si a mají hodně schůzek. Osobně si nemyslím, že je to správné, ale opět můžete nesouhlasit. Jinde si lidé raději napíší třeba přes Asanu, jednou týdně sepíšou status svých projektů, a schází se spíš ve chvíli, kdy je třeba vyřešit něco složitého nebo něco vytvářet. Tahle otázka je často rozcestníkem mezi využíváním Slacku a Teams a třeba Asanou, Basecampu nebo Twistem.

Potřebujete mít ve firmě jasně danou zodpovědnost?

Stačí vám, když zadáte práci ústně nebo formou zprávy, aniž byste měli možnost to v budoucnu dohledat? Vyhovuje vám, když zadáte jeden úkol více lidem (neplést se stejný úkol více lidem), nebo raději striktně přiřadíte jednoho plnitele, i když na úkolu bude pracovat více lidí?

Potřebujete omezovat, co kdo může…?

Tady budu konkrétní – některým firmám na Asaně vadí, že můžu smazat úkol, aniž by se o tom někdo dozvěděl. Stejně to má i mnoho dalších nástrojů. Jak pak vedoucí dokáže, že úkol zadal podřízenému, který tvrdí opak – a přitom ho jen smazal? Chápu, že jsou tyhle obavy reálné, ale myslím, že řešením není nástroj. Takový problém je třeba řešit jinde a jinak.

Jakým jazykem se u vás ve firmě komunikuje? Umí lidé anglicky?

Pokud se u vás většina lidí dorozumí pouze česky a angličtiny se třeba i bojí, je čeština jako jazyk nástroje zásadní kritérium.

4 – Náklady na nástroj

Jaký obchodní model je pro vás vhodný?

Některé nástroje jsou placené za uživatele, jiné za organizaci. Dám příklad (možná ne úplně aktuální, ale pro demonstraci stačí). Asana byla levnější než Basecamp, pokud jste měli do 20 uživatelů. Pak už začala být Asana dražší. Často záleží, jak rychle rostete, kolik máte externistů, jak intenzivně tito externisté pracují… My využíváme několik stejných externistů nárazově a hodí se nám, když mají účet, kam se mohou po čtvrt roku nečinnosti vrátit, aniž bychom my museli řešit navyšování tarifu. Proto např. v Makevisionu využíváme pro trackování času Clockify a ne Toggl.

Dokážete odhadnout, kolik vám může nástroj ušetřit práce?

Častým problémem je vysoká nominální cena za roční provoz nástroje. U Asany to klidně může být i 30 000 Kč za rok. Je to moc, nebo málo? Pokud nedokážete odhadnout přínos a úsporu nákladů, půjdete spíše po nižší nominální ceně. Pokud si ale vyberete méně vhodný nástroj, celková úspora může být minimální.

5 – Funkce, které nezbytně potřebujete?

Není to náhoda, že funkce řeším jako poslední. Pokud si ještě pamatujete třetí problém úvodní části – propast mezi deklarovanými a opravdovými potřebami, chápete proč. Neodvážil bych si tvrdit, že funkce nejsou důležité. Ale musíte velmi dobře vědět, jakou potřebu by měla funkce plnit a jestli tu potřebu neplní nástroj jinak.

Tady je seznam nejčastějších funkcí, na které se lidé ptají:

• Wiki
• Měření času stráveného s úkoly
• Tvorba ganntova diagramu a nastavení návaznosti úkolů
• Posílání zpráv
• Využívání šablon projektů
• Využívání šablon checklistů
• Standardizované zadávání práce přes formulář
• Možnost nastavit počáteční datum
• Přidávat k úkolům dodatečné informace (vlastní pole)
• Importovat a exportovat projekty
• Sdílet informace veřejně
• Řešit fakturaci

6 – Jak se vám nástroj líbí? Jak se vám s ním pracuje?

Možná se budete divit, ale na konci článku o tom, jak si systematicky vybrat nástroj na řízení práce, je tak subjektivní věc jako dojem z nástroje. Výše jsem psal, že většinu práce odřídíte v jakémkoliv nástroji. A za tím si stojím. Často ale máte z nástrojů různý feeling. Pro někoho může být nekomfortní, že Asana všechny informace rovnou ukládá, aniž byte je museli potvrzovat. Mně třeba zase nevyhovuje, když musím na zadání úkolu kliknout desetkrát, jako třeba v Teamworku. Někdo potřebuje super mobilní appku, někomu je to jedno. S každým nástrojem se vám musí dobře pracovat a ten pocit je toho součástí.

Závěr – zhodnoťte si, jestli je pro vás Asana vhodná

Teď byste měli mít dostatek podnětů pro to, abyste si dokázali nastavit kritéria, podle kterých se budete rozhodovat. A právě na to rozhodnutí jsem se chtěl v článku zaměřit. Je to totiž téma, které řeším až příliš často. A věřím, že můj článek ušetří nějaký čas vám i mně.

Tento článek čtou určitě i firmy, které zvažují Asanu. Pokud patříte mezi ně, můžete si sami zhodnotit, zda je pro vás Asana vhodná. Vytvořil jsem na to speciální dotazník, který zahrnuje většinu důležitých otázek z článku a vyloženě směřuje k odlišnostem, které Asana přináší. A dám ruku do ohně za to, že je vůči Asaně objektivní. Více informací najdete na stránce k dotazníku.

P.S.: Tento článek plánuji i dále rozvíjet. Pokud vás napadne cokoliv, co by stálo za to přidat, zpřesnit nebo vyjasnit, budu rád za feedback (ať už mi ho napíšete do komentářů, nebo pošlete e-mailem na honza@honzapav.cz).