Showing Posts From

서비스기획

슬랙 폭탄의 아침, 어떻게 대응할 것인가

슬랙 폭탄의 아침, 어떻게 대응할 것인가

8시 52분, 슬랙을 연다 출근하자마자 노트북을 켰다. 슬랙이 열렸다. 빨간 알림. 47개. 심호흡 한 번 하고 커피 한 모금 마셨다. 아직 9시도 안 됐는데.메시지들을 쭉 훑었다. "K님 이거 급합니다" "어제 요청드린 건 언제쯤?" "화면 정의서 확인 부탁드려요" "@기획자K 대표님이 이거 물어보시는데요" 전부 다 급하다고 한다. 근데 정말 급한 건 3개 정도다. 경험상 그렇다. 첫 5분이 하루를 결정한다 예전에는 위에서부터 순서대로 답했다. 그게 잘못이었다. 메시지 순서 = 중요도가 아니다. 보낸 사람의 급함 = 내 우선순위도 아니다. 지금은 다르게 한다. 1단계: 읽지 않고 분류부터멘션(@) 있는 것만 먼저 체크 DM은 제목만 훑음 채널 메시지는 나중2단계: 5초 룰 각 메시지당 5초만 쓴다. 판단만 한다."지금 답해야 함" → 🔴 "오늘 중" → 🟡 "이번 주" → 🟢 "답 안 해도 됨" → ⚪이모지로 표시해둔다. 내 마음속으로. 3단계: 🔴만 처리 진짜 급한 건 많아봐야 5개다. 나머지는 나중이다.급한 척하는 메시지 거르기 "급합니다"라고 쓴 메시지의 80%는 안 급하다. 진짜 급한 건 이렇게 온다:"운영 에러 발생" "대표님이 30분 뒤 미팅에서 물어보신대요" "유저 cs 폭주 중"나머지는 대부분 이거다:"제가 급해요" (= 당신 일정은 모름) "오늘까지 가능할까요?" (= 어제 줬으면 좋았을 걸) "확인 좀" (= 대충 봐주세요)구분하는 법. 누가 물어보나 대표님, 이해관계자, 개발 리드가 물으면 🔴. 주니어 개발자, 디자이너가 물으면 🟡. 마케팅 인턴이 물으면 🟢. 냉정하지만 사실이다. 언제까지인가 "지금 당장" → 🔴 "오늘 중" → 🟡 "이번 주" → 🟢 "괜찮을 때" → ⚪ 왜 급한가 썼나 이유 없으면 안 급하다. "릴리즈 전이라" → 🔴 "회의 자료 필요" → 🟡 "궁금해서요" → 🟢 답하는 순서 🔴 급한 것부터 처리한다. 근데 답하는 방식이 있다. 즉답형 (30초 이내) "네, 10시까지 드릴게요" "확인했습니다" "지라 티켓 확인 부탁드려요" 이런 건 바로 답한다. 고민할 필요 없다. 조사형 (5분 이상) "스펙 확인해보고 답드릴게요" "개발팀이랑 싱크 후 회신 드립니다" 이건 시간이 걸린다. 답장에 "언제까지"를 꼭 쓴다. 안 그러면 30분마다 물어본다. 거절형 "이번 스프린트에는 어려울 것 같아요" "우선순위상 다음 주 가능합니다" 이유를 쓴다. 안 그러면 싸운다.실전 사례 어제 아침. 슬랙 62개. 10분 만에 처리한 방법 9:00 - 슬랙 열고 스크롤만. 읽지 않음. 9:03 - 멘션 7개 확인. 🔴 2개, 🟡 3개, 🟢 2개. 9:05 - 🔴 2개 답장. 첫 번째: "운영 DB 에러요" → "확인했습니다. 개발팀 호출할게요" 두 번째: "대표님이 MAU 수치 물으심" → "5분 뒤 노션에 정리해드립니다" 9:10 - 🟡 3개 일정 잡기. "화면 정의서 리뷰" → "오후 2시 30분 어떠세요?" "백로그 우선순위" → "내일 스프린트 리뷰 때 논의합시다" "스펙 질문" → "컨플에 댓글 달아주시면 확인할게요" 9:15 - 🟢 2개 무시. "이 기능 왜 이렇게 됐어요?" → 나중에. 급하지 않다. 10시쯤 답했다. 충분했다. 안 읽는 메시지 몇 가지는 아예 안 읽는다. 1. 단톡방 잡담 "점심 뭐 먹지" "주말에 뭐 했어요" 보지 않는다. 시간 낭비다. 2. 이미 해결된 스레드 누가 답 달았으면 나는 패스. 굳이 끼어들 필요 없다. 3. 나랑 상관없는 기술 논의 "React 18 마이그레이션" "DB 인덱스 최적화" 개발자들이 알아서 한다. 내가 끼어들면 방해만 된다. 4. 'FYI' 메시지 "참고만 하세요" 읽지 않는다. 진짜 중요하면 멘션 달았을 거다. 시간대별 전략 슬랙은 하루 종일 온다. 시간대별로 대응이 다르다. 오전 (9-11시)🔴만 처리 🟡은 시간 잡기만 🟢은 무시아침에는 집중력이 좋다. 기획서 쓸 시간이다. 슬랙에 빠지면 하루가 날아간다. 점심 (12-1시)밀린 🟡 처리 간단한 답장만밥 먹으면서 폰으로 본다. 노트북 열면 일하게 된다. 오후 (2-5시)회의 많음 🟢도 처리 시작 내일 준비회의 사이사이 시간에 답한다. 저녁 (6-7시)급한 거 없으면 안 봄 있어도 내일로 미룸퇴근 시간이다. 슬랙 끄고 집에 간다. 도구와 팁 몇 가지 설정이 도움된다. 알림 커스터마이징멘션만 알림 ON 채널 알림은 OFF DM도 소리 OFF소리 나면 집중 못 한다. 상태 메시지 활용 "🔴 급한 업무 중 (11시까지)" "📝 기획서 작성 중" "🍔 점심 (1시 복귀)" 이거 해놓으면 급한 거 아니면 안 보낸다. 스레드 적극 사용 답장은 스레드로. 채널에 바로 답하면 누가 누구한테 한 말인지 헷갈린다. 슬랙 끄기 집중할 때는 슬랙을 끈다. 30분, 1시간씩. "방해금지 시간" 설정해둔다. 안 그러면 2분마다 메시지 온다. 경계 설정하기 슬랙은 끝이 없다. 경계를 정해야 한다. 즉답 노예 되지 않기 "K님 답장 빠르시네요" 칭찬 아니다. 함정이다. 빨리 답하면 앞으로도 빨리 답해야 한다. 기대치를 낮춰둔다. '급합니다' 남발 견제 "무엇이 급한가요?" "언제까지 필요하신가요?" 되물으면 생각하게 된다. 진짜 급한지. 야근 시간 슬랙 안 보기 8시 넘으면 끈다. 내일 볼 거다. "어? 못 봤네요" 이게 정답이다. 실수와 배움 초반에는 다 답했다. 47개 메시지. 47개 답장. 3시간 걸렸다. 기획서는 못 썼다. 회의 준비도 못 했다. 하루가 슬랙으로 끝났다. 지금은 안다. 슬랙은 내 일이 아니다 슬랙 답하는 게 일이 아니다. 서비스 기획하는 게 일이다. 유저 플로우 그리는 게 일이다. 데이터 분석하는 게 일이다. 슬랙은 도구다. 주인이 되면 안 된다. 모든 메시지에 답할 필요 없다 안 답해도 된다. 정말이다. 중요하면 다시 물어본다. 두 번 물어봐도 안 중요하면 그냥 그런 거다. 우선순위는 내가 정한다 "이거 급해요" 급한지는 내가 판단한다. 보낸 사람이 정하는 게 아니다. 한 달 후 이 방식으로 한 달 지났다. 바뀐 것들. 오전 2시간 확보 9시~11시는 내 시간이다. 슬랙 최소화. 기획서 작성. 생산성이 3배 올랐다. 스트레스 감소 "답 안 했다고 뭐라 하면 어쩌지" 걱정했는데 아무 일 없었다. 정말 급하면 전화 온다. 전화 안 오면 안 급한 거다. 관계 개선 답장 늦어도 이유를 말하니까 이해한다. "스펙 정리 중이라 오후에 드릴게요" 이렇게 말하면 기다린다. 무작정 답 안 하는 것과 다르다. 마무리 슬랙은 폭탄이다. 매일 터진다. 해체하는 법을 배워야 한다. 급한 선 하나 긋고. 중요한 선 하나 긋고. 그 안에 있는 것만 처리한다. 나머지는 내일.슬랙 끄고 일하는 시간. 그게 진짜 일하는 시간이다.

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

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

스펙이 명확하지 않습니다 - 개발팀의 신호를 읽는 법 신호는 이미 왔었다 화요일 오후 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년 차에 깨달았다. 내 머릿속 이미지를 다른 사람은 모른다. 말로 옮겨야 한다. 구체적으로. 지금도 배운다. 매 스프린트마다. 회고 때 물어본다. "어떤 스펙이 애매했나요?" "어떻게 쓰면 더 좋았을까요?" 개발자들이 알려준다. 그들이 진짜 선생님이다. 최근에 배운 것. "버튼 비활성화 조건" 항상 놓친다. 이제는 모든 버튼마다 적는다.활성화 조건 비활성화 조건 비활성화 시 색상 비활성화 시 토스트 메시지작은 것 같지만 이런 게 쌓인다.스펙이 명확하지 않다는 말. 이제는 듣기 전에 먼저 찾아낸다. 그게 성장이다.