IT 스타트업 업무 체계, 과정, 산출물, 커뮤니케이션
[들어가기 앞서 - 스타트업의 직무와 업무 범위에 대해]
IT 스타트업에서는 직무 정의와 업무 범위가 굉장히 천차만별입니다. 스타트업은 본질적으로 리소스(인적 자원, 시간, 돈)가 부족할 수밖에 없기 때문입니다. 그래서 사업이 정상적으로 진행되기 위해 필요한 과정들이 진행되려면 제한된 인력으로 업무 범위를 넓게 잡거나, 아니면 전문성이 필요한 상황이 와 특정 업무에만 집중하는 인력을 배치해야 하는 상황이 발생하는 등 여러가지 경우의 수가 발생합니다.
위의 ‘업무적 범위에 따른 직무 정의’는 ‘제품 관리(직접적으로 제품을 만드는 행위)’ 과정에 관여하는 주요 직무를 기준으로 개인의 주관적 기준에 따라 나눈 것이며, 일반적인 정의는 아님을 알려드립니다.
또한, 프로덕트 오너(Product Owner)와 같이 ‘스크럼’이라는 특정 프레임 워크에서 칭해지는 ‘역할’은 직무로 규정하지 않았으며, 통상적으로 칭해지는 직무 하위에 세부적으로 나뉘는 직무들(ex. 마케터 내에 컨텐츠, 퍼포먼스, 브랜딩 등을 나누는 경우)은 포함하지 않았습니다.
그래서 위의 사진과 같이, 업무의 범위에 따라 직무의 이름도 다양해집니다. 하지만 분명한 것은, 사업에서 필요한 각 단계와 각 단계에서 필요한 작업들은 변하지 않는다는 점입니다. 그렇기에 사업과 제품이 성공적으로 진행될 수 있으려면, 스타트업 내의 인원들이 각자 나름대로의 역량을 발휘하여 각 단계에서 필요한 것들을 챙기고 앞으로 나아갈 수 있어야 합니다.
[이 글의 목적]
잘못된 제품, 프로젝트 관리는 조직 전체를 파국으로 치닫게 할 수 있습니다.
탁월한 제품팀은 수평적인 조직 구조를 갖고 있으며, 이는 프로덕트 매니저가 ‘CEO 행세를 하지 않는다는 것’을 의미합니다.
Finally, just to be very clear, an empowered product team is a flat structure, and this means the product manager is not the boss of anyone.
- 마티 케이건, 인스파이어드
제품 관리는 협업을 중심으로 진행되기 때문에, 누군가의 책임 전가나 업무 미비는 협업 하는 사람들에게 심리적 불안과 분노를 느끼게 할 뿐만 아니라 업무 과중과 비효율을 야기합니다. 특히, PM의 업무 미비와 업무 소홀은 본인에게 손해일뿐만 아니라, 팀의 붕괴를 일으킬 수 있습니다. 직접적이든 간접적이든, 프로젝트가 제대로 진행되지 않는 상황에서 수동적으로 기다리기만 하거나, 처음부터 누군가의 탓을 하거나, 해결책을 적극적으로 찾지 않는다면 이는 PM의 문제일 가능성이 큽니다. 왜냐하면, PM이 가지고 있는 유일한 장점이자 직무적 의미는 ‘CEO가 갖는 권위(권위란 것은, 협업에서 굉장한 단점이 됩니다.)없이 팀원들과 조화를 이뤄내 프로젝트를 성공으로 이끄는 것’이기 때문입니다.
PM이 CEO 행세를 하는 것은 다음과 같습니다.
- 프로젝트가 원활하게 돌아가기 위해서와 팀원들이 업무를 효율적으로 진행하기 위해 필요한 리소스들을 충분히 준비하지 않은 채 팀원들에게 일을 시작하라고 시작하는 경우
- 프로젝트상 문제가 발생했을 때 문제의 당사자와 직접 이야기하지 않고, 문제의 원인을 파악하지 않은 채 아무 조치도 취하지 않는 경우
- 프로젝트의 실패를 팀원의 잘못으로만 돌리는 경우
블라인드에서 최근에 비슷한 예시가 올라왔던 적이 있습니다. 요즘 IT 업계에서 PM들의 업무에 관해서 지속적으로 오르내리는 화제이기도 합니다.
본 글은 효과적인 제품 관리(product management)를 위해 필요한 것들을 설명하기 위해 작성했습니다. 제품 관리 과정의 거시적 분류는 SVPG의 INSPIRED를 기준으로 분류하였으며, 하위의 세부 항목들은 직무와 각 직무의 업무 단계를 기준으로 작성했습니다.
이 글에서는 효과적인 제품 관리를 위한 마인드셋과 전제에 대해서는 깊게 다루지 않습니다. 해당 주제에 관해서는 아래 링크를 참고해주세요.
- 지극히 개인적인 제품 전략과 제품 관리 체계 https://brunch.co.kr/@uxn00b/383
- 왜 어떤 팀의 프로덕트 오너(PO)는 무능한가 https://brunch.co.kr/@uxn00b/124
- 프로덕트 매니저(PM)란? (feat. CEO, PO) https://brunch.co.kr/@uxn00b/27
- 강력한 프로덕트팀을 만들기 위한 원칙 https://brunch.co.kr/@uxn00b/24
- 제품을 위한 조직 구조를 어떻게 만들 것인가? https://brunch.co.kr/@uxn00b/28
- 프로덕트 매니저와 협력 https://brunch.co.kr/@uxn00b/87
- 사람을 기계처럼 업무하게 만든다면 그것은 체계가 아니다 https://brunch.co.kr/@uxn00b/377
전체 내용 표생산적인 업무와 논의를 위한 커뮤니케이션 원칙
- 사람은 누구나 실수하기 때문에 문제가 발생할 수 있는 것은 당연합니다. 하지만 문제를 빠르게 인지하고 개선시키는 것이 중요합니다. 그렇기 때문에 동일한 원인으로 인해 문제가 반복적으로 일어난다는 것은 업무가 제대로 이뤄지고 있지 않다는 것을 의미할 수 있으며, 본질적인 원인이 무엇인지 파악해야 합니다.
- 논의가 필요한 사항은 회의 전에 미리 관련 안건과 논의 목적을 정리하여 전달하여, 미팅에서는 생산적인 논의가 이뤄질 수 있도록 진행합니다.
- 논의를 요청한다는 것은 다른 사람의 시간을 사용한다는 것입니다. 다른 사람의 시간의 기회비용을 희생할 만큼의 준비가 되지 않았다면(회의를 제대로 준비 못 했다거나, 회의의 생산성이 적다면), 더 효율적인 방법을 고민해보세요.
- 산출물을 만들었다는 것은 그 일이 끝났다는 것이 아니라, 그 일이 이제 시작될 수 있음을 의미합니다. 그렇기에 그 이후의 일이 제대로 흘러가지 않았다면, 직접적으로 보이는 문제는 피상적인 현상일 뿐이고, 본질적인 문제는 이전 단계에 있을 가능성이 크다는 것을 인지해야 합니다.
✅ DO
- 업무의 목적이 무엇인지, 그 목적을 달성하기 위해 필요한 것들이 무엇인지 고민하고 상세화합니다.
- 논의가 왜 필요한지, 안건이 정말 필요한 사안인지 파악합니다.
- 논의 목적을 달성하기 위한 자료와 정보를 철저히 준비합니다.
- 프로젝트 진행 사항에 영향을 끼치는 요소는 간소화하여 관련 슬랙 채널이나 노션에 기록한 후, 관련 프로젝트를 일원화하여 관리하는 곳에 아카이빙 해둡니다.
❌ DON’T
- 소개의 목적이 아닌 회의에서 논의 안건을 회의 자리에서 공개하고, 설명하는 데에만 시간을 모두 소진하는 경우
- 스스로 해결 가능한 안건을 무작정 회의를 통해 해결하려 하는 경우
- 논의를 위한 정보들이 제대로 준비되지 않은 상태에서 논의를 진행하여 불확실성으로 인해 미팅 후 액션 플랜이 사실상 무의미해지는 경우
- 본인의 산출물을 만들었다고 해서 그 일에 대한 관여도를 낮추는 경우
- 사업적인 중요도나 영향이 불명확하거나, 논의로써 알 수 없는 안건에 대해 지속적으로 논의하며 장시간을 잡아먹는 경우
의사결정권자(ex. 리드, 임원진)와 효과적인 논의를 위한 원칙
- 의사결정권자는 회사 리소스를 효과적으로 배분하기 위해 프로젝트의 전반적인 상황과 주요 이슈를 파악해야 합니다. 이를 위해 필요한 정보를 일목요연하게 정리하여 전달해야 합니다.
✅ DO
- 프로젝트 현재 단계, 진행 상황, 문제 사항, 일정 차질 여부 등을 포함한 문서를 준비합니다.
❌DON’T
- 회의 목적에 맞지 않은 지엽적인 사항 전달 및 논의 (예: 실무자와 결정해야 할 것을 안건으로 끌어오는 경우)
실무진과 효과적인 논의를 위한 원칙
- 실무진 간의 정보 전달은 효율적인 협업의 기본입니다. 문서화와 시각화를 통해 작업 효율성을 높이고, 필요한 경우 즉시 논의를 통해 문제를 해결해야 합니다.
- 팀은 성과를 내기 위해 협력하는 사람들이기 때문에, 이슈/문제 제기가 필요한 경우, 생각나는 대안과 함께 제시하여 논의가 생산적으로 이뤄질 수 있도록 합니다. 피상적인 현상에 대해 문제를 제기하는 것은 쉬운 일이며, 이러한 문제 제기는 생산성에 도움이 되지 않습니다. 대안을 생각해보는 것은, 진짜 문제의 본질을 파악하는 데에 도움을 줄 뿐만 아니라, 상대가 방어적으로 돌변하지 않도록 이끄는 데에도 큰 역할을 합니다.
✅ DO
- 작업을 착수하기 위해서 필요한 내용과 상대가 작업을 할 때 반복적으로 볼 수밖에 없는 부분들을 문서화하여 전달합니다.
- 표, 그래프, 다이어그램 등으로 시각화하여 가독성이 좋고 이해하기 편하게 문서를 작성합니다.
- 논의가 필요하거나 궁금증이 생기면 적극적으로 묻고 문제를 해결합니다.
- 본인의 업무가 완결성 있게, 그리고 협업하기 좋게 구성되었는지 고민합니다.
❌DON’T
- 정리되지 않은 내용과 문서를 다음 직무자에게 넘겨 업무의 효율성을 저해하는 경우
- 실제 산출물과 직결되는 중요한 사항들을 말로만 전달하여 휘발되고, 추적을 놓치게 되어 프로젝트가 마무리될 때쯤 알아차리는 경우
- 포함되어야 할 실무자를 제외한 채 논의를 진행하고 실행하는 경우
- 논의가 필요한 사항이지만 논의를 하지 않고 업무의 범위를 임의로 줄이거나 늘리는 경우
각 상세 단계의 세부 정의
- 실무자: 산출물을 만드는 데에 깊게 관여해야 하는 사람
- 협업자: 산출물에 깊게 관여하지는 않지만, 논의에서 포함되거나 내용을 꼭 공유받아야 할 사람
- 산출물 필수 내용: 다음 단계로 진행하기 위해 반드시 필요한 내용
- 산출물 예시: 문서 예시
각 산출물들은 단순히 '만들었다'고해서 업무가 끝나는 것이 아니고, 그 산출물의 본질적인 목적을 달성해야만 업무가 제대로 수행될 수 있음을 인지해야 합니다. 각 산출물의 목적과 의미에 대해서는 '참고'에 포스팅을 첨부해두었습니다.
[기획 단계 - 주요 직무자: 프로덕트 매니저]
목적 및 필요성
- 기획 단계는 성공적인 제품 개발을 위한 첫걸음으로, 시장과 사용자를 깊이 있게 이해하고 프로젝트의 방향성을 설정하는 단계입니다. 이 단계에서 철저한 조사를 통해 잠재적인 리스크를 파악하고 명확한 목표를 수립함으로써 이후 과정의 효율성과 효과성을 높입니다.
1.1 사용자 / 고객 조사
당위성
- 시장의 트렌드와 고객의 니즈를 정확히 파악해야만 경쟁력 있는 제품을 개발할 수 있습니다.
실무자
- 프로덕트 매니저: 사용자 조사 총괄 및 방향성 설정
- 마케터: 시장 분석 및 고객 데이터 수집
- 디자이너: 사용자 경험 관점에서의 인사이트 제공
협업자
- 엔지니어: 기술적 가능성 검토 및 의견 제공
- 오퍼레이터: 운영 측면에서의 고객 피드백 수집
산출물 필수 내용
- 조사 배경
- 산업/시장 동향
- 타겟 고객 행동 패턴
- 고객군
- 고객의 니즈/문제/욕망
- 고객의 사용 맥락
- 고객의 만족을 위해 달성해야할 가치
산출물 예시
- 시장 트렌드
- 경쟁사 분석
- 주요 리스크 분석
- 사용자 페르소나
- 고객 여정 맵
- 사용자 조사 보고서
참고
- 밑장빼기는 통하지 않는 제품의 세계 이해하기 https://brunch.co.kr/@uxn00b/21
- 잘못된 문제 정의는 모두를 이기적이게 만든다 https://brunch.co.kr/@uxn00b/325
- 제품 발견: 구린 제품을 만들기에 우리 삶은 너무 짧다 https://brunch.co.kr/@uxn00b/34
- 만들만한 제품을 구상하는 방법 https://brunch.co.kr/@uxn00b/36
- '간편하게 만들어라'는 제품 전략이 아니다. https://brunch.co.kr/@uxn00b/42
- 사용 맥락 (Context of Use) https://brunch.co.kr/@uxn00b/32
- 우리의 뇌는 사업을 망치려고 한다 https://brunch.co.kr/@uxn00b/322
- 기회-해결책 트리 만들기 1단계: 아는 것을 시각화하기 https://brunch.co.kr/@uxn00b/109
- 기회-해결책 트리 만들기 2단계: 지속적인 인터뷰하기 https://brunch.co.kr/@uxn00b/110
1.2 제품 데이터 분석
당위성
- 기존 제품의 데이터를 분석하여 사용자 행동 패턴과 개선점을 파악함으로써 데이터 기반의 의사결정을 내릴 수 있습니다.
실무자
- 프로덕트 매니저: 데이터 분석 방향 설정 및 결과 해석
- 마케터: 사용자 행동 데이터 수집 및 분석
협업자
- 엔지니어: 데이터 인프라 제공 및 기술 지원
- 디자이너: 사용자 인터페이스 관련 데이터 해석
- 오퍼레이터: 운영 데이터 제공 및 인사이트 도출
산출물 필수 내용
- 주요 지표 정의
- 사용자 행동 데이터
- 인사이트 및 개선 사항
산출물 예시
- 데이터 분석 보고서
참고
- 지표 설정을 위한 프레임워크 https://brunch.co.kr/@uxn00b/267
- 데이터 중심적 사고와 데이터 기반 사고 https://brunch.co.kr/@uxn00b/265
- 린 애널리틱스: 코호트 분석과 A/B 테스트 https://brunch.co.kr/@uxn00b/264
- 그로스 해킹은 바이럴 마케팅이 아니다: 정의, 필요조건 https://brunch.co.kr/@uxn00b/350
- 그로스 해킹 방법: 핵심 지표 이해와 빠른 실험 https://brunch.co.kr/@uxn00b/355
- 기업의 성장 정체를 막기 위한 자세 https://brunch.co.kr/@uxn00b/370
1.3 프로젝트 일정 계획
당위성
- 명확한 일정 계획은 프로젝트의 원활한 진행과 목표 달성을 위해 필수적입니다.
실무자
- 프로덕트 매니저: 프로젝트 목표 설정 및 일정 수립
협업자
- 엔지니어: 기술적 일정 검토 및 리스크 평가
- 디자이너: 디자인 작업 일정 제공
- 마케터: 마케팅 일정 조율
- 오퍼레이터: 운영 일정 및 리스크 공유
산출물 필수 내용
- 프로젝트 목표
- 프로젝트 원칙
- 프로젝트 이해관계자
- 프로젝트 주요 일정 (시작일, 마감일)
- 프로젝트 주요 리스크
산출물 예시
- 프로젝트 요구사항 분석
- 프로젝트 차터
참고
- [PM 101] 프로젝트 생명 주기와 PM의 역할 https://brunch.co.kr/@uxn00b/12
- 성공적인 프로젝트 관리를 위한 PM의 원칙 https://brunch.co.kr/@uxn00b/7
- [PM 101] 워터폴, 애자일, 린, 식스시그마 https://brunch.co.kr/@uxn00b/8
1.4 제품/사업 기획
당위성
- 제품의 비전과 전략을 명확히 하여 팀 전체가 동일한 목표를 향해 나아갈 수 있도록 합니다.
실무자
- 프로덕트 매니저: 제품 비전 수립 및 전략 기획
협업자
- 엔지니어: 기술 전략 및 구현 가능성 검토
- 디자이너: UX/UI 전략 기획 및 제안
- 마케터: 시장 진입 전략 및 포지셔닝 제안
- 오퍼레이터: 운영 전략 및 고객 지원 방안 제시
산출물 필수 내용
- 주요 기능 및 목표 지표
- 기능 목적, 배경, 가설, 근거
- 각 문서 내 내용 정의
- 대략적인 인터페이스 시각화 (Low-fi 와이어프레임)
- 상세 기능 명세 (작동 방식, 상호작용 결과)
- 사용자 시나리오 및 플로우 차트 (기능별, 화면별)
- 리스크 및 관계 법령
산출물 예시
- 제품 비전 및 전략 문서
- 수익 모델 분석
- 기능 요구사항 정의서 및 기능 명세서
참고
- 기획자와 개발자의 고질적인 싸움의 원인: 문서 https://brunch.co.kr/@uxn00b/123
- 프로덕트 매니저와 아이디어 https://brunch.co.kr/@uxn00b/13
- 제품 문서 (The Written Narrative) https://brunch.co.kr/@uxn00b/85
- 잘못된 유저 스토리 사용의 역습: ‘기능’은 비용이다. https://brunch.co.kr/@uxn00b/348
- 제품을 죽이는 방법: 고객 말대로 기능 만들기 https://brunch.co.kr/@uxn00b/72
- 스토리 매핑의 원칙과 절차 https://brunch.co.kr/@uxn00b/119
- 스토리 매핑: 빠르게 배우기 위해 계획하라 https://brunch.co.kr/@uxn00b/121
- 스토리 매핑: 덜 만들기위해 계획하라 https://brunch.co.kr/@uxn00b/120
- 기회-해결책 트리 만들기 3단계: 기회 만들기 https://brunch.co.kr/@uxn00b/112
- 기회-해결책 트리 만들기 4단계: 기회의 우선순위 결정 https://brunch.co.kr/@uxn00b/113
- 기회-해결책 트리 만들기 5단계: 해결책 만들기 https://brunch.co.kr/@uxn00b/114
- 기회-해결책 트리 만들기 6단계: 가설 캐내기 https://brunch.co.kr/@uxn00b/115
- 기회-해결책 트리 만들기 7단계: 가설 실험하기 https://brunch.co.kr/@uxn00b/116
- UX 라이팅: 쓸데없고 모호한 말은 과감하게 버릴 것 https://brunch.co.kr/@uxn00b/341
1.5 마케팅 기획
당위성
- 마케팅 기획은 제품을 시장에 효과적으로 출시하고 목표 고객에게 도달하기 위한 전략을 수립하는 단계입니다. 이 단계에서는 제품의 포지셔닝을 명확히 하고, 주요 메시지와 USP(Unique Selling Proposition)를 개발하여 시장에서의 경쟁력을 확보합니다.
실무자
- 마케터: 마케팅 전략 수립 및 캠페인 기획
- 프로덕트 매니저: 제품 특성 파악 및 마케팅 방향성 제공
협업자
- 디자이너: 마케팅 소재 디자인 및 시각적 요소 개발
- 오퍼레이터: 고객 지원 전략 및 운영 측면에서의 피드백 제공
산출물 필수 내용
- 마케팅 전략 목적
- 목표 시장 및 위치
- 타겟 오디언스
- USP, 핵심 메시지
- 마케팅 캠페인 일정
산출물 예시
- 포지셔닝 목표 및 주요 메시징 전략 문서
- 마케팅 캠페인 전략 및 캠페인 운영 계획 문서
- 대외 공개용 문서
- 프라이싱/패키징 계획 문서
참고
- 프로덕트 마케팅은 왜 중요한가? https://brunch.co.kr/@uxn00b/93
- 시장의 대사, 전략가로서 프로덕트 마케팅 https://brunch.co.kr/@uxn00b/96
- 스토리텔러, 전도사로서 프로덕트 마케팅 https://brunch.co.kr/@uxn00b/97
- 메시징 캔버스: 제품 포지셔닝을 위한 가이드 https://brunch.co.kr/@uxn00b/106
- 프로덕트 마케팅: 캐즘은 전략으로 인해 발생한다. https://brunch.co.kr/@uxn00b/102
- 가격 책정: 구매가 발생하지 않으면 가격도 없다. https://brunch.co.kr/@uxn00b/103
- 애자일 시대의 프로덕트 마케팅: 배포 등급 문서 https://brunch.co.kr/@uxn00b/100
- 제품 출시 전략 캔버스 https://brunch.co.kr/@uxn00b/104
- 거부할 수 없는 CTA 작성을 위한 프레임워크 https://brunch.co.kr/@uxn00b/69
[디자인 단계 - 주요 직무자: 디자이너]
목적 및 필요성
- 디자인 단계에서는 기획된 내용을 시각적으로 구현하여 사용자 경험을 최적화합니다. 이는 제품의 첫인상을 결정하고 사용자의 만족도를 높이는 데 핵심적인 역할을 합니다.
2.1 디자인 일정 계획
당위성
- 효율적인 디자인 진행을 위해서는 명확한 일정 계획이 필요합니다.
실무자
- 디자이너: 디자인 일정 수립 및 관리
- 프로덕트 매니저: 디자인 방향성 확인 및 일정 조율
협업자
- 엔지니어: 기술 구현 가능성 검토 및 일정 공유
산출물 필수 내용
- 각 기능 / 화면별 작업 예상 시작일 및 완료일
- 각 기능 / 화면별 작업에 필요한 요소
산출물 예시
- 디자인 완료 추정 일정
2.2 디자인
당위성
- 사용자 친화적이고 일관성 있는 디자인은 제품의 경쟁력을 높입니다.
실무자
- 디자이너: 화면 디자인 및 인터랙션 설계
협업자
- 프로덕트 매니저: 요구사항 전달 및 피드백 제공
- 마케터: 브랜드 일관성 및 마케팅 요소 반영
- 엔지니어: 기술적 구현 가능성 및 제약 사항 공유
산출물 필수 내용
- 요구사항에 따른 상세 화면 디자인 산출물
- (필요한 경우) 사용자 인터랙션 방식 정의
산출물 예시
- Hi-fi 디자인 와이어프레임
참고
- 맥락 조사(Contextual Inquiry) https://brunch.co.kr/@uxn00b/163
- AEIOU - 활동, 환경, 상호작용, 객체, 사용자 https://brunch.co.kr/@uxn00b/159
- KJ 기법 (KJ Technique) https://brunch.co.kr/@uxn00b/178
- UX 관련 법칙 및 효과 10가지 https://brunch.co.kr/@uxn00b/66
- 디자인의 최종 목적은 즐거움이 되어선 안 된다. https://brunch.co.kr/@uxn00b/339
- 카노 모델, 카노 분석법 (Kano Analysis) https://brunch.co.kr/@uxn00b/175
- 효과적인 UI 디자인을 위한 58가지 규칙 https://brunch.co.kr/@uxn00b/187
- 디자인 에스노그라피(Design Ethnography) https://brunch.co.kr/@uxn00b/167
- 비슷한 디자인을 선호하는 이유: 생존을 위한 본능 https://brunch.co.kr/@uxn00b/345
- 디자인 시스템 명명 규칙 https://brunch.co.kr/@uxn00b/68
- 모달의 굴레에서 벗어나는 법 https://brunch.co.kr/@uxn00b/65
2.3 사용성 조사
당위성
- 최종 디자인 전/후 시기에 사용성 검증을 통해 사용자 경험을 개선합니다.
실무자
- 디자이너: 사용성 테스트 계획 및 수행
- 프로덕트 매니저: 사용성 이슈 식별 및 개선 방안 도출
협업자
- 엔지니어: 기술적 개선 가능성 검토
산출물 필수 내용
- 최종 디자인 결과물에 대한 사용성 관련 리스크, 개선 필요사항 파악
산출물 예시
- 사용성 조사 보고서
참고
- 프로토타입: 값싸지만 귀중한 학습법 https://brunch.co.kr/@uxn00b/98
- A/B 테스트 101 https://brunch.co.kr/@uxn00b/73
2.4 디자인 일정 관리
당위성
- 일정 변경 사항을 관리하여 프로젝트 전체 일정에 영향을 최소화합니다.
실무자
- 디자이너: 일정 변경 사항 관리 및 공유
- 프로덕트 매니저: 일정 조율 및 영향 분석
협업자
- 엔지니어: 개발 일정과의 연계성 검토
산출물 필수 내용
- 일정 변경 사유 (기획 범위 추가/변경, 일정 산출에서 놓친 부분, 사용성으로 인한 개선 필요 등)
산출물 예시
- 디자인 일정 계획에서 나온 산출물 업데이트
[개발 단계 - 주요 직무자: 엔지니어]
목적 및 필요성
개발 단계에서는 디자인된 내용을 실제 제품으로 구현하여 사용자에게 제공할 수 있는 상태로 만듭니다.
3.1 개발 일정 계획
당위성
- 효율적인 개발 진행과 일정 준수를 위해 명확한 계획이 필요합니다.
실무자
- 엔지니어: 개발 일정 수립 및 관리
- 프로덕트 매니저: 개발 우선순위 설정 및 일정 조율
협업자
- 디자이너: 디자인 전달 및 개발 지원
- 마케터: 출시 일정에 따른 마케팅 계획 조율
산출물 필수 내용
- 각 기능/화면별 작업 예상 시작일 및 완료일
- 각 기능/화면별 작업에 필요한 요소
산출물 예시
- 개발 완료 추정 일정
3.2 프론트 개발
당위성
- 사용자와 직접 상호작용하는 부분을 구현하여 제품의 완성도를 높입니다.
실무자
- 엔지니어: 프론트엔드 개발 및 UI 구현
협업자
- 프로덕트 매니저: 기능 요구사항 전달 및 피드백 제공
- 디자이너: 디자인 요소 전달 및 개발 지원
산출물 필수 내용
- 프로덕트 관련자의 원활한 커뮤니케이션과 추후 작업을 위한 집중적 관리
산출물 예시
- 각 화면/기능 프론트단 개발물
참고
- HTML: 기본, 요소, 경로지정 https://brunch.co.kr/@uxn00b/231
- CSS: 정의, 적용, 박스모델 https://brunch.co.kr/@uxn00b/232
- CSS: 선택자, 위치, 디스플레이, 플롯 https://brunch.co.kr/@uxn00b/233
- 반응형 웹 - 플렉스박스, 그리드, 부트스트랩 https://brunch.co.kr/@uxn00b/235
- 자바스크립트(Javascript) https://brunch.co.kr/@uxn00b/237
- 자바스크립트 문서 객체 모델 (DOM) https://brunch.co.kr/@uxn00b/238
- React.js https://brunch.co.kr/@uxn00b/249
3.3 백엔드 개발
당위성
- 데이터 처리와 비즈니스 로직을 구현하여 제품의 핵심 기능을 완성합니다.
실무자
- 엔지니어: 백엔드 개발 및 데이터베이스 설계
협업자
- 프로덕트 매니저: 기능 요구사항 전달 및 피드백 제공
산출물 필수 내용
- 프로덕트 관련자의 원활한 커뮤니케이션과 추후 작업을 위한 집중적 관리
산출물 예시
- ERD (데이터베이스 구조 시각화)
- API 명세서(Request, Response, Parameter, Naming Rule 등)
- 시스템 구조도
참고
- 백엔드(Backend)와 Node.js https://brunch.co.kr/@uxn00b/242
- 데이터베이스, SQL, PostgreSQL https://brunch.co.kr/@uxn00b/247
- API https://brunch.co.kr/@uxn00b/250
3.4 QC/QA
당위성
- 제품의 품질을 보장하고 사용자에게 최상의 경험을 제공합니다.
실무자
- 엔지니어: 테스트 계획 수립 및 수행, QA 사항 개발물 반영
- 프로덕트 매니저: 테스트 계획 수립 및 수행, 테스트 결과 검토 및 개선 사항 도출
- 디자이너: 테스트 계획 수립 및 수행, UI/UX 관점의 테스트 및 피드백 제공
산출물 필수 내용
- QC/QA 이상 사항(보고자, 작업환경, 시도 방식, 작동 실패 사유, 개선 필요 사항 등)
산출물 예시
- QC/QA 시트
3.5 개발 일정 관리
당위성
- 일정 변경 사항을 관리하여 출시 일정에 차질이 없도록 합니다.
실무자
- 엔지니어: 일정 변경 사항 관리 및 공유
- 프로덕트 매니저: 일정 조율 및 영향 분석
협업자
- 디자이너: 디자인 변경 사항과의 연계성 검토
산출물 필수 내용
일정 변경 사유 (기획 범위 추가/변경, 일정 산출에서 놓친 부분, 예상치 못한 버그 등)
산출물 예시
- 개발 완료 추정 일정
[배포 및 마케팅 단계 - 주요 직무자: 마케터 및 오퍼레이터]
목적 및 필요성
- 개발된 제품을 성공적으로 시장에 출시하고, 마케팅 활동을 통해 고객에게 알리는 단계입니다. 이 단계에서는 제품의 안정적인 배포와 효과적인 마케팅 전략 실행을 통해 제품의 가치를 극대화합니다.
4.1 배포 사전 작업
당위성
- 배포 전에 모든 문서를 최신화하고, 제품 사용법을 고객 관점에서 검토하여 출시 후 발생할 수 있는 문제를 최소화합니다.
실무자
- 프로덕트 매니저: 배포 계획 수립 및 문서 최신화 관리
- 마케터: 고객 관점 사용법 검토 및 피드백 제공
- 오퍼레이터: 운영 측면에서의 준비 사항 확인, 사용자 매뉴얼 및 가이드 업데이트
협업자
- 디자이너: 배포시 필요한 디자인 작업 진행
- 엔지니어: 기술 문서 최신화 및 배포 준비
산출물 필수 내용
- 고객 중심 관점 사용법
- 이전 단계에서 작성된 문서 중 변경사항이 발생된 부분 최신화
산출물 예시
- 패치노트
- 모든 문서 최신화
4.2 마케팅 운영
당위성
- 실제 마케팅 캠페인을 실행하여 제품의 인지도를 높이고 목표한 성과를 달성합니다.
실무자
- 마케터: 마케팅 캠페인 실행 및 관리
- 디자이너: 마케팅 소재 디자인 및 제작
협업자
- 프로덕트 매니저: 캠페인 내용 검토 및 제품 정보 제공
산출물 필수 내용
- 마케팅 전략 단계에서 작성한 기획서 기반 실제 수행 항목 업데이트 (실제 수행 기간, 수행 전술, 결과 지표)
산출물 예시
- 마케팅 캠페인 리포트
4.3 마케팅 데이터 분석
당위성
- 마케팅 활동의 성과를 분석하여 인사이트를 도출하고 향후 전략에 반영합니다.
실무자
- 마케터: 데이터 수집 및 분석
협업자
- 프로덕트 매니저: 분석 결과 검토 및 제품 개선 방향 논의
산출물 필수 내용:
- 주요 지표 정의
- 관련 사용자 행동 데이터
- 인사이트 및 개선 사항
산출물 예시
- 데이터 분석 보고서
