Visa begränsningen innan du väljer arbetet

Tolv begärda fält står på en illustrativ lista för en integration. Tre avgör om den första godkända synkroniseringen kan köras: kundidentitet, målgrupp i målsystemet och tillstånd för marknadsföring. De andra nio kan bli viktiga senare. Om varje fält får lika mycket uppmärksamhet nu kan teamet ägna veckan åt att putsa berikning medan den första säkra skrivningen fortfarande inte går att göra.

En gräns ändrar samtalet. Ge den första versionen fem platser för granskning och lägg varje fält på en plats. Ett sjätte fält kräver att du namnger det fält som får lämna platsen.

Det betyder inte att fem är rätt antal. Det gör kostnaden för ännu en begäran synlig.

Samma grepp fungerar när flaskhalsen inte är människor. En leverantör kan tillåta bara ett visst antal anrop per period. Ett migrationsfönster kan rymma en enda ändring före en revision. Ett supportteam kanske bara hinner verifiera några kundspecifika mappningar. Den användbara gränsen är den som skulle stoppa resultatet även om allt annat fanns i överflöd.

En uppgiftslista kan dölja sitt eget pris

I ett samtal om begränsningar och kreativt arbete gjorde ett produktionsteam sin kapacitet påtaglig med fysiska markörer för en arbetsvecka. För att fortsätta finslipa en liten bakgrundsdetalj måste de flytta markörer från annat arbete. Metoden avgjorde inte vad som var vackert. Den gjorde avvägningen svår att ignorera.

Programvaruteam håller vanligtvis markörerna osynliga. En begäran hamnar i en uppgiftslista, får en prioritetsmarkering och står bredvid tjugo andra ”viktiga” begäranden. Ingen markering säger vilken granskning, migration eller kunddiskussion som måste vänta för att arbetet ska bli klart.

För en integration kan det knappa vara leverantörens anropsgräns. Det kan vara tillgången till ett riktigt testkonto eller tiden som krävs för att förstå betydelsen av samtycke. En synlig begränsning bör namnge resursen som hindrar resultatet och visa hur det föreslagna arbetet använder den.

Tajos guide för att integrera företagsverktyg ber teamen identifiera arbetsflödet och den styrande källan först. Då växer inte listan kring varje tänkbart fält. Den första synkroniseringen behöver de data som dess verkliga resultat kräver.

Välj nyckelfälten och vänta med resten

Den illustrativa mappningen med tolv fält har några få nycklar. Identitet avgör vilken post i målsystemet som ändras. Tillstånd avgör om posten får användas för marknadsföring. Målgruppstillhörighet avgör vilket flöde den går in i. Om de tre blir fel kan de andra nio inte rädda resultatet.

En planeringstavla kan visa nyckelfälten bredvid kapaciteten de tar. Anta att varje fält behöver en definition, ett testfall och en kontroll i målsystemet. Reservera de kontrollerna först. Ett extra preferensfält måste då svara på en konkret fråga: ändrar det den första fungerande synkroniseringen, eller kan det vänta?

Att vänta är inte ett omdöme om att fältet saknar värde. Det är en partiell ordning. Nästa beroende är avgjort; resten finns kvar när underlag eller kundbehov gör det relevant.

Gör uppskjutandet tydligt. Lägg de nio övriga fälten i en senare kö med ett villkor för när vart och ett ska flyttas fram: ett namngivet användningsfall, en kundpost som behöver det eller ett leverantörskontrakt som kräver det. Det skiljer sig från att tappa bort begäran i en uppgiftslista. En villkorad kö bevarar möjligheter och skyddar det första resultatet från spekulativ omfattning.

En rimlig invändning är: ”Konstgjorda gränser kan hämma teamet och dölja en värdefull idé.” Ja. En gräns som skyddar fel prioritet blir ett problem. Skriv resultatet bredvid gränsen och ompröva båda. Om ett nyupptäckt fält krävs för samtycke ska det genast ersätta ett berikningsfält. Gränsen gör ändringen synlig i stället för att förhindra den.

Kapacitetsmarkörer blottlägger också oenighet som prioritetsmarkeringar döljer. Ett team kan tro att utvecklingstid är flaskhalsen; ett annat vet att den verkliga väntan gäller administratören för målkontot. Då hjälper inte fler utvecklingsplatser. Följ arbetet tills den första skrivningen har godkänts och sätt gränsen där vägen faktiskt blockeras.

Vad får en plats i den första synkroniseringen?

1. Krävs för identitet, tillstånd eller målgrupp

   Verifiera nu

   Utan det är den första godkända skrivningen inte definierad.

2. Krävs för ett namngivet senare användningsfall

   Ange villkor för att flytta fram

   Behåll begäran utan att försena första resultatet.

3. Ingen definierad effekt på resultatet

   Skjut upp begäran

   Lägg inte knapp granskningstid på spekulativ omfattning.

Mät vad gränsen gav

Grafen som är värd att rita är inte ”avklarade begäranden denna månad”. Den är vägen från begäran till första korrekta resultat, med anteckningar om vad som stoppade vägen. Gick granskningstiden åt till valfria fält? Försenade en saknad leverantörsdefinition varje test? Sparade teamet tid genom att skjuta upp en dashboard som ingen behövde för att aktivera?

Hitta inte på en ökning i genomströmning. Registrera före och efter för en verklig grupp: dagar till godkänd mappning, antal fält som kontrollerades i målsystemet och antal problem som hittades efter aktivering. En synlig begränsning är bara användbar om den ändrar de resultaten.

Guiden till reverse ETL skiljer planerad dataflytt från arbetet med att definiera dess mappning. Det är vid mappningen som tidig omfattning spelar störst roll. Mer data kan läggas till senare; det första kontraktet måste vara rätt nu.

En lista visar vad någon bad om. En synlig gräns visar vad begäran kostar.