Resursutjämning i Monday – Fred Baker – ENDAST FÖR MEDLEMMAR

[00:00:00] Mhm.

Galen: Hej allihop, och välkomna till vår praktiska session om hur man använder Monday för att planera, jämna ut och hantera projektteamets resurser. För er som inte redan känner oss är jag Galen, och det här är den certifierade Monday-konsulten Fred Baker.

Fred, tack för att du är med i dag.

Fred: Tack, Galen.

Galen: Okej. Låt oss gå in på resursplanering. Jag har ett litet scenario här. Jag vet att du har konfigurerat din sandlåda, så låt mig beskriva förutsättningarna. Jag leder ett team av projektledare på en liten digital byrå.

Vi har ett par projektledare som driver flera parallella projekt, alla med varierande storlek, tidsplaner och komplexitet. Men viktigast av allt är att alla projekten delar teammedlemmar från utvecklings- och kreativa avdelningar. Det jag egentligen vill veta är följande: vilket är det bästa sättet för mina projektledare att prognostisera teamets resurser över projekten med hjälp av Monday? [00:01:00] Mer specifikt undrar jag hur jag ska veta om vi har överallokerat någon teammedlem. Och om jag har överallokerat någon, hur kan jag använda Monday för att jämna ut den resursen så att personen inte överstiger sin kapacitet? Det är ungefär det scenario jag vill gå igenom.

Jag tänkte att vi kanske kunde börja med grunderna. Om du snabbt kunde visa hur du skulle fördela resurser till ett par projekt kan vi sedan gå vidare till problemområdet, där någon kanske arbetar 12 eller 16 timmar om dagen. Är det verkligen okej?

Fred: Ja, ja, ja. Det är ett riktigt bra scenario. Det första jag vill säga är att det jag visar är ett av 7 000 olika sätt att göra detta på. Det fina med Monday – jag tror att jag nämnde det tidigare – är att jag brukar säga till kunder att Monday egentligen är som en låda med byggklossar.

Du kan bygga vad du vill med den. Det finns många olika sätt att göra samma sak på. Där människor vanligtvis stöter på problem är när de försöker anpassa Monday till sin process eller sin process [00:02:00] till Monday. Det finns några användbara verktyg. Arbetsbelastningswidgeten, som jag har öppnat här – eller, rättare sagt, det här är arbetsbelastningswidgeten.

Låt mig uttrycka mig korrekt. Den här arbetsbelastningswidgeten är en av de nyare funktionerna som de har släppt under det senaste året eller så. Det är förmodligen det bästa sättet att få en uppfattning om kapaciteten. Som du ser i det här exemplet verkar jag ligga på 61 procents kapacitet under vecka 25. Man kan lägga saker ovanpå varandra, och jag återkommer till det, men man kan stapla projekt och säga: Okej, Fred verkar faktiskt vara med i många projekt just nu.

Då börjar du se 93 procents kapacitet, och vi kan lägga till lite mer och se hur det ser ut. Men du kan nå det röda området. Du ser alltså visuellt när människor är överbelastade eller när de har mindre belastning, som här under vecka 29.

Det här är kopplat till en projektpanel. Det här skulle alltså kunna vara projektpanelen [00:03:00], och det här kan vara en projektpanel på hög nivå. Det finns en panel på hög nivå och en på låg nivå. En panel på hög nivå är i princip en vy på portföljnivå där alla projekt finns, med en rad för varje projekt.

De kanske ligger i olika grupper eller något liknande. Vanligtvis finns det en sådan övergripande vy som hela teamet eller projektledaren kan titta på. Därifrån kan det finnas en panel på låg nivå, alltså en detaljvy. Du kan till exempel ha alla dina projekt här uppe och sedan ett mycket specifikt webbdesignprojekt för en stor kund, kopplat till panelen på hög nivå, men med en projektnivå som innehåller alla detaljer.

Där kan det stå att vi genomför uppstarten, samlar in resurser, tar fram en trådmodell och gör en granskning. Allt sådant skulle kartläggas i panelen på låg nivå, men inte i panelen på hög nivå. Panelen på hög nivå säger bara: Hej, vi bygger en ny webbplats åt DPM.

Galen är ägare, Fred är projektledare och här är kanske personerna som tilldelats projektet. Det här skulle [00:04:00] alltså vara mer som en panel på hög nivå, där alla projekt finns. Låt oss lägga till ytterligare ett projekt här. Jag kallar det DPM och lägger till mig själv.

Det finns många olika sätt att konfigurera detta på. Det jag har satt upp här är en mängd olika exempel. Ett av dem är en projektuppstart: när ska projektet faktiskt starta? Jag lägger det på den 26:e så att det visas i de aktuella veckorna. Man kan använda antingen ett fast datum eller en tidslinje.

Låt oss säga att projektet löper från den 26:e till den 31 juli. Det är förmodligen alldeles för kort tid för att bygga en riktig webbplats.

Galen: Vi arbetar snabbt. Hmm. Mm.

Fred: Ja, ja. Vi säger att det tar hundra timmar, bara för att få in några siffror. Det här är alltså det totala antalet projekttimmar, och det är en kolumn som jag själv har skapat.

Det är i grunden en sifferkolumn. Jag har ställt in den på timmar, men man kunde ha valt vad som helst – eller ingenting. Längst ner har vi en sammanställning. [00:05:00] Där ser du totalsumman. Om du använder detta för projekt kan du fråga: Hur många projekttimmar har jag totalt? Jag har 375 timmar i projekt. Det kan vara helt annorlunda, men tanken är att se det totala åtagandet.

Det ger en viss insikt. Sedan har vi projektveckor, där jag har en summa. Det här är den totala summan av veckor, inte start och stopp. Den här tidslinjen visar start och slut. Låt oss säga att projektet tar sex veckor. Jag tror att jag lade in ungefär sex veckor i tidslinjekolumnen, så vi skriver sex veckor här. Du ser att summan längst ner ökar.

Sedan har jag en tjänstetyp. Jag har bara lagt in några exempel, men du kanske har olika typer av projekt: sökmotoroptimering, webbutveckling och liknande. De visas här och kan användas för filtrering eller sortering så att du får en annan vy. Det finns också olika sätt att registrera tid, vilket kanske är relevant för det du gör här.

Det här är en kolumn för tidsregistrering. Du kan antingen trycka på start och stopp för att registrera tiden eller lägga in den manuellt. Jag kan säga att Fred arbetade med detta den 27:e från klockan 9 till 10:34. Då har jag registrerat en timme och 34 minuter.

I det här scenariot är detta konfigurerat för att användas längre fram. Vi har också ett antal andra kolumner. Den här är den tilldelade veckovisa förbrukningen. Om projektet omfattar 100 timmar och pågår i 10 veckor har du en timme per vecka som ska förbrukas. Du tilldelar alltså det du vill.

Det totala projektåtagandet gäller inte bara Fred, utan projektet som helhet. Om fem personer arbetar med det anger du det här. DPM beräknas automatiskt till sex timmar per vecka, eftersom vi har 100 timmar över sex veckor och jag har ställt in detta för automatisk beräkning.

I det här fallet säger den att projektet omfattar sex veckor. Eftersom jag redan har registrerat en timme och 34 minuter räknar den ut att vi har 98 timmar och 43 minuter kvar. Det här är bara formelkolumner som beräknar värdena. Du kan konfigurera dem annorlunda, men det är en snabb automatisk formel.

Sedan finns det en planerad veckoförbrukning. Den faktiska veckoförbrukningen och den tilldelade veckoförbrukningen behöver inte båda användas. Den tilldelade veckoförbrukningen kan exempelvis vara sex timmar per vecka enligt projektet, medan den planerade veckoförbrukningen kan vara annorlunda. Som projektledare kan du säga att vi i vecka ett, två och tre faktiskt kommer att arbeta tio timmar per vecka.

Då ändrar du den till tio timmar per vecka. Under vecka fyra, fem och sex kanske vi arbetar fem timmar. Det ändrar du manuellt. Det är den planerade veckoförbrukningen. Sedan finns planerad veckoförbrukning per person.

Den här är 16,7, vilket motsvarar värdet här. Den här är fem i stället för tio eftersom två personer arbetar i projektet. Det betyder att jag och George båda får fem timmar. Du kan konfigurera det annorlunda om exempelvis grafikdesignern behöver en annan fördelning. Det här är bara en snabb formel som jag har skapat.

Sedan har vi den faktiska veckoförbrukningen. Jag måste titta på formeln en stund för att minnas var jag lade den. Den faktiska veckoförbrukningen är projekttidregistreringen i timmar dividerad med antalet veckor som projektet har pågått.

Det betyder hur många timmar vi har registrerat och hur många veckor vi faktiskt har kommit in i projektet. Om vi är tre veckor in i projektet beräknas den faktiska veckoförbrukningen som hur många timmar vi hittills har arbetat. Här ser vi varför det står sex veckor – det var ett tag sedan jag tittade på den här delen. Det visar hur många veckor projektet omfattar och hur många veckor som återstår.

Det här är alltså några av de saker som har konfigurerats automatiskt. Här ser vi hur många timmar per vecka som återstår för att slutföra projektet enligt tidsplanen. Om noll veckor återstår och det fortfarande finns 36 timmar kvar i projektet måste vi arbeta 36 timmar den här veckan för att bli klara i tid. Det är förmodligen inte rimligt, om det inte finns fyra eller fem personer tilldelade.

Det är något att hålla koll på. Sedan har vi några andra kolumner, som planerad projektförbrukning hittills. Det visar hur många timmar vi planerade att förbruka fram till nu, och därefter den faktiska förbrukningen hittills. Då kan du se förhållandet mellan dem och avgöra om du ligger nära det du trodde från början.

Allt detta matas in i tabellen. Det som matas in i själva arbetsbelastningswidgeten är projektets timmar och, tror jag, de tilldelade veckotimmarna. Du kan ändra det, men jag tror att det är så jag har konfigurerat den. Det är projektets tidslinje och projekttimmar som används i arbetsbelastningsexemplet.

I det här fallet ser du att jag nu är överbelastad under vecka 26, 28 och 29 eftersom DPM-projektet har lagts till. Om jag ser att jag är överbelastad kan jag göra ett par saker. Jag kan flytta projektet till en period då jag är mindre upptagen, om det är möjligt. Jag kan dra tidslinjen. Jag kan omfördela någon eller lägga till någon annan.

Fred är tilldelad här och det är mycket, så låt oss även lägga till George. Nu finns George också med och vi har minskat en del av belastningen. Det är fortfarande för många timmar för både Fred och George, men nu delas det åtminstone mellan dem i stället för att allt ligger på Fred.

Det finns alltså flera saker du kan göra. Om vi drar ned tidslinjen ser det ut som att vi inte längre är överbelastade. Vi kan flytta den ett steg till. Då klarar vi det om projektet startar under vecka 29.

En annan sak jag gjorde här, men inte pratade om, var att klicka på projektet. I arbetsbelastningsvyn fälls projekten ihop, så du kan se vyn per person och se vad som händer under vecka 28. Det verkar som att de ligger på kapacitetsgränsen.

Du kan fälla ned raden och se alla projekt som personen arbetar med. För att redigera projektet klickar du på det, så öppnas en praktisk kortvy, som är relativt ny i Monday. Den fanns inte förra året. I kortvyn kan du redigera allt som jag gick igenom i tabellen.

Jag kan säga att projektet faktiskt omfattar 80 timmar i stället för 100. Då minskar kapacitetsproblemet. När kapacitetsproblemet har minskat kanske jag också kan korta tidslinjen.

Galen: Det jag uppskattar här – om jag förstår det rätt – är att du har skapat ett par anpassade fält för saker som timmar och hur du fördelar dem på projektet. Du använder formler för att förstå förbrukningen och resursfördelningen. [00:13:00]

Sedan lägger Monday på den här vyn under arbetsbelastningsfliken. Där är det ganska enkelt att visuellt föreställa sig och simulera hur det skulle se ut när du jämnar ut resurserna. Du kan också klicka dig in i vyn, som i princip är den kompakta tabellvyn, och experimentera.

Du kan säga: Okej, några av variablerna har faktiskt förändrats. Vi ligger före i arbetet, det tar inte lika lång tid som vi trodde eller det tar dubbelt så lång tid. Det driver sedan samtalet: Okej, kund eller sponsor, här är våra alternativ.

Vår förbrukning är högre än vi trodde. Vi kan lägga till George, vilket jämnar ut belastningen, men George kan inte börja förrän i mitten av juli. Där har du samtalet. Om någon säger att de inte tror på det kan du visa vyn internt och säga: Här är de fem projekt ni har bett mig driva. Vi delar resurser mellan dem. Röda punkter är dåliga. [00:14:00] Blå punkter är okej.

Fred: Du kan till och med se hur nära gränsen du är. Om vi vill hålla alla på 70 procent kanske jag vill lägga till lite mer arbete för Fred. Här ligger han på 90 eller 94 procent. Då kanske jag tar bort något eller flyttar runt något. Eftersom du prognostiserar kan du hantera mycket av detta innan det blir ett verkligt problem.

Det som är särskilt bra med den här vyn är att den fungerar som ett personligt Gantt-schema. Det finns ett Gantt-schema för hela projektet, som jag visar om en stund, där du kan se alla projekt. Här är det i stället Galens Gantt-schema. Jag kan se hur många projekt han är med i under de kommande sju veckorna, eller hur långt fram du vill titta.

Du kan titta ett år framåt eller längre. Du får en tidslinje och kan säga: Det ser ut som att Galen kommer att bli överöst med arbete i april om jag inte gör något. Låt mig se hur vi kan börja andra kvartalet på rätt sätt genom att flytta något, lägga till en resurs eller skjuta fram något som inte är högsta prioritet.

Det ger stor flexibilitet. Eftersom vyn är visuell är den särskilt bra när du kommunicerar uppåt. Människor på högre nivå har ofta ett mer övergripande perspektiv och mindre tid att gå igenom detaljerna.

Du behöver inte kasta fram en massa siffror. Du kan säga: Titta, röda punkter är dåliga och det finns sex överlappande projekt. Jag föreslår att vi flyttar det här projektet. Då kan de säga ja eller nej utan att behöva granska en mängd tabeller.

Galen: Ja, jag älskar det. Jag hade en fråga om detaljnivå. Vi pratade om att kanske lägga till en designer under några dagar i ett projekt, medan vi fördelar resurser utifrån planerade eller tilldelade förbrukningstakter.

Hur skulle du lägga till en designer under en kort period och tilldela resurser till den personen? Det verkar som att systemet utgår från ett fast antal timmar per vecka.

Fred: Ja.

Galen: För varje person i ett projekt.

Fred: Den här konfigurationen gör just det. Det finns andra sätt också. Du kan ha en tidslinje för hela projektet och sedan en tidslinje för en underpost. Jag har inte konfigurerat den här på det sättet, men låt oss låtsas att projektet pågår från januari till ett visst datum.

Hela projektet sträcker sig från den ena punkten till den andra. Sedan skapar vi en tidslinje för designern. Under perioden från den 12 juni till den 31 juli behöver vi designern från den 8:e till den 18:e.

Okej. Sedan tilldelar vi George till det. Då bör du kunna se underposten där. En annan sak du kan göra är att visa sammanfattningar på överordnade objekt. Om du klickar på tidslinjen och väljer att visa sammanfattning på överordnat objekt skapas en separat tidslinjekolumn.

Den ena är projektets tidslinje och den andra är en sammanfattning av de individuella tidslinjerna. Det finns vissa begränsningar med speglade kolumner och automatiseringar, men du kan se att tidslinjen nu sträcker sig från den 8:e till den 18:e och att det är elva dagar.

Om någon annan behöver något under den perioden sträcks tidslinjen ut och du kan se vad som redan är ifyllt. Vi kan växla till designervyn och förhoppningsvis se underposterna. George hade ett annat projekt där, så låt oss leta efter projekt A. Han var redan tilldelad projekt A, så jag tar bort honom och tilldelar mig själv till projekt A.

Nu borde vi kunna se det, om jag inte har missat något. Jag hade inte aktiverat detta för underposter. [00:18:00]

Galen: Bra. Men konceptuellt förstår jag det, eftersom du skapar en underpost för att ange att du behöver en designer i två dagar i början av augusti. Den läggs in och visas i resursfördelningen om underposterna är aktiverade.

Fred: Ja, jag aktiverade dem precis i inställningarna. Jag lade till underposterna i arbetsbelastningsexemplen och tidslinjen. Nu är designern tilldelad under den aktuella delen, precis som du sade.

Om du vill konfigurera det på det sättet har du hela tidslinjen här uppe och sedan den mer detaljerade tilldelningen här. Det kan uppstå problem om personen också är tilldelad på den överordnade projektnivån. Det kan därför vara bättre att tilldela en projektledare till hela projektet och sedan lägga designern, utvecklaren, kvalitetssäkraren och textförfattaren som underposter.

Då kan du se var designern arbetar, var utvecklaren arbetar och så vidare.

Galen: Jag älskar det. När jag arbetade på byrå var vi mycket detaljerade i vår resursfördelning. En designer kunde komma in och utföra en uppgift i två timmar under en dag. Vi arbetade nerifrån och upp och sade att vi behövde designern här, här, här och här. Sedan summerades allt.

Men i många projekt i dag, särskilt om man arbetar agilt eller har ett fast team, kanske man inte behöver göra den fördelningen nerifrån och upp. Man kanske bara säger: Jag behöver fyra personer som arbetar med detta i åtta veckor. Så fördelar vi resurserna.

Utanför kundtjänster, till exempel i ett internt projekt, kan man säga att personerna kan arbeta med projekt 50 procent av tiden och med ordinarie verksamhet 50 procent. Av en 40-timmarsvecka får vi alltså 20 timmar per vecka för projekten. Sedan tilldelar vi dem till projekt och ser under den strategiska planeringen om det fungerar.

Fred: Med Monday kan du verkligen göra det på båda sätten. Det är en låda med byggklossar. Om du förstår hur verktyget fungerar och känner till dina processer kan du få dem att fungera tillsammans i 90 procent av fallen.

När det uppstår problem finns det vanligtvis en app eller något annat som du kan använda, eller så kan du automatisera saker. Det går att konfigurera det åt båda hållen. Om du säger att vi arbetar på ett visst sätt betyder det inte att du inte kan använda Monday. Det betyder bara att du kan behöva hjälp att förstå hur du gör det i Monday.

Det är en av mina favoritdelar: jag gör aldrig samma sak två gånger. Någon kommer till mig med en utmaning och varje gång blir det problemlösning. Jag måste stanna upp och tänka: Hur gör vi detta egentligen? Vad är det bästa sättet att uppnå det?

Ibland blir det en enorm kringlösning med en massa automatiseringar, men den fungerar. Andra gånger är det sömlöst och går direkt på plats. Oavsett vilket är det anpassningsbart.

Det är därför verktyg som Monday och andra liknande verktyg tar marknadsandelar från exempelvis Microsoft Project. Microsoft Project var en gång standarden för all projektledningsprogramvara, men det var inte flexibelt, licenserna var dyra och inlärningskurvan var brant.

Du kan lära dig Monday på en timme, eller på några timmar åtminstone. Problemet är att du verkligen måste förstå hur verktyget passar ihop med dina processer. Det är där människor får problem.

Galen: Jag gillar det. Jag sätter dig kanske på prov nu, eftersom verktyget uppenbarligen utvecklas snabbt. Du visade mig gränssnitt som inte fanns för några månader sedan. Har någon av dina komplicerade kringlösningar någonsin förstörts av en förändring? Något som fungerade ena dagen men gick sönder nästa dag, så att du var tvungen att använda de nya funktionerna och bygga om allt?

Fred: Jag har faktiskt haft det motsatta problemet. Monday är väldigt bra på att inte förstöra saker. De är försiktiga med det, vilket jag uppskattar.

Problemet är att du kan lägga mycket tid på att skapa en portföljvy på hög nivå med detaljerade vyer längre ner. Du gör det på det långsamma sättet, kartlägger allt och blir riktigt bra på det. Sedan släpper Monday ett portföljverktyg, som kom för en eller två månader sedan men bara finns för företagskunder.

Det verktyget är en vy på hög nivå där alla projekt visas på portföljnivå, allt hänger ihop och du kan skapa olika paneler. Det är det vi tidigare gjorde på det svåra sättet. Nu är det vackert, enkelt och fungerar.

Jag har aldrig varit med om att de förstört något vi byggt. De är mycket bra på att undvika det. Det är mer som att jag är van vid att bära bagage och plötsligt får en skottkärra.

Galen: Ja.

Fred: Då tänker man: Okej, det här kan jag använda. När förändringen kommer är den bra, men ibland önskar man att den hade släppts tre veckor tidigare.

Galen: Åtminstone lyssnar produktteamen på användarna.

Fred: Verkligen. Som partners får vi information om nya funktioner, och de är mycket bra på att kommunicera. Vanligtvis vet vi vad som är på väg. De har aldrig förstört något.

En intressant sak är att de börjar dela upp produkten i flera produkter. Det här är arbetsledningsprodukten, en allmän produkt för det mesta. Kunder började använda den och frågade om de kunde bygga ett CRM i den. Vi började bygga CRM-system med intagsformulär, kontaktformulär och liknande.

Monday insåg att de kunde göra ett bättre jobb med en särskild plattform och byggde därför en CRM-plattform. Den lanserades för ungefär ett till ett och ett halvt år sedan. I början var den lite ojämn och vissa saker gick inte att redigera, men under det senaste året har de utvecklat den mycket.

Nu är CRM-plattformen fantastisk. Den konkurrerar väl med andra system. Den är kanske inte lika anpassningsbar som Salesforce, men den är mycket mer lättillgänglig. Den är enklare att lära sig och mycket funktionell.

Det finns e-post och aktiviteter. Du kan se när du har skickat e-post till människor och när du träffat dem. Kontakterna flyttas in i säljprocessen och systemet skapar automatiskt diagram. Det finns så många användbara funktioner som inte ens fanns för sex månader sedan.

Det är nu ett mycket konkurrenskraftigt CRM-system. Som småföretagare önskar jag nästan att jag hade större behov av det, eftersom jag vill använda det. Vi använder det för kunder, men jag skulle själv använda det om jag arbetade mer med marknadsföring.

De har också en utvecklarprodukt för utvecklingsteam, som konkurrerar med Jira. Om du vill använda Scrum-arbetsflöden kan du använda utvecklarprodukten. De har även en ny produkt som fortfarande är i betaversion och snart ska släppas, som kallas Service. Den hanterar supportärenden och hjälpförfrågningar.

Du kan få ett e-postmeddelande via ett intag, skapa ett ärende på panelen, spåra alla supportärenden, ge dem nummer, kontakta personer, föra anteckningar och överföra ägarskap. Det är lika enkelt som allt annat jag har visat.

Det är det som jag tycker är styrkan med Monday: det tar inte lång tid att lära sig. Om du utbildar ett team kan du få någon att sätta upp ett robust system och sedan utbilda teamet på en helg.

Ursäkta, jag återhämtar mig från en förkylning i bröstet. Men jag tycker verkligen att det är fantastiskt. Jag vet att vi bara har några minuter kvar. En annan sak jag ville visa snabbt är Gantt-schemat.

Galen: Ja.

Fred: Hej Google, sluta. Tekniken, alltså. Gantt-scheman kan användas för hela projektet och konfigureras på en miljon olika sätt.

Det fina är att de ger ungefär samma vy som arbetsbelastningswidgeten, men mer holistiskt. Här ser du datumintervallet, projekten, när de startar och när de flyttas. Du kan dra runt saker.

Du kan också använda beroenden. Projekt Z är exempelvis beroende av projekt D. Om du flyttar fram projekt D kan nästa projekt flyttas. Jag trodde att jag hade konfigurerat beroendena här, men det hade jag inte. Du kan dock ställa in dem så att ett projekt startar när ett annat börjar eller slutar.

Poängen är att du kan dra runt dem. Den här vyn är grupperad efter projekt och den här visar tilldelad person. Du kan se vilka projekt Fred och George arbetar med och vem som är tilldelad.

Du kan även gruppera efter tjänst. I början visade jag kanske webbdesign och anpassade arbetsflöden. Här ser du anpassat arbete, CRM och förbättring av arbetsflöden. Du kan definiera grupperna själv.

Jag kan till exempel se att jag har fyra arbetsflödesimplementeringar under andra och tredje kvartalet, men att tre av dem överlappar kraftigt. Det kanske är för mycket och jag vill förlänga ett av projekten. Du kan ta sådana samtal innan det blir ett problem.

Det finns även andra sätt att konfigurera vyn, till exempel med uppstartsdatum eller startdatum. Det finns mycket användbart att göra. Instrumentpaneler är också en stor del, så jag visar det kort.

Instrumentpanelen hämtar data. Jag har inte mycket data här, men den visar hur många timmar som återstår, den genomsnittliga förbrukningstakten och fördelningen av projekttyper. Du kan använda vilken typ av diagram, tabell eller arbetsbelastningsvy som helst på instrumentpanelen.

Du behöver alltså inte ha en separat arbetsbelastningsflik. Du kan bädda in den bland många andra delar på en instrumentpanel. [00:29:00] Möjligheterna är i princip oändliga.

Galen: Jag älskar de här vyerna och möjligheten att anpassa dem. Jag kan se hur detta skulle fungera i ett verkligt projektscenario där du har en detaljerad vy för dig själv, olika vyer för driftchef, trafikchef och resurschef och en vy för att berätta en historia för ledningsgruppen eller projektsponsorerna utan att de behöver gå igenom allt.

Det kan användas för att driva samtalet på ett mycket tydligt sätt och anpassas efter hur organisationen arbetar.

Fred: Jag vill visa en sak till snabbt. När vi satte upp detta var det faktiskt användbart för mig eftersom George byggde det och jag inte hade tittat på det så mycket som jag borde. Jag bad honom dokumentera det.

Om det uppstår ett problem i Monday är det vanligtvis något mycket litet, till exempel ett webbläsarproblem, och det går oftast snabbt att lösa. Det jag bad honom göra var att dokumentera allt. Det här är dokumentationen för panelen vi nyss tittade på.

Här finns vyerna, huvudtabellvyn, beskrivningen och alla olika kolumner. Det står vad varje kolumn betyder: hur lång tid projektet uppskattas ta, vilken formelkolumn som används och vilken formel som ska läggas in.

Längre ner finns arbetsbelastningswidgeten och de olika delarna. Jag bad honom inte dokumentera Gantt-schemat, men du kan hämta tabeller, paneler och vyer och lägga in widgetar och annat i Monday-dokument.

Det här är en mycket bra metod och den finns i rätt sammanhang. Tänk på det som en standardiserad arbetsrutin för hur panelen fungerar. Det är projektanteckningar: här är projektet, här är anteckningarna, här är de åtgärdspunkter som ska göras. Jag kan tagga dig och säga att Galen arbetar med den här delen och få uppdateringar i dokumentet.

Det är ett bra sätt att hålla allt i sitt sammanhang.

Galen: Jag älskar det. Allt finns samlat.

Fred: Ja.

Galen: Fantastiskt. Fred, stort tack för att du tog dig tid att visa oss resursfördelning, förbrukning, Gantt-scheman och allt annat. Tack också för att du delade med dig av din kunskap om Monday.

Mhm.