반응형
사례 연구 - 현업에서 마주하는 실제 요청은?
회사 구성팀들
- 사업 (전략, 기획, 제휴, 마케팅)
- 경영 기획 (재무, 회계)
- 인사
- 컴플라이언스
- 기획
- 디자인 (브랜드, 프로덕트, 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가 기다림
- 위의 모든 과정이 동시에 일어날 수 있다.
반응형
'cs > java-spring-boot' 카테고리의 다른 글
[Zero-base] 12-3. 운영성 업무들 (0) | 2022.03.22 |
---|---|
[Zero-base] 12-2. 서비스 중 기능 추가, 변경 시 고려해야 할 것들 (0) | 2022.03.22 |
[Zero-base] 10-5. 테스트 코드 (3) - 실습 (0) | 2022.03.19 |
[Zero-base] 10-4. 테스트 코드 (2) (0) | 2022.03.18 |
[Zero-base] 10-3. 테스트 코드 (1) (0) | 2022.03.18 |