Asana, nebo Jira: snadný start versus řízení vývoje

Pro projekt, v němž spolupracuje obchod, produktový tým a externí partner, bývá vhodnější Asana. Pokud většinu práce tvoří vývojové položky, chyby a sprinty, dává větší smysl Jira. Hodnocení The Digital Project Manager popisuje právě tento rozdíl: Asanu jako nástroj pro obecnou koordinaci a Jiru jako podrobnější prostředí pro řízení vývoje.

Snazší zavedení samo o sobě nestačí, musí-li tým každý týden plánovat kapacitu sprintu a vysvětlovat, co blokuje vydání. Stejně tak vývojová struktura Jiry nemusí být výhodou pro lidi, kteří především zadávají požadavky a schvalují výstupy. Do rozhodnutí proto patří i práce potřebná k nastavení postupu, zaškolení účastníků a správě přístupů.

Stejný požadavek ukáže rozdíl už při příjmu

Představme si modelový projekt: firma připravuje novou funkci zákaznického portálu. Obchodní tým přinese požadavek, produktový tým doplní zadání, vývojáři funkci vytvoří a externí partner schválí výsledek. Jde o podmíněný příklad pro srovnání postupů, nikoli o zkušenost konkrétní firmy.

V Asaně může požadavek začít jako úkol s vlastníkem, termínem a stavem. Formulář, vlastní pole a automatizace na placeném tarifu Starter pomohou sjednotit příjem zadání od lidí, kteří nepracují s vývojovým backlogem. Produktový tým může ve stejném projektu sledovat, zda už dorazily podklady a kdo má rozhodnout o dalším předání. Pro společnou koordinaci je podstatné, že účastníci vidí srozumitelný postup bez vlastní sady vývojářských stavů.

V Jiře lze tentýž námět převést na položku backlogu, doplnit požadavky a určit prioritu pro vývoj. Tím vzniká přímá návaznost mezi zadáním a technickou prací. Cena za podrobnost se projeví při zapojení netechnických lidí: tým jim musí vysvětlit typy položek, povinná pole a význam stavů, které nastaví. Čím složitější postup zvolí, tím více správy bude potřebovat i u jednoduchého požadavku.

Sprinty a závislosti: kde se vrací podrobnější řízení

Jira má pro pravidelný vývoj připravenou strukturu, kterou by tým v univerzálním nástroji musel zčásti vybudovat sám. Scrumová šablona Atlassianu spojuje backlog, plánování sprintu, časovou osu se závislostmi a sprintové reporty. V modelovém projektu tak lze oddělit přípravu funkce od implementace a oprav chyb a průběžně sledovat, které položky se dostaly do plánovaného vydání.

Asana také umí zaznamenat závislosti mezi úkoly a ukázat je na časové ose. Pokud jde hlavně o pořadí schválení návrhu, dokončení vývoje a předání partnerovi, může to stačit. Při opakovaném plánování sprintů však tým musí určit vlastní pravidla pro připravenost práce, přesuny nedokončených položek a rozlišení chyb od nových požadavků. Nejde o nemožnost řídit vývoj v Asaně, ale o další práci při udržování stejného postupu napříč sprinty.

Závislost má v obou prostředích odlišný praktický význam. Pro koordinátora projektu může znamenat, že partner nesmí schvalovat výstup před dokončením úprav. Vývojový vedoucí potřebuje navíc vidět, která konkrétní položka blokuje další práci ve sprintu nebo vydání. Pokud se takové blokace řeší pravidelně, podrobnější evidence Jiry pomáhá vysvětlit příčinu zpoždění, nejen posunutý termín.

Reporting má odpovědět na různé otázky

Vedoucí společného projektu obvykle potřebuje vědět, komu úkol patří, zda je hotové zadání a na čem stojí schválení. Asana umožňuje držet tyto údaje spolu s termíny, závislostmi a přehledy projektu. V modelovém případě tak může být společným prostorem pro obchod, produkt i partnera; nikdo z nich nemusí převádět stav spolupráce do sprintových metrik.

Vývojový vedoucí se častěji ptá, co zbývá v backlogu, jak postupuje sprint a které chyby ovlivní vydání. Jira váže reporty právě na tuto strukturu práce. Přehled pak získává hodnotu z důsledně vedených položek: pokud lidé neaktualizují jejich stav nebo prioritu, ani podrobný report neposkytne spolehlivý obraz. Při výběru tedy záleží také na tom, zda tým dokáže potřebnou míru evidence dlouhodobě udržet.

Hosté, licence a AI mění cenu volby

Externí partner v modelovém projektu potřebuje přístup k relevantní části práce a jasně vymezená oprávnění. Starter v Asaně zahrnuje bezplatné hosty, takže pozvání partnera samo o sobě nezvyšuje počet placených členů. U Jiry je třeba cenu a rozsah přístupu posoudit podle zvoleného tarifu a nastavení projektu. Prosté srovnání ceny za jedno sedadlo proto nemusí vystihnout spolupráci s lidmi mimo firmu.

Údaje o bezplatné Asaně vyžadují pozornost. Červencové srovnání Cloudwards uvádí u plánu Personal deset uživatelů; tento údaj se liší od současné nabídky výrobce. Podle ceníku Asany je Personal určen pro dva uživatele, Starter stojí 10,99 USD za uživatele měsíčně při roční platbě a placené AI požadavky vycházejí na 0,50 USD předplaceně nebo 0,60 USD při průběžném účtování. Průběžný režim má navíc poplatek 5,99 USD za uživatele měsíčně při roční platbě.

Starter už zahrnuje omezenou kapacitu AI požadavků. U většího využití je proto potřeba rozlišit spotřebu zahrnutou v tarifu od placené spotřeby a zohlednit i způsob účtování. Předplacené balíčky platí po dobu fakturačního cyklu; u roční smlouvy se nemusí spotřebovat každý měsíc stejně. Při průběžném účtování lze nastavit měsíční strop výdajů. Pro tým, který chce AI používat ve velkém, je tato volba součástí rozpočtu, nikoli drobným doplňkem licence.

Podle přehledu tarifů Atlassianu podporuje bezplatná Jira až deset uživatelů a zahrnuje backlog i scrumové tabule; Rovo AI začíná až v placených tarifech, jejichž měsíční příděl činí 25 kreditů na uživatele ve Standardu, 70 v Premium a 150 v Enterprise. Kredit Rovo a AI požadavek Asany nejsou totožné jednotky, takže jejich počty ani cenu nelze mechanicky postavit vedle sebe. Rozpočet má vycházet z funkcí, které tým skutečně využije, a z pravidel příslušného tarifu.

Kolik práce bude stát samotné zavedení

Licence jsou jen část nákladů. U Asany musí někdo navrhnout formulář, odpovědnosti a pravidla předávání; u Jiry typy položek, stavy, oprávnění a způsob práce s backlogem. V modelovém projektu je rozdíl v tom, kolik pravidel potřebují znát lidé mimo vývoj a kolik správy vyžaduje jednotný postup uvnitř vývojového týmu. Složitější nastavení se vyplatí tehdy, když pomáhá opakovaně rozhodovat o prioritách, kapacitě a vydání.

Pokud většina účastníků žádá o práci, připomínkuje ji a schvaluje, dává přednost Asaně smysl. Jestliže projekt stojí na pravidelných sprintech, sledování chyb a návaznostech mezi vývojovými položkami, má Jira přesvědčivější základ. Smíšený tým by měl do ceny započítat také čas lidí, kteří budou postup spravovat a vysvětlovat ostatním: právě tam se může výhoda rychlého startu ztratit, nebo naopak projevit.

Přečtěte si také: