Giv CRM-opgaver i baggrunden en tydelig statusaftale
Når et CRM bestiller arbejde i et andet system, kan modtagelsen af bestillingen komme længe før resultatet. En statusaftale fortæller både brugere og udviklere, hvad hver besked betyder, og hvem der reagerer ved ventetid.
1. Beskriv det resultat, brugeren venter på
GitHubs asynkrone merge-API er anledning til denne generelle metode. Guiden er min anbefaling til baggrundsarbejde og hævder ikke, at et bestemt CRM har de samme statusnavne eller API-kald.
Vælg én opgave, eksempelvis generering af et internt dokument. Skriv, hvad brugeren skal kunne se eller åbne, før arbejdet kan kaldes gennemført.
- GitHub: Async merge API generally available Publiceret
2. Definér mellemtrinnene
Beskriv, hvad modtaget og i gang betyder i det konkrete system. Angiv, hvilket observerbart signal der flytter opgaven til næste trin. Brug ikke en positiv farve som erstatning for en tydelig betydning.
I et tænkt forløb kan dokumentbestillingen være modtaget, mens genereringen stadig venter. Brugeren skal kunne forstå den forskel uden at læse en teknisk log.
3. Knyt opgave og status sammen
Bevar en reference, der forbinder CRM-opgaven med den eksterne behandling. Den skal være tilgængelig for den kollega, der undersøger en fejl, uden at eksponere hemmelige værdier for brugeren.
Kontrollér, at en statusopdatering vedrører den rigtige bestilling og version. En tidligere gennemført opgave må ikke få en nyere bestilling til at se afsluttet ud.
4. Aftal behandling af lang ventetid
Beslut, hvornår en ventende opgave skal undersøges, og hvem der får ansvaret. Tidsgrænsen bør vælges efter opgaven og systemets normale behandlingstid.
Et tidsudløb i brugerfladen er ikke i sig selv dokumentation for, at den eksterne handling blev annulleret. Undersøg den eksisterende bestilling, før nogen manuelt starter nyt arbejde.
5. Afprøv hele statusforløbet
Brug ufølsomme prøver til gennemført, fejlet og fortsat ventende arbejde. Kontrollér, at beskederne og de næste handlinger passer til hvert udfald.
Aftalen er færdig, når en bruger kan forstå, hvad der sker nu, og en ansvarlig kan finde grundlaget for den viste status. Den må ikke afhænge af, at alle opgaver altid bliver hurtigt færdige.