기획자와 개발자의 커뮤니케이션 오류 줄이는 방법
기획자와 개발자의 커뮤니케이션 오류는 대부분 실력 차이보다 이해 기준 차이에서 발생합니다.
기획자는 “사용자가 이렇게 하면 좋겠다”를 중심으로 생각하고, 개발자는 “이걸 시스템에서 어떻게 구현할 수 있나”를 중심으로 봅니다.
그래서 같은 말을 해도 서로 다르게 이해하는 경우가 많습니다.
가장 흔한 오류는 기획자가 기능을 말로 설명하고, 개발자가 각자 해석해서 구현하는 경우입니다.
예를 들어
“회원가입을 간단하게 해주세요”라는 말은 너무 모호합니다.
기획자는 입력 항목을 줄이라는 의미일 수 있고,
개발자는 화면 단계를 줄이라는 의미로 이해할 수 있습니다.
따라서 요구사항은 반드시 문서나 화면 기준으로 남겨야 합니다.
좋은 방식은 다음과 같습니다.
* 어떤 화면에서
* 어떤 버튼을 누르면
* 어떤 조건에서
* 어떤 결과가 나오는지
이 흐름을 명확하게 작성해야 합니다.
기획 문서는 개발자가 바로 이해할 수 있어야 합니다.
기능을 설명할 때는 “관리자가 회원을 관리한다”처럼 추상적으로 쓰기보다, 사용자 행동 기준으로 작성하는 것이 좋습니다.
예시:
사용자가 로그인 화면에서 아이디와 비밀번호를 입력한다.
로그인 버튼을 누른다.
입력값이 일치하면 메인 화면으로 이동한다.
일치하지 않으면 “아이디 또는 비밀번호를 확인해주세요” 문구를 보여준다.
이렇게 작성하면 개발자가 구현해야 할 조건과 결과를 쉽게 파악할 수 있습니다.
기획자와 개발자가 가장 많이 부딪히는 부분이 예외 상황입니다.
기획자는 기본 흐름만 생각하고, 개발자는 예외 상황까지 처리해야 합니다.
예를 들어 회원가입 기능이라면 이런 내용이 필요합니다.
* 이미 가입된 이메일이면 어떻게 할 것인가
* 비밀번호 형식이 틀리면 어떤 문구를 보여줄 것인가
* 필수 입력값이 비어 있으면 어떻게 할 것인가
* 서버 오류가 나면 어떤 안내를 할 것인가
이런 예외 조건이 없으면 개발자는 임의로 판단하게 되고, 나중에 수정이 반복됩니다.
기획 회의에서 디자인, 기능, 정바카라이 섞이면 오해가 생깁니다.
예를 들어
“버튼을 눈에 잘 띄게 해주세요”는 디자인 요청입니다.
“버튼 클릭 시 결제 페이지로 이동해야 합니다”는 기능 요청입니다.
“결제 전 약관 동의가 필수입니다”는 정바카라입니다.
이 세 가지를 구분해서 전달해야 개발자가 헷갈리지 않습니다.
기획자와 개발자는 큰 기능 단위보다 화면 단위로 합의하는 것이 좋습니다.
예를 들어 “예약 기능 개발”이라고 하면 범위가 넓습니다.
대신 다음처럼 나눕니다.
* 예약 목록 화면
* 예약 상세 화면
* 예약 등록 화면
* 예약 수정 화면
* 예약 취소 화면
각 화면별로 입력값, 버튼, 조건, 결과를 정리하면 누락이 줄어듭니다.
작은 용어 차이도 큰 오류를 만듭니다.
예를 들어 기획자는 “회원”, 개발자는 “유저”, 디자이너는 “고객”이라고 부르면 같은 대상을 다르게 이해할 수 있습니다.
프로젝트 초기에 용어집을 만드는 것이 좋습니다.
예시:
회원 = 앱에 가입한 사용자
관리자 = 서비스 운영 담당자
승인 대기 = 관리자가 확인하기 전 상태
활성 = 정상 이용 가능한 상태
비활성 = 이용 제한 상태
용어가 통일되면 회의와 문서의 오해가 줄어듭니다.
회의에서는 합의한 것 같지만, 시간이 지나면 기억이 달라집니다.
그래서 회의 후에는 반드시 짧게라도 기록해야 합니다.
정리할 내용은 다음 정도면 충분합니다.
* 결정된 내용
* 변경된 내용
* 보류된 내용
* 담당자
* 완료 예정일
회의록이 길 필요는 없습니다.
중요한 것은 “누가 무엇을 언제까지 할지”가 남아야 한다는 점입니다.
기획이 거의 끝난 뒤 개발자에게 전달하면 문제가 커질 수 있습니다.
개발자가 보기에는 구현이 어렵거나 비용이 큰 기능일 수 있기 때문입니다.
따라서 기획 초안 단계에서 개발자에게 확인해야 합니다.
이 기능이 가능한지,
비용이 얼마나 드는지,
대체 방법은 있는지,
일정에 영향을 주는지
초기에 확인하면 수정 비용이 줄어듭니다.
개발 중간에 “이 부분만 살짝 바꿔주세요”라는 말이 반복되면 프로젝트가 흔들립니다.
변경 요청은 반드시 기록해야 합니다.
좋은 변경 요청 방식은 다음과 같습니다.
* 변경 전 내용
* 변경 후 내용
* 변경 사유
* 영향받는 화면
* 일정 영향 여부
* 최종 승인자
이렇게 해야 나중에 “누가 이렇게 하라고 했는지” 문제가 줄어듭니다.
기획자는 “잘 작동하면 완료”라고 생각할 수 있지만, 개발자는 완료 기준이 필요합니다.
예를 들어 로그인 기능의 완료 기준은 이렇게 정할 수 있습니다.
* 정상 로그인 가능
* 아이디 오류 시 안내 문구 노출
* 비밀번호 오류 시 안내 문구 노출
* 5회 실패 시 제한 처리
* 모바일 화면에서도 정상 작동
* 테스트 계정으로 검수 완료
완료 기준이 명확하면 검수 과정에서 불필요한 논쟁이 줄어듭니다.
기능명 : 회원가입 기능
목적 : 신규 사용자가 서비스를 이용하기 위해 계정을 생성한다.
사용자 흐름 :
회원가입 화면 진입
이메일 입력
비밀번호 입력
약관 동의
가입하기 버튼 클릭
가입 완료 후 로그인 화면 이동
입력 항목
이메일
비밀번호
비밀번호 확인
약관 동의
정바카라
이메일은 중복 가입 불가
비밀번호는 영문, 숫자 포함 8자 이상
약관 동의 필수
예외 상황
중복 이메일이면 안내 문구 노출
비밀번호 형식 오류 시 안내 문구 노출
서버 오류 시 다시 시도 안내
완료 기준
정상 가입 가능
오류 문구 정상 노출
가입 후 로그인 화면 이동
모바일 화면 검수 완료
기획자와 개발자의 커뮤니케이션 오류를 줄이는 핵심은 명확한 문서화와 기준 합의입니다.
좋은 커뮤니케이션은 말을 많이 하는 것이 아니라, 서로 같은 기준을 보고 일하게 만드는 것입니다.
기획자는 “무엇을 왜 만들어야 하는지”를 명확히 설명하고, 개발자는 “어떻게 구현할 수 있는지와 어떤 제약이 있는지”를 초기에 공유해야 합니다.
결국 프로젝트의 품질은 기획서의 화려함보다
기획자와 개발자가 같은 그림을 보고 있는가에 달려 있습니다.