기획자의 작업대

Jira 7일차: 기획자가 개발자와 잘 소통하기 위해 꼭 기억할 핵심 정리 Jira 7일차: 기획자가 개발자와 잘 소통하기 위해 꼭 기억할 핵심 정리 기획자가 Jira를 이해해야 하는 이유는 단순히 티켓을 보기 위해서가 아닙니다. 개발자의 작업 흐름과 일정의 현실을 더 정확하게 이해하고, 더 짧고 선명하게 소통하기 위해서입니다. 이번 글에서는 7일 동안 다뤘던 핵심 내용을 실무 중심으로 정리해, 개발자와 더 잘 소통하기 위해 꼭 기억해야 할 포인트를 한 번에 묶어봅니다. 서론 Jira를 처음 접하는 기획자에게는 화면도 많고 용어도 많고 상태값도 많아 보입니다. Issue, Epic, Story, Task, Backlog, Sprint, Board 같은 단어는 익숙해지기 전까지는 회의실의 외계어처럼 느껴질 수 있습니다. 그래서 처음에는 Jira가 개발자만을 위한 도구처럼 보이기도 합니다. 하지만 7일 동안 차근차근 흐름을 따라오면 보이는 것이 달라집니다. Jira는 단순한 티켓판이 아니라, 프로젝트의 우선순위와 실행 계획, 상태와 병목, 일정과 릴리스가 남는 협업의 기록판입니다. 어떤 일이 후보군에 있는지, 무엇이 이번 스프린트에 들어갔는지, 어디서 막히는지, 어떤 릴리스에 묶여 있는지를 한곳에서 읽을 수 있습니다. 기획자가 Jira를 이해하면 개발자와의 대화는 훨씬 짧아집니다. “언제 돼요?” 대신 “이 이슈는 아직 백로그 단계인가요, 아니면 이번 스프린트 범위인가요?”라고 묻게 되기 때문입니다. 질문이 달라지면 답도 달라집니다. 협업은 결국 같은 화면을 보고 같은 상태를 이해하는 일입니다. 이번 마지막 글에서는 1일차부터 6일차까지 다뤘던 내용을 실무 관점에서 다시 묶어보겠습니다. Jira를 왜 알아야 하는지, 어떤 개념을 먼저 잡아야 하는지, 어떤 ...

Jira 5일차: 기획자가 개발자에게 더 정확하게 요청하는 방법 Jira 5일차: 기획자가 개발자에게 더 정확하게 요청하는 방법 기획자가 Jira를 이해하기 시작하면 가장 먼저 달라져야 하는 것은 보는 눈입니다. 그리고 그다음에 달라져야 하는 것은 요청의 방식입니다. 이번 글에서는 Jira의 이슈 구조를 바탕으로 개발자에게 더 정확하고 실무적으로 요청하는 방법을 정리합니다. 서론 기획자와 개발자의 소통이 어려운 이유는 종종 정보 부족보다 요청 방식의 차이에서 시작됩니다. 기획자는 결과를 원하고, 개발자는 조건과 범위를 확인합니다. 기획자는 “이 기능 수정해 주세요”라고 말하고, 개발자는 “어느 화면인지, 어떤 예외가 있는지, 완료 기준은 무엇인지”를 다시 묻습니다. 둘 다 틀린 말은 아니지만, 시작점이 다르면 대화는 자꾸 왕복합니다. Jira를 이해한 기획자는 이 왕복을 줄일 수 있습니다. Jira의 이슈는 제목, 설명, 상태, 우선순위, 담당자, 워크플로 같은 필드로 협업 정보를 모으고, 팀이 필요한 문맥을 같은 장소에서 보게 해줍니다. Atlassian은 이슈에 상태, 우선순위, 담당자, 링크, 댓글 같은 정보가 붙고, 이것들이 팀이 일을 이해하고 추적하는 데 중요한 필드라고 설명합니다. 또한 Atlassian은 사용자 스토리에 사용자 관점, 목표, 이유, 그리고 수용 기준이 포함되는 것이 좋다고 설명하며, 수용 기준은 특정 작업이 완료로 받아들여지기 위한 명확하고 테스트 가능한 조건이라고 안내합니다. 이번 글에서는 기획자가 Jira를 바탕으로 개발자에게 어떻게 요청해야 하는지 실무 관점에서 정리합니다. 막연한 요청과 좋은 요청의 차이, 이슈 필드별 작성 포인트, 수용 기준을 쓰는 법, 상황별 요청 예시까지 콘텐츠 중심으로 다뤄보겠습니다. 좋은 요청...

GitHub 7일차: 기획자가 개발자와 잘 소통하기 위해 꼭 기억할 핵심 정리 GitHub 7일차: 기획자가 개발자와 잘 소통하기 위해 꼭 기억할 핵심 정리 기획자가 GitHub를 이해해야 하는 이유는 코드를 읽기 위해서가 아니라, 개발자의 작업 흐름과 협업의 구조를 더 정확히 이해하기 위해서입니다. 이번 글에서는 7일 동안 다뤘던 핵심 내용을 실무 중심으로 정리해, 개발자와 더 잘 소통하기 위해 꼭 기억해야 할 포인트를 한 번에 정리합니다. 서론 GitHub를 처음 접한 기획자에게는 모든 것이 낯설게 느껴질 수 있습니다. Repository, Branch, Commit, Pull Request, Issue 같은 단어는 익숙하지 않고, 화면은 복잡해 보이며, 개발자의 대화는 너무 빠르게 흘러갑니다. 그래서 처음에는 GitHub가 개발자만을 위한 공간처럼 보이기도 합니다. 하지만 7일 동안 차근차근 흐름을 따라오면 보이는 것이 달라집니다. GitHub는 단순한 코드 저장소가 아니라, 프로젝트의 작업 흔적과 협업 맥락이 남는 공간입니다. 누가 무엇을 바꿨는지, 어떤 요청이 들어왔는지, 어떤 논의가 있었는지, 무엇이 반영되었는지를 확인할 수 있는 협업의 기록장입니다. 기획자가 이 구조를 이해하면 개발자와의 대화는 훨씬 짧고 정확해집니다. 이번 마지막 글에서는 1일차부터 6일차까지 다뤘던 내용을 실무 관점에서 다시 묶어 보겠습니다. GitHub를 왜 알아야 하는지, 어떤 개념을 먼저 이해해야 하는지, 어떤 화면을 봐야 하는지, 어떻게 질문해야 하는지, 어떤 실수를 줄여야 하는지까지 핵심만 모아 정리하겠습니다. 시리즈 마지막 날인 만큼, 오늘은 새로운 벽돌을 쌓는 날이라기보다 이미 쌓은 벽을 한 번 손으로 두드려 보는 날입니다. 생각보다 튼튼하면 꽤 뿌듯합...

GitHub 5일차: 기획자가 개발자에게 더 정확하게 질문하는 방법 GitHub 5일차: 기획자가 개발자에게 더 정확하게 질문하는 방법 기획자가 GitHub를 이해하기 시작하면 가장 먼저 달라지는 것은 보는 눈입니다. 그리고 그다음에 달라져야 하는 것은 질문의 방식입니다. 이번 글에서는 GitHub의 흐름을 바탕으로 개발자에게 더 정확하고 실무적인 질문을 던지는 방법을 정리합니다. 서론 기획자와 개발자의 소통이 어려운 이유는 종종 정보 부족보다 질문 방식의 차이에서 시작됩니다. 기획자는 결과를 알고 싶어 하고, 개발자는 과정과 조건을 설명합니다. 기획자는 “언제 되나요?”라고 묻고, 개발자는 “리뷰가 남아 있고 예외 케이스를 확인해야 합니다”라고 답합니다. 둘 다 틀린 말은 아니지만, 서로 서 있는 좌표가 다르면 대화는 자꾸 비껴갑니다. GitHub를 이해한 기획자는 이 좌표를 조금 더 개발자의 언어 쪽으로 옮길 수 있습니다. Issue가 열려 있는지, Pull Request가 리뷰 중인지, Branch가 아직 살아 있는지, Commit이 최근에도 쌓이고 있는지를 보면 지금 상황이 단순 대기인지, 작업 중인지, 검토 단계인지 훨씬 명확하게 보입니다. 이 상태를 알고 질문하면 같은 질문도 전혀 다른 품질로 바뀝니다. 이번 글에서는 기획자가 GitHub를 바탕으로 개발자에게 어떻게 질문해야 하는지 실무 관점에서 정리합니다. 막연한 질문과 좋은 질문의 차이, 상황별 질문 구조, 실제 협업에서 바로 써먹을 수 있는 표현까지 콘텐츠 중심으로 다뤄보겠습니다. 질문은 단순한 말이 아니라 협업의 방향키입니다. 방향키를 잘못 누르면 프로젝트는 옆 차선으로 신나게 미끄러집니다. ...

말 안 통하는 개발자와 싸우지 않고 ‘의도’대로 구현시키는 법 (기획자 필수 커뮤니케이션) 말 안 통하는 개발자와 싸우지 않고 ‘의도’대로 구현시키는 법 (기획자 필수 커뮤니케이션) 기획서와 Figma 시안을 정성껏 준비해 Handoff 미팅에 들어갔는데, 시작 10분 만에 이런 말을 듣는 순간이 있습니다. “기획대로 다 하려면 최소 1년은 걸립니다. 기능 좀 빼서 다시 전해 주세요.” 머릿속이 하얘지죠. ‘이 기능이 빠지면 서비스가 안 돌아가는데…’, ‘현업에는 뭐라고 설명하지…’라는 걱정이 앞섭니다. 사실 저도 그랬습니다. 처음 이런 피드백을 받았을 때, 속으로 ‘개발하기 싫어서 핑계 대는 거 아닌가?’라고 오해하기도 했고, 제 기획 능력이 부족한 것 같아 며칠을 자책하며 기획서를 고치고 또 고쳤거든요. 하지만 수많은 충돌 끝에 깨달았습니다. 이건 누군가의 잘못이 아니라, 서로가 사용하는 ‘언어’와 ‘우선순위’가 달랐을 뿐이라는 것을요. 여기서 “왜 안 돼요?”라며 감정적으로 맞붙으면 소모적인 기싸움이 되고, “네, 알겠습니다…”라며 무조건 물러나면 기획의 본질이 증발해 버립니다. 오늘은 제가 수많은 시행착오 끝에 정착한 방법, 즉 개발자와 싸우지 않으면서도 기획의 ‘의도’를 끝까지 지켜내는 실무 커뮤니케이션 전략 을 정리해 보려 합니다. 📚 목차 개발자의 “1년” 뒤에 숨은 진짜 의미 해석하기 “기능”이 아니라 “비즈니스 임팩트”로 대화하기 ‘안 된다’를 ‘어떻게 하면 된다’로 바꾸는 질문 템플릿 기획서와 Figma를 ‘그림’에서 ‘설계도’로 바꾸는 방법 Handoff 미팅을 ‘전달’이 아니라 ‘합의’로 만드는 진행 스크립트 최종 체크리스트 + 자주 묻는 질문(FAQ) 1) 개발자의 “1년” 뒤에 숨...