[Zero-base] 12-1. 현업에서 마주하는 실제 요청은?

사례 연구 - 현업에서 마주하는 실제 요청은?

 

 

회사 구성팀들

• 사업 (전략, 기획, 제휴, 마케팅)
• 경영 기획 (재무, 회계)
• 인사
• 컴플라이언스
• 기획
• 디자인 (브랜드, 프로덕트, UI/UX)
• QA
• 개발

 

 

서비스가 만들어지는 과정

• 요구사항 분석(기획) → 설계 → 구현 → 테스트 → (서비스 출시) → 유지보수

 

요구사항 분석 단계

• 기획자 : xx 기능을 추가하려고 하는데 구현 가능한가요? 얼마나 걸리나요?
• 개발자 : (아무 방해없고, 기능 추가없이) 1~2주 정도
• 기획자 :  기능 구현에 대한 기획서 작성 → 기획서<초안>

 

설계 단계

• 기획자  :  개발, 디자인, QA 일정 조율 → 1차 기획서
• 디자이너 : Flow 수정 필요, UX/UI 관점으로 기능 변경 필요 -> 2차 기획서
• 기획자 : 디자인 변경에 따른 기능 및 정책 추가 -> 3차 기획서
• 백엔드 개발자 : 디자인 및 기획 변경으로 인한 과거 정책 충돌 발견 -> 4차 기획서
• 프론트 / 앱 개발자 : 해당 화면 이후 씬이 끊김, 다음 씬으로 연결할 방법 없음 -> 5차 기획서
• 기획서 : 너무 많이 변경되어서 기획서 버전을 카운트하지 않음

 

구현단계

보안팀, 컴플라이언스팀 : 해당 피처 법무 검토가 필수, 대고객 서비스니까 보안검수 필요

QA : 개발망 QA 진행해도 될까요? 다음 QA 일정이 있어서 미룰 수 없음

 

서비스 출시

• 기획자 : 다들 고생하셨습니다. 덕분에 성공적으로 런칭했네요.
• 마케터 : 오픈했으니 이제 마케팅해야겠죠 -> 마케팅 기획서
• CS센터 : 오픈 이후에 관련 CS가 늘었어요. 확인 바랍니다.

 

유지보수

• 기능 개선
• 정책 변경
• 서비스 확장
• 프로모션

 

 

백엔드 개발자과 관련된 부분

• 1. 요구사항 분석 단계에서 구현 가능 여부
• 2. 1차 기획서 첫 리뷰
• 3. 디자인에 따라 유저씬 / 플로우가 변경될 때
• 4. 보안검수 / 컴플라이언스 검토 후 처리
• 5. QA
• 6. 런칭 전까지 변경되는 모든 스펙
• 7. 런칭 후 프로모션 (마케팅)
• 8. 런칭 후 CS

 

 

 

정리

• 기획서의 변경은 당연하다. (그런데 오픈 전까지 바뀌는 것은 함정)
• 스펙이나 기능이 변경되는 것은 수많은 이해관계가 엮여있기 때문
• 서비스를 성공적으로 런칭하면, 그 때부터가 시작
• 런칭 후에는 오픈 마케팅과 고객 CS가 기다림
• 위의 모든 과정이 동시에 일어날 수 있다.

 

 

 

---