Pozdravljeni vsi, moje ime je Konstantin Kuznetsov, sem izvršni direktor in ustanovitelj podjetja RocketSales. Na IT področju je precej pogosta zgodba, ko razvojni oddelek živi v svojem vesolju. V tem vesolju so na vsakem namizju vlažilci zraka, kopica pripomočkov in čistil za monitorje in tipkovnice ter najverjetneje svoj sistem za vodenje nalog in projektov.
Kaj je tako hudo?
Morda za nekatere ni nič. Vendar smo naleteli na težavo. Gradimo in avtomatiziramo prodajne sisteme, implementiramo CRM in ustvarjamo infrastrukturo v oblaku za poslovanje. Poleg razvojnih in proizvodnih oddelkov so v naročnikovih projektih pogosto vključeni tržniki, prodajalci, računovodje in drugi zaposleni. In začeli smo razmišljati, kako organizirati učinkovit proces vodenja projektov.
Če je razvojni in proizvodni proces organiziran v platformi, kot sta Jira ali GitLab, potem nihče razen razvoja ne razume, kaj je kaj. Če želite v projekt vključiti zunanjega sodelavca, se morate z njim srečati, razložiti kontekst, nalogo nekje posneti, nato spremljati stopnjo pripravljenosti v delovnih klepetih, preko klepeta pridobiti rezultat in ga vnesti v Jira. In tako vsakič.
Razvoj je odrezan od drugih oddelkov podjetja, ne znajo nas vključiti, mi pa ne vemo, ali potrebujejo naše sodelovanje.
Pred nekaj leti smo odkrili platformo Asana. V tem gradivu vam želim povedati, kako smo organizirali proces upravljanja razvoja in proizvodnje, da bi:
- celotno podjetje je delovalo v enotnem ekosistemu,
- vsi so imeli dovolj funkcionalnosti,
- je bilo mogoče oceniti stroške vsakega projekta v urah in denarju,
- delo z naročniki je bilo dolgoročno: ne v okviru ene naloge, ampak v okviru celotnega projekta s stalnim zaostankom idej.
Malo o spoznavanju Asane
10 let sem iskal priročno programsko opremo za vodenje projektov. Trello, Jira, Planfix, Megaplan, Bitrix24 in na desetine drugih sledilnikov opravil niso prestali testa trdnosti. Potem sem našel Asano. In vse se je izšlo.
Po našem mnenju je to najboljša in najhitreje rastoča platforma za vodenje nalog in projektov. Danes je Asana vodilna v svetu po priljubljenosti in zadovoljstvu uporabnikov. To dokazuje lestvica ocen g2.
Smo ljubitelji Asane, dobili smo celo certifikat, da jo lahko izvajamo za naše stranke.
Na kratko bom opisal potek od prodaje do izvedbe projekta
Ker prodajamo IT storitve, je naš tok precej dolg in proti koncu zaide v proizvodnjo in včasih tudi v razvojni oddelek.
Prodajni oddelek izvaja standardne manipulacije: revizijo, odobritev CP, podpis pogodbe, prenos transakcije v proizvodnjo. Produkcija ne sme sprejeti pogodbe: v njej mora biti naveden predračun, datum prenosa v proizvodnjo in predviden časovni fond za izvedbo projekta.
Zahvaljujoč kombinaciji amoCRM + Asana pri prenosu transakcije iz prodajnega oddelka v proizvodnjo in nazaj delo ni nikjer prekinjeno. Modra označuje področje odgovornosti prodajnega oddelka, oranžna označuje proizvodni oddelek, roza označuje razvojni oddelek.
Pomembno je, da razvojni oddelek za razliko od oddelka za oblikovanje ni vključen v vsak projekt. Včasih nastavitev sistema ne zahteva prilagojenih rešitev.
Torej, ko je vodja sprejel projekt v proizvodnjo, gre vodja prodaje v Asano v 1 kliku (posnetek zaslona). Iz amoCRM se projekt samodejno ustvari v Asani.
Naloga (naloga) z načrtom projekta in komercialnimi predlogi se samodejno ustvari na skupni projektni plošči stranke. Tukaj so prikazani vsi odjemalci, ki so trenutno v proizvodnji. Tu se določi odgovorni vodja, določijo roki, izbere vrsta dela in spremenijo statusi nalog.
Upravitelj lahko zažene katerega koli od predlaganih samodejnih poslovnih procesov v opravilu:
- Poiščite/ustvarite odjemalski projekt + tam priložite nalogo
- Izpolnite nalogo s podatki o transakciji
- Ustvarite dogovor iz trenutne naloge
Projekt je napolnjen z vsemi podatki, navedenimi v amoCRM. Odvisno od vrste storitve se takoj ustvari nabor podnalog za izvajanje dejanskih blokov dela. Vodja projekta preostane, da podrobno razčleni naloge, dodeli odgovornosti in roke.
Ta tabla pomaga pri sprejemanju novih projektov. Toda spremljanje trenutnih statusov in prisotnosti ogroženih projektov na njem je neprijetno.
Kako združujemo naloge in projekte strank
Iz splošne table vseh projektov upravitelj doda projekt še na 3 table:
- osebna tabla stranke;
- portfelj aktivnih strank;
- upraviteljev portfelj.
Ugotovimo, zakaj potrebujemo vsako od entitet.
Na posnetku zaslona, ki ga vidite strankina osebna tabla.
Zakaj ta tabla?
Prej smo razmišljali v okviru nalog. Nalogo sem opravil in šel delat drugo. Izkazalo se je, da smo za naročnika opravili točno toliko dela, kot ga je zahteval. A želeli smo graditi dolgoročne odnose, zato smo se od dela z nalogami preusmerili k delu s strankami.
Za stranko poskrbimo, da zapišemo vse ideje za izboljšave. Tudi če gre za misel, ki jo stranka pomotoma vrže v zrak, jo popravimo in dodelamo. Tako nastanejo zaostanki nalog, delo s stranko se ne konča.
Kaj je na tej tabli?
Naša Asana je povezana z več storitvami:
- CRM sistem (za interakcijo s prodajnim oddelkom),
- TimeDoctor (za merjenje časa),
- ERP sistem (za združevanje vseh podatkov v enem vmesniku).
V Asani smo predstavili hitro nadzorno ploščo virov. Pokažete na ploščo nad nalogo in vidite, kdo je delal na nalogi in koliko časa ter kakšen bonus si je prislužil.
Delo proizvodnega oddelka je ocenjeno na uro, zato je bilo za nas pomembno, da strogo spremljamo, koliko časa vsak zaposleni porabi za reševanje težav strank.
Kakšne so prednosti uporabe deske?
Kot rezultat, v sistemu ERP vidimo Poročilo o projektu. Status transakcije, udeleženci projekta, proračun projekta, število opravljenih ur in roki.
Predvidimo lahko stroške podobnih razvojnih projektov, izračuni KPI postanejo popolnoma pregledni in ni prostora za iluzije, da razvoj traja le nekaj ur. Po potrebi imamo vedno na voljo vmesnik, ki ga lahko stranki pokažemo za poročanje.
Aktovke Asana
Ta funkcionalnost je v Asani implementirana že dolgo časa. Vendar tega nismo takoj cenili. Sprva smo preprosto zbrali vse projekte naših menedžerjev v portfelje. Izkazalo se je, da je Denis Kiselev v času svojega dela v podjetju delal z 61 strankami.
Lepo je vedeti, vendar ne dovolj, da bi upravičili čas, porabljen za zbiranje. In zadeli smo na aktovkah. Vse se je spremenilo, ko smo projekt v Asani enačili z eno transakcijo v sistemu CRM.
Prej se je upravitelj naročal na vse projekte in prejemal obvestila o vseh spremembah v Inbox (notification feed). Vsaka posodobitev stanja in nov komentar sta bila prikazana v viru, začenši z najnovejšim. V ponedeljek se je upravitelj usedel in zaporedno opravil naloge iz nabiralnika. Ni bilo govora o prioritetah in včasih pomembne naloge niso bile dosežene.
Zdaj obstajata portfelj zaposlenih in portfelj projektnega oddelka. V prvem vodja vodi svoje projekte, v drugem daje vodji nadzor nad trenutno obremenjenostjo vseh zaposlenih.
Portfelj oddelka za oblikovanje
Na posnetku zaslona si lahko ogledate projekte, razvrščene po zaposlenih.
Enkrat tedensko vodja projekta posodobi status posameznega projekta. Piše, kaj je bilo narejeno prejšnji teden in kaj je načrtovano za naslednji teden. Nastavi eno od treh oznak: pod nadzorom, v nevarnosti, obstajajo težave.
Vodja lahko hitro oceni:
- trenutni obseg strank v oddelku za oblikovanje,
- število projektov v delu za vsakega vodjo,
- število zamudnih nalog na projektih,
- prisotnost težav in potreba po vključevanju v projekte,
- projektni roki, porabljeni čas, stopnja lijaka in prioriteta projekta.
Pri poročanju so nam v pomoč tudi portfelji. Po posodobitvi statusa projekta se samodejno pošlje poročilo o opravljenem in načrtovanem delu v klepet stranke.
Portfelj zaposlenega
Tudi vodja oddelka za oblikovanje ima svoj portfelj. Če, pah-pah-pah, odstrani svojo oblast, bo nova oseba videla vse projekte pod njegovim nadzorom, ki jih mora še naprej spremljati.
Zaposleni v liniji so cenili tudi priročnost načrtovanja obremenitve v portfelju. V zavihku »Obremenitev« Asana analizira obseg nalog glede na roke in opozori, če je zaposleni načrtoval prevelik obseg nalog. Spremenite lahko roke in prilagodite podrobnosti, ne da bi zapustili ta zavihek.
Odpravljanje napak in razvoj po meri
Imamo ločeno ekipo, odgovorno za razvoj. Kot del poslovnega procesa prejme naloge dveh vrst:
- hrošč,
- nov razvoj.
Služba za tehnično podporo preveri hrošče, oceni kritičnost in jih prenese v delo.
Razvojne naloge prihajajo bodisi iz internega proizvodnega zaostanka podjetja ali od vodje projekta, če obstaja ustrezna zahteva naročnika.
Razvojni proces na splošno izgleda takole.
Naloge padajo na razvojno tablo v Asani. Tukaj je.
Vodja naloge izbere vrsto »Hrošč« ali »Funkcija«, nastavi stopnjo kritičnosti, navede stranko in notranje oddelke podjetja, na katere naloga vpliva. Ko nalogo izpolnjuje vse zahteve internega pravilnika, direktor klikne na ikono strele v zgornji vrstici nad nalogo in zažene samodejni poslovni proces »Oceni v razvoju«.
Vodja razvojnega oddelka prejme obvestilo o novi nalogi za ocenjevanje, sama naloga pa se za čas ocenjevanja premakne na ločeno istoimensko tablo.
Po oceni vodja premakne nalogo v sprint, ki ustreza mesecu načrtovanega zaključka. Naloge so vedno na več ploščah hkrati:
- na osebni tabli vodje projekta,
- na odboru za tehnično podporo,
- na razvojni plošči.
Vsi udeleženci in zaposleni, ki spremljajo nalogo, vidijo potek naloge, prejemajo obvestila in vodijo razprave neposredno v komentarjih k nalogi. Ko je naloga opravljena, jo vodja projekta ali odgovorni strokovnjak za tehnično podporo »vzame« na svojo stran, da nadaljuje delo na projektu.
Kaj se je zgodilo, ko smo razvojni in proizvodni oddelek vrnili v enotno okolje z ekipo?
Prvič, projekti strank so postali dolgoročnejši. Zaradi nenehno polnjenega zaostanka se je povprečni račun povečal.
Drugič, kakovost projektov se je močno izboljšala, saj je razvojni oddelek lahko kadarkoli zastavil vprašanja marketingu, prodaji, računovodstvu itd. Uspeli smo pravočasno povezati potrebne kompetence ekipe in ponuditi rešitve povsem drugačne ravni.
Tretjič zaposleni, vodje in naročniki dobili popolno transparentnost načrtovanih in izvedenih nalog. Naučili smo se VODITI projekte in ugotovili, da je to povsem tehničen proces, iz katerega je mogoče skoraj popolnoma izločiti človeški dejavnik.
Četrti, ekipa je postala bolj enotna. Prej so zaposleni imeli malo pojma, kaj počnejo mitični razvojni in proizvodni oddelki.
Zdaj pa si oglejte proces razvoja in tehnične konfiguracije sistemov:
- oddelek prodaje v njem najde ideje in navdih, kako prodajati,
- tržniki redno jemljejo uporabne vsebine za objave, članke, pozicioniranje in oglasna besedila,
- menedžerji analizirajo potrebe in vedenje strank, prilagajajo strategijo.
Rezultat je bila preobrazba, v kateri so vsi zmagali, pri kateri smo imeli koristi mi, naše stranke in naši partnerji. Vesel bom, če v komentarjih delite svoje mnenje: ali je bilo v mojem članku kaj koristnega in katere metode vodenja projektov uporabljate pri razvoju!
Vir: www.habr.com