Så optimerar du din process med arbetsflödeshantering (med Marc Boscher från Unito)

Läs transkriberingen:

Vi provar att transkribera våra poddar med hjälp av ett program. Ha överseende med eventuella stavfel eftersom boten inte är korrekt till 100 procent hela tiden.

Ben Aston:

Slösar du massor av tid på att försöka hitta den information du behöver? Det gör du säkert. Och dessutom är det oerhört frustrerande att se sitt team lägga timmar på att försöka hitta information, särskilt när man ansvarar för andra människor. Verkligheten är dock att det inte finns ett system för arbetsflödeshantering som passar alla. Ditt UX- och strategiteam kanske gärna använder Trello eller Asana, men när det gäller utvecklarna vill de nästan alltid använda JIRA. Så hur hanterar man denna röra? Hur avgör man vilket verktyg som ska vinna? En McKinsey-rapport visade faktiskt att de flesta anställda lägger omkring åtta timmar i veckan bara på att försöka hitta information.

Den goda nyheten är att det finns ett sätt att lösa problemet, och lösningen är ett system för arbetsflödeshantering. Om du vill spara tid åt dig själv, ditt team och din budget ska du fortsätta lyssna på dagens podd. Vi ska prata om hur man skapar och optimerar ett system för arbetsflödeshantering. Tack för att du lyssnar. Jag heter Ben Aston. Jag är digital projektledare och grundare av thedigitalprojectmanager.com. Vi arbetar för att hjälpa digitala projektledare att leverera bättre och hjälpa människor som leder projekt i en digital värld att lyckas.

Om du vill komma i kontakt med vår gemenskap kan du gå till the digital project manager punkt com. Där hittar du många resurser som hjälper dig att bygga kompetens, bli tryggare och börja leverera bättre projekt. I dag har jag sällskap av Marc Boscher. Marc är webbutvecklare som blev produktansvarig och nu är vd och grundare av Unito. Marc, välkommen till podden.

Marc Boscher:

Tack för att jag fick komma.

Ben Aston:

Berätta lite om din resa. Hur går man från att vara webbutvecklare till projektledare, vidare till produktansvarig och sedan till att grunda sitt eget företag? Berätta lite om den utvecklingen.

Marc Boscher:

Det tog några år, antar jag. Jag började under dotcom-bubblan när allt rörde sig väldigt snabbt. Jag drogs in i tekniken och vidare mot produktsidan. Jag har i princip arbetat med produkter i 20 år. När man arbetar med produkt får man en väldigt intressant möjlighet: man ser problem hela tiden och tänker att någon borde lösa dem, men man kommer aldrig riktigt till skott. Jag fortsatte dock att skriva ner problemen, och Unito föddes ur ett av de problem som jag såg hela tiden.

Ben Aston:

Du säger att du har arbetat med produkter i 20 år, medan Unito fortfarande är en relativt ny produkt. Varifrån kom inspirationen till att specifikt lösa just det problemet?

Marc Boscher:

Inom produkt- och i viss mån projektledning måste man samarbeta med många olika team, grupper och kompetenser, och man har sällan formell auktoritet. Man är sällan deras chef och måste leda genom påverkan. Det innebär att man inte får bestämma vilka verktyg de ska använda. Man hamnar därför ofta i mottagaränden av den blandning av verktyg som de olika teamen använder. Jag kom hela tiden på mig själv med att hoppa mellan Zendesk, Asana, JIRA, GitHub och alla andra verktyg, och fick betala priset för det.

Det var ett sådant ögonblick när jag tänkte att någon borde lösa detta. Vanligtvis löser man problemet genom att tvinga alla att använda samma verktyg. Men när API:er utvecklades tänkte vi: kan vi koppla ihop verktygen? Kan människor få stanna i sina egna verktyg, så att projektledare slipper springa runt och fråga om saker är klara, var de befinner sig och om en försening påverkar någon annan? Idén växte fram ur behovet att lösa vårt eget problem. Vi hade länge tänkt starta något eget, så vi tog steget och försökte. När det började få fäste fortsatte vi. Och här är vi i dag.

Ben Aston:

Fantastiskt. Berätta lite om vilka verktyg ni själva integrerar med internt. Jag vet att man kan koppla ihop projektledningsverktyg och projektledningsprogram som Trello, Asana och JIRA. Vilka verktyg väljer ni att koppla samman, och hur fungerar det?

Marc Boscher:

Personligen är jag en verktygsentusiast, så jag använder nästan alla. Det är spännande när man upptäcker en design som passar ens sätt att tänka och är anpassad till ens roll. Man vinner mycket när det gäller produktivitet, men det verkliga hindret är ofta att övertyga andra om att byta verktyg.

Jag tror att många hinder för att ta till sig teknik i dag handlar mindre om det tekniska, som att installera och distribuera programvara, och mer om att få människor att använda den. Vi har ett dussintal verktyg just nu. Vi lanserade en ClickUp-integration för ett par veckor sedan och lanserar en till nästa vecka och ytterligare en om tre eller fyra veckor. Vi tar fram integrationer för verktyg inom projekt- och arbetsledning, som Asana, Wrike och Trello. Vi började också med utvecklarverktyg som GitHub, Bitbucket, GitLab och JIRA.

Fokus ligger på att koppla samman projektledare med tekniska team, eller verksamhetsanvändare med tekniska team, som vanligtvis inte talar samma språk eller använder samma verktyg. Med tiden har vi lagt till Zendesk för supportsystem, HubSpot för försäljning och CRM samt marknadsföring. Frågan är hur man kan börja se arbete som något som sträcker sig över hela organisationen, inte bara som något inom ett enskilt team. Där finns ett mycket större och viktigare problem, där enormt mycket tid läggs och går till spillo.

Ben Aston:

Du säger att du är en verktygsentusiast. Finns det några nya verktyg som du nyligen har upptäckt och som har gjort dig särskilt entusiastisk?

Marc Boscher:

Alla verktyg vi integrerar med är bland de bästa på marknaden. Men vi vill gärna tro att det inte finns ett enda verktyg som är bäst för alla. Det beror på vad man försöker uppnå, vem man är och hur man arbetar. Det är en grundläggande övertygelse. Jag rekommenderar inte ett verktyg framför ett annat; det beror på situationen. Alla har sitt verktyg, det som gör dem mest produktiva. Utmaningen är att det aldrig är samma verktyg för alla. Nya verktyg dyker upp varje dag. Vi brukar välja de som är populära, växer och är på väg uppåt. De måste naturligtvis också ha ett API-lager så att de kan integreras. De flesta verktyg i dag har den komponenten och ett ekosystemperspektiv.

Ben Aston:

Marc har skrivit ett inlägg på thedigitalprojectmanager.com som heter ”Så bygger du ett system för arbetsflödeshantering”. Där finns flera exempel. För dem som inte har läst det, kan du förklara vad du menar med arbetsflödeshantering? Som projektledare förstår vi processer: hur man tar något från A till B, där A är projektets början och B är projektets slut, med olika steg på vägen.

På resan från A till B levererar och skapar vi värde. Vad innebär arbetsflödeshantering, och hur passar det in i förståelsen av hur man tar sig från A till B inom projektets begränsningar och samtidigt skapar värde?

Marc Boscher:

Det liknar det vi redan känner till, alltså samma process. Människor använder ofta arbetsflöden och processer som synonymer. Vi brukar tänka på processer som ganska linjära steg-för-steg-sekvenser, eftersom det är så vi naturligt tänker. När vi planerar projekt börjar vi ofta med: först gör du detta, sedan detta och därefter det där. Sedan kommer verkligheten.

När människor börjar arbeta upptäcker man saker, måste samarbeta mellan team och involvera andra i en mycket dynamisk miljö, särskilt i dagens digitala arbete. Det är inte lika linjärt eller specifikt, och det är mindre förutsägbart. Ett programvaruutvecklingsteam kan ha en utvecklingsprocess, marknadsföringen kan ha en kampanjprocess och försäljningen en säljprocess. Varje team måste definiera sin process, och det finns många ramverk för detta.

När man börjar samarbeta över dessa gränser blir det dock ofta mer möten, videosamtal och chattar, och mindre användning av verktyg som hjälper oss att hantera arbete och leverans. Med arbetsflödeshantering menar vi ett lager som kopplar ihop allt över alla dessa processer och ser till att detaljerna stämmer.

Ben Aston:

Om vi säger att ett system för arbetsflödeshantering tar hänsyn till scenarier av typen ”om detta händer, gör då detta”, så är vägen från A till B i ett projekt sällan rak. Den består oftast av loopar och övergångar från en riktning till en annan. Vi behöver ett sätt att hantera när saker händer. När vi presenterar UX för kunden kanske vi samtidigt utvecklar stilpaneler. Vad händer när UX godkänns men stilpanelerna inte gör det? Hur fortsätter vi framåt och ser till att rätt personer är anslutna och uppdaterade så att utvecklingen kan börja?

En mer komplex och nyanserad förståelse kan hjälpa oss att bli effektivare när vi levererar projekt. Vi behöver inte längre se projekt som en helt linjär process, utan som en serie mindre cykler som gradvis integreras med varandra. Vi har parallella arbetsflöden för UX, design, utveckling och kvalitetssäkring. När vi kopplar ihop dem tätare kan de fungera mer sömlöst och effektivt. Är det det du menar med arbetsflödeshantering?

Marc Boscher:

Ja, absolut. Det handlar om många av de principer inom agilt arbete som säger att man inte ska försöka kontrollera allt, utan ge människor större frihet att samarbeta, undanröja hinder och arbeta i korta cykler. Verktygen kommer ofta i vägen eftersom alla använder olika verktyg och processer. Det första steget i arbetsflödeshantering är därför att gå dit arbetet utförs, acceptera att människor arbetar på olika platser och möta dem där.

Det innebär att integrera verktygen där arbetet sker. Det andra steget är att kartlägga arbetsflödet över dessa verktyg och forma flödet. Vilka är reglerna och riktlinjerna? Så här arbetar marknadsföringen med utvecklingen. När en funktion skapas, behöver designteamet involveras? Behöver produktansvariga och utvecklare involveras? Man behöver inte begränsa människor, utan snarare öppna möjligheter för dem att samarbeta från sina egna verktyg utan att behöva lämna dem.

Ett enkelt exempel är att man har en projektplan i ett Gantt-diagram i ett verktyg som Wrike eller Asana. En aktivitet ska utföras av utvecklare. Den aktiviteten blir automatiskt ett JIRA-ärende, men förblir synkroniserad med JIRA-ärendet. När någon tilldelas ärendet, arbetet börjar eller ärendet läggs i en sprint, vet projektledaren vad som händer utan att behöva hoppa mellan verktygen.

Marc Boscher:

Man kan se beroenden till andra avdelningar, team eller aktiviteter utan att behöva hoppa runt där arbetet utförs. Börja med att förstå var arbetet sker. Koppla sedan ihop verktygen och definiera reglerna: när något händer i det här projektet vill jag till exempel se det i min projektplan. När man har gjort det behöver människor inte lämna sina verktyg. All information är tillgänglig oavsett var man befinner sig. Då blir samarbetet rikare och friktionen minskar. Det är då man kan börja optimera och förbättra.

Ben Aston:

Olika team vill alltså arbeta i olika verktyg. Ett design- eller UX-team vill kanske inte arbeta i JIRA eftersom det kan vara komplext. Fördelen med Unito är att människor kan arbeta i det verktyg som passar dem bäst. Många försöker fortfarande hitta ett enda verktyg som kan göra allt, men verkligheten är att varje verktyg bygger på en viss filosofi om hur projekt ska hanteras. Den filosofin gör det lättare eller svårare för olika team att samarbeta.

Jag har försökt få designteam att arbeta i JIRA, och det har i praktiken aldrig fungerat. Hur kartlägger man då processen och avgör hur komplext arbetsflödessystemet ska vara? Hur utformar man arbetsflödet utan att göra det onödigt komplext? Hur automatiserar man saker utan att fastna i ett system som inte går att ändra?

Marc Boscher:

Från första dagen var målet att verksamhetsanvändare skulle kunna konfigurera systemet själva, utan teknisk kompetens. Det är avgörande. Om man vill koppla ihop två team ska man inte behöva tekniska färdigheter eller vänta på en utvecklare. Det handlar om visuell design och att kunna ange regler på ett naturligt språk: när detta händer ska det hamna hos utvecklingsteamet.

Det handlar också om att kartlägga processer med olika detaljnivåer. Inom programvaruutveckling kanske man har kvalitetssäkring, kollegial granskning och testmiljöer. Ur marknadsföringens perspektiv kanske man bara behöver veta om en funktion är redo att lanseras. Man behöver inte se alla detaljer. De tio stegen inom utvecklingen kan för marknadsföringen motsvara ”under utveckling”.

Börja med en dialog om hur ni arbetar och hur ni kan föra ihop arbetssätten. Ge verksamhetsanvändarna flexibilitet att konfigurera och förbättra relationen över tid. Man behöver inte lösa allt på en gång. Börja med enkla regler: när jag tilldelar något till Ben ska det visas i hans verktyg, eller när ett supportärende eskaleras till utveckling ska det visas i ett JIRA-projekt. När man ser hur informationen flödar kan man stegvis göra systemet mer avancerat och spara mer tid.

Ben Aston:

Jag ser något bakom dig som liknar ett arbetsflöde. Är det en processkarta?

Marc Boscher:

Det är faktiskt en kvarleva från förr. Det är en kundresa på en vägg med post-it-lappar. Den finns inte längre. Det är som en tapet. Vi arbetar alla på distans nu.

Ben Aston:

När ni försöker samla olika team som arbetar i olika verktyg och förstå vem som behöver vad, när och i vilket format, liknar det att ta fram en kommunikationsplan. Hur bygger ni upp den dialogen? Utformar ni allt direkt i verktyget, eller börjar ni med att rita upp helheten på en whiteboard?

Marc Boscher:

Vi såg kunder rita upp sina processer och använda whiteboard. Därför byggde vi in en funktion i verktyget där man visuellt kan kartlägga var arbetet sker och styra arbetsflödet. Den dialogen är mycket viktig. Kunderna är bra på sina egna teamprocesser, men när det gäller samarbete över teamgränserna vet de ofta mindre om hur andra arbetar. Projektledare känner igen detta eftersom de hela tiden arbetar vid och över dessa gränser.

I stället för att projektledare ska lägga tid på att översätta, kopiera, klistra in och upprepa information borde verktygen sluta vara ett hinder. Kommunikationen ska kunna flöda direkt, så att projektledare kan göra det de är bäst på: samordna människor, hålla koll på risker, minska risker och sätta prioriteringar utan det manuella arbetet med att hålla alla informerade.

Ben Aston:

En stor del av tiden i budget- och projektledning går åt till att se till att människor känner till sådant de borde känna till, har läst ärendet i sin inkorg eller sett att något har uppdaterats i Trello. Alla kommer att arbeta på olika sätt, så det är klokt att anpassa sig efter det. Om någon vill arbeta i Trello, låt informationen finnas i Trello. Om någon vill ha ett JIRA-ärende, skapa det. Att göra det möjligt för människor att arbeta på det sätt som passar dem bäst är sannolikt framtiden.

Men vad händer när det misslyckas? Vilka utmaningar finns med systemet? Man kan lätt börja se arbetsflödet som lösningen på alla problem. Då kan många saker ändå hända på många olika platser och falla mellan stolarna. Jag antar att en risk är att förlita sig blint på verktygen. Vilka utmaningar har du sett med ett system för arbetsflödeshantering?

Marc Boscher:

Kommunikation är alltid avgörande, oavsett om man har ett system som hjälper till att integrera två team eller inte. När kommunikationen blir enklare kan människor använda de verktyg de arbetar i varje dag för att kommunicera, samarbeta och uppdatera personer som inte använder samma verktyg.

Tänk på det som en orkester. Musikerna har varsitt instrument eller verktyg. Fiolsektionen använder kanske Trello och pianisten JIRA. Någon, ofta projektledaren, försöker hålla alla synkroniserade och samordnade. Men man tvingar inte alla att byta till fiol. Det som gör orkestern stark är att varje person har sitt eget instrument.

Projektledaren är dirigenten och försöker vägleda gruppen. Alla är självständiga och har sitt eget sätt att spela. Det handlar om att föra samman alla och hålla dem i harmoni. Den första frågan är om alla kan se dirigenten och varandra. I den distansbaserade världen är det ännu svårare, med fördröjningar, tidsskillnader och tidszoner. En lösning för arbetsflödeshantering kan fungera som orkestrering av alla dessa människor utan att de behöver ändra sitt arbetssätt eller lämna sina verktyg.

Ben Aston:

Hur ser du på utvecklingen framöver, framtidens arbete och projekt samt verktygets framtid? Hur förändras projektledarens roll?

Marc Boscher:

Förhoppningsvis lägger projektledare mindre tid på manuellt arbete och mer tid på att dirigera. Vi tror att trenden mot fler och fler verktyg kommer att fortsätta eftersom det är billigt att bygga programvara, enkelt att distribuera den och enkelt för människor att ta den i bruk. Man måste därför gå dit människor arbetar och omfamna verkligheten i stället för att kämpa emot den.

När teamen får organisera sig själva måste man fortfarande samordna dem och hålla dem synkroniserade. Med ett lager för arbetsflödeshantering som kopplar ihop dem får man mycket bättre insyn i vad som händer. Tidigare frågade du vilket verktyg som vinner. Det antyder att någon måste förlora och byta till det andra verktyget. Vi tror på en framtid där ingen behöver förlora och där verktygen fungerar sömlöst tillsammans. Vi hoppas kunna vara den plattformen och tror att arbetsflödeshantering är plattformen som gör detta möjligt.

Ben Aston:

Om någon är ny inom process- och arbetsflödeshantering, var börjar man? Många byråer och studior har fem till tio personer och försöker bara få ut arbetet. Vd:n är affärsutvecklare och projektledare i en snabb och ganska fri digital miljö. Var börjar man med processdesign och sedan optimering av arbetsflöden? Hur tar man de första stegen när man inte ens inser att man har en process?

Marc Boscher:

Det finns alltid lågt hängande frukt. Tröskeln är lägre än man tror. Det behöver inte vara särskilt komplext. Alla kunder har sitt eget sätt att organisera sig. En mindre byrå måste ofta anpassa sig efter kundens arbetssätt och verktyg, vilket innebär mycket tid som går åt till att lära sig nya system.

Börja med ett projekt och se vilket verktyg kunden använder. Vilket verktyg skulle vara idealiskt för er? Om ni kan använda samma verktyg kan ni börja upprepa arbetssättet. Om ni kan hålla er till ett verktyg internt för byråns projekt blir det lättare när nästa kund använder ett annat verktyg. I stället för att ändra hela arbetsflödet kan ni prova en integration mellan verktygen.

Det fina med att gå dit arbetet sker är att det inte kräver att man river ut och ersätter allt. Det kräver inte mycket förarbete. Man kan börja med ett litet team, ett projekt eller ett arbetsflöde. Det kan vara att få marknadsföringen att skicka en ändringsbegäran till utvecklingen på webbplatsen, eller att låta supporten eskalera ett ärende till utvecklingen. Börja där ni lägger mest tid och förbättra sedan stegvis.

Ben Aston:

Ett mer agilt tankesätt innebär att man testar och lär sig. Man får inte processen rätt första gången. Leta efter lågt hängande frukt och möjligheter att bygga processer där de saknas. Ett bra sätt är att utgå från lärdomar från det senaste projektet. Var gick det fel? Varför började designen två veckor för sent? Varför startade utvecklingen för tidigt?

Genom att identifiera sådana lärdomar kan man börja utforma en process. Sedan bygger man processen, kartlägger den, testar den och lär sig vad som fungerar och inte fungerar. Det kan vara ett bra första steg för att utforma och optimera processen. Marc, tack så mycket för att du var med oss i dag.

Marc Boscher:

Tack, Ben.

Ben Aston:

Om du vill lära dig mer och komma vidare med design av projektledningsprocesser kan du gå till thedigitalprojectmanager.com. Där hittar du mängder av bra resurser, inklusive vårt medlemskap och vår webbaserade utbildning. Tack för att du lyssnade.