Gjør begrensningen synlig før du velger arbeidet

Tolv ønskede felt står på oppgavelisten til en tenkt integrasjon. Tre avgjør om den første godkjente synkroniseringen kan kjøre: kundeidentitet, målgruppe i målsystemet og tillatelse til markedsføring. De andre ni kan bli viktige senere. Hvis alle felt får like mye oppmerksomhet nå, kan teamet bruke uken på å finpusse databerikelse mens den første trygge oppdateringen fortsatt ikke kan skje.

En grense endrer samtalen. Gi den første lanseringen fem plasser til gjennomgang, og sett ett felt i hver. Skal et sjette felt inn, må du navngi feltet som går ut.

Det betyr ikke at fem er riktig antall. Det gjør bare kostnaden ved enda en forespørsel synlig.

Det samme grepet virker når flaskehalsen ikke er mennesker. En leverandør kan tillate et begrenset antall forespørsler i en periode. Et migreringsvindu kan tillate én endring før en revisjon. Et støtteteam kan ha tid til å kontrollere bare noen få kundespesifikke mappinger. Den nyttige grensen er den som ville stoppet resultatet selv om alle andre ressurser var rikelige.

En oppgaveliste kan skjule sin egen pris

I en diskusjon om begrensninger og kreativt arbeid gjorde et produksjonsteam kapasitet håndgripelig med fysiske brikker som representerte en arbeidsuke. Hvis teamet ville fortsette å polere en liten detalj i bakgrunnen, måtte det flytte brikker bort fra annet arbeid. Grepet avgjorde ikke hva som var vakkert. Det gjorde avveiningen vanskelig å overse.

Programvareteam holder som regel brikkene usynlige. En forespørsel kommer inn i et oppgavesystem, får en prioritetsmerkelapp og ligger ved siden av tjue andre «viktige» forespørsler. Ingen av merkelappene forteller hvilken gjennomgang, migrering eller kundesamtale som må vente for at den nye oppgaven skal bli ferdig.

I en integrasjon kan den knappe ressursen være leverandørens grense for forespørsler. Det kan være tilgang til en ekte testkonto. Det kan være tiden det tar å undersøke hva samtykke betyr. En synlig begrensning bør navngi ressursen som holder resultatet tilbake, og vise hvordan det foreslåtte arbeidet bruker den.

Tajos guide til å koble sammen bedriftsverktøy ber teamet finne arbeidsflyten og datakilden som er fasit først. Det hindrer at oppgavelisten vokser rundt alle tenkelige felt. Den første synkroniseringen trenger bare dataene som det faktiske resultatet krever.

Velg de avgjørende punktene, utsett resten

Den tenkte mappingen med tolv felt har noen få avgjørende punkter. Identitet bestemmer hvilken post i målsystemet som endres. Tillatelse bestemmer om posten kan brukes til markedsføring. Målgruppetilhørighet bestemmer hvilken arbeidsflyt som får den. Hvis disse tre er feil, kan ikke de andre ni redde resultatet.

En planleggingstavle kan vise disse punktene sammen med kapasiteten de bruker. Anta at hvert punkt krever en feltdefinisjon, et testgrunnlag og en kontroll i målsystemet. Sett av tid til disse kontrollene først. Et ekstra preferansefelt må så svare på et konkret spørsmål: Endrer det den første fungerende synkroniseringen, eller kan det vente?

Å vente er ikke en dom over feltets verdi. Det er en delvis rekkefølge. Neste nødvendige avhengighet er avgjort. Alt annet er fortsatt tilgjengelig når data eller kundebehov gjør det relevant.

Gjør utsettelsen tydelig. Sett de ni andre feltene i en senere kø med betingelsen som kan løfte hvert felt frem: et navngitt bruksområde, en kundepost som trenger det, eller en leverandørkontrakt som gjør det påkrevd. Det er noe annet enn å miste forespørselen i en oppgaveliste. En kø med betingelser bevarer muligheter og beskytter det første resultatet mot spekulativt omfang.

En rimelig innvending er: «Kunstige grenser kan hemme teamet og skjule en verdifull idé.» Ja. En grense som beskytter feil prioritet, blir et problem. Løsningen er å skrive resultatet ved siden av grensen og vurdere begge på nytt. Hvis et nylig oppdaget felt er nødvendig for samtykke, skyver det straks ut et berikelsesfelt. Begrensningen gjør endringen synlig i stedet for å hindre den.

Kapasitetsbrikkene avslører også uenighet som prioritetsmerkelapper skjuler. Ett team kan tro at flaskehalsen er utviklingstid. Et annet vet kanskje at den virkelige ventetiden ligger hos administratoren for målkontoen. Da hjelper det ikke å sette av mer utviklingstid. Følg arbeidet frem til den første oppdateringen er godkjent, og plasser grensen der veien faktisk stopper.

Hva fortjener en plass i den første synkroniseringen?

1. Nødvendig for identitet, tillatelse eller målgruppe

   Kontroller nå

   Uten dette er ikke den første godkjente oppdateringen definert.

2. Nødvendig for et navngitt senere bruksområde

   Sett en betingelse for prioritering

   Behold forespørselen uten å forsinke det første resultatet.

3. Ingen definert virkning på resultatet

   Utsett forespørselen

   Ikke bruk den knappe plassen på spekulativt omfang.

Mål hva grensen ga

Grafen som er verdt å tegne, viser ikke «oppgaver lukket denne måneden». Den viser veien fra en forespørsel til det første riktige resultatet, med merknader om hva som stoppet den. Forsvant gjennomgangstiden i valgfrie felt? Forsinket en manglende leverandørdefinisjon alle testene? Sparte teamet tid ved å utsette et dashboard som ingen bruker trengte for aktivering?

Ikke finn på en forbedring i gjennomstrømning. Registrer før og etter for et ekte parti: dager frem til godkjent mapping, antall felt kontrollert i målsystemet og antall problemer funnet etter aktivering. En synlig begrensning er nyttig bare hvis den endrer disse resultatene.

Guiden til reverse ETL skiller mellom planlagt dataflytting og arbeidet med å definere mappingen. Det er i mappingen at tidlig avgrensning har størst virkning. Flere data kan legges til senere. Den første kontrakten må være riktig nå.

En liste viser hva noen ba om. En synlig grense viser hva forespørselen koster.