'10년차 IT 기획자의 노트' 리뷰

 

 

서비스 기획에 관련된 여러 책을 읽다보면 결국 궁금증은 하나로 이어진다. '그래서 뭘 어떻게 해야하라는 건데?' 이 질문이 계속해서 머릿속을 돌아다닌다. 많은 서비스 기획과 관련된 책에서 여러 방법론과 마인드셋에 대해 알려주는데 이를 내재화해서 적용하면 분명 도움이 되겠지만, 당장 현실적으로 서비스를 기획을 할 때 반영할 수 있는 건 아니다. 이런 고민을 하다가 접하게 된 것이 바로 이 책이다. 이 책은 10년간 여러 스타트업에서 IT 기획자로서 근무하며 겪은 다양한 상황에 대한 대응 방법과 프로젝트를 어떻게 관리해야 하는지, 문서 정리 방법은 또 어떤 식으로 하는 것이 좋은 지에 대해 알려준다. 프로젝트를 진행하다보면 노션에서 많은 문서를 정리하고 공유하게 되는데, 이를 잘 알려준다는 점에서 실무적으로 많은 도움이 되는 책이라고 생각한다.

 

---

 

9가지 노트

 

1. 배움 노트

내용

• 뉴스레터, 미디어 등에서 본 정보
• 일하면서 경험하고 알게 된 내용

정리법

• 날짜, 내용 구분에 따라 페이지 별도 생성해 정리 ➜ '태그'로 내용 핵심 키워드 등록
• 새롭게 알게 된 지식, 실수로 깨닫게 된 내용 등 기록 ➜ 상황 구체적 명시, 배운 점, 개선점 등 기록

 

2. 리뷰 노트

내용

• 신규 런칭 앱, 서비스, 담당 서비스와 유사하거나 참고할만한 앱 등 리뷰

정리법

• 서비스 이름, 버전, 기능 이름, OS 등 태그로 달기

 

3. 팀 기획 노트

내용

• 여러 사람이 같이 보는 공용 문서
• 기준(개요) ➜ 팀원 의견 청취 후 내용 구성
• 주요 문서(팀 운영 관련 여러 문서) 링크 정리
• 현재 진행 중, 진행 예정 프로젝트 관련 스펙 노트 링크 걸기 ➜ 수시 열람하며 원래 의도, 개발 방향 잊지 않기
• 새롭게 추가됐으면 하는 각종 아이디어, 팀 업무 도움될만한 참고 자료 등 메모

 

4. 스펙 노트(PRD, 정책 등)

내용

• 개발 목표, 주요 기능, 개발 범위, 담당 인원 등이 담긴 일종의 개발 가이드 문서
• 프로젝트 필요한 이유, 얻을 수 있는 가치

정리법

1. 해결하고자 하는 문제 작성
2. 달성하고자 하는 목표
3. 이번 플젝에 포함되지 않는 사항 정리(for 개발 범위, 일정 산정)
4. 용어 정의
5. 일정, 담당자 지정
6. 핵심 기능 위주 개발 내용 정리
7. 주요 담당자들과 함께 리뷰
8. 최종 개발 스펙 확정

 

5. 운영 매뉴얼

내용

• 새로 개발된 앱/서비스 운영 원활히 하기 위함
• 어디에 무슨 기능, 이를 관리 하는 방법 등 안내
• 바뀌는 정책, 일부 업데이트 되는 기능 등 반영 필수
• 내용 정리되면 가장 빈도 높은 질문만 뽑아 FAQ 추가 작성

 

6. 기능 가이드

내용

• 새로 업데이트되는 추가 기능에 대해 담당자(or 부서)별 해석 및 이용 안내 문서
• 새로 업데이트된 사항에 초점 맞춰 정리
• 기능 추가 어디에 됐는지, 사용자에게 어떻게 고지할 것인지 등 포함

정리법

• 개요, 배포 계획, 기능 안내, 기능 FAQ, 담당자, 참고 순서 정리

 

7. 백로그

내용

• 투두리스트 정로로 생각하면 X
• 앞으로 개발해야 할 내용, 제품에서 새롭게 요구하는 기능 등 미리 점검, 우선 순위 정하는 것

정리법

• 해결하려는 문제는 무엇인가? (일해야 하는 이유)
• 누구를 위해 문제를 해결하려는 것인가? (누구에게 어떤 접근 필요?)
• 우리가 바라는 결과는 무엇인가? (성공을 검증하는 기준?)

 

8. 회고 노트

내용

• KPT 방법 활용
• Keep(좋았던 부분), Problem(잘 안된 부분), Try(문제 해결 위해 실행가능한 부분)
• Action(회고 내용 중 실제 행동으로 옮길 것)

정리법

• 팀마다 페이지 생성 ➜ 각자 작성한 내용 한곳에 모으기 (서로의 내용 참고 X, 온전히 자신 의견 작성)

 

9. 피드백 노트

내용

• 피드백 받은 내용 몇가지(상황별, 유형별 등) 기준으로 분류, 내 생각 기록 ➜ 수시로 꺼내보고 리마인드

정리법

1. 피드백 필요한 내용인지 판단
2. 피드백 필요한 이유, 누구에게 받을 것인지 등 정하기
3. 피드백 요청 내용을 질문 형태로 작성
4. 피드백 완료
5. 피드백 내용 살피고, 내 생각 다시 메모

 

---

 

일의 순서를 통제하는 법

• Time Block: 언제까지 무엇을 해야 하는지 모두 적고, 업무 우선순위 파악하는 방법
• 추가 기준:
  • 업무와 업무(시간과 시간) 사이 10~15분 정도의 여유 두기
  • 다른 업무가 끼어들 때 우선순위 다시 정하기
  • 하나씩 뒤로 미루기보다 빠지게 된 업무만 다른 시간대 찾아 넣기

 

배움을 구체화하는 법

• 우리에게 익숙하다는 이유로 커뮤니케이션 수단을 정하지 않기
• 상대방 상황을 고려하기
• 실패로 끝난다 하더라도 이를 배움으로 받아들이는 마음가짐 중요
• 노션에 <배움 노트>를 확인하는 것으로 하루 마무리 ➜ 배움을 써먹고, 실수를 줄이기
• 세 번부터는 어느 누구라도 실수를 봐주지 않음
• 배움을 기록하고 확인하는 일을 빼먹지 않아야 함

 

기획자의 데이터 분석 루틴

• 서비스의 목표가 무엇인지 생각해보기
• 데이터와 목표를 연결 짓는 과정에서 집중할 데이터 범위 정하고, 사업 목적에 맞춰 분석하기
• 가설 설정: 어디에 초점을 맞춰 데이터를 확인할 지, 잘했는지 개선이 필요한지 등 판단하는 중요한 기준
  • 가설을 확인하기 위한 데이터 수집이 필요(무작정 데이터 열어보기 X)
• 사용자 의견 받기: 설문 코너 or 오프라인 만나 이야기 듣기 ➜ 데이터로 파악안되는 앱 만족도, 기타 의견 자세히 청취
• 데이터의 중요성
  • 설득의 근거: 근거가 있다면 비교를 통해 더 나은 의사결정 가능, 근거가 없다면 말 잘하고 포기하지 않고 목소리 큰 사람이 주도권 가짐
  • 무엇을 잘 했는지 확인하는 데 필요한 기준 제공: 뭘 잘했고, 뭘 놓쳤는지 알게 도와줌(다만, 보고 싶은대로 데이터 보면 X)
  • 진짜 중요한 것이 무엇인지 알려줌
• 데이터를 해석하는 주관자의 시선에 따라 데이터는 다르게 사용됨(발견못한 새로운 사실을 계속 발견 가능)

 

기획자로서 신뢰를 얻는 소통법

• 각자의 업무 방식을 적고, 충돌 or 문제 발생될 것 같은 부분에 빨간색 표시
• 개발자 성향, 기존 프로덕트 개발 과정 등 듣기
• 함께 일할 구성원들과 1:1 인터뷰 진행:
  • 개발자와 기획 사이의 이해관계 좁히고, 서로 이해하는 계기 마련 가능
  • PM을 중심으로 끈끈하게 뭉치는 방법 알기 가능
  • 프로젝트 출발 전 팀원 간 신뢰도 높이는 좋은 방식
• 서로를 잘 아는것, 공간의 기준과 바탕을 만드는 것이 프로젝트의 출발점

 

필요한 일을 주도적으로 찾는 법

• 입사 이후 기본 가이드를 받는다 하더라도, 어떻게 일할 것인지 스스로 정의하는 온보딩 과정 중요
  • 넓은 범위에서 내가 하는 일이 무엇인가? 그 일이 가진 역할과 가치는 무엇인가?
• 업무 리스트 작성하기
  • 기존 기획 문서 확인, 동료 업무 스타일 관찰 ➜ 1:1 인터뷰 통해 기존 업무 방식에서 개선되었으면 하는 점, 기획자에게 바라는 점 등 청취 ➜ 해야 하는 일 리스트업 ➜ 동료 만나 확인 ➜ 일정 정하기(우선순위)
• 나보다 팀에게 더 필요한 일인지 판단하기
  • 할 수 있는 일과 할 수 없는 일을 구분 ➜ 팀에게 꼭 필요하고 도움되는 일인지 판단하기, 욕심으로 무리하게 일을 잡는다면 업무는 밀리고 팀원의 불만 일정에 영향 가능

 

프로젝트 시작을 잘하는 법

• 현실적으로 소화 가능한 방향으로 세부 기능에 집중해 기획안 다시 정리
• <스펙 노트>에 플젝 필요한 이유, 얻을 가치 등 포함, 담당자 미리 지정 ➜ 미팅(최소 단위로 기능 줄이고 시간 파악, 우려 부분, 이슈 의견)
• 새로운 일에 대한 설득: '왜' <<< '어떻게' ➜ 동료의 부담을 줄일 수 있는 일
• 신규 프로젝트 논의에 동료가 자발적으로 참여하도록
• 팀과 회사의 상황을 고려해 업무 분배, 일정 산정

 

나 없이도 서비스가 돌아가는 법

• 보통 프로젝트의 모든 이슈가 '기획자'를 통함
• 단계별로 <운영 매뉴얼> 작성 ➜ 주간 회의 통해 내용 업데이트 
  • 서비스 관련 문의 내용 정리 ➜ 채널별 문의 내용 정리
  • 반복 정도에 따라 우선 순위 결정 ➜ + 현재 대응 가능한 방법 함께 고려
  • 자동화 가능한 업무가 있는지 파악 (ex. 매일 아침 자동 상황 알려주는 봇)
  • 앞으로 업데이트될 기능 파악 ➜ FAQ 미리 작성해보기

 

서비스 기능 변경 or 업데이트 잘하는 법

• 문서를 공유하더라도 기획자의 언어가 아닌, 우리 모두의 언어로 전달해야 함
• 내부 지원 성격의 <기능 가이드> 필요: 마케팅, 고객 지원, 세일즈, 개발, 디자인 고려
• 각자가 새롭게 추가, 변겨오디는 기능을 어떻게 받아들일 지 관점과 기준이 생김

 

실수를 줄이는 법

• 영향을 받는 기능 지표 확인하기: OS별 화면 캡쳐 ➜ 전체 영향 받는 구간 확인
• 오버플로우 툴 활용: 실제 화면 캡쳐, 흐름 시각화, 메모 남기기
• 기획자에게 변수 통제 = 일이 물 흐르듯 흘러가도록 하는 것
• 기능 자체 잘 설계, 사후 관리 운영은 더 중요 ➜ 팀 전체 일정, 업무에 영향

 

해야할 일을 정하고, 정보와 지식을 관리하는 법

• <백로그>: 팀원 의견, 이슈, 사용자 피드백, 기능 개선 등 다양한 성격의 '할 일' 저장
• 백로그 우선순위 찾기: MoSCoW, KANO, RICE 등
• 자료 공유 방법 다시 생각하기: 링크 + 공유 목적 + 활용 방안 등 개인 의견 덧붙이기
• <팀 기획 노트>에 정리하기

 

더 나아짐에 목표를 둔 회고

• 회고가 어떤 의미인가? 회고에서 중복된 내용이 무엇인가? 회고 했음에도 문제 해결이 안되는 이유는?
• 회고 방법: 4L(Liked, Lacked, Learned, Longed for)
• 회고 방법 개선, 회고 종합 시간 필요

 

제안서 작성이 쉬워지는 법

• 제안서 쓰는 이유, 누가 최종적으로 보는지, 미리 논의된 내용이 없는지 확인하고 시작
• 내부 피드백 ➜ 기본 뼈대(목차) ➜ 질문형으로 바꿔보기(ex. 우리가~해결할 수 있는 방법은?) ➜ 이야기하듯 쭉 읽어보기
• 자료 찾기 ➜ 문서 작성 ➜ 내용 우선순위 파악 후 분량 조절(덜어내는 내용이 많아야 하고자 하는 이야기가 선명해짐)
• 다시 내부 피드백

 

혼란을 초래하지 않는 커뮤니케이션

• 1:1 커뮤니케이션 상황을 지양해야
  • 서로의 이해 수준에 대해 실시간 파악 어려움
  • 한 주제를 가지고서 다시 논의하는 상황을 줄이기 위해
  • 내가 모르는 상황을 만들지 않기 위해

 

성장의 갈증을 없애는 방법 : 사이드 프로젝트 주의점

• <지금 써보러 갑니다>: 앱 소개, 페북 페이지 개설, 페북 페이지 광고, 워드프레스 공부, 서비스 사이트 제작 개설, 광고 제작 운영, 검색엔진 최적화 진행, IT 관련 미디어와의 제휴, 페이스북 그룹 개설, 뉴스레터 제작 및 발행
• '욕심내지 말자': '사이드'=철저히 업무 시간 밖에서 진행 ➜ 한정된 시간 잘 활용해야
• 목표 달성에 따라오는 성취감 중요: 작은 목표라도 단계별로 달성해나가기
• 대단하다고 느끼는 어떤 것이 아니라 작게 시작할 수 있는 무언가로 스타트

 

유사/경쟁 서비스 분석 방법

• 기능 업데이트: 업데이트 의도 파악 ➜ 우리 서비스 적용 고민
• 담당 앱과 비슷한 앱, 업무에 자주 쓰는 앱, 실생활에서 자주 쓰는 앱, 새롭게 알게 된 앱 등으로 구분 ➜ 폴더화
• 릴리즈 노트 확인: 이전 버전과 새 버전 캡쳐 비교
• 해결하고자 하는 문제, 핵심 기능, 써본 느낌, 분석 이유, 사용 경험 등
• 자신만의 <리뷰 노트> 만들기

 

슬럼프와 번아웃을 이겨내는 방법

• 일과 쉼의 경계 지키기
• 하고싶은 것들을 우선순위에 따라 작성
• 동기부여: 나로부터의 시작, 일의 의미를 확고히 해야함
• 커리어 방향(3년, 5년 후) 설정하기

 

글쓰기를 꾸준히 하는 법

• 생각하는 습관을 들이는 데 중요(논리를 탄탄하게 하기)
• 트렌드, 정책 등 흐름에 대한 이해도 높이기 가능
• 두려움을 이겨내는 마음가짐이 중요
• 글쓰는 시간을 따로 만들기

 

피드백을 잘 활용하는 방법

• 모든 피드백을 무조건 수용하지 X
• 모든 걸 신경쓰면 내가 가져야 할 기준이 흔들릴 수 밖에 없음 ➜ 전진해야 할 때 타이밍을 놓침
• 피드백 요청 시 상대의 강점을 파악한 후 가려서 요청
• 피드백의 목적: 다양하게 받는 것 X ➜ 정확하게 받는 것 O
• 피드백을 듣고 어디까지 수용할 것인지 판단 필요

 

기분 나쁘지 않게 거절하는 법

• 정작 내 일은 못하고, 남 일만 열심히 하게 되는 꼴 가능
• 적절한 기준을 갖고 승낙해야 함
• 경험, 보수/인센티브에 현혹되지 X, 팀의 우선순위를 생각해봐야
• 거절의 이유를 생각해야 함: '좋은 의견이지만 제 생각에는 ~'

 

좋은 질문을 하는 법

• 보통 기획자가 PM으로서 프로젝트를 이끄는 경우가 많은데, 팀원이 질문에 대답을 하지 않는다면 이는 기획자의 잘못
  • 질문 받는 팀원의 상황을 고려해야 함
  • 미리 질문 공유하고 생각해보는 시간을 갖게 하기
  • 어떤 목적의 미팅인지 문서로 먼저 공유
• 질문을 할 때는 매우 구체적으로 하기
  • 질문의 의도를 다시 물어볼 수도 있음
  • 팀 단위로 자주 하는 질문 모음집 고려

 

이런 기획자가 되자

• 감정 조절을 잘하는 사람이 되자 ➜ 기록(글쓰기)으로 감정 주체 못하는 이유, 결과를 글로 써보기
• 배려하는 사람이 되자 ➜ 수정 사항 발생 시 수정된 자료 + 최근에 함께 논의한 내용에 끼친 영향 전달
• 왜?라는 이유에 답할 수 있는 사람이 되자 ➜ 왜 이 일을 해야하는지 명확한 근거를 가지고 있어야 설득 가능
• 모든 과정에 원인/이유를 생각하는 사람이 되자 ➜ 이견 발생 시 1:1 대화로 원인을 정확히 파악 후 해결 방법 찾기
• 팀과 함께 성장하는 사람이 되자 ➜ 같은 실수를 반복하지 않게 함께 노력할 방법 찾기
• 함께 일하는 팀원에게 집중할 수 있는 사람이 되자 ➜ 기획이 끝났다고 손놓지 X, 팀원 어려움 등 파악
• 경험을 의심할 수 있는 사람이 되자 ➜ 경험은 지극히 주관적임

 

 

 

출처 | 한성규, 10년차 IT 기획자의 노트 : 아홉 개의 노트가 알려준 성장과 배움의 습관, 좋은습관연구소, 2023