Gør begrænsningen synlig, før du vælger arbejdet

Tolv ønskede felter står på en tænkt integrations opgaveliste. Tre afgør, om den første godkendte synkronisering kan køre: kundeidentitet, målgruppen i målsystemet og marketingtilladelse. De andre ni kan blive vigtige senere. Hvis alle felter får lige meget opmærksomhed nu, kan teamet bruge ugen på at finpudse databerigelse, mens den første sikre opdatering stadig ikke kan ske.

En grænse ændrer samtalen. Giv første udgivelse fem pladser til gennemgang, og placer et felt i hver. At tilføje et sjette betyder, at du skal navngive det felt, der ryger ud.

Det er ikke et argument for, at fem er det rigtige antal. Det er en måde at gøre prisen for endnu en forespørgsel synlig.

Samme greb virker, når flaskehalsen ikke er mennesker. En leverandør kan tillade et begrænset antal kald i en periode. Et migrationsvindue kan tillade én ændring før en revision. Et supportteam kan have tid til kun at kontrollere få kundespecifikke mappings. Den nyttige grænse er den, der ville standse resultatet, selv hvis alle andre ressourcer var rigelige.

En opgaveliste kan skjule sin egen pris

I en samtale om begrænsninger og kreativt arbejde gjorde et produktionsteam kapacitet håndgribelig med fysiske brikker, der repræsenterede en uges arbejde. Hvis teamet ville fortsætte med at finpudse en lille baggrundsdetalje, måtte det flytte brikker væk fra andre opgaver. Grebet afgjorde ikke, hvad der var smukt. Det gjorde afvejningen svær at ignorere.

Softwareteams holder som regel brikkerne usynlige. En forespørgsel kommer ind i et opgavesystem, får et prioritetsmærke og ligger ved siden af tyve andre »vigtige« forespørgsler. Ingen af mærkerne fortæller, hvilken gennemgang, migration eller kundesamtale der må vente, for at opgaven kan blive færdig.

I en integration kan den knappe ressource være en leverandørs grænse for kald. Det kan være adgang til en rigtig testkonto. Det kan være tiden til at undersøge samtykkets betydning. En synlig begrænsning bør navngive den ressource, der sætter grænsen for resultatet, og vise, hvordan det foreslåede arbejde bruger den.

Tajos guide til at integrere virksomhedsværktøjer beder teams fastlægge arbejdsgangen og den autoritative kilde først. Det er én måde at hindre, at opgavelisten vokser omkring alle tænkelige felter. Den første synkronisering skal have de data, dens faktiske resultat kræver.

Vælg de afgørende dele, og udskyd resten

Den tænkte mapping med tolv felter har nogle få afgørende punkter. Identitet bestemmer, hvilken post i målsystemet der ændres. Tilladelse bestemmer, om posten må bruges til marketing. Medlemskab af en målgruppe bestemmer, hvilken arbejdsgang der modtager den. Hvis de tre er forkerte, kan de øvrige ni ikke redde resultatet.

En planlægningstavle kan vise de afgørende punkter sammen med den kapacitet, de bruger. Antag, at hvert punkt kræver en feltdefinition, et testgrundlag og en kontrol i målsystemet. Reserver de kontroller først. Et ekstra præferencefelt skal derefter besvare et konkret spørgsmål: Ændrer det den første fungerende synkronisering, eller kan det vente?

At vente er ikke en dom om, at feltet er uvigtigt. Det er en delvis rækkefølge. Den næste afhængighed er afgjort. Alt andet er stadig tilgængeligt, når dokumentation eller kundebehov gør det relevant.

Gør udsættelsen tydelig. Sæt de ni øvrige felter i en senere kø med den betingelse, der ville rykke hvert felt frem: en navngivet anvendelse, en kundepost, der har brug for det, eller en leverandørkontrakt, der gør det obligatorisk. Det er noget andet end at miste forespørgslen i en opgaveliste. En kø med tydelige betingelser bevarer mulighederne og beskytter det første resultat mod spekulativ udvidelse.

En rimelig indvending er: »Kunstige grænser kan hæmme et team og skjule en værdifuld idé.« Ja. En grænse, der beskytter en dårlig prioritet, bliver et problem. Løsningen er at skrive resultatet ved siden af grænsen og genoverveje begge. Hvis et nyopdaget felt er nødvendigt for samtykke, fortrænger det straks et berigelsesfelt. Begrænsningen gør ændringen synlig frem for at forhindre den.

Kapacitetsbrikker viser også uenighed, som prioritetsmærker skjuler. Et team kan tro, at flaskehalsen er udviklingstid. Et andet ved måske, at den reelle ventetid ligger hos målsystemets kontoadministrator. Så hjælper det ikke at reservere mere udviklingstid. Følg arbejdet frem til godkendelsen af den første opdatering, og placer grænsen ved det trin, der faktisk holder forløbet tilbage.

Hvad fortjener en plads i den første synkronisering?

1. Nødvendigt for identitet, tilladelse eller målgruppe

   Kontrollér nu

   Uden det er den første godkendte opdatering ikke defineret.

2. Nødvendigt for en navngivet senere anvendelse

   Sæt en betingelse for at rykke frem

   Bevar forespørgslen uden at forsinke det første resultat.

3. Ingen defineret virkning på resultatet

   Udskyd forespørgslen

   Brug ikke den knappe gennemgangsplads på spekulativ udvidelse.

Mål, hvad grænsen gav

Den graf, der er værd at tegne, viser ikke »opgaver lukket denne måned«. Den viser vejen fra en forespørgsel til det første korrekte resultat, med noter om det, der blokerede vejen. Forsvandt gennemgangstiden i valgfrie felter? Forsinkede en manglende leverandørdefinition alle tests? Sparede teamet tid ved at udskyde et dashboard, som ingen bruger behøvede for at aktivere løsningen?

Opfind ikke en forbedring af gennemløbet. Registrer før og efter for et rigtigt parti: dage til godkendt mapping, antal felter kontrolleret i målsystemet og antal problemer fundet efter aktivering. En synlig begrænsning er kun nyttig, hvis den ændrer de resultater.

Guiden til reverse ETL skelner mellem den planlagte dataflytning og arbejdet med at definere dens mapping. Det er i mappingen, at den tidlige afgrænsning har størst virkning. Flere data kan altid tilføjes senere. Den første kontrakt skal være korrekt nu.

En liste viser, hvad nogen bad om. En synlig grænse viser, hvad forespørgslen koster.