목차
개발팀과 주고받는 요청이 늘수록 정작 막힌 건이 묻혔습니다. 무엇을 묻고 무엇을 넘길지가 고민이었어요.
넘기는 범위부터 정했습니다
출발점은 8월 25일 결정권자와 정한 SEO 협업 방식입니다. 그때 문제로 짚인 건 “개발팀 AI와 우리 AI가 서로 반려하는 구조”였어요. 그래서 세 가지를 정했습니다.
- 기존 페이지는 문제 인식과 근거까지만 넘깁니다.
- 신규 기획은 기획서까지 씁니다.
- DB 조회는 모아서 한 번에 요청합니다.
요청은 두 층으로만 나눕니다
10월 1일 신규 서비스 개발 확인 목록이 P0~P2 10건으로 불어난 뒤로는 요청을 두 층으로만 나눠요. 회신이 없으면 그로스가 다음 일을 못 하는 건만 ‘회신 필요’로 둡니다. 보통 3건 안팎이에요. 나머지는 ‘검토 사항’으로 전달만 합니다.
요청서는 이런 모양입니다. 내용은 예시예요.
## 회신 필요 (답이 없으면 다음 작업이 멈춥니다)
1. 결제 완료 신호를 승인 응답 직후에 보낼 수 있을까요?
필요한 시점: 테스트 시작 전
## 검토 사항 (회신 없이 진행합니다)
- 모바일 폼 첫 입력칸 포커스 이벤트가 있으면 이탈 지점을 더 좁힐 수 있습니다.
<!-- 넣기 전 체크: 답이 오면 내 판단이 바뀌나? 안 바뀌면 검토 사항으로 내린다 -->질문을 넣기 전에는 “답이 오면 판단이 바뀌나”를 먼저 따져요. 안 바뀌는 질문은 받는 쪽 시간만 씁니다.
메시지 톤과 역할도 다듬었습니다
- CTO께 보내는 메시지는 지시형에서 여쭙는 제안형으로 바꿨습니다.
- 부탁받지 않은 점검 결과는 제보로 보냅니다.
- 광고 상품의 측정 설계가 과해지자 걷어냈습니다. 신청 규모가 작아서 건별 귀속을 알아도 판단이 바뀌지 않았어요. 개발 요청은 신청 완료 신호 1건만 남겼습니다.
- 목표 때문에 동료 업무가 늘어나면 ‘역할별 업무량’ 표로 정리해 팀리드에게 배분을 맡깁니다.