Tjue prosjekter uten et regneark

Hva regnearket gjorde for deg

De fleste regneark for byråer svarer på tre spørsmål. Hvor er hvert prosjekt akkurat nå. Hvem har for mye arbeidsbelastning denne uken. Hvilket prosjekt kommer til å bli forsinket. Regnearket svarer bare så godt som den siste personen som oppdaterte det, og ved tjue prosjekter bruker denne personen tiden på å oppdatere det i stedet for å drive prosjektene.

Tasked svarer på de samme tre spørsmålene basert på registreringer teamet produserer ved å jobbe, ikke ved å rapportere. En oppgave flyttes fra ett steg til det neste på en tavle; denne flyttingen er registreringen. Alt nedenfor er bygget på dette, og ingenting av det krever at noen fyller ut en celle.

Én tavle per prosjekt, fra en mal

Hvert prosjekt kjører på en arbeidsflyttavle kopiert fra en mal. Tasked leveres med ti arbeidsflytpakker for generelt arbeid (sprint, hendelse, designforespørsel, kampanje, feilretting, godkjenningsflyt, testsyklus, utgivelse, programvare, prosjektlevering) pluss fem for video (reklamefilm, dokumentar, bryllup, bedrift, pakke for sosiale medier). En mal navngir stegene i rekkefølge, gir hvert steg sine SLA-timer, og markerer hvilke steg som er godkjenninger.

Malen for reklamefilm har for eksempel ti steg. Brief har 48 timer, Manus 72, Manusgodkjenning 48, Preproduksjon 120, Opptak 48, Klipp 120, Gjennomgang av grovklipp 48, Godkjenning av endelig klipp 72, Levering 24, og deretter Ferdig. Disse timene er malverdier du endrer per organisasjon; de er ikke et løfte Tasked gir om studioet ditt.

Godkjenningssteg åpner en kundeportal som ikke krever noen konto. Kunden kommer inn via en kode, en lenke, et telefonnummer eller en e-post, ser på klippet frame-nøyaktig med sin originale kildeframerate (inkludert 23,976 og 29,97), legger igjen tidsbestemte kommentarer, og godkjenner, avviser eller ber om endringer. Beslutningen flytter oppgaven på tavlen, og den flyttingen registreres som alle andre.

Registreringen analysene bygger på

Hver gang en oppgave går inn i et steg, åpner Tasked et intervall, og hver gang den forlater det, lukkes det, i samme databasetransaksjon som selve flyttingen. En oppgave som sendes tilbake til samme steg, starter unødig et nytt intervall. Et intervall som fremdeles er åpent, teller frem til nå.

Intervaller grupperes etter stegnavn på tvers av prosjekter, ikke etter den enkelte tavlen. Hvert prosjekt har sin egen kopi av arbeidsflyten, så Klipp-steget på prosjekt A og Klipp-steget på prosjekt B er forskjellige rader; analysene behandler dem som samme steg fordi de har samme nøkkel.

Endringsloggen i bunnen kan bare skrives til (append-only). Det finnes ingen mulighet for å oppdatere eller slette i applikasjonen, så et tall på en analyseskjerm kan alltid spores tilbake til hendelsene som skapte det.

Fem visninger, ett sett med tall

En daglig jobb slår sammen gårsdagens hendelser til én rad per organisasjon, per prosjekt og per medlem, og beregner en poengsum for risiko for forsinket levering for hvert prosjekt. De fem analysevisningene leser disse radene; de beregner aldri alt på nytt fra bunnen av, og det er derfor to skjermer aldri kan vise ulike tall.

• Portefølje: oppgaver fullført i tidsrommet, åpne og forsinkede oppgaver nå, timer brukt på å vente på kunder, gjennomsnittlig syklustid, og antall dager uten data.
• Flaskehalser: mediantiden i hvert steg, fra registrerte intervaller, med det tregeste steget først.
• Kunder: hvilke prosjekter som venter på en kundegodkjenning, og hvor mange dager de har ventet.
• Arbeidsbelastning: hver persons åpne arbeidsmengde i minutter mot deres ukentlige kapasitet, med antall åpne, forsinkede og fullførte oppgaver.
• Risiko: en poengsum fra 0 til 100 per prosjekt med årsakene som bidrar til den, fordelt på tre nivåer: lav, følg med og høy.

Den ukentlige rapporten, og hva den ikke gjør

Mandag morgen mottar eieren en rapport for de siste sju dagene på e-post og som et varsel i appen. Rapporten viser fullførte, åpne og forsinkede oppgaver, timer som venter på kunder, de tre tregeste stegene, de tre prosjektene som har ventet lengst på en kunde, de tre travleste personene og de tre prosjektene med høyest risiko.

Tallene beregnes først. AI-en får deretter overlevert disse tallene og blir bedt om tre til fem setninger og nøyaktig tre foreslåtte tiltak, der hvert tiltak er knyttet til et av de oppførte tallene. Den blir aldri bedt om å oppgi et tall. Hvis teksten ikke lar seg generere, venter e-posten på neste kjøring, mens oppføringen i appen fortsatt leveres med tallene.

Slik kommer du i gang

Velg en mal som samsvarer med hvordan prosjektene dine allerede kjører, og juster SLA-timene til det du faktisk forventer. Inviter teamet og opprett et team med en ukentlig kapasitet hvis standarden på 2 400 minutter (fem dager à åtte timer) ikke passer for dere. Send kundene inn via kundeportalen fra første godkjenning, slik at ventetiden registreres fra dag én.

Kjør deretter i en måned. Etter det har flaskehalsvisningen nok intervaller til å være pålitelig, risikopoengsummen har steghistorikk å trekke veksler på i stedet for standardverdien, og prosessrevisjonen kan fortelle deg hvilken SLA du satte feil.

• Tavler: ti generelle pakker og fem videopakker, hver med SLA-timer per steg.
• Registreringer: et intervall per oppgave per steg, en endringslogg som er append-only.
• Visninger: portefølje, flaskehalser, kunder, arbeidsbelastning, risiko.
• Rapport: tall først, deretter tekst, hver mandag.