Hej alle, mit navn er Konstantin Kuznetsov, jeg er administrerende direktør og grundlægger af RocketSales. I IT-branchen oplever man ofte, at udviklingsafdelingen lever i sin egen verden. I denne verden er der luftfugtere på hvert skrivebord, en masse gadgets og rengøringsprodukter til skærme og tastaturer, og sandsynligvis også deres eget system til opgavestyring og projekter.
Hvad er der galt med det?
Muligvis ikke noget for nogle. Men vi stødte på et problem. Vi arbejder med at bygge og automatisere salgssystemer, implementerer CRM, skaber cloud-infrastruktur til virksomheder. I kundeprojekter involverer vi ofte marketingfolk, sælgere, bogholdere og andre medarbejdere udover udviklings- og produktionsafdelingerne. Og vi begyndte at tænke over, hvordan vi kunne organisere en effektiv projektstyringsproces.
Hvis udviklings- og produktionsprocessen er organiseret på en platform som Jira eller GitLab, så forstår ingen andre end udviklingen, hvad der foregår.. For at involvere en ekstern medarbejder i projektet, skal man mødes med dem, forklare konteksten, nedskrive opgaven et sted, derefter overvåge graden af færdiggørelse i arbejdsbeskeder, få resultatet gennem chatten, indtaste det i Jira. Og sådan hver gang.
Udviklingen er afskåret fra de andre afdelinger i virksomheden, de ved ikke, hvordan de kan involvere os, og vi ved ikke, om de har brug for vores deltagelse.
For et par år siden opdagede vi platformen Asana. I dette materiale vil jeg fortælle, hvordan vi organiserede processen med at styre udvikling og produktion, så:
- hele virksomheden arbejder i et fælles økosystem,
- alle har tilstrækkelig funktionalitet,
- man kunne vurdere omkostningerne ved hvert projekt i timer og penge,
- arbejdet med kunderne var langsigtet: ikke begrænset til én opgave, men i rammerne af et helt projekt med et konstant backlog af idéer.
Lidt om at blive bekendt med Asana
Jeg brugte 10 år på at finde det rette software til projektstyring. Trello, Jira, Planfix, Megaplan, Bitrix24 og mange andre task-trackere klarede ikke prøven. Så fandt jeg Asana. Og alt faldt på plads.
Efter vores mening er dette den bedste og hurtigst voksende platform til opgave- og projektstyring. I dag er Asana verdens førende, når det kommer til popularitet og brugertilfredshed. Det fremgår tydeligt af g2-ranglisten.
Vi er store fan af Asana og har endda gennemført certificering for at kunne implementere den for vores kunder.
Jeg vil kort beskrive processen fra salg til implementering af projektet.
Da vi sælger IT-tjenester, er vores salgstragt ret lang, og tættere på slutningen kommer den ind i produktionsafdelingen og nogle gange udviklingsafdelingen.
Salgsafdelingen udfører standardmanipulationer: audit, godkendelse af tilbud, underskrivelse af kontrakt, overdragelse af handlen til produktionen. Produktionen kan vælge ikke at acceptere kontrakten: den skal nødvendigvis indeholde budget, dato for overdragelse til produktion og et beregnet tidsramme for implementeringen af projektet.
Takket være integrationen mellem amoCRM + Asana, når handlen overføres fra salgsafdelingen til produktionen og tilbage, forstyrres arbejdet ikke. Blå farve angiver salgsafdelingens ansvarsområde, orange produktionens, og pink udviklingsafdelingens.
Det er vigtigt, at udviklingsafdelingen, i modsætning til projektafdelingen, ikke er involveret i hvert enkelt projekt. Nogle gange kræver systemopsætningen ikke tilpassede løsninger.
Når lederen har godkendt projektet til produktion, kan sælgeren med et klik gå til Asana (skærmbillede). Projektet oprettes automatisk i Asana fra amoCRM.
Task (opgave) med projektets kort og kommercielle tilbud oprettes automatisk på den fælles projektoversigt for kunderne. Her vises alle kunder, der i øjeblikket er i produktion. Her tildeles en ansvarlig leder, deadlines sikres, arbejdstypen vælges, og opgavens status ændres.
Lederen kan starte en hvilken som helst af de foreslåede automatiske forretningsprocesser i opgaven:
- Find/Opret kundens projekt + Vedhæft en opgave
- Udfyld opgaven med oplysninger om handlen
- Opret en handel fra den aktuelle opgave
Projektet fyldes med alle data angivet i amoCRM. Afhængigt af typen af tjenester oprettes straks et sæt underopgaver til implementering af aktuelle arbejdsblokke. Projektlederen skal blot nedbryde detaljerne i opgaverne, tildele ansvarlige og deadlines.
Denne tavle hjælper med at tage nye projekter i arbejde. Men det er besværligt at holde styr på aktuelle statusser og projekter i risikozonen.
Hvordan vi grupperer opgaver og projekter for kunderne
Fra den samlede tavle med alle projekter tilføjer lederen et projekt til yderligere 3 tavler:
- kundens personlige tavle;
- portefølje af aktive kunder;
- portefølje for lederen.
Lad os se på formålet med hver af disse enheder.
På skærmbilledet ser du kundens personlige tavle.
Hvad er formålet med denne tavle?
Tidligere tænkte vi i opgaver. Jeg gjorde en opgave, så gik jeg videre til en anden. Det betød, at vi kun leverede det arbejde, klienten bad om. Men vi ønskede at opbygge langsigtede relationer, så vi skiftede fra at arbejde med opgaver til at arbejde med kunder.
Vi noterer altid alle ideer til forbedringer for klienten. Selv hvis det er en tanke, tilfældigt nævnt af klienten, noterer vi det og følger op. Sådan formes et backlog af opgaver, arbejdet med klienten afsluttes 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 aggregering af alle data i et enkelt interface).
Vi har integreret en hurtig kontrolpanel i Asana. Fører musen over modulet over opgaven og ser, hvem og hvor meget der har arbejdet på opgaven, samt hvilken bonus de har tjent.
Arbejdet i produktionsafdelingen vurderes efter timer, så det var vigtigt for os at overvåge, hvor meget tid hver medarbejder har brugt på at løse kundens opgaver.
Hvad giver brugen af tavlen?
Som et resultat ser vi i ERP-systemet En rapport om projekterne. Status for aftalen, projektmedlemmer, budget for projektet, antal arbejdede timer og tidsfrister.
Vi kan forudsige omkostningerne ved lignende udviklingsprojekter, og KPI-beregningen bliver fuldstændig gennemsigtig, hvilket efterlader ingen illusioner om, at udviklingen kun tager et par timer. Om nødvendigt har vi altid et interface, vi kan vise kunden til rapportering.
Asana-porteføljer
Denne funktionalitet har længe været implementeret i Asana. Men vi værdsatte den ikke straks. Først samlede vi blot alle projekterne fra vores ledere i porteføljer. Det viste sig, at i løbet af sin tid i virksomheden havde Denis Kiselev arbejdet med 61 kunder.
At kende det er cool, men ikke nok til at retfærdiggøre den tid, der er brugt på at samle det. Og vi opgav projekter. Alt ændrede sig, da vi ligestillede projektet i Asana med en aftale i CRM-systemet.
Tidligere underskrev lederen sig på alle projekter og modtog meddelelser om alle ændringer i Inbox (informationsstrømmen). Hver statusopdatering, ny kommentar blev vist i strømmen, begyndende med den nyeste. Om mandagen satte lederen sig ned og udførte opgaverne i inboxen sekventielt. Der blev ikke talt om prioriteter, og de vigtige opgaver blev ofte nedprioriteret.
Nu er der et medarbejderportfolio og et projektafdelingsportfolio. I den første administrerer manageren sine projekter, mens den anden giver lederen kontrolfunktionalitet over den aktuelle arbejdsbyrde for alle medarbejdere.
Projektafdelingens portfolio
På skærmbilledet ser du projekterne sorteret efter medarbejdere.
Engang om ugen opdaterer projektlederen status for hvert projekt. Han skriver, hvad der er blevet gjort i den forgangne uge, og hvad der er planlagt til næste uge. Han fastsætter en af tre tags: under kontrol, i risikozonen, er der problemer.
Lederen kan hurtigt vurdere:
- den nuværende mængde kunder i projektafdelingen,
- antallet af projekter, der er i gang hos hver leder,
- antallet af forsinkede opgaver i projekterne,
- tilstedeværelsen af problemer og behov for at involvere sig i projekterne,
- deadline for projekterne, den tid der er brugt, trin i trakten og prioriteringen af projektet.
Portfolios hjælper os også med at lave rapportering. Efter statusopdateringen for projektet sendes rapporten om udført og planlagt arbejde automatisk til chatten med klienten.
Medarbejderens portfolio
Selv lederen af projektafdelingen har sin egen portfolio. Hvis han, håber vi, skulle fratræde, vil den nye person se alle de kontrollerede projekter, som han skal fortsætte med at overvåge.
De linjeansatte satte også pris på bekvemmeligheden ved at planlægge arbejdsbyrden i portfolioen. I fanen "Arbejdsbyrde" analyserer Asana mængden af opgaver under hensyntagen til deadlines og advarer, hvis medarbejderen har planlagt en uoverkommelig mængde opgaver. Deadlines og detaljer kan ændres uden at forlade denne fane.
Fejlrettelse og tilpasset udvikling
Et særligt team er ansvarligt for udviklingen hos os. I forbindelse med forretningsprocessen modtager de opgaver af to typer:
- bug,
- ny udvikling.
Bugs bliver tjekket, vurderet for kritikalitet og overgivet til supportafdelingen.
Udviklingsopgaver kommer enten fra backloggen for virksomhedens interne produkter eller fra projektlederen ved eksisterende kundeanmodninger.
Udviklingsprocessen ser generelt sådan her ud.
Opgaverne falder på udviklingsbrættet i Asana. Her er det.
Opgavens forfatter vælger typen 'Bug' eller 'Feature', angiver graden af kritikalitet, identificerer kunden og interne afdelinger, som opgaven berører. Når opgaven opfylder alle kravene i det interne regulativ, klikker forfatteren på lynsymbolet på den øverste panel over opgaven og starter den automatiske forretningsproces 'Vurdere i udvikling'.
Lederen for udviklingsafdelingen modtager en meddelelse om den nye vurderingsopgave, og selve opgaven flyttes midlertidigt til et særskilt tavle med samme navn under vurderingen.
Efter vurderingen flytter lederen opgaven til den sprint, der svarer til den planlagte afslutningsmåned. Opgaverne befinder sig altid på flere tavler samtidigt:
- på projektlederens personlige tavle,
- på supportens tavle,
- på udviklingstavlen.
Alle deltagere og medarbejdere, der overvåger opgaven, kan se fremskridtene, modtage meddelelser og føre diskussioner direkte i kommentarerne til opgaven. Når opgaven er færdig — tager projektlederen eller den ansvarlige specialist fra supporten den 'over' for at fortsætte arbejdet i projektet.
Hvad fik vi, da vi samlede udviklings- og produktionsafdelingerne i et fælles miljø med teamet?
For det første, blev kundeprojekterne mere langsigtede. Den konstant opdaterede backlog har øget gennemsnitsordren.
For det andet, blev kvaliteten af projekterne markant forbedret, da udviklingsafdelingen til enhver tid kunne stille spørgsmål til marketing, salg, regnskab osv. Vi fik mulighed for rettidigt at inddrage de nødvendige teamkompetencer og tilbyde løsninger på et helt andet niveau.
For det tredje, Både medarbejdere, ledere og kunder har fået fuld gennemsigtighed i planlagte og gennemførte opgaver. Vi har lært at styre projekter, og indset at det er en helt teknisk proces, hvor den menneskelige faktor næsten helt kan udelukkes.
For det fjerde, er teamet blevet mere sammenhængende. Tidligere havde medarbejderne en svag forståelse af, hvad de mytiske afdelinger for udvikling og produktion lavede.
Nu, med indblik i udviklingsprocessen og den tekniske opsætning af systemerne:
- finder salgsteamet idéer og inspiration til, hvordan man sælger,
- marketerne tager regelmæssigt nyttigt indhold til indlæg, artikler, positionering og reklamekopier,
- lederne analyserer kundernes behov og adfærd, hvilket tilpasser strategien.
Det har resulteret i en win-win-win transformation, hvor vi, kunderne og vores partnere har vundet. Jeg vil sætte pris på, hvis du deler din mening i kommentarerne: var der noget nyttigt i min artikel, og hvilke projektledelsesmetoder bruger du i udviklingen!
Kilde: habr.com
