Showing Posts From

명확하지

스펙이 명확하지 않습니다 - 개발팀의 신호를 읽는 법

스펙이 명확하지 않습니다 - 개발팀의 신호를 읽는 법

스펙이 명확하지 않습니다 - 개발팀의 신호를 읽는 법 신호는 이미 왔었다 화요일 오후 3시. 슬랙 알림. "K님, 이 부분 스펙이 명확하지 않은데요?" 심장이 내려앉는다. 어제 밤 11시까지 작성한 PRD였다. 3번 검토했다고 생각했는데. 돌아보니 신호는 있었다. 월요일 스프린트 회의 때 백엔드 개발자 J님이 물었다. "이 케이스는 어떻게 처리하나요?" 나는 대답했다. "그건... 일단 논의해볼게요." 그게 신호였다. 명확하지 않다는 신호. 개발자는 직접적으로 말하지 않는다. "이건 불가능합니다" 전에 "이 부분 좀 애매한데요" 가 먼저 온다. "스펙이 명확하지 않습니다" 는 이미 3번째 신호다. 6년 차에 깨달은 것. 개발자의 질문은 단순한 질문이 아니다. PRD의 구멍을 발견했다는 신호다.모호한 표현의 전형 내 PRD에서 가장 많이 쓴 표현들. 하나씩 지워나가는 중이다. "적절하게" 뭐가 적절한가. 5개? 10개? 1000개? 개발자는 숫자로 말한다. "필요시" 언제가 필요한 때인가. 조건이 없으면 코드를 쓸 수 없다. if문에는 boolean이 필요하다. "사용자가 원하는" 어떤 사용자? 무엇을 원하는지 어떻게 판단? 데이터는? "적당히" 이게 제일 위험하다. 개발자의 적당함과 기획자의 적당함은 다르다. 100% 다르다. 지난주 기획서. "리스트는 적당한 개수로 표시" 개발자는 20개로 구현했다. 나는 5개를 생각했다. 다시 작성했다. "리스트는 최대 5개 표시. 5개 초과 시 '더보기' 버튼 노출. 더보기 클릭 시 10개 단위 추가 로딩." 구체적 숫자. 조건. 예외 케이스. 이게 명확함이다.체크리스트를 만들었다 PRD 작성 후 이 항목들을 체크한다. 하나라도 빠지면 슬랙 폭탄 확정이다. 1. 숫자가 있는가최대/최소 값 타임아웃 리스트 개수 페이지네이션 단위 캐시 시간 파일 용량 제한숫자 없으면 개발자가 정한다. 그리고 그건 내가 원한 숫자가 아니다. 2. 모든 케이스를 적었는가정상 케이스 에러 케이스 엣지 케이스 네트워크 끊김 데이터 없음 권한 없음 동시 접속에러 케이스를 안 쓰면 개발자가 "에러 발생" 토스트만 띄운다. 사용자는 뭐가 문제인지 모른다. 3. 우선순위가 명확한가Must have Should have Nice to have전부 중요하다고 하면 전부 중요하지 않은 것이다. 개발 기간 2주인데 요구사항 30개. 불가능하다. 우선순위 없으면 개발자가 정한다. 쉬운 것부터. 중요한 게 아니라. 4. 판단 기준이 있는가"최신순"이면 → 어떤 날짜 기준? "인기순"이면 → 어떤 지표? "추천"이면 → 무슨 알고리즘?기준 없으면 개발자가 정한다. 그리고 PM은 나다. 내가 정해야 한다.진짜 문제는 화면 밖에 있다 가장 많이 놓치는 부분. 화면에 보이지 않는 것들. 상태 관리. A 화면에서 데이터 수정하면 B 화면에도 반영되나? 새로고침 해야 하나? 자동으로 되나? 안 적으면 개발자는 가장 쉬운 방법을 선택한다. 새로고침. 지난달 릴리즈. 프로필 수정 기능 추가했다. PRD에는 프로필 수정 화면만 있었다. QA 단계에서 발견했다. 프로필 수정 후 메인 화면 가면 이전 프로필 정보 그대로다. 앱 재시작해야 반영된다. 다시 개발 2일. 릴리즈 하루 연기. 이제는 적는다. "프로필 수정 완료 시, 해당 데이터를 사용하는 모든 화면에 실시간 반영. 메인 화면, 설정 화면, 마이페이지 포함." 데이터 플로우. API 호출 시점. 캐시 정책. 화면 전환 시 동작. 보이지 않는 것도 스펙이다. 개발자의 질문 패턴 6년간 받은 질문들을 정리했다. 패턴이 있다. "이 케이스는요?" → PRD에 해당 케이스 없음 → 내일까지 추가 스펙 정리 필요 "이게 가능한가요?" → 기술적으로 어려움 → 대안 논의 필요 "왜 이렇게 하나요?" → 더 좋은 방법 있다는 신호 → 이유 설명 or 방법 수정 "급한가요?" → 다른 급한 일 있음 → 우선순위 재조정 필요 "디자이너분과 얘기했나요?" → 디자인-개발 간 괴리 있음 → 3자 회의 필요 질문을 무시하지 않는다. 모든 질문은 리스크 신호다. 금요일 오후 3시 이후의 질문. 이건 월요일 이슈로 번진다. 바로 응답한다. 구체성의 기준 "어느 정도로 구체적이어야 하나요?" 신입 기획자가 물었다. 대답했다. "개발자가 당신 자리에 안 와야 할 정도로." PRD만 보고 개발 가능하면 됐다. 슬랙으로 질문 안 하면 됐다. 회의 안 잡으면 됐다. 물론 불가능하다. 100% 명확한 PRD는 없다. 하지만 90%는 가능하다. 질문 10개를 3개로 줄일 수 있다. 구체성의 기준. 다른 사람이 읽고 같은 그림을 그릴 수 있는가. 테스트 방법이 있다. PRD를 다른 기획자에게 보여준다. 설명 없이. 그림 그려보라고 한다. 내가 생각한 것과 다르면 그건 명확하지 않은 것이다. 요즘은 ChatGPT에게 물어본다. "이 스펙으로 개발하면 어떤 질문이 나올까?" 의외로 정확하다. 내가 놓친 케이스를 찾아낸다. 스프린트 첫날의 루틴 월요일 아침 10시. 스프린트 시작. 예전에는 티켓만 할당하고 끝났다. 지금은 다르다. 티켓 하나씩 읽는다. 개발자들 앞에서. "이해 안 되는 부분 있으면 바로 말해주세요." 5분이면 나온다. 애매한 부분. 놓친 케이스. 기술적 제약. 그 자리에서 정리한다. 티켓 수정한다. 디자이너 부른다. 3자 회의 즉석에서 한다. 이렇게 하니 중간 질문이 70% 줄었다. 일정 변경이 50% 줄었다. 시간 투자다. 스프린트 첫날 1시간. 나중에 3시간 아낀다. 목요일에 "이거 어떻게 하나요?" 듣는 것보다 월요일에 1시간 쓰는 게 낫다. 결국 학습이다 명확한 스펙 작성은 기술이다. 타고나는 게 아니다. 나도 1년 차 때는 엉망이었다. "대충 이런 느낌으로" "예쁘게" "사용자 친화적으로" 개발자들이 매일 물었다. 뭐가 예쁜 건지. 어떤 게 친화적인 건지. 3년 차에 깨달았다. 내 머릿속 이미지를 다른 사람은 모른다. 말로 옮겨야 한다. 구체적으로. 지금도 배운다. 매 스프린트마다. 회고 때 물어본다. "어떤 스펙이 애매했나요?" "어떻게 쓰면 더 좋았을까요?" 개발자들이 알려준다. 그들이 진짜 선생님이다. 최근에 배운 것. "버튼 비활성화 조건" 항상 놓친다. 이제는 모든 버튼마다 적는다.활성화 조건 비활성화 조건 비활성화 시 색상 비활성화 시 토스트 메시지작은 것 같지만 이런 게 쌓인다.스펙이 명확하지 않다는 말. 이제는 듣기 전에 먼저 찾아낸다. 그게 성장이다.