Tyve projekter uden et regneark

Hvad regnearket gjorde for dig

De fleste regneark i bureauer besvarer tre spørgsmål. Hvor er hvert enkelt projekt lige nu. Hvem bærer for meget i denne uge. Hvilket projekt bliver forsinket. Regnearket besvarer dem kun så godt som den sidste person, der opdaterede det, og ved tyve projekter opdaterer den person det i stedet for at køre projekterne.

Tasked besvarer de samme tre spørgsmål ud fra registreringer, som teamet producerer ved at arbejde, ikke ved at rapportere. En opgave flytter sig fra én fase til den næste på et board; den flytning er registreringen. Alt herunder er bygget ud fra det, og intet af det kræver, at nogen udfylder en celle.

Et board pr. projekt, fra en skabelon

Hvert projekt kører på et workflow-board kopieret fra en skabelon. Tasked leveres med ti workflow-pakker til generelt arbejde (sprint, incident, design request, campaign, bugfix, approval flow, test cycle, release, software, project delivery) plus fem til video (commercial, documentary, wedding, corporate, social content batch). En skabelon navngiver faserne i rækkefølge, giver hver fase dens SLA-timer og markerer, hvilke faser der er godkendelser.

Skabelonen til en reklamefilm har for eksempel ti faser. Brief tager 48 timer, Script 72, Script-godkendelse 48, Pre-production 120, Shoot 48, Edit 120, Rough cut-review 48, Final cut-godkendelse 72, Delivery 24, og derefter Done. Disse timer er skabelonværdier, du ændrer pr. organisation; de er ikke et løfte, Tasked giver om dit studie.

Godkendelsesfaser åbner en kundeportal, som ikke kræver en konto. Kunden ankommer via en kode, et link, et telefonnummer eller en e-mail, ser sit cut frame-præcist med dets oprindelige frame rate (inklusive 23,976 og 29,97), efterlader tidsstemplede noter og godkender, afviser eller anmoder om ændringer. Beslutningen flytter opgaven på boardet, og den flytning registreres ligesom alle andre.

Registreringen, som analysen er bygget på

Hver gang en opgave går ind i en fase, åbner Tasked et interval, og hver gang den forlader den, lukkes det i samme databasetransaktion som selve flytningen. En opgave, der sendes tilbage til den samme fase, starter et nyt interval. Et interval, der stadig er åbent, tæller op til nu.

Intervaller grupperes efter fasenavnet på tværs af projekter, ikke efter det enkelte board. Hvert projekt har sin egen kopi af workflowet, så Edit-fasen på projekt A og Edit-fasen på projekt B er forskellige rækker; analysen behandler dem som den samme fase, fordi de har samme nøgle.

Den underliggende revisionslog er append-only. Der er ingen opdaterings- eller sletningsmulighed for den i applikationen, så et tal på en analyseskærm kan altid spores tilbage til de hændelser, der skabte det.

Fem visninger, ét sæt tal

Et dagligt job samler gårsdagens hændelser i én række pr. organisation, pr. projekt og pr. medlem, og beregner en score for risikoen for forsinket levering for hvert projekt. De fem analysevisninger læser disse rækker; de genberegner aldrig fra bunden, hvilket er grunden til, at to skærme ikke kan være uenige.

• Portefølje: opgaver fuldført i tidsrummet, åbne og overskredne nu, timer brugt på at vente på kunder, gennemsnitlig cyklustid og antallet af dage uden data.
• Flaskehalse: mediantiden i hver fase, fra registrerede intervaller, med den langsomste fase først.
• Kunder: hvilke projekter der venter på en kundegodkendelse, og i hvor mange dage.
• Arbejdsbelastning: hver persons åbne arbejdsbelastning i minutter i forhold til deres ugentlige kapacitet, med antal åbne, overskredne og fuldførte opgaver.
• Risiko: en score fra 0 til 100 pr. projekt med de årsager, der bidrager til den, i tre niveauer: lav, hold øje og høj.

Den ugentlige rapport, og hvad den ikke gør

Mandag morgen modtager ejeren en rapport for de seneste syv dage via e-mail og som en notifikation i appen. Rapporten viser fuldførte, åbne og overskredne opgaver, timer brugt på at vente på kunder, de tre langsomste faser, de tre projekter, der venter længst på en kunde, de tre mest travle personer og de tre mest risikofyldte projekter.

Tallene beregnes først. Derefter overdrages disse tal til AI'en, som bliver bedt om tre til fem sætninger og præcis tre foreslåede handlinger, der hver især er knyttet til et af de listede tal. Den bliver aldrig bedt om et tal. Hvis teksten ikke kan genereres, venter e-mailen på næste kørsel, og visningen i appen lander stadig med tallene.

Hvor skal man starte

Vælg en skabelon, der matcher den måde, dine projekter allerede kører på, og tilpas SLA-timerne til det, du rent faktisk forventer. Inviter teamet, og opret et team med en ugentlig kapacitet, hvis standarden på 2.400 minutter (fem dage af otte timer) ikke passer til dig. Send kunderne ind gennem portalen fra den allerførste godkendelse, så ventetiden registreres fra dag ét.

Kør derefter i en måned. Derefter har flaskehalsvisningen nok intervaller til at være retvisende, risikoscoren har fasehistorik at trække på i stedet for standardværdien, og procesrevisionen kan fortælle dig, hvilken SLA du har sat forkert.

• Boards: ti generelle pakker og fem videopakker, hver med SLA-timer pr. fase.
• Registreringer: et interval pr. opgave pr. fase, en append-only revisionslog.
• Visninger: portefølje, flaskehalse, kunder, arbejdsbelastning, risiko.
• Rapport: tal først, derefter ord, hver mandag.