Ahoj všem, jmenuji se Konstantin Kuzněcov, jsem generálním ředitelem a zakladatelem společnosti RocketSales. V oblasti IT se poměrně často setkáváme s příběhem, kdy vývojové oddělení žije ve své vlastní realitě. V této realitě jsou na každém pracovním stole zvlhčovače vzduchu, spousta gadgetů a čističů monitorů a klávesnic a pravděpodobně také vlastní systém správy úkolů a projektů.
Co na tom je?
Možná, pro někoho – nic. Ale my jsme se setkali s problémem. Zabýváme se budováním a automatizací prodejních systémů, zavádíme CRM, vytváříme cloudovou infrastrukturu pro podnikání. Do klientských projektů kromě vývojových a výrobních oddělení často zahrnujeme marketingové specialisty, prodejce, účetní a další zaměstnance. A začali jsme přemýšlet, jak efektivně organizovat proces řízení projektů.
Pokud je proces vývoje a výroby organizován v platformě typu Jira nebo GitLab, pak nikdo kromě vývoje nechápe, co se tam děje.. Abychom zapojili externího zaměstnance do projektu, musíme se s ním setkat, vysvětlit kontext, někde zapsat úkol, poté kontrolovat míru připravenosti v pracovních chatech, přes chat obdržet výsledek a zapsat do Jira. A tak pořád dokola.
Vývoj je oddělen od ostatních oddělení společnosti, nevědí, jak nás zapojit, a my nevíme, zda je naše účast potřebná.
Před dvěma lety jsme objevili platformu Asana. V tomto materiálu chci povědět, jak jsme organizovali proces řízení vývoje a výroby, abychom:
- celá společnost pracovala v jedné ekosystému,
- všem stačil funkčnost,
- bylo možné ocenit náklady každého projektu v hodinách a penězích,
- práce se zákazníky byla dlouhodobá: nikoli v rámci jednoho úkolu, ale v rámci celého projektu s permanentním backlogem nápadů.
Trochu o seznámení s Asana
Na hledání pohodlného softwaru pro řízení projektů jsem strávil 10 let. Trello, Jira, Planfix, Megaplan, Bitrix24 a desítky dalších task-trackerů neprošly testem na odolnost. Pak jsem našel Asanu. A všechno zapadlo na místo.
Z našeho pohledu je to nejlepší a nejrychleji se rozvíjející platforma pro správu úkolů a projektů. Dnes je Asana celosvětovým lídrem v popularitě a spokojenosti uživatelů. To dokazuje graf hodnocení g2.
Jsme fanoušci Asany, dokonce jsme absolvovali certifikaci, abychom ji mohli implementovat pro naše klienty.
Stručně popíšu proces od prodeje po realizaci projektu.
Jelikož prodáváme IT služby, naše prodejní trychtýře jsou poměrně dlouhé a blíže ke konci přecházejí do výrobního oddělení a někdy do oddělení vývoje.
Obchodní oddělení provádí standardní úkony: audit, schválení nabídek, podepsání smlouvy a předání zakázky do výroby. Výroba nemusí smlouvu přijmout: musí obsahovat rozpočet, datum předání k výrobě a kalkulovanou časovou náročnost na realizaci projektu.
Díky propojení amoCRM + Asana při předávání zakázky mezi obchodním a výrobním oddělením práce nikde nepřestává. Modrou barvou je označena zodpovědnost obchodního oddělení, oranžovou – výrobního oddělení, růžovou – oddělení vývoje.
Je důležité, že oddělení vývoje se na rozdíl od projektového oddělení neúčastní každého projektu. Někdy nastavení systému nevyžaduje žádná individuální řešení.
Takže, když vedoucí přijal projekt k výrobě, obchodní manažer jedním kliknutím přechází do Asany (screenshot). Z amoCRM se projekt automaticky vytvoří v Asaně.
Úkol (task) s mapou projektu a obchodními nabídkami se automaticky vytváří na společné desce projektů klientů. Zde jsou zobrazeni všichni klienti, kteří jsou právě ve výrobě. Zde je přidělen odpovědný manažer, nastavují se termíny a vybírá se typ práce a mění se stavy úkolů.
Manažer může spustit v úkolu libovolný z navrhovaných automatických obchodních procesů:
- Najít/vytvořit projekt klienta + Připojit k němu úkol
- Vyplnit úkol informací o zakázce
- Vytvořit zakázku z aktuálního úkolu
Projekt se vyplní všemi údaji uvedenými v amoCRM. V závislosti na typu služeb se ihned vytváří sada podúkolů pro realizaci aktuálních bloků práce. Projektovému manažerovi zbývá úkoly dekomponovat, přidělit odpovědné osoby a termíny.
Tato deska pomáhá přijímat nové projekty do práce. Ale sledování aktuálních stavů a detekce projektů v rizikové zóně na ní je nepraktické.
Jak skupinujeme úkoly a projekty klientů
Z obecné desky všech projektů manažer přidává projekt ještě na 3 desky:
- osobní deska klienta;
- portfolio aktivních klientů;
- portfolio manažera.
Pojďme si ujasnit, proč nám každá z těchto entit slouží.
Na screenshotu vidíte osobní tabuli klienta.
Proč tato tabule?
Dříve jsme mysleli úkoly. Udělal jsem úkol, šel dělat další. Dopadlo to tak, že jsme dělali pro klienta přesně ten objem práce, který požadoval. Ale chtěli jsme budovat dlouhodobé vztahy, a proto jsme přešli od práce s úkoly k práci s klienty.
Určitě zaznamenáváme všechny nápady na úpravy pro klienta. I když je to myšlenka, kterou klient jen tak nadhodil, zaznamenáme to a dořešíme. Takto se formuje backlog úkolů, práce s klientem nekončí.
Co je na této tabuli?
Naše Asana je propojena s několika službami:
- CRM systém (pro interakci s obchodním oddělením),
- TimeDoctor (pro sledování času),
- ERP systém (pro agregaci všech dat v jednom rozhraní).
V Asaně jsme vytvořili panel rychlé kontroly zdrojů. Najedete na blok nad úkolem a vidíte, kdo a kolik času pracoval na úkolu, jakou prémii si vydělal.
Práce výrobního oddělení je hodnocena podle hodin, takže pro nás bylo důležité přísně sledovat, kolik času každý zaměstnanec věnoval řešení úkolů klienta.
Jaké výhody přináší používání tabule?
V ERP systému vidíme Zprávu o projektech. Stav obchodu, účastníci projektu, rozpočet na projekt, počet odpracovaných hodin a termíny.
Můžeme předpovědět náklady na podobné projekty vývoje, počítání KPI se stává naprosto průhledným a nezůstává místo pro iluze, že vývoj zabere jen pár hodin. V případě potřeby máme vždy rozhraní, které můžeme klientovi ukázat pro reportování.
Portfolia Asana
Tato funkčnost je v Asaně k dispozici už dlouho. Ale hned jsme ji neocenili. Nejdřív jsme prostě sestavili do portfolií všechny projekty našich manažerů. Ukázalo se, že během své práce ve společnosti Denis Kiseleva pracoval s 61 klientem.
Vědět to je fajn, ale nestačí to k ospravedlnění času stráveného na shromáždění. A my jsme na portfolia zapomněli. Všechno se změnilo, když jsme projekt v Asaně přiřadili k jedné dohodě v CRM systému.
Dříve se vedoucí podepisoval na všech projektech a dostával oznámení o všech změnách v Inboxu (kanál oznámení). Každá aktualizace stavu, nový komentář se zobrazovaly v kanálu, počínaje nejnovějšími. V pondělí se vedoucí posadil a úkoly z inboxu plnil postupně. O prioritách se nemluvilo, až se k důležitým úkolům někdy nedostaly ruce.
Nyní existuje portfolio zaměstnance a portfolio projektového oddělení. V prvním manažer spravuje své projekty, druhé dává vedoucímu kontrolní funkci nad aktuálním zatížením všech zaměstnanců.
Portfolio projektového oddělení
Na screenshotu vidíte projekty seřazené podle zaměstnanců.
Jednou týdně projektový manažer aktualizuje stav každého projektu. Píše, co bylo uděláno za minulý týden a co je plánováno na následující. Stanoví jednu ze tří nálepek: pod kontrolou, v rizikové zóně, jsou problémy.
Vedoucí může rychle zhodnotit:
- aktuální objem klientů v projektovém oddělení,
- počet projektů, na kterých pracuje každý manažer,
- počet opožděných úkolů k projektům,
- přítomnost problémů a potřebu zapojit se do projektů,
- termíny projektů, vynaložený čas, fáze v procesu a prioritizace projektu.
Portfolia nám také pomáhají sestavovat zprávy. Po aktualizaci stavu projektu je zpráva o vykonané a plánované práci automaticky odeslána do chatu se zákazníkem.
Portfolio zaměstnance
Vlastní portfolio má dokonce i vedoucí projektového oddělení. Pokud se, fuj-fuj-fuj, vzdá svých pravomocí, nový člověk uvidí všechny projekty, které má sledovat.
Lineární zaměstnanci také ocenili pohodlí plánování zátěže v portfoliu. Na kartě "Zátěž" Asana analyzuje objem úkolů s ohledem na termíny a varuje, pokud si zaměstnanec naplánoval neúnosný objem úkolů. Termíny a detaily lze měnit, aniž byste opustili tuto kartu.
Řešení chyb a vlastní vývoj
Za vývoj máme samostatný tým. Ten v rámci obchodního procesu přijímá úkoly dvou typů:
- chyba,
- nový vývoj.
Chyby kontroluje, hodnotí jejich kritičnost a předává je k řešení technické podpoře.
Úkoly pro vývoj přicházejí buď z backlogu interních produktů společnosti, nebo od projektového manažera na základě příslušného požadavku od klienta.
Proces vývoje vypadá celkově takto.
Úkoly se dostávají na vývojovou desku v Asaně. Tady je.
Předkladatel úkolu vybírá typ „Bug“ nebo „Funkce“, stanoví kritičnost, uvádí zákazníka a interní oddělení společnosti, která se týká úkolu. Jakmile úkol splní všechny požadavky interního předpisu, předkladatel stiskne ikonu blesku na horním panelu nad úkolem a spustí automatický obchodní proces „Ocenit ve vývoji“.
Vedoucí vývoje dostává oznámení o novém úkolu k ocenění, samotný úkol se během hodnocení přesune na samostatnou desku se stejným názvem.
Po ocenění vedoucí přesune úkol do sprintu odpovídajícího měsíci plánovaného dokončení. Úkoly se vždy nacházejí na několika deskách současně:
- na osobní desce projektového manažera,
- na desce technické podpory,
- na desce vývoje.
Všichni účastníci a kontrolující pracovníci úkolu vidí průběh plnění, dostávají oznámení a vedou diskuzi přímo v komentářích k úkolu. Když je úkol splněn - projektový manažer nebo zodpovědný pracovník technické podpory si jej „vezmou“ na svou stranu, aby pokračovali v práci na projektu.
Co se stalo, když jsme vrátili oddělení vývoje a výroby do společného prostředí s týmem?
Za prvé, klientske projekty se staly dlouhodobějšími. Díky neustále doplňovanému backlogu vzrostla průměrná částka.
Za druhé, kvalita projektů se výrazně zlepšila, protože oddělení vývoje mohlo kdykoli položit otázku marketingu, prodeji, účetnictví atd. Získali jsme možnost včas zapojit potřebné kompetence týmu a nabízet řešení zcela jiné úrovně.
Za třetí, jak zaměstnanci, tak vedoucí pracovníci a klienti získali plnou transparentnost v plánovaných i splněných úkolech. Naučili jsme se ŘÍDIT projekty, uvědomili jsme si, že je to zcela technický proces, ze kterého lze téměř úplně vyloučit lidský faktor.
Za čtvrté, Tým se stal soudržnější. Dříve zaměstnanci málo chápali, čím se zabývají mytické oddělení vývoje a výroby.
Nyní, když vidí proces vývoje a technického nastavení systémů:
- prodejní oddělení v něm nachází nápady a inspiraci, jak prodávat,
- marketeři pravidelně berou užitečný obsah pro příspěvky, články, pozicování a reklamní texty,
- vedoucí analyzují potřeby a chování zákazníků, upravují strategii.
Vznikla win-win-win transformace, ve které vyhráli jak my, tak zákazníci a naši partneři. Budu rád, pokud se podělíte o svůj názor v komentářích: bylo něco užitečného v mém článku a jaké metody řízení projektů používáte při vývoji!
Zdroj: habr.com
