일을 선택하기 전에 제약을 보이게 하세요

예시 연동의 작업 목록에 요청된 필드가 12개 있습니다. 그중 3개가 첫 번째 승인된 동기화를 실행할 수 있는지 결정합니다. 고객 식별자, 대상 오디언스, 마케팅 허가입니다. 나머지 9개도 나중에는 중요할 수 있습니다. 지금 모든 필드를 똑같이 다루면 첫 번째 안전한 쓰기조차 불가능한데도 팀은 보충 정보를 다듬는 데 한 주를 쓸 수 있습니다.

제한을 두면 대화가 달라집니다. 첫 출시의 검토 자리를 다섯 개로 정하고 필드를 하나씩 놓습니다. 여섯 번째를 추가하려면 무엇을 뺄지 이름을 말해야 합니다.

다섯 개가 정답이라는 주장은 아닙니다. 요청 하나를 더하는 비용을 보이게 하는 방법입니다.

병목이 사람이 아닐 때도 같은 방법이 통합니다. 공급업체가 일정 기간의 요청 수를 제한할 수 있고, 이전 작업에 주어진 시간 안에는 감사 전에 변경 한 건만 허용될 수 있습니다. 지원팀이 확인할 수 있는 고객별 매핑도 몇 개뿐일 수 있습니다. 유용한 제한은 다른 자원이 충분해도 결과를 막는 것입니다.

작업 목록은 자체 비용을 숨깁니다

제약과 창작 작업에 관한 논의에서 제작팀은 한 주의 작업량을 나타내는 실제 표식으로 여력을 드러냈습니다. 작은 배경 요소를 계속 다듬으려면 다른 작업에서 표식을 옮겨야 했습니다. 이 장치는 무엇이 아름다운지 정하지는 않았지만 맞교환을 외면하기 어렵게 했습니다.

소프트웨어 팀에서는 표식이 대개 보이지 않습니다. 요청이 추적 도구에 들어가 우선순위 표를 얻고 다른 20개의 “중요한” 요청 곁에 놓입니다. 어느 검토, 이전 작업, 고객 대화를 미뤄야 하는지는 표시되지 않습니다.

연동에서 부족한 자원은 공급업체의 요청 수 제한일 수 있습니다. 실제 시험 계정에 대한 접근이나 동의의 의미를 조사하는 시간일 수도 있습니다. 눈에 보이는 제약은 결과를 제한하는 자원을 이름 붙이고 제안된 일이 어떻게 소비하는지 보여 줘야 합니다.

Tajo의 업무 도구 연동 가이드는 워크플로와 기준 시스템을 먼저 확인하라고 합니다. 이는 가능한 모든 필드로 목록이 커지지 않게 하는 방법입니다. 첫 동기화에는 실제 결과에 필요한 데이터만 있으면 됩니다.

핵심을 선택하고 나머지는 미룹니다

예시의 12개 필드 매핑에는 몇 가지 핵심이 있습니다. 식별자는 어떤 대상 레코드가 바뀌는지 결정합니다. 허가는 그 레코드를 마케팅에 사용할 수 있는지 결정합니다. 오디언스 소속은 어느 워크플로로 가는지 결정합니다. 셋이 틀리면 다른 9개로 결과를 구할 수 없습니다.

계획표에서 핵심 필드와 그것들이 소비하는 여력을 나란히 놓습니다. 각각 필드 정의, 시험 자료, 대상 확인이 필요하다고 가정합니다. 그 확인을 먼저 예약합니다. 추가적인 선호도 필드에는 구체적으로 묻습니다. 첫 번째로 작동하는 동기화를 바꿉니까, 아니면 기다릴 수 있습니까?

기다림은 중요하지 않다는 판결이 아닙니다. 부분적인 순서입니다. 다음 의존 대상을 정하고 나머지는 증거나 고객 수요가 중요하게 만들 때 사용할 수 있게 둡니다.

연기는 명시해야 합니다. 남은 9개 필드를 나중의 대기열에 넣고 각각을 앞당길 조건을 적습니다. 이름이 있는 사용 사례, 필드가 필요한 고객 레코드, 필수로 정한 공급업체 계약 등입니다. 목록 안에서 요청을 잃어버리는 것과 다릅니다. 조건부 대기열은 선택지를 보존하면서 첫 결과를 추측에 따른 범위 확장으로부터 지킵니다.

“인위적인 제한이 팀을 억누르고 가치 있는 아이디어를 숨길 수 있다”는 반론은 옳습니다. 나쁜 우선순위를 지키는 제한은 문제입니다. 지키려는 결과를 제한 옆에 적고 둘 다 다시 살펴야 합니다. 새로 발견한 필드가 동의에 필수라면 보충 정보 필드를 즉시 밀어냅니다. 제한은 변화를 막지 않고 보이게 합니다.

여력 표식은 우선순위 표가 숨기는 의견 차이도 드러냅니다. 한 팀은 개발 시간이 병목이라고 생각하지만 다른 팀은 대상 계정 관리자의 승인을 기다리는 시간이 실제 문제라는 것을 알 수 있습니다. 그렇다면 개발 자리를 늘려도 소용없습니다. 첫 쓰기가 승인될 때까지 경로를 따라가 실제로 일을 막는 단계에 제한을 둡니다.

첫 동기화에 무엇이 들어갈 자격이 있습니까?

1. 식별자, 허가, 오디언스에 필요

   지금 검증

   없으면 첫 승인된 쓰기를 정의할 수 없습니다.

2. 이름이 있는 향후 사용 사례에 필요

   앞당길 조건 설정

   첫 결과를 늦추지 않고 요청을 남겨 둡니다.

3. 결과에 미치는 영향이 정의되지 않음

   요청 연기

   추측성 범위에 부족한 검토 자리를 쓰지 않습니다.

제한이 얻어 낸 것을 측정합니다

그릴 가치가 있는 그래프는 “이번 달 닫은 요청 수”가 아닙니다. 요청에서 첫 올바른 결과까지의 경로와 무엇이 막았는지입니다. 검토 시간을 선택 필드에 다 써 버렸습니까? 공급업체 정의가 없어 모든 시험이 늦어졌습니까? 활성화에 아무도 필요로 하지 않는 대시보드를 미뤄 시간을 절약했습니까?

처리량 증가를 꾸며서는 안 됩니다. 실제 한 묶음의 전후를 기록합니다. 승인된 매핑까지 걸린 일수, 대상에서 확인한 필드 수, 활성화 후 발견한 문제 수입니다. 눈에 보이는 제약은 이런 결과를 바꿀 때만 유용합니다.

리버스 ETL 가이드는 예정된 데이터 이동과 그 매핑을 정의하는 일을 구분합니다. 초기 범위의 영향이 가장 큰 곳은 매핑입니다. 더 많은 데이터는 나중에 더할 수 있지만 첫 계약은 지금 정확해야 합니다.

목록은 누가 무엇을 요청했는지 알려 줍니다. 눈에 보이는 제한은 그 요청이 무엇을 소비하는지 알려 줍니다.