스프레드시트를 대체하기 전에, 사용자가 사용하는 모습을 지켜보세요

누군가 당신에게 스프레드시트를 앱으로 만들라고 요청합니다. 파일을 열고 탭들을 살펴본 다음, 표와 화면 목록을 만들기 시작합니다. 풀기 어려운 수식들이 있고, 몇 개의 드롭다운 메뉴가 있으며, 어쩌면 승인 열이 있을 수도 있습니다. 관리할 만해 보입니다.

그런 다음 그 스프레드시트를 사용하는 사람과 함께 앉아 있게 됩니다.

그 사람이 한 행을 '승인'으로 표시하기 전에, 이메일을 확인합니다. 수량은 다른 시스템에서 오지만, 항상 신뢰하는 것은 아닙니다. 한 고객은 감독관의 서명이 필요합니다. 무언가 긴급할 때, 팀은 채팅으로 처리하고 나중에 시트에 업데이트합니다.

당신은 모든 열을 재현할 수 있지만, 여전히 그 사람들에게 대부분의 동일한 작업을 하게 할 수는 있습니다. 대체 시스템은 요청이 도착해서 완료될 때까지 어떻게 진행되는지, 심지어 파일에 기록되지 않은 부분들까지 고려해야 합니다.

그곳에서 저는 빌드 범위를 잡기 시작할 것입니다.

하나의 요청을 끝까지 따라가세요

최근의 요청 하나를 가져와서 누군가에게 실제 기록을 사용해 설명하도록 요청하세요. 스프레드시트를 열어둔 채, 그들이 무엇이 일어났는지 설명하는 데 필요한 다른 모든 것들(시스템)도 함께 둡니다. 만약 그들이 이메일이나 다른 시스템, 또는 동료와의 대화로 전환한다면, 그것까지 따라가세요.

예를 들어, 시트가 창고 승인이 필요한 요청을 추적한다고 가정해 봅시다. 절차는 요청을 입력하고, 검토한 다음, 완료로 표시하는 것일 수 있습니다. 워크스루(walkthrough)를 하는 동안, '검토'라는 것이 어제 재고 수출본을 확인하고, 창고에 불일치 여부를 문의하며, 계정 관리자가 대체품을 승인하기를 기다리는 것을 의미한다는 것을 발견할 수도 있습니다. 최종 상태는 이 모든 것을 알려주지 않습니다.

이것은 구현에 중요합니다. 수량을 어떤 시스템이 공급하는지, 그 값이 마지막으로 언제 업데이트되었는지, 누가 대체품을 승인할 수 있는지, 그리고 그러한 결정들이 보류되는 동안 요청이 무엇을 보여야 하는지 알아야 합니다.

이러한 주변 활동들이 바로 '섀도우 워크플로우(shadow workflow)'를 형성합니다. 이는 문서화된 프로세스를 작동하게 유지하는 검토, 승인 절차, 비공식적인 대화, 그리고 판단적 결정들을 포함합니다. 일부는 새로운 소프트웨어에 자리를 차지할 가치가 있지만, 다른 것들은 시스템이 데이터를 교환할 수 있게 되면 사라질 수도 있습니다. 따라서 어떤 단계가 존재하는지 이해해야만 대체 여부를 결정할 수 있습니다.

워크스루(walkthrough)를 진행하는 동안 유용한 질문은 다음과 같습니다: “이 파일의 어느 부분을 바꾸는 것이 가장 걱정되시나요?” 복사된 수식이나 이상하게 이름 붙여진 탭에는 아무도 문서화하지 않은 의존성이 있을 수 있습니다. 알아낼 때까지 그 자리에 그대로 두세요.

상태가 실제로 의미하는 바를 파악하세요

노란색 행은 '상태 필드(status field)'로 대체하기 쉽습니다. 하지만 노란색이 무엇을 의미하는지 파악하는 것은 더 많은 작업이 필요합니다.

이는 누군가가 요청을 검토해야 함을 의미할 수도 있고, 검토가 이루어졌으나 문제가 있다는 것을 의미할 수도 있습니다. 두 사람이 같은 색상을 다르게 사용하고 있을 수 있으며, 다음 행동에 대해 설명해 달라고 요청하기 전까지는 알아차리지 못할 수 있습니다.

상태를 일반 언어로 작성하세요: 신규(new), 검토 대기(waiting for review), 차단됨(blocked), 승인됨(approved), 완료(complete). 각 전환 단계에 대해 누가 이 단계를 수행할 수 있는지, 어떤 정보가 필요한지, 그리고 그 후에 무엇이 발생해야 하는지를 파악합니다. 만약 승인이 다른 시스템에서 작업을 시작한다면, 그 업데이트 내용도 명세서에 포함되어야 합니다.

시트에 전혀 손대지 않는 사람들도 포함하세요. 요청을 제출하는 고객 서비스 담당자와 내보내기(export) 데이터를 조정하는 재무 담당자 모두 주요 사용자의 화면에서는 보이지 않는 행동에 의존할 수 있습니다. 그들에게 무엇을 받는지, 언제 필요한지, 그리고 그것이 누락되거나 잘못되었을 때 무엇을 하는지 물어보세요.

이 시점에서 작성된 메모는 파일과 데이터 소스, 관련된 사람들, 상태와 결정, 예외 사항, 비공식 대화, 그리고 다운스트림 출력(downstream outputs)을 모두 다루어야 합니다. 이들이 바로 워크플로우 맵의 일곱 가지 부분입니다. 이들을 위해 일곱 번의 별도 회의가 필요하지는 않지만, 누군가에게 기억 속에서 빈틈을 채우도록 요청할 필요 없이 작업이 어떻게 진행되는지 설명할 수 있을 만큼 충분한 디테일이 필요합니다.

문제가 발생했던 마지막 경우에 대해 물어보세요

일반적인 요청만으로는 팀이 중복(duplicate) 건, 오래된 수량(stale quantity), 또는 사용 불가능한 시스템을 어떻게 처리하는지 알 수 없습니다. 성공 사례만큼이나 최근 발생했던 실패 사례 몇 가지를 물어보고, 그 과정을 주의 깊게 따라가 보세요.

누가 알아차렸나요? 무엇이 멈추게 했나요? 누가 해결하도록 허용되었나요? 결정 기록과 요청이 다시 진행된 방식에 주목하세요. 때로는 이러한 기록이 스프레드시트의 필드라기보다는 메시지 형태일 수 있습니다.

창고(warehouse) 예시를 들면, 수량 불일치(quantity mismatch)는 여러 가지 구체적인 요구사항을 제시해야 합니다. 요청에는 눈에 보이는 '차단됨(blocked)' 상태와 담당자가 필요합니다. 누가 어떤 수량을 확인했고 어디서 왔는지 알아야 합니다. 차이점을 해결하는 사람은 적절한 권한을 가져야 하며, 그 해결 내용은 요청이 다음 단계로 넘어가도 계속 보이도록 유지되어야 합니다.

이를 통해 팀과 함께 테스트할 수 있는 승인 시나리오(acceptance scenario)를 얻게 됩니다:

• 수량 불일치가 있는 요청을 제출합니다.
• 지정된 사람이 조사하는 동안 '차단됨' 상태가 유지되는 것을 확인합니다.
• 권한이 있는 사람이 해결 내용을 기록하도록 합니다.
• 요청이 올바른 다음 상태로 이동하고, 하류(downstream) 기록들이 그 결정을 반영하는지 확인합니다.

만약 이 하류 업데이트마저 실패한다면 어떻게 해야 할지 결정하세요. 다음 팀이 여전히 정보를 기다리고 있다면 '완료(complete)'라고 표시된 화면은 오해를 불러일으킬 수 있습니다. 이러한 실패는 눈에 보여야 하며, 복구하기 위한 합의된 방식이 있어야 합니다.

모든 대화를 양식으로 만들 필요는 없습니다. 감독자(supervisor)가 여전히 운영 담당자(operator)와 특이 케이스에 대해 논의해야 할 수도 있습니다. 결정 내용과 누가 했는지 기록하는 것만으로 충분할 수 있습니다. 목표는 나중에 업무를 인계받을 사람이 현재 상황을 이해하도록 하는 것입니다.

이해한 후에 자동화할 것을 선택하세요

이러한 지도를 얻었다면, 빌드에 대해 상당히 구체적인 결정을 내릴 수 있습니다.

같은 값을 두 시스템에 반복적으로 입력하는 것은 통합(integration)의 후보가 될 수 있습니다. 아무도 사용하지 않는 보고서는 삭제될 수도 있습니다. 비싼 실수로부터 비즈니스를 보호하는 승인 절차는 더 명확한 기록과 불필요한 추적 과정이 필요하므로 유지되어야 할 수도 있습니다. 규칙이 여전히 논란 중이거나 변경되고 있는 경우에는, 올바른 동작 방식이 무엇인지 누군가 설명할 수 있을 때까지 자동화하는 것을 미루세요.

AI는 입력에 해석(interpretation)이 필요한 지점에 활용될 수 있습니다. 지저분한 이메일에서 세부 정보를 추출하거나, 들어오는 요청을 분류하거나, 검토를 위해 응답 초안을 작성할 수 있습니다. 안정적인 유효성 검사 규칙(validation rules)과 알려진 라우팅 조건(routing conditions)은 일반 코드에 남아 있을 수 있습니다. 비용이 많이 들거나 되돌리기 어려운 결과를 초래하는 결정에는 인간의 확인 지점(human checkpoint)이 있어야 합니다.

예를 들어, 이메일에서 요청된 수량을 추출하는 것이 재고가 존재하는지 또는 고객이 주문할 권한이 있는지를 확립하지는 못합니다. 그러한 검사는 여전히 정의된 출처와 소유자(owner)가 필요합니다. 에이전트에게 스프레드시트에 접근 권한을 준다고 해서 누락된 비즈니스 규칙(business rules)이 제공되는 것은 아닙니다.

설계 단계에서 이 구분을 명확하게 유지하세요. AI가 무엇을 생성하는지, 어떤 검사들이 뒤따르는지, 그리고 아무런 중대한 일이 발생하기 전에 사람이 결정해야 하는 지점이 어디인지를 명시해야 합니다.

팀이 작업을 완료할 수 있는 첫 번째 버전을 구축하세요

하나의 요청 유형이나 승인 프로세스를 선택하고, 접수(intake)부터 최종 시스템 업데이트까지 이를 지원하세요. 누가 작업의 소유자인지, 현재 어떤 상태인지, 그리고 다음에 무엇을 해야 하는지를 볼 수 있어야 합니다. 발견 과정에서 찾은 일반적인 예외 사항들(common exceptions)도 포함하여, 첫 번째 까다로운 요청이 모두를 이전 시트로 되돌려 보내는 일이 없도록 하세요.

실제 업무를 수행하는 사람들과 함께 사용해 보세요. 만약 그들이 계속해서 스프레드시트를 다시 열어본다면, 무엇을 찾으려고 했는지 물어보세요. 그것은 누락된 역사적 기록일 수도 있고, 새 시스템이 지원하지 않는 검사일 수도 있으며, 적절하게 표현되지 않은 결정일 수도 있습니다. 이는 도구를 다른 워크플로우로 확장하기 전에 유용한 피드백입니다.

파일이 그대로 유지되어야 하는 경우도 있습니다. 변화가 잦고 위험도가 낮은 프로세스에 숙련된 한 사람이 사용하는 스프레드시트는 단순히 더 명확한 소유권이나 검증만 필요할 수 있습니다. 맞춤형 소프트웨어는 추가적인 유지보수와 포기해야 하는 유연성을 정당화해야 합니다.

다음 기획 세션 전에, 누군가에게 완료된 요청 하나와 막힌 요청 하나를 보여달라고 요청하세요. 둘 다 스프레드시트의 경계를 넘어까지 따라가 보세요. 그러면 첫 번째 버전이 무엇을 해야 할지 훨씬 더 잘 알게 될 것입니다.

Stephen Talley(Stride Techworks)의 Your spreadsheet isn't the problem. The invisible workflow around it is.를 각색함.