Hei alle sammen, mitt navn er Konstantin Kuznetsov, jeg er administrerende direktør og grunnlegger av RocketSales. På IT-feltet er det en ganske vanlig historie når utviklingsavdelingen lever i sitt eget univers. I dette universet er det luftfuktere på hvert skrivebord, en haug med dingser og rengjøringsmidler for skjermer og tastaturer, og mest sannsynlig sitt eget oppgave- og prosjektstyringssystem.
Hva er problemet?
Kanskje for noen er det ingenting. Men vi fikk et problem. Vi bygger og automatiserer salgssystemer, implementerer CRM og lager skyinfrastruktur for bedrifter. I tillegg til utviklings- og produksjonsavdelingene inkluderer klientprosjekter ofte markedsførere, selgere, regnskapsførere og andre ansatte. Og vi begynte å tenke på hvordan vi skulle organisere en effektiv prosjektledelsesprosess.
Hvis utviklings- og produksjonsprosessen er organisert i en plattform som Jira eller GitLab, da ingen bortsett fra utvikling forstår hva som er hva. For å involvere en tredjepartsansatt i et prosjekt, må du møte ham, forklare konteksten, ta opp oppgaven et sted, deretter overvåke graden av beredskap i arbeidschatter, få resultatet gjennom chatten og legge det inn i Jira. Og slik hver gang.
Utvikling er avskåret fra andre avdelinger i selskapet, de vet ikke hvordan de skal involvere oss, og vi vet ikke om de trenger vår deltakelse.
For et par år siden oppdaget vi Asana-plattformen. I dette materialet vil jeg fortelle deg hvordan vi organiserte utviklings- og produksjonsstyringsprosessen for å:
- hele selskapet jobbet i ett enkelt økosystem,
- alle hadde nok funksjonalitet,
- det var mulig å estimere kostnadene for hvert prosjekt i timer og penger,
- arbeidet med kunder var langsiktig: ikke innenfor rammen av én oppgave, men innenfor rammen av et helt prosjekt med et konstant etterslep av ideer.
Litt om å bli kjent med Asana
Jeg brukte 10 år på å søke etter praktisk programvare for prosjektledelse. Trello, Jira, Planfix, Megaplan, Bitrix24 og dusinvis av andre oppgavesporere besto ikke styrkeprøven. Så fant jeg Asana. Og alt ordnet seg.
Etter vår mening er dette den beste og raskest voksende plattformen for oppgave- og prosjektledelse. I dag er Asana verdensledende innen popularitet og brukertilfredshet. Dette er bevist av g2-karakteren.
Vi er fans av Asana, vi ble til og med sertifisert for å kunne implementere det for våre kunder.
Jeg vil kort beskrive prosessen fra salg til prosjektgjennomføring
Siden vi selger IT-tjenester, er trakten vår ganske lang, og mot slutten går den inn i produksjons- og noen ganger utviklingsavdelingen.
Salgsavdelingen utfører standardmanipulasjoner: revisjon, godkjenning av CP, signering av en avtale, overføring av transaksjonen til produksjon. Produksjonen kan ikke godta kontrakten: den må angi budsjett, dato for overføring til produksjon og estimert tidsfond for gjennomføring av prosjektet.
Takket være kombinasjonen amoCRM + Asana, når du overfører en transaksjon fra salgsavdelingen til produksjon og tilbake, blir ikke arbeidet avbrutt noe sted. Blå indikerer ansvarsområdet til salgsavdelingen, oransje indikerer produksjonsavdelingen, og rosa indikerer utviklingsavdelingen.
Det er viktig at utviklingsavdelingen, i motsetning til designavdelingen, ikke er involvert i alle prosjekter. Noen ganger krever det ikke tilpassede løsninger å sette opp et system.
Så når lederen godtok prosjektet for produksjon, går salgssjefen til Asana med ett klikk (skjermbilde). Fra amoCRM opprettes prosjektet automatisk i Asana.
En oppgave (oppgave) med prosjektkart og kommersielle forslag opprettes automatisk på felles byggherreprosjekttavle. Alle klienter som er i produksjon vises her. Her utnevnes ansvarlig leder, frister settes, type arbeid velges og oppgavestatus endres.
Lederen kan starte hvilken som helst av de foreslåtte automatiske forretningsprosessene i oppgaven:
- Finn/opprett et klientprosjekt + Legg ved en oppgave der
- Fyll ut oppgaven med transaksjonsinformasjon
- Opprett en avtale fra gjeldende oppgave
Prosjektet er fylt med alle data spesifisert i amoCRM. Avhengig av typen tjeneste, opprettes et sett med underoppgaver umiddelbart for å implementere de faktiske arbeidsblokkene. Prosjektlederen gjenstår å dekomponere detaljerte oppgaver, tildele ansvar og tidsfrister.
Dette styret er med på å ta fatt på nye prosjekter. Men det er upraktisk å overvåke gjeldende status og tilstedeværelsen av prosjekter i fare.
Hvordan vi grupperer kunders oppgaver og prosjekter
Fra hovedstyret for alle prosjekter legger lederen prosjektet til ytterligere 3 styrer:
- klientens personlige styre;
- portefølje av aktive kunder;
- forvalterens portefølje.
La oss finne ut hvorfor vi trenger hver av enhetene.
På skjermbildet ser du klientens personlige styre.
Hvorfor dette brettet?
Tidligere tenkte vi i oppgaver. Jeg fullførte oppgaven og gikk for å gjøre en annen. Det viste seg at vi gjorde for klienten akkurat det arbeidet han ba om. Men vi ønsket å bygge langsiktige relasjoner, så vi gikk bort fra å jobbe med oppgaver til å jobbe med kunder.
Vi sørger for å skrive ned alle ideer til forbedringer for kunden. Selv om det er en tanke som ved et uhell kastes i luften av klienten, fikser vi den og fullfører den. Slik dannes et etterslep av oppgaver, arbeidet med klienten tar ikke slutt.
Hva står på denne tavlen?
Vår Asana er koblet til flere tjenester:
- CRM-system (for samhandling med salgsavdelingen),
- TimeDoctor (for tidsregistrering),
- ERP-system (for å samle alle data i ett enkelt grensesnitt).
Vi har introdusert et raskt ressurskontrollpanel i Asana. Du peker på platen over oppgaven og ser hvem som har jobbet med oppgaven og hvor lenge, og hvilken bonus de tjente.
Arbeidet til produksjonsavdelingen er estimert per time, så det var viktig for oss å strengt overvåke hvor mye tid hver ansatt brukte på å løse klientproblemer.
Hva er fordelene med å bruke et brett?
Som et resultat ser vi i ERP-systemet Prosjektrapport. Transaksjonsstatus, prosjektdeltakere, prosjektbudsjett, antall utførte timer og tidsfrister.
Vi kan forutsi kostnadene for lignende utviklingsprosjekter, KPI-beregninger blir helt transparente og det er ikke rom for illusjoner om at utviklingen tar bare et par timer. Ved behov har vi alltid et grensesnitt som vi kan vise til oppdragsgiver for rapportering.
Asana kofferter
Denne funksjonaliteten har vært implementert i Asana i lang tid. Men vi satte ikke pris på det umiddelbart. Til å begynne med samlet vi ganske enkelt alle prosjektene til lederne våre i porteføljer. Det viste seg at i løpet av sin tid i selskapet jobbet Denis Kiselev med 61 kunder.
Det er kult å vite, men ikke nok til å rettferdiggjøre tiden brukt på å samle den. Og vi scoret på kofferter. Alt endret seg da vi likestilte et prosjekt i Asana til én transaksjon i CRM-systemet.
Tidligere har lederen abonnert på alle prosjekter og mottatt varsler om alle endringer i innboksen (varslingsfeed). Hver statusoppdatering og nye kommentar ble vist i feeden, og startet med den nyeste. Mandag satte lederen seg ned og fullførte oppgaver fra innboksen sekvensielt. Det var ikke snakk om prioriteringer, og noen ganger ble viktige oppgaver aldri nådd.
Nå er det en medarbeiderportefølje og en prosjektavdelingsportefølje. I det første styrer lederen sine prosjekter, det andre gir lederen kontrollfunksjonalitet angående gjeldende arbeidsmengde for alle ansatte.
Portefølje til designavdelingen
I skjermbildet kan du se prosjekter sortert etter ansatt.
En gang i uken oppdaterer prosjektlederen status for hvert prosjekt. Skriver hva som ble gjort forrige uke og hva som er planlagt for neste uke. Angir en av tre tagger: under kontroll, i faresonen, det er problemer.
Lederen kan raskt vurdere:
- nåværende antall kunder i designavdelingen,
- antall prosjekter i arbeid for hver leder,
- antall forfalte oppgaver på prosjekter,
- tilstedeværelse av problemer og behovet for å involvere seg i prosjekter,
- prosjektfrister, tidsbruk, traktstadium og prosjektprioritet.
Porteføljer hjelper oss også med rapportering. Etter oppdatering av prosjektstatus sendes en rapport om utført og planlagt arbeid automatisk til klientchatten.
Ansattes portefølje
Selv lederen for designavdelingen har sin egen portefølje. Hvis han, pah-pah-pah, fjerner sin autoritet, vil den nye personen se alle prosjektene under hans kontroll, som han må fortsette å overvåke.
Line-ansatte satte også pris på bekvemmeligheten av lastplanlegging i porteføljen. I «Last inn»-fanen analyserer Asana volumet av oppgaver under hensyntagen til tidsfrister og advarer hvis en ansatt har planlagt et for stort volum av oppgaver. Du kan endre tidsfrister og justere detaljer uten å forlate denne fanen.
Feilløsning og tilpasset utvikling
Vi har et eget team som er ansvarlig for utvikling. Som en del av en forretningsprosess mottar den oppgaver av to typer:
- feil,
- ny utvikling.
Feil sjekkes, vurderes for kritikkverdighet og overføres til arbeid av den tekniske støttetjenesten.
Utviklingsoppgaver kommer enten fra selskapets interne produktbacklog eller fra prosjektleder dersom det er tilsvarende forespørsel fra oppdragsgiver.
Utviklingsprosessen ser generelt slik ut.
Oppgaver faller på utviklingsstyret i Asana. Her er hun.
Oppgavelederen velger typen «Bug» eller «Funksjon», setter graden av kritikalitet, angir kunden og de interne avdelingene i selskapet som oppgaven påvirker. Når oppgaven oppfyller alle kravene i det interne regelverket, klikker direktøren på lynikonet i topplinjen over oppgaven og starter den automatiske forretningsprosessen «Evaluer i utvikling».
Leder for utviklingsavdelingen mottar melding om ny oppgave til vurdering, og selve oppgaven flyttes til et eget styre med samme navn så lenge vurderingen varer.
Etter vurdering flytter leder oppgaven til en sprint tilsvarende måneden for planlagt ferdigstillelse. Oppgaver er alltid på flere tavler samtidig:
- i prosjektlederens personlige styre,
- på styret for teknisk støtte,
- i utviklingsstyret.
Alle deltakere og ansatte som overvåker oppgaven ser fremdriften til oppgaven, mottar varsler og gjennomfører diskusjoner direkte i kommentarene til oppgaven. Når en oppgave er fullført, "tar" prosjektlederen eller ansvarlig teknisk støttespesialist den til sin side for å fortsette arbeidet med prosjektet.
Hva skjedde da vi brakte utviklings- og produksjonsavdelingene tilbake til ett miljø med teamet?
For det første, klientprosjekter har blitt mer langsiktige. På grunn av den stadig etterfylte etterslepet økte gjennomsnittsregningen.
Sekund, kvaliteten på prosjektene har blitt kraftig forbedret, siden utviklingsavdelingen til enhver tid kunne stille spørsmål til markedsføring, salg, regnskap osv. Vi var i stand til i tide å koble den nødvendige kompetansen til teamet og tilby løsninger på et helt annet nivå.
For det tredje, ansatte, ledere og kunder fikk full åpenhet i planlagte og utførte oppgaver. Vi lærte å STYRE prosjekter og innså at dette er en absolutt teknisk prosess som den menneskelige faktoren nesten kan elimineres fra.
Fjerde, laget har blitt mer samlet. Tidligere hadde ansatte liten anelse om hva de mytiske utviklings- og produksjonsavdelingene drev med.
Nå, ser prosessen med utvikling og teknisk konfigurasjon av systemer:
- salgsavdelingen finner ideer og inspirasjon til hvordan selge,
- Markedsførere tar regelmessig nyttig innhold for innlegg, artikler, posisjonering og reklametekster,
- ledere analyserer kundenes behov og atferd, justerer strategi.
Resultatet var en vinn-vinn-vinn-transformasjon der vi, våre kunder og våre partnere hadde nytte. Jeg ville bli glad hvis du deler din mening i kommentarene: var det noe nyttig i artikkelen min og hvilke prosjektledelsesmetoder bruker du i utviklingen!
Kilde: www.habr.com
