제1화. 아들아, 고객의 "알아서 잘"이라는 말은 가장 무서운 함정이란다
아들아, 네가 나중에 아빠처럼 IT 업계에서 일하게 된다면, 회의실에서 가장 많이 듣게 될 달콤하고도 무서운 말이 하나 있어.
“전문가시니까 알아서 잘 해주시겠죠?”
이 말은 너에 대한 무한한 신뢰가 아니야. 오히려 ‘나는 고민하기 귀찮으니, 나중에 결과물이 마음에 안 들면 네 탓을 하겠다’는 책임 전가의 시작이지. 아빠가 20년 넘게 이 정글에서 구르며 배운, ‘사람 좋게 웃다가 독박 쓰지 않는 진짜 분석 노하우’를 정리해 줄게.
고객이 "A 화면에 빨간 버튼을 만들어주세요"라고 할 때, 바로 "네!"라고 답하면 초보란다. 베테랑은 "그 버튼을 왜 누르려고 하시나요?"라고 되묻지.
진짜 목적을 찾아내면 일의 양은 줄어들고, 시스템의 가치는 올라간단다.
아빠의 노하우: 진짜 목적을 찾아내면 일의 양은 줄어들고 시스템의 가치는 올라간단다. 버튼이 아니라 '보고서 자동 출력'이 목적이라는 걸 알게 되면, 아빠는 버튼 대신 ‘아침 9시 자동 메일 발송’으로 고객의 니즈를 맞춰줄 수도 있거든.
요구사항 리스트(엑셀)만 채우려다 보면 전체 숲을 놓치게 돼. 사용자가 시스템에 들어와서 나갈 때까지의 동선을 화살표로 먼저 그려봐야 한단다.
흐름을 찾아내면 불필요한 동작을 줄일 수 있단다.
아빠의 노하우: 아빠는 회의실 화이트보드에 사용자의 움직임을 먼저 그렸어. "여기서 숫자를 입력하면, 저기서 결재가 나야 하죠?"라고 그림을 보여주면, 건성으로 대답하던 고객들도 그제야 "아, 그럼 중간에 승인 단계가 하나 더 필요한데!"라며 꼭 필요하거나 빠진 프로세스를 확인 할 수 있단다. 어쩌면 그들도 놓치고 있었을 수도 있어.
평범한 상황(Happy Path)은 누구나 다 설계할 수 있어. 진짜 실력은 '안 될 때 어떻게 할 것인가'를 찾아내는 데 있단다.
사소한 액션도 최대한 정의를 해놓아야, 나중에 판을 뒤집지 않는단다.
아빠의 노하우: "잔액이 부족하면 어떻게 보여줄까요?", "네트워크가 끊기면 데이터는 사라지나요?" 이런 어쩌면 사소한 질문을 던져야 해. 그래야 나중에 개발 단계에서 판이 뒤집혀 네 팀원들이 밤을 새우는 비극을 막을 수 있단다.
고객은 늘 "우리 업무는 간단해요"라고 말하지. 하지만 그 말을 믿고 상상해서 설계하면 필패야. 고객은 이미 업무에 익숙해져 있어서 그들이 생각하는 간단하다는 것과 개발자가 생각하는 간단하다는 것에는 간극이 있을 있단다.
업무는 말보다는 데이터로 확인해야 해... 특히 인풋 데이터와 아웃풋 데이터를 꼭 확인해야 해.
아빠의 노하우: 고객이 쓰는 엑셀 장표, 현재 시스템의 데이터 구조를 직접 네 눈으로 확인해야 한단다. 현장의 데이터는 거짓말을 하지 않거든. "이 숫자는 어디서 온 건가요?"라고 근거를 추적하는 집요함이 너를 전문가로 만들어줄 거야.
한 마디
"고객의 '맞겠죠'는 긍정이 아니라 '방관'이야. 그 방관의 대가는 테스트 기간에 당신과 개발자의 밤샘으로 돌아 오는 경우가 허다하지. 고객이 귀찮아할 정도로 물으십시오. 지금 욕먹는 것이 나중에 프로젝트 드랍되는 것보다 훨씬 낫아."
아들아, 요구사항 정의서를 작성하기 전에 이 10가지만은 꼭 스스로에게 물어보렴.
Why 체크: 이 기능의 최종 목적을 한 문장으로 설명할 수 있는가?
Fact 체크: 고객의 말 대신 실제 장표와 데이터 샘플을 직접 보았는가?
Flow 체크: 업무의 시작부터 끝까지 끊김 없는 흐름도(Flow Chart)를 그렸는가?
Exception 체크: '에러 상황'이나 '예외 케이스'에 대한 처리 방안을 정했는가?
Scope 체크: 이번 프로젝트에서 '안 하는 일'을 명확히 구분했는가?
User 체크: 의사결정자 외에 매일 시스템을 쓸 실무자의 불편함을 들었는가?
Priority 체크: 일정이 부족할 때 포기할 수 있는 기능 순위를 매겼는가?
Record 체크: 나중에 딴소리하지 못하게 회의록에 확정 내용을 기록했는가?
Visual 체크: 글자가 아닌 그림(와이어프레임)으로 고객의 확인을 받았는가?
Confirm 체크: "맞겠죠"라는 방관 대신, "이대로 개발하면 문제없겠습니까?"라고 다시 물었는가?