Tere kõigile, minu nimi on Konstantin Kuznetsov, olen RocketSalesi tegevjuht ja asutaja. IT-sektoris on tihti lugusid, kus arendusosakond elab oma maailmas. Selles maailmas on igal töölaual õhuniisutajad, hunnik vidinaid ja monitoride ning klaviatuuride puhastajaid ja tõenäoliselt oma ülesannete ja projektide haldamise süsteem.
Mis selles halba on?
Võib-olla mõne jaoks — mitte midagi. Kuid me sattusime probleemiga silmitsi. Meie tegeleme müügisüsteemide ehitamise ja automatiseerimisega, rakendame CRM-e, loome ettevõtluse jaoks pilveinfrastruktuuri. Klientide projektidesse kaasatakse lisaks arendus- ja tootmisosakondadele sageli turundajad, müüjad, raamatupidajad ja teised töötajad. Ja me hakkasime mõtlema, kuidas korraldada tõhusat projektijuhtimise protsessi.
Kui arendus- ja tootmisprotsess on korraldatud Jira või GitLabi tüüpi platvormis, siis ei mõista keegi peale arendajate, mis seal toimub.. Et projekti kaasata kolmanda osapoole töötaja, tuleb temaga kohtuda, selgitada konteksti, kuskil ülesanne fikseerida, siis kontrollida valmisoleku astet töörühmades, samuti saada tulemust ja sisestada see Jira-sse. Ja nii iga kord.
Arendus on teistest osakondadest eraldatud, nad ei tea, kuidas meid kaasata, ja me ei tea, kas neil on meie osalemist vaja.
Mõni aasta tagasi avastasime Asana platvormi. Selles materjalis tahan rääkida, kuidas korraldasime arenduse ja tootmise haldamise protsessi, et:
- kogu ettevõte töötaks ühtses ökosüsteemis,
- kõigile jaguks funktsiooni,
- saaksime hinnata iga projekti maksumust tundide ja rahaga,
- töötamine klientidega oli pikaajaline: mitte ühe ülesande raames, vaid kogu projekti raames pideva ideede tagavara olemasoluga.
Veidi Asanaga tutvumisest
Olen otsinud mugavat tarkvara projektijuhtimiseks 10 aastat. Trello, Jira, Planfix, Megaplan, Bitrix24 ja põhimõtteliselt kümneid teisi ülesannete jälgimisriistu ei suutnud kvaliteedis testi läbida. Siis leidsin Asana. Ja kõik klappis.
Meie arvates on see parim ja kõige kiiremini arenev platvorm ülesannete ja projektide haldamiseks. Täna on Asana maailmas populaarseim ja kasutajate rahulolu poolest juhtiv platvorm. Selle tõestuseks on g2 reitingugraafik.
Me oleme Asana fännid, oleme isegi saanud sertifikaadi, et saaksime seda oma klientidele juurutada.
Kokkuvõttes kirjeldan müügist projekti elluviimiseni.
Kuna me müüme IT-teenuseid, on meie müügitoru suhteliselt pikk ja lõpupoole jõuab see tootmisosakonda ning aeg-ajalt ka arendusosakonda.
Müügisektori standardmanevrid on: auditeerimine, pakkumise kooskõlastamine, lepingu allkirjastamine ja tehingu edastamine tootmisse. Tootmine ei pruugi lepingut vastu võtta: selles peavad kindlasti olema välja toodud eelarve, tootmise alguse kuupäev ja projekti elluviimiseks vajalik ajakalkulatsioon.
Aitäh amoCRM + Asana seosele, ei katkea tehingu edastamisel müügiosakonnast tootmisse ja tagasi. Sinisega on märgitud müügiosakonna vastutusala, oranžiga tootmisosakond, roosaga arendusosakond.
Oluline on märkida, et arendusosakond ei osale iga projektis, erinevalt projektiosakonnast. Mõnikord ei nõua süsteemi seadistamine kohandatud lahendusi.
Nii et kui juht võtab projekti tootmisse, saab müügihaldur ühe klikiga Asanasse minna (ekraanipilt). amoCRM-ist luuakse projekt automaatselt Asanas.
Ülesanne, kus on projekti kaart ja kommertspakkumised, luuakse automaatselt klientide projektide ühisele tahvlile. Siin kuvatakse kõik kliendid, kes praegu tootmises on. Siin määratakse vastutav haldur, seatakse tähtajad, valitakse töö tüüp ja muudetakse ülesannete staatuseid.
Haldur saab ülesandes käivitada ükskõik millise ettepanekutest automaatsetest äriprotsessidest:
- Leida/Luua kliendi projekt + Lisada sinna ülesanne
- Täita ülesanne tehinguga seotud teabega
- Luua tehing praegusest ülesandest
Projekt täidetakse kõikide amiCRM-is märkitud andmetega. Teenuste tüübi põhjal luuakse kohe hulk alamülesandeid aktuaalsete tööplokkide elluviimiseks. Projekti halduril jääb üle vaid dekompozitsioneerida detailseid ülesandeid, määrata vastutavad ja tähtajad.
See tahvel aitab võtta uusi projekte ette. Kuid selle abil on ebamugav kontrollida, millised projektid on aktiivsed ja millised on riskitsoonis.
Kuidas me rühmitame klientide ülesandeid ja projekte
Üldiselt laud kõikide projektide kohta lisab juht veel 3 tabelisse projekti:
- klientide isiklik laud;
- aktiivsete klientide portfell;
- juhi portfell.
Selgitame välja, miks meil igaüks neist entiteetidest vajalik on.
Kuvatud ekraanipildil näete klientide isiklikku lauda.
Miks on see laud vajalik?
Varem mõtlesime ülesannete peale. Tehtud ülesanne, läksin tegema teist. Tõdesime, et teeme kliendi jaoks täpselt nii palju tööd, kui ta palus. Kuid soovisime luua pikaajalisi suhteid, seetõttu lahkusime ülesannete töötamisest klienditööle.
Külastame kindlasti kõiki klientide täiendamisideid. Isegi kui see on mõtteviis, mis visati kliendi poolt õhku, registreerime ja viime selle lõpuni. Nii moodustame tagavara ülesandeid, töötamine kliendiga ei lõpe.
Mida sees on sellel laud?
Meie Asana on seotud mitmete teenustega:
- CRM-süsteem (müügiosakonnaga suhtlemiseks),
- TimeDoctor (aja arvestamiseks),
- ERP-süsteem (kõigi andmete kogumiseks ühes liideses).
Me oleme Asanas väljastanud kiire ressurside kontrolli paneeli. Viidatud ülesande kohal oleva kastikese peale ja näed, kes ja kui kaua on ülesande kallal töötanud, millist preemiat teenis.
Tootmisosakonna tööd hinnatakse tundide kaupa, seetõttu oli oluline täpselt jälgida, kui palju aega kulus igal töötajal kliendi ülesannete lahendamiseks.
Mida toob laua kasutamine?
Lõppkokkuvõttes näeme ERP-süsteemis Projektide aruanne. Tehingu staatus, projekti osalised, projekti eelarve, töötatud tundide arv ja tähtajad.
Saame prognoosida sarnaste projektide arendamise maksumust, KPI arvutamine muutub täiesti läbipaistvaks ja ei jää kohta illusioonidele, et arendus on vaid paar tundi. Vajadusel on meil alati liides, mida saame kliendile aruandluseks näidata.
Asana portfellid
See funktsionaalsus on Asanas juba ammu realiseeritud. Kuid me ei hinnanud seda kohe. Esmalt kogusime portfellidesse kokku kõik meie juhtide projektid. Selgus, et Denise Kiselevi tööea jooksul on ta töötanud 61 kliendiga.
Teada on lahe, aga sellest ei piisa, et õigustada kulutatud aega kogumise peale. Me loobusime portfellidest. Kõik muutus, kui me sidusime projekti Asanas kliendihalduse süsteemis oleva tehinguga.
Varem kirjutas juht alla kõigile projektidele ja sai teadet kõigist muudatustest Inboxis (teatete voos). Iga staatuseuuendus, uus kommentaar kuvatakse voos alguses kõige uuema. Esmaspäeval istus juht maha ja täitis järjestikku ülesandeid Inboxist. Prioriteetide üle ei olnud juttu, olulised ülesanded jäid tihti tähelepanuta.
Nüüd on olemas töötaja portfell ja projektiosakonna portfell. Esimeses haldab juht oma projekte, teine annab juhile ülevaate kogu meeskonna hetke koormusest.
Projektiosakonna portfell
Kuvatud ekraanipildil näete projekte, mis on sorteeritud töötajate järgi.
Kord nädalas uuendab projektijuht iga projekti staatust. Ta kirjutab, mis tehti eelmisel nädalal ja mis on plaanis järgmiseks. Üks kolmest tähistest määratakse: kontrolli all, riskitsoonis, on probleeme.
Juht saab kiiresti hinnata:
- hetke kliendikoormust projektiosakonnas,
- iga juhi töös olevate projektide arvu,
- tähtaegadest möödas olevaid ülesandeid projektides,
- probleemide esinemist ja vajadust projektidesse sekkuda,
- projektide tähtaegu, kulutatud aega, müügi etappi ja projekti prioriteeti.
Portfellid aitavad meil ka aruandeid koostada. Pärast projekti staatuse uuendamist saadetakse kliendiga vestlusesse automaatselt tehtud ja plaanitud tööde aruanne.
Töötaja portfell
Isegi projektiosakonna juhi portfell on olemas. Kui, kop-kop-kop, ta loobub oma volitustest, näeb uus inimene kõiki projekte, mis tal on jälgida.
Töötajad hindasid ka koormuse planeerimise mugavust portfellis. Vahekaardil "Koormus" analüüsib Asana ülesannete mahtu tähtsuse arvestamisel ja hoiatab, kui töötajal on plaanitud ülekoormus. Tähtaegu ja detaile saab muuta selle vahekaardi kaudu lahkumata.
Vigade lahendamine ja kohandatud arendus
Meil on eraldi tiim, mis vastutab arenduse eest. Sellesse voolavad äri protsessi raames ülesanded kahest tüübist:
- vead,
- uus arendus.
Vead kontrollib, hindab nende kriitilisust ja edastab need tehnilise toetuse osakonda.
Arendamise ülesanded tulevad kas firma sisemistest toodetest tagasiendist või projekti juhilt vastava kliendipalve puhul.
Arendamisprotsess näeb üldiselt välja selline.
Ülesanded jõuavad Asana arendustahvlile. Siin see on.
Ülesande koostaja valib tüübi “Viga” või “Funktsioon”, määrab kriitilisuse taseme, märgib tellija ning sisemised osakonnad, mida ülesanne puudutab. Kui ülesanne vastab kõigile sisereeglitele, vajutab koostaja ülesande ülaosas asuvale välguikoonile ja käivitab automaatse äri protsessi “Hinda arenduses”.
Arendusosakonna juht saab teate uue hindamise ülesande kohta, ise ülesanne liigub hindamise ajaks eraldi samanimelisele tahvlile.
Pärast hindamist liigutab juht ülesande sprindisse, mis vastab plaanitud lõpetamise kuule. Ülesanded asuvad alati mitmel tahvlil korraga:
- projekti juhi isiklikul tahvlil,
- tehnilise toe tahvlil,
- arendustahvlil.
Kõik osalejad ja ülesande jälgimisega tegelevad töötajad näevad edusamme, saavad teateid ja arutavad otse ülesande kommentaarides. Kui ülesanne on täidetud, “võtab” projektijuhi või vastutav tehnilise toe spetsialist selle enda poole, et jätkata projektiga.
Mida me saime, kui tõime arendus- ja tootmisosakonnad ühte keskkonda koos meeskonnaga?
Esiteks, kliendiprojektid on saanud pikemaajalisteks. Regulaarne tagasienda kasvu tõttu on tõusnud keskmine tellimuse väärtus.
Teiseks, projektide kvaliteet on oluliselt paranenud, kuna arendusosakond sai igal hetkel küsida turunduselt, müügilt, raamatupidamiselt jne. Saime võimaluse õigeaegselt kaasata vajalikke oskusi meeskonnast ja pakkuda täiesti teistsuguseid lahendusi.
Kolmandaks, Nii töötajad, juhid kui ka kliendid said täieliku läbipaistvuse planeeritud ja täidetud ülesannetes. Oleme õppinud projektide juhtimist, mõistes, et see on täiesti tehniline protsess, millest on võimalik peaaegu täielikult kõrvaldada inimfaktor.
Neljas, tiim on muutunud ühtsemaks. Varem ei olnud töötajad hästi teadlikud, millega tegelevad müütilised arendus- ja tootmisosakonnad.
Praegu, nähes süsteemide arendus- ja tehnilise seadistamise protsessi:
- müügiosakond leiab sellest ideid ja inspiratsiooni müümiseks,
- turundajad võtavad regulaarselt kasulikku sisu postituste, artiklite, positsioneerimise ja reklaamitekstide jaoks,
- juhid analüüsivad klientide vajadusi ja käitumist, kohandades strateegiat.
Tulemusena sai teoks win-win-win transformatsioon, kus võitsid nii meie, kliendid kui ka meie partnerid. Oleksin tänulik, kui jagaksite oma arvamust kommentaarides: kas minu artiklis oli midagi kasulikku ja milliseid projektijuhtimise meetodeid kasutate arenduses!
Allikas: habr.com
