적절한 질문 없이 제품을 만드는 것은 마치 땅을 확인하지 않고 콘크리트를 붓는 것과 같습니다. 한동안은 버틸 수 있을지 몰라도, 균열은 시간문제일 뿐입니다.
"시작"에 대한 서두름에 휩싸인 팀들은 종종 이러한 발견 단계를 건너뜁니다. 비즈니스 분석가(BA)는 때때로 늦게 참여합니다. 범위 확장(scope creep)이 시작되고 예산이 부족하며 모두가 제품이 기대에 미치지 못하는 이유를 궁금해할 때입니다. 하지만 초기에 참여하면 BA는 비즈니스 요구와 기술 실행 사이의 통역자 역할을 합니다. 단순히 요구 사항을 수집하는 데 그치지 않고, 전체 팀이 자신 있게 구축할 수 있는 무언가로 구체화합니다.
그래서 좋은거야 비즈니스 분석가 바로 스토리를 쓰거나 기능 매핑에 뛰어들지 마세요. 먼저, 그들이 묻습니다.
정중한 확인뿐 아니라, 날카롭고 때로는 불편한 질문들까지. 숨겨진 위험을 드러내고, 사각지대를 드러내며, 팀이 잘못된 것을 아름답게 구축하는 것을 막아주는 질문들 말입니다.
숙련된 비즈니스 분석가가 프로젝트를 시작하기 전에 묻는 필수 질문
라스트 마일 배송 차량을 관리하는 웹 및 모바일 앱을 개발한다고 가정해 보겠습니다. 경로를 할당하고, 운전자를 실시간으로 추적하고, 성과 보고서를 생성하는 등의 작업을 담당합니다. 훌륭한 BA는 디자인이나 코딩을 시작하기 전에 다음과 같은 질문을 던집니다.
1. 우리는 어떤 문제를 해결하고 있는가? 그리고 누구를 위해 해결하고 있는가?
"실시간으로 배송 상황을 추적하고 싶어요."라고 말할 수도 있습니다. 하지만 왜 그럴까요?
고객이 택배가 늦을 때 불평하는 게 문제인가요? 배송 담당자가 운전자 위치를 모른다는 게 문제인가요? 고객이 송장에 이의를 제기할 때 배송 시간을 증명할 수 없다는 게 문제인가요?
BA는 핵심적인 문제점을 파악하고, 그 문제점이 운전자, 배차 담당자, 고객, 관리자 중 누구의 것인지 파악하려고 노력합니다. 잘못된 문제를 해결하는 것은 시간 낭비를 부르는 가장 쉬운 방법이기 때문입니다.
2. 성공은 어떤 모습일까요?
"추적 개선"은 좋은 생각이지만, 성공했다는 걸 어떻게 알 수 있을까?
더 나은 답변:
"고객이 주문한 상품이 어디 있는지 묻는 전화를 80% 줄이고 싶습니다."
"더욱 스마트한 배정을 통해 운전자가 10% 더 빠르게 경로를 완료하기를 바랍니다."
이러한 명확성은 디자이너부터 팀 전체에 도움이 됩니다. 테스터 — 모호하지 않고 측정 가능한 목표를 중심으로 정렬합니다.
3. 오늘은 무슨 일이 일어날까요? 그리고 무엇이 망가졌을까요?
BA는 기능을 제안하기 전에 현재 작업이 어떻게 진행되고 있는지 묻습니다.
배차 담당자들이 엑셀로 경로를 배정하고 있을 수도 있고, 운전자들이 도착 시간을 문자로 보내고 있을 수도 있고, 유일한 성과 추적은 월별 보고서에서 수동으로 이루어지고 있을 수도 있습니다.
현재의 업무 흐름을 이해하면 실제 마찰 지점을 파악하고 단순히 나쁜 습관을 디지털화하는 것을 방지하는 데 도움이 됩니다.
4. 실제로 누가 시스템을 사용할 것인가, 그리고 어떤 조건에서 사용할 것인가?
배달 기사가 빠른 Wi-Fi가 있는 맥북에서 앱을 사용하는 게 아닙니다. 밴 안에서 싸구려 안드로이드 폰을 사용하며, 햇볕 아래서 인터넷이 끊기는 상황입니다.
BA는 다음과 같이 질문할 것입니다.
- 어떤 장치가 사용되고 있나요?
- 사용자들은 기술에 능숙한가?
- 장갑을 낀 채로 사용할 수 있나요? 운전할 때도 사용할 수 있나요?
이러한 세부 사항은 디자인, 플랫폼 결정, 인터페이스의 관대함에 영향을 미칩니다.
5. 첫날부터 반드시 효과가 있어야 하는 것은 무엇입니까?
보고 모듈은 기다릴 수 있겠지만, 경로 할당과 실시간 추적은 처음부터 완벽해야 합니다. 아니면 회사 보험 정책 때문에 운전자 신원 확인이 중요할 수도 있겠네요.
좋은 BA는 다음의 우선순위를 정하는 데 도움이 됩니다.
- 출시 후에는 무엇이 작동해야 하나요?
- 나중에 무슨 일이 일어날 수 있나요?
- 확장 전까지는 무엇이 선택 사항인가요?
6. 우리가 사실이라고 가정하지만 검증하지 않은 것은 무엇인가?
당신은 다음과 같이 가정할 수 있습니다:
"고객은 우리가 보낸 추적 링크를 사용할 것입니다."
"운전자는 배달 완료를 표시하는 것을 잊지 않습니다."
"배차 담당자는 수동으로 경로를 지정하고 싶어합니다."
하지만 가정은 사실이 아닙니다. 학사는 이러한 가정에 이의를 제기하고 다음과 같은 질문을 던질 것입니다.
- 사용자와 이야기를 나누었나요?
- 사용 데이터가 있나요?
- 제작하기 전에 테스트해 볼 수 있나요?
이렇게 하면 값비싼 놀라움으로부터 보호받을 수 있습니다.
7. 어떤 문제가 발생할 수 있나요? 그리고 시스템은 어떻게 대응해야 하나요?
운전자가 신호를 잃어버리면 앱이 위치 데이터를 오프라인으로 저장하고 나중에 동기화해야 할까요? 두 명의 배차 담당자가 동시에 경로를 배정하면 누가 이길까요? 고객이 택배가 도착하지 않았다고 주장하면 증거가 있을까요?
BA는 이상적인 흐름뿐 아니라 예외 상황을 고려하도록 훈련받습니다. 이러한 사고방식은 고객 지원과 관련된 골치 아픈 문제나 고객의 화난 상황을 예방합니다.
8. 어떤 기존 시스템이나 데이터에 연결해야 합니까?
이미 GPS 제공업체를 사용하고 있을 수도 있고, 운전자 정보가 다른 CRM에 저장되어 있을 수도 있습니다. 회계 부서에서 청구를 위해 배송 데이터가 필요할 수도 있습니다.
앱은 고립되어 있지 않습니다. BA는 다음과 같은 질문을 할 것입니다.
- 어떤 통합이 필요한가?
- 잘 문서화되어 있나요?
- 누가 소유합니까?
이렇게 하면 마지막 순간의 통합 과정에서 비용이 많이 드는 예상치 못한 상황을 피할 수 있습니다.
9. 누가 무엇을 언제 승인해야 합니까?
많은 프로젝트에서 "중요한 사람"이 제품을 보고 "이건 우리가 원하던 게 아니야"라고 말할 때까지는 모든 것이 순조롭게 진행됩니다. BA는 다음과 같은 사항을 계획합니다.
- 실제 결정권자는 누구인가?
- 누가 일찍 참여해야 합니까?
- 누가 단지 정보를 받기만 하면 되나요?
이를 통해 팀이 개발 중간에 재작업이나 범위 변경을 겪지 않도록 보호할 수 있습니다.
10. '완료'란 당신에게 실제로 무엇을 의미합니까?
한 팀에게 "완료"는 내부 사용자를 대상으로 한 파일럿 테스트를 의미합니다. 다른 팀에게는 법적 승인, 고객 지원 및 SLA 보장을 포함한 공개 출시를 의미합니다. BA는 다음과 같은 질문을 할 것입니다.
- 누가 서명을 하나요?
- 법적, 규정 준수 또는 교육 요구 사항이 있습니까?
- 명확한 가동 체크리스트가 있나요?
결승선을 아는 것은 끝없는 연마나 성급한 출시를 방지합니다.
BA Discovery를 건너뛸 때 흔히 저지르는 실수
- 과잉 구축: 아무도 사용하지 않는 기능을 추가하는 것.
- 우선순위의 불일치: 핵심 전달 기능이 여전히 신뢰할 수 없는 상황에서 보고에 수개월을 소모함.
- 통합 혼란: API가 존재하지 않거나 추가 비용이 든다는 사실을 너무 늦게 발견함.
- 범위 확장: 일정을 늘리고 예산을 늘리는 확인되지 않은 변경 사항입니다.
최종 생각
이미 머릿속에 있는 것을 적어 두라고 비즈니스 분석가를 데려오는 게 아닙니다. 다른 누구도 생각하지 못하는 질문을 던지라고 하세요.
최고의 BA는 처음부터 속도를 늦춰 중간에 난관에 부딪히지 않도록 합니다. 모든 기능이 명확한 비즈니스 목표를 달성하고, 모든 가정을 검증하며, 모든 위험에 대한 완화 계획을 수립하여 투자를 보호합니다.
새로운 것을 구축하든, 잘못된 것을 고치든, 빠르게 확장하든, 이 10가지 질문은 초기 경고 시스템입니다. 이 질문들을 무시하면 불안정한 기반 위에 사업을 확장할 위험이 있습니다.
