Slik bygger du en oppgavehåndteringsapp: huskelister, kanban og team

For å bygge en oppgavehåndteringsapp, start med en oppgave som har tittel, status, ansvarlig og frist, grupper oppgavene i prosjekter, og gi folk ett godt overblikk: en liste, eller en kanbantavle med kolonner for hver status. Legg til innlogging slik at hver person ser sitt eget arbeid, og deretter kommentarer og varsler. Et AI-verktøy for apper kan lage dette ut fra en beskrivelse på én økt. Det vanskeligere spørsmålet er om du bør gjøre det: generelle oppgaveverktøy er modne og billige, så en egen løsning er bare verdt det når arbeidet ditt har en form de ikke passer til.

Når det er fornuftig å bygge selv

Vær ærlig om dette først, for svaret er ofte «bruk et eksisterende verktøy». Egne oppgaveapper er verdt det når:

• Oppgavene dine følger en fast arbeidsflyt. Jobbene til et renholdsfirma trenger en sjekkliste, bilder før og etter og godkjenning fra kunden. En rekrutterers oppgaver følger et ansettelsestrinn. Generelle verktøy kan tilnærme seg dette, men det blir klønete.
• Oppgavene kommer fra andre data dine. En ny ordre, en supporthenvendelse eller en mislykket inspeksjon bør lage en oppgave automatisk.
• Du trenger spesifikke felt og regler. «En oppgave kan ikke lukkes uten et bilde», «bare ledere kan flytte kort til Godkjent».
• Personene som gjør jobben, er ikke kontorfolk. Feltarbeidere eller innleide vil ha ett skjermbilde med dagens jobber, ikke et helt prosjektverktøy.
• Pris per plass gjør vondt. Mange sporadiske brukere kan bli dyre på planer med pris per plass.

Hvis ingen av disse gjelder, er et modent oppgaveprodukt sannsynligvis det bedre valget. Hvordan erstatte dyr SaaS med ditt eget verktøy dekker avveiningene mer generelt.

Hva appen trenger

Kjernedata

For en arbeidsflytapp legger du til feltene som gjør arbeidet ditt annerledes: en sjekkliste per oppgave, en kunde, et sted, påkrevde bilder, et godkjenningstrinn.

Visninger

Bygg én visning godt før du legger til flere. For et team er kanbantavlen vanligvis det mest nyttige utgangspunktet; for personlig bruk, en liste med seksjonene «I dag» og «Kommende».

Avgjørelser før du bygger

Personlig eller team

En personlig huskeliste-app kan være veldig enkel: én bruker, ingen tillatelser, kanskje ingen innlogging hvis den bare kjører for deg. Det er et godt første prosjekt, likt i formen til en vanesporer. En teamapp trenger kontoer, delte prosjekter, ansvarlige og regler for hvem som kan se og endre hva. Det er der mesteparten av byggearbeidet ligger.

Faste eller egne statuser

Faste statuser (Å gjøre, Pågår, Ferdig) er enklere å bygge, rapportere på og holde konsekvente. Egne kolonner per prosjekt er mer fleksible, men gjør rapporter vanskeligere, fordi «Ferdig» kan hete noe annet i hvert prosjekt. Hvis du trenger egne kolonner, gi hver en skjult «kategori» (ikke startet, aktiv, avsluttet), slik at rapportene fortsatt fungerer.

Direkte oppdateringer eller oppfriskning

Hvis to personer har samme tavle åpen og den ene flytter et kort, skal den andre se det flytte seg med en gang? Direkte oppdateringer føles bra, men gir mer kompleksitet (en sanntidsforbindelse, og håndtering av at to personer redigerer samme oppgave). For små team holder det ofte å oppfriske når siden får fokus, pluss et tydelig «sist oppdatert»-tidspunkt, for å komme i gang.

Varsler

Bestem hva som utløser et varsel, ellers slår folk av dem alle sammen. Et fornuftig utgangssett: du ble tildelt en oppgave, noen kommenterte din oppgave, en oppgave du eier forfaller i morgen. E-post er den enkleste kanalen; en daglig oppsummering er snillere enn én e-post per hendelse.

Bygg det steg for steg

Steg 1: Beskriv arbeidsflyten, ikke funksjonene

Skriv ned hvordan en oppgave oppstår, hvem som jobber med den, trinnene den går gjennom, og hva «ferdig» betyr. Det er din første prompt.

Bygg en oppgavetavle for Brightside Cleaning, et team med 12 renholdere og 2 ledere. Ledere oppretter jobber med kunde, adresse, dato, tildelt renholder og en sjekkliste valgt fra maler (standard rengjøring, grundig rengjøring, rengjøring ved leieavslutning). Tavlekolonner: Planlagt, Pågår, Må gjennomgås, Ferdig. Renholdere logger inn og ser bare sine jobber for i dag, som en telefonvennlig liste; de krysser av sjekklistepunkter, laster opp minst ett bilde etter rengjøring, og trykker «Ferdig», som flytter jobben til Må gjennomgås. Bare ledere kan flytte jobber til Ferdig. Lagre alt i en database. Enkel, tydelig design med store knapper.

Steg 2: Få kjerneløkken riktig

Opprett en oppgave, tildel den, flytt den gjennom hvert trinn, og fullfør den. Gjør dette som hver type bruker. Sjekk at folk bare kan se og gjøre det de skal: logg inn som en renholder og prøv å åpne en annen renholders jobb via URL.

Steg 3: Gjør tavlen god å bruke

Dra-og-slipp på en kanbantavle krever omsorg: kort skal bli værende der du slipper dem etter en oppfriskning, rekkefølgen i en kolonne skal lagres, og det må fungere med berøring på telefoner og nettbrett. Test med 50 eller flere oppgaver, slik at du ser hvordan det oppfører seg med reell mengde, ikke bare fem eksempelkort.

Steg 4: Legg til kommentarer, filer og aktivitet

Kommentarer holder diskusjonen på oppgaven i stedet for i chatapper. En aktivitetslogg («Sam flyttet denne til Gjennomgang, 15:14») svarer på de fleste spørsmål om hva som skjedde. Filopplastinger krever lagring og en størrelsesgrense.

Steg 5: Legg til varsler

Start med e-post for tildelinger og påminnelser om frist i morgen. Hvordan sende e-post fra appen din dekker leverandører og oppsett.

Steg 6: Flytt ekte arbeid inn gradvis

Kjør ett prosjekt eller ett team på den i et par uker. Behold det gamle verktøyet skrivebeskyttet i stedet for å slette det før folk stoler på det nye.

Vanlige feil

• Å bygge et generelt verktøy funksjon for funksjon. Hvis du legger til Gantt-diagrammer, tidsregistrering og dokumenter, konkurrerer du med produkter som har gjort dette i årevis. Hold fokus på arbeidsflyten din.
• Ingen tillatelser. I en teamapp vil noen slette andres oppgave før du tror. Legg til et bekreftelsestrinn og myk sletting.
• Å glemme tidssoner på frister. «Forfaller fredag» bør bety fredag der personen er.
• For mange varsler. Folk ignorerer alle sammen. Start med få, og la folk velge selv.
• Å ikke lagre rekkefølgen. En tavle som stokker om kort ved hver oppfriskning er ubrukelig.
• Å bare teste på en laptop. Mange oppgaveoppdateringer skjer på telefoner.

Når et ferdig produkt er det bedre valget

Trello, Asana, Todoist, Linear, Notion, ClickUp og mange andre er modne og godt testet, med mobilapper, integrasjoner og i flere tilfeller frakoblet støtte som ville tatt lang tid å bygge selv. Bruk et av dem når:

• Arbeidet ditt er generelt kunnskapsarbeid: prosjekter, frister, tildelinger
• Du trenger native mobilapper med frakoblet støtte
• Du vil ha dusinvis av integrasjoner med andre verktøy fra dag én
• Ingen på teamet vil eie et stykke programvare

Bygg selv når arbeidsflyten er produktet, når oppgavene må kobles til dine egne data, eller når verktøyet du trenger er en brøkdel av et stort produkt priset per plass. Mange egne oppgaveapper er egentlig interne verktøy med en tavle på toppen.

Bygge det med Mythex

Mythex er et AI-verktøy for apper: du beskriver arbeidsflyten din, og det bygger tavlen, listene og skjemaene i en live forhåndsvisning, og legger til en database i prosjektet for oppgaver og kommentarer, og fillagring for vedlegg og bilder. Bruk Planleggingsmodus først hvis du vil bli enige om statuser og roller før det skrives kode, og sjekkpunkter lar deg rulle tilbake en endring som går galt. Det er én ting du bør vite: Mythex-kontoer og medarbeidere er for folkene som bygger appen. Folkene som bruker oppgaveappen din trenger sin egen innlogging, som du legger til med et autentiseringsbibliotek eller en leverandør du velger; se hvordan legge til innlogging i appen din og dokumentasjonen om legge til autentisering og bygge en CRUD-app.

For å starte fra en skrevet første prompt, prøv malen for teamets kanbantavle eller malen for agile sprinttavler.

Spørsmål