Hej alle sammen, mit navn er Konstantin Kuznetsov, jeg er CEO og grundlægger af RocketSales. På IT-området er der en ganske almindelig historie, når udviklingsafdelingen lever i sit eget univers. I dette univers er der luftfugtere på hvert skrivebord, en masse gadgets og rengøringsmidler til skærme og tastaturer, og højst sandsynligt sit eget opgave- og projektstyringssystem.
Hvad er den store sag?
Måske er det for nogle ingenting. Men vi løb ind i et problem. Vi bygger og automatiserer salgssystemer, implementerer CRM og skaber cloud-infrastruktur til erhvervslivet. Ud over udviklings- og produktionsafdelingerne omfatter kundeprojekter ofte marketingfolk, sælgere, revisorer og andre medarbejdere. Og vi begyndte at tænke på, hvordan vi kunne organisere en effektiv projektledelsesproces.
Hvis udviklings- og produktionsprocessen er organiseret i en platform som Jira eller GitLab, så ingen undtagen udvikling forstår, hvad der er hvad. For at involvere en tredjepartsmedarbejder i et projekt, skal du mødes med ham, forklare konteksten, optage opgaven et sted, derefter overvåge graden af parathed i arbejdschat, få resultatet gennem chatten og indtaste det i Jira. Og sådan hver gang.
Udvikling er afskåret fra andre afdelinger i virksomheden, de ved ikke, hvordan de skal involvere os, og vi ved ikke, om de har brug for vores deltagelse.
For et par år siden opdagede vi Asana-platformen. I dette materiale vil jeg fortælle dig, hvordan vi organiserede udviklings- og produktionsstyringsprocessen for at:
- hele virksomheden arbejdede i et enkelt økosystem,
- alle havde nok funktionalitet,
- det var muligt at estimere omkostningerne ved hvert projekt i timer og penge,
- arbejdet med kunder var langsigtet: ikke inden for rammerne af én opgave, men inden for rammerne af et helt projekt med et konstant ideoplag.
Lidt om at lære Asana at kende
Jeg brugte 10 år på at søge efter praktisk software til projektledelse. Trello, Jira, Planfix, Megaplan, Bitrix24 og snesevis af andre opgavesporere bestod ikke styrketesten. Så fandt jeg Asana. Og alt lykkedes.
Efter vores mening er dette den bedste og hurtigst voksende platform til opgave- og projektledelse. I dag er Asana verdens førende inden for popularitet og brugertilfredshed. Dette fremgår af g2 rating-diagrammet.
Vi er fans af Asana, vi blev endda certificeret til at kunne implementere det for vores kunder.
Jeg vil kort beskrive processen fra salg til projektgennemførelse
Da vi sælger it-tjenester, er vores tragt ret lang, og mod slutningen kommer den ind i produktions- og nogle gange udviklingsafdelingen.
Salgsafdelingen udfører standardmanipulationer: revision, godkendelse af CP, underskrivelse af en aftale, overførsel af transaktionen til produktion. Produktionen accepterer muligvis ikke kontrakten: den skal angive budgettet, datoen for overførsel til produktion og den anslåede tidsramme for projektets gennemførelse.
Takket være kombinationen amoCRM + Asana bliver arbejdet ikke afbrudt nogen steder, når du overfører en transaktion fra salgsafdelingen til produktionen og tilbage. Blå angiver salgsafdelingens ansvarsområde, orange angiver produktionsafdelingen, og pink angiver udviklingsafdelingen.
Det er vigtigt, at udviklingsafdelingen i modsætning til designafdelingen ikke er involveret i alle projekter. Nogle gange kræver opsætning af et system ikke tilpassede løsninger.
Så da lederen accepterede projektet til produktion, går salgschefen til Asana med 1 klik (skærmbillede). Fra amoCRM oprettes projektet automatisk i Asana.
En opgave (opgave) med projektkort og kommercielle forslag oprettes automatisk på den fælles bygherreprojekttavle. Alle kunder, der i øjeblikket er i produktion, vises her. Her udpeges en ansvarlig leder, deadlines sættes, arbejdstype vælges og opgavestatus ændres.
Lederen kan starte enhver af de foreslåede automatiske forretningsprocesser i opgaven:
- Find/opret et klientprojekt + Vedhæft en opgave der
- Udfyld opgaven med transaktionsoplysninger
- Opret en aftale fra den aktuelle opgave
Projektet er fyldt med alle data specificeret i amoCRM. Afhængigt af typen af tjeneste oprettes der straks et sæt underopgaver for at implementere de faktiske arbejdsblokke. Projektlederen skal dekomponere detaljerede opgaver, tildele ansvar og deadlines.
Denne bestyrelse hjælper med at påtage sig nye projekter. Men det er ubelejligt at overvåge de aktuelle statusser og tilstedeværelsen af projekter i fare.
Hvordan vi grupperer kunders opgaver og projekter
Fra hovedbestyrelsen for alle projekter tilføjer lederen projektet til yderligere 3 bestyrelser:
- klientens personlige bestyrelse;
- portefølje af aktive kunder;
- leders portefølje.
Lad os finde ud af, hvorfor vi har brug for hver af enhederne.
På skærmbilledet ser du kundens personlige bestyrelse.
Hvorfor dette bord?
Tidligere tænkte vi i opgaver. Jeg fuldførte opgaven og gik for at lave en anden. Det viste sig, at vi udførte for kunden præcis den mængde arbejde, som han bad om. Men vi ville bygge langsigtede relationer, så vi gik væk fra at arbejde med opgaver til at arbejde med kunder.
Vi sørger for at nedskrive alle idéer til forbedringer for kunden. Selvom det er en tanke, der ved et uheld er smidt i luften af klienten, retter vi den og afslutter den. Sådan dannes et efterslæb af opgaver, arbejdet med klienten slutter ikke.
Hvad er der på denne tavle?
Vores Asana er forbundet med flere tjenester:
- CRM-system (til interaktion med salgsafdelingen),
- TimeDoctor (til tidsregistrering),
- ERP-system (til at samle alle data i en enkelt grænseflade).
Vi har introduceret et hurtigt ressourcekontrolpanel i Asana. Du peger på pladen over opgaven og ser, hvem der har arbejdet på opgaven og hvor længe, og hvilken bonus de har optjent.
Produktionsafdelingens arbejde er estimeret pr. time, så det var vigtigt for os at nøje overvåge, hvor meget tid hver medarbejder brugte på at løse kundeproblemer.
Hvad er fordelene ved at bruge et bræt?
Som følge heraf ser vi i ERP-systemet Projektrapport. Transaktionsstatus, projektdeltagere, projektbudget, antal arbejdstimer og deadlines.
Vi kan forudsige omkostningerne ved lignende udviklingsprojekter, KPI-beregninger bliver absolut gennemsigtige, og der er ikke plads til illusioner om, at udvikling kun tager et par timer. Om nødvendigt har vi altid en grænseflade, som vi kan vise kunden til rapportering.
Asana dokumentmapper
Denne funktionalitet har været implementeret i Asana i lang tid. Men vi satte ikke umiddelbart pris på det. Først samlede vi simpelthen alle vores lederes projekter i porteføljer. Det viste sig, at Denis Kiselev i sin tid i virksomheden arbejdede med 61 kunder.
Det er fedt at vide, men ikke nok til at retfærdiggøre den tid, der bruges på at indsamle det. Og vi scorede på dokumentmapper. Alt ændrede sig, da vi sidestillede et projekt i Asana med én transaktion i CRM-systemet.
Tidligere har lederen abonneret på alle projekter og modtaget notifikationer om alle ændringer i Indbakken (notifikationsfeed). Hver statusopdatering og ny kommentar blev vist i feedet, begyndende med den nyeste. Mandag satte lederen sig ned og udførte opgaver fra indbakken sekventielt. Der blev ikke talt om prioriteringer, og nogle gange blev vigtige opgaver aldrig nået.
Nu er der en medarbejderportefølje og en projektafdelingsportefølje. I den første styrer lederen sine projekter, den anden giver lederen kontrolfunktionalitet vedrørende den aktuelle arbejdsbyrde for alle medarbejdere.
Designafdelingens portefølje
På skærmbilledet kan du se projekter sorteret efter medarbejder.
En gang om ugen opdaterer projektlederen status for hvert projekt. Skriver hvad der blev lavet i sidste uge og hvad der er planlagt i næste uge. Indstiller et af tre tags: under kontrol, i fare, er der problemer.
Lederen kan hurtigt vurdere:
- nuværende antal kunder i designafdelingen,
- antal projekter i arbejde for hver leder,
- antal forfaldne opgaver på projekter,
- tilstedeværelsen af problemer og behovet for at blive involveret i projekter,
- projektdeadlines, tidsforbrug, tragtfase og projektprioritet.
Porteføljer hjælper os også med rapportering. Efter opdatering af projektstatus sendes en rapport om det udførte og planlagte arbejde automatisk til klientchatten.
Medarbejders portefølje
Selv lederen af designafdelingen har sin egen portefølje. Hvis han, pah-pah-pah, fjerner sin autoritet, vil den nye person se alle projekter under hans kontrol, som han skal fortsætte med at overvåge.
Line-medarbejdere satte også pris på bekvemmeligheden ved belastningsplanlægning i porteføljen. På fanen "Indlæs" analyserer Asana mængden af opgaver under hensyntagen til deadlines og advarer, hvis en medarbejder har planlagt en for stor mængde opgaver. Du kan ændre deadlines og justere detaljer uden at forlade denne fane.
Fejlløsning og tilpasset udvikling
Vi har et separat team med ansvar for udvikling. Som en del af en forretningsproces modtager den opgaver af to typer:
- insekt,
- ny udvikling.
Bugs kontrolleres, vurderes for kritikalitet og overføres til arbejde af den tekniske supporttjeneste.
Udviklingsopgaver kommer enten fra virksomhedens interne produktbacklog eller fra projektlederen, hvis der er et tilsvarende ønske fra kunden.
Udviklingsprocessen ser generelt sådan ud.
Opgaver falder på udviklingstavlen i Asana. Her er hun.
Opgavelederen vælger typen "Bug" eller "Feature", angiver graden af kritikalitet, angiver kunden og de interne afdelinger i virksomheden, som opgaven påvirker. Når opgaven opfylder alle kravene i de interne regler, klikker direktøren på lynikonet i den øverste bjælke over opgaven og starter den automatiske forretningsproces "Evaluer i udvikling".
Lederen af udviklingsafdelingen modtager besked om en ny opgave til vurdering, og selve opgaven flyttes til en særskilt bestyrelse af samme navn i vurderingens varighed.
Efter vurdering flytter lederen opgaven til en sprint svarende til den planlagte afslutningsmåned. Opgaverne er altid på flere tavler på samme tid:
- i projektlederens personlige bestyrelse,
- i teknisk support bestyrelse,
- i udviklingsbestyrelsen.
Alle deltagere og medarbejdere, der overvåger opgaven, ser fremdriften af opgaven, modtager meddelelser og fører diskussioner direkte i kommentarerne til opgaven. Når en opgave er afsluttet, "tager" projektlederen eller den ansvarlige tekniske supportspecialist den til deres side for at fortsætte arbejdet med projektet.
Hvad skete der, da vi bragte udviklings- og produktionsafdelingerne tilbage i et enkelt miljø med teamet?
For det første har kundeprojekter er blevet mere langsigtede. På grund af det konstant genopfyldte efterslæb steg den gennemsnitlige regning.
Sekund, kvaliteten af projekterne er blevet væsentligt forbedret, da udviklingsafdelingen til enhver tid kunne stille spørgsmål til marketing, salg, regnskab mv. Vi var i stand til rettidigt at forbinde teamets nødvendige kompetencer og tilbyde løsninger på et helt andet niveau.
Tredje, medarbejdere, ledere og kunder fik fuld gennemsigtighed i planlagte og udførte opgaver. Vi lærte at STYRE projekter og indså, at dette er en absolut teknisk proces, hvorfra den menneskelige faktor næsten helt kan elimineres.
Fjerde, holdet er blevet mere samlet. Tidligere anede medarbejderne ikke meget, hvad de mytiske udviklings- og produktionsafdelinger lavede.
Nu ser vi processen med udvikling og teknisk konfiguration af systemer:
- salgsafdelingen finder i sin idé og inspiration til, hvordan man sælger,
- marketingfolk tager regelmæssigt brugbart indhold til indlæg, artikler, positionering og reklametekster,
- ledere analyserer kundernes behov og adfærd, justerer strategi.
Resultatet var en win-win-win transformation, hvor vi, vores kunder og vores partnere fik fordel. Jeg ville være glad, hvis du deler din mening i kommentarerne: var der noget nyttigt i min artikel, og hvilke projektledelsesmetoder bruger du i udviklingen!
Kilde: www.habr.com