Ahoj všichni, jmenuji se Konstantin Kuznetsov, jsem CEO a zakladatel RocketSales. V IT oblasti je docela častý příběh, kdy vývojové oddělení žije ve svém vlastním vesmíru. V tomto vesmíru jsou zvlhčovače vzduchu na každém pracovním stole, spousta vychytávek a čističů pro monitory a klávesnice a s největší pravděpodobností vlastní systém řízení úkolů a projektů.
Co v tom je?
Pro někoho to možná není nic. Ale narazili jsme na problém. Stavíme a automatizujeme prodejní systémy, implementujeme CRM a vytváříme cloudovou infrastrukturu pro podnikání. Kromě vývojového a výrobního oddělení jsou mezi klientskými projekty často zastoupeni marketéři, prodejci, účetní a další zaměstnanci. A začali jsme přemýšlet o tom, jak zorganizovat efektivní proces projektového řízení.
Pokud je vývojový a výrobní proces organizován na platformě, jako je Jira nebo GitLab, pak nikdo kromě vývoje nechápe, co je co. Chcete-li do projektu zapojit zaměstnance třetí strany, musíte se s ním sejít, vysvětlit mu souvislosti, úkol někam zaznamenat, poté sledovat míru připravenosti v pracovních chatech, získat výsledek přes chat a zadat jej do Jiry. A tak pokaždé.
Vývoj je odříznut od ostatních oddělení společnosti, nevědí, jak nás zapojit, a nevíme, zda potřebují naši účast.
Před pár lety jsme objevili platformu Asana. V tomto materiálu vám chci říci, jak jsme organizovali proces řízení vývoje a výroby, abychom:
- celá společnost pracovala v jediném ekosystému,
- každý měl dostatek funkcí,
- bylo možné odhadnout náklady na každý projekt v hodinách a penězích,
- práce s klienty byla dlouhodobá: ne v rámci jednoho úkolu, ale v rámci celého projektu s neustálým hromaděním nápadů.
Něco málo o poznávání Ásany
Strávil jsem 10 let hledáním vhodného softwaru pro řízení projektů. Trello, Jira, Planfix, Megaplan, Bitrix24 a desítky dalších task trackerů neprošly testem síly. Pak jsem našel Asanu. A všechno se povedlo.
Podle našeho názoru se jedná o nejlepší a nejrychleji rostoucí platformu pro řízení úkolů a projektů. Dnes je Asana světovým lídrem v popularitě a spokojenosti uživatelů. Svědčí o tom tabulka hodnocení g2.
Jsme fanoušky Asany, dokonce jsme získali certifikaci, abychom ji mohli implementovat pro naše klienty.
Stručně popíšu proces od prodeje až po realizaci projektu
Vzhledem k tomu, že prodáváme IT služby, je náš trychtýř poměrně dlouhý a ke konci vstupuje do výrobního a někdy i vývojového oddělení.
Obchodní oddělení provádí standardní manipulace: audit, schválení CP, podpis smlouvy, převedení transakce do výroby. Výroba nemusí smlouvu přijmout: musí v ní být uveden rozpočet, datum převodu do výroby a předpokládaný časový fond pro realizaci projektu.
Díky kombinaci amoCRM + Asana se při převodu transakce z obchodního oddělení do výroby a zpět nikde nepřeruší práce. Modrá označuje oblast odpovědnosti obchodního oddělení, oranžová označuje výrobní oddělení a růžová označuje vývojové oddělení.
Důležité je, že vývojové oddělení, na rozdíl od konstrukčního, není zapojeno do každého projektu. Někdy nastavení systému nevyžaduje vlastní řešení.
Takže, když manažer přijal projekt do výroby, obchodní manažer přejde do Asany jedním kliknutím (screenshot). Z amoCRM se projekt automaticky vytvoří v Asaně.
Na společné klientské projektové desce se automaticky vytvoří úkol (úkol) s mapou projektu a komerčními návrhy. Zde jsou zobrazeni všichni klienti, kteří jsou aktuálně ve výrobě. Zde se určí odpovědný vedoucí, stanoví se termíny, vybere se druh práce a změní se stavy úkolů.
Manažer může v úloze spustit kterýkoli z navrhovaných automatických obchodních procesů:
- Najít/vytvořit klientský projekt + tam připojit úkol
- Vyplňte úkol informacemi o transakci
- Vytvořte dohodu z aktuálního úkolu
Projekt je naplněn všemi údaji uvedenými v amoCRM. V závislosti na typu služby se okamžitě vytvoří sada dílčích úkolů pro implementaci skutečných bloků práce. Projektový manažer zůstává rozkládat podrobné úkoly, přidělovat odpovědnosti a termíny.
Tato deska pomáhá při přijímání nových projektů. Sledovat aktuální stavy a přítomnost ohrožených projektů na něm je ale nepohodlné.
Jak seskupujeme úkoly a projekty klientů
Z hlavní rady všech projektů manažer přidá projekt do dalších 3 desek:
- osobní deska klienta;
- portfolio aktivních klientů;
- manažerské portfolio.
Pojďme zjistit, proč potřebujeme každou z entit.
Na snímku obrazovky vidíte osobní deska klienta.
Proč tato deska?
Dříve jsme uvažovali o úkolech. Splnil jsem úkol a šel udělat další. Ukázalo se, že jsme pro klienta udělali přesně takové množství práce, o které požádal. Chtěli jsme ale budovat dlouhodobé vztahy, a tak jsme od práce s úkoly přešli k práci s klienty.
Dbáme na to, abychom pro klienta zapsali všechny nápady na vylepšení. I když je to myšlenka náhodně vyhozená klientem do vzduchu, opravíme ji a dokončíme. Tak se tvoří nevyřízené úkoly, práce s klientem nekončí.
Co je na této desce?
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 jediném rozhraní).
Zavedli jsme rychlý ovládací panel zdrojů v Asaně. Ukážete na štítek nad úkolem a uvidíte, kdo a jak dlouho na úkolu pracoval a jaký bonus získal.
Práce výrobního oddělení se odhaduje na hodinu, proto pro nás bylo důležité přísně sledovat, kolik času každý zaměstnanec strávil řešením klientských problémů.
Jaké jsou výhody použití desky?
V důsledku toho v ERP systému vidíme Zpráva o projektu. Stav transakce, účastníci projektu, rozpočet projektu, počet odpracovaných hodin a termíny.
Dokážeme předvídat náklady podobných developerských projektů, výpočty KPI se stávají naprosto transparentními a není prostor pro iluze, že vývoj trvá jen pár hodin. V případě potřeby máme vždy k dispozici rozhraní, které můžeme klientovi ukázat pro reportování.
Aktovky Asana
Tato funkcionalita je v Asaně implementována již dlouhou dobu. Ale hned jsme to neocenili. Nejprve jsme jednoduše shromáždili všechny projekty našich manažerů do portfolií. Ukázalo se, že za dobu svého působení ve společnosti pracoval Denis Kiselev s 61 klienty.
Je skvělé to vědět, ale nestačí to na ospravedlnění času stráveného jeho sbíráním. A bodovali jsme na kufřících. Vše se změnilo, když jsme projekt v Asaně přirovnali k jedné transakci v CRM systému.
Dříve se manažer přihlásil k odběru všech projektů a dostával oznámení o všech změnách ve složce Doručená pošta (informační kanál). Každá aktualizace stavu a nový komentář byly zobrazeny ve zdroji, počínaje tím nejnovějším. V pondělí se manažer posadil a postupně plnil úkoly z doručené pošty. Nemluvilo se o prioritách a někdy nebylo nikdy dosaženo důležitých úkolů.
Nyní existuje portfolio zaměstnanců a portfolio projektového oddělení. V první řídí manažer své projekty, druhá dává manažerovi kontrolní funkcionalitu týkající se aktuálního vytížení všech zaměstnanců.
Portfolio konstrukčního oddělení
Na snímku obrazovky můžete vidět projekty seřazené podle zaměstnanců.
Jednou týdně projektový manažer aktualizuje stav každého projektu. Píše, co se dělalo minulý týden a co se plánuje na týden příští. Nastavuje jednu ze tří značek: pod kontrolou, v ohrožení, jsou problémy.
Manažer může rychle posoudit:
- aktuální objem klientů v konstrukčním oddělení,
- počet projektů v práci pro každého manažera,
- počet zpožděných úkolů na projektech,
- přítomnost problémů a potřeba zapojit se do projektů,
- termíny projektu, strávený čas, fáze trychtýře a priorita projektu.
Portfolia nám také pomáhají s reportingem. Po aktualizaci stavu projektu je automaticky odeslána zpráva o provedené a plánované práci do klientského chatu.
Portfolio zaměstnance
I vedoucí konstrukčního oddělení má své portfolio. Pokud, pah-pah-pah, odebere svou autoritu, nový člověk uvidí všechny projekty pod jeho kontrolou, které musí nadále sledovat.
Zaměstnanci linky také ocenili pohodlí plánování zátěže v portfoliu. V záložce „Načíst“ Asana analyzuje objem úkolů s ohledem na termíny a varuje, pokud zaměstnanec naplánoval nadměrné množství úkolů. Můžete změnit termíny a upravit podrobnosti, aniž byste opustili tuto kartu.
Řešení chyb a zakázkový vývoj
Máme samostatný tým zodpovědný za vývoj. Jako součást obchodního procesu přijímá úkoly dvou typů:
- Chyba,
- nový vývoj.
Chyby jsou zkontrolovány, posouzeny z hlediska kritickosti a převedeny do práce službou technické podpory.
Vývojové úkoly pocházejí buď z interního produktového backlogu společnosti, nebo od projektového manažera, pokud existuje odpovídající požadavek od klienta.
Proces vývoje obecně vypadá takto.
Úkoly padají na vývojovou desku v Asaně. Tady je.
Ředitel úkolu vybere typ „chyba“ nebo „vlastnost“, nastaví stupeň kritičnosti, označí zákazníka a interní oddělení společnosti, kterých se úkol týká. Když úkol splňuje všechny požadavky vnitřních předpisů, klikne ředitel na ikonu blesku v horní liště nad úkolem a spustí automatický obchodní proces „Vyhodnocovat ve vývoji“.
Vedoucí vývojového oddělení obdrží oznámení o novém úkolu k posouzení a samotný úkol se po dobu posuzování přesune na samostatnou stejnojmennou tabuli.
Po posouzení přesune manažer úkol do sprintu, který odpovídá měsíci plánovaného dokončení. Úkoly jsou vždy na několika deskách současně:
- v osobní radě projektového manažera,
- na tabuli technické podpory,
- na vývojové desce.
Všichni účastníci a zaměstnanci sledující úkol vidí průběh úkolu, dostávají upozornění a vedou diskuse přímo v komentářích k úkolu. Když je úkol dokončen, projektový manažer nebo odpovědný specialista technické podpory jej „vezme“ na svou stranu, aby pokračoval v práci na projektu.
Co se stalo, když jsme s týmem vrátili vývojové a výrobní oddělení zpět do jednoho prostředí?
Za prvé, klientské projekty se staly dlouhodobějšími. Vzhledem k neustále doplňovanému nahromadění se průměrný účet zvýšil.
Za druhé, kvalita projektů se výrazně zlepšila, protože vývojové oddělení mohlo kdykoli klást otázky týkající se marketingu, prodeje, účetnictví atd. Dokázali jsme včas propojit potřebné kompetence týmu a nabídnout řešení úplně jiné úrovně.
Za třetí, zaměstnanci, manažeři a klienti byli plně transparentní v plánovaných a dokončených úkolech. Naučili jsme se ŘÍDIT projekty a uvědomili jsme si, že jde o naprosto technický proces, ze kterého lze téměř úplně eliminovat lidský faktor.
Za čtvrté, tým se více sjednotil. Dříve měli zaměstnanci pramálo tušení, co bájná vývojová a výrobní oddělení dělají.
Nyní, když vidíte proces vývoje a technické konfigurace systémů:
- obchodní oddělení v něm nachází nápady a inspiraci, jak prodávat,
- marketéři pravidelně berou užitečný obsah pro příspěvky, články, pozice a reklamní texty,
- manažeři analyzují potřeby a chování zákazníků, upravují strategii.
Výsledkem byla oboustranně výhodná transformace, ze které jsme profitovali my, naši klienti a naši partneři. Budu rád, když se v komentářích podělíte o svůj názor: bylo v mém článku něco užitečného a jaké metody projektového řízení při vývoji používáte!
Zdroj: www.habr.com
