[제로베이스 PM스쿨 18기 학습일지 #14] 프로젝트 이해하기

 

프로젝트란

일정한 기간 안에 일정한 목적을 달성하기 위해 수행하는 업무

 

 

프로젝트 추진 배경

-비즈니스 전략의 변경이 일어날 시 

-새로운 서비스 또는 신상품 런칭에 웹앱이 필요한 경우

-기업, 조직의 변화가 있어 공표해야할 경우

-사용자 환경의 변화, 사용자와의 관계 변화에 대응해야 할 경우

 

 

프로젝트 특징

✅일시성/한시적 - 시작과 종료가 존재

✅고유성 - 모든 상황이 고유성을 띈다 (인력, 컨셉, 일정 비용 등)

✅불확실성 - 불확실한 것을 구체화해 나간다 

✅산출물 - 산출물, 상품 등의 결과물이 존재 

 

---

프로젝트 구조 

발주사(클라이언트)

✅사업계획

✅예산확정

✅RFP 작성

✅제안평가

✅우선협상대상업체 선정

✅구축사 확정

 

🙋‍♀️RFP(Request For Proposal) : 회사에서 프로젝트를 담당할 업체에게 요구 사항을 정리하여 전달하는 문서

 

구축사(수행사 - SI, 웹에이전시)

✅RFP 분석

✅RFA작성 및 사전 인터뷰

✅TFT 수립

✅제안서 제출

✅경쟁 PT

 

 

---

프로젝트 시작하기

📌프로젝트 컨셉 정의

목표 정의 - 기능과 역할 - 수익 모델 - 경쟁력/차별화

 

프로젝트 준비하기 

발주사

✅사전정보 요청서(RFI, Request for information)

추진하고자 하는 프로젝트에 대한 간단한 개요, 목적, 기간 정도를 표시하고,

필요로 하는 정보에 대해 리스트업 후 외주업체에게 제출

 

✅제안 요청서(RFP, Request for proposal)

RFI를 통해 1차로 업체를 선정하고 제안요청서를 보낸다 

프로젝트에 대한 자세한 정보, 추진 일정, 예산 등 구체적으로 명시한다

 

✅제안견적 요청서(RFQ, Request for quotation)

제안사가 발주처에 공급가능한 물품 및 내용을 미리 알려주기 위함의 목적을 가진다

발주처는 전반적인 제반 비용을 확인할 수 있다

제안사항을 실행하는데 필요한 대략적인 견적 가격을 미리 받고 최종 업체를 선정한다

 

 

수행사

✅제안서(proposal)

✅제안 견적서(기간 및 단가)

✅투입인력 계획서 (일정 및 투입 인력 프로필)

 

 

참고

https://medium.com/@js230023/rfi-rfp-rfq-%EC%9A%A9%EC%96%B4-%EC%84%A4%EB%AA%85-42e3cf872c62

RFI, RFP, RFQ 용어 설명

 

 

 

---

 

프로젝트의 프로세스

 

계획 - 분석 - 설계 - 구현(개발) - 검수 - 종료

 

✅계획

업무 분석 / 인력 구성 / 환경 세팅 / 프로세스 정의 / 산출물 정의 / 일정 산정

 

✅분석

환경 분석 : 시장 환경 분석 / 업무 환경 분석 / 벤치마킹

요건 분석 : ASIS 분석 / 요구 사항 정의 / 개발 가능 범위 확인(개발자와 협의)

컨텐츠 분석 : ASIS 분석 / IA 방향 정의 / 개선안 도출

정책 정의 : ASIS 분석 / 전략 정의 / 서비스별 정책

가이드 정의

시스템 분석

 

✅설계

IA 설계 : IA 구조 확정 / IA 별 업무 배분 / 개발 리뷰 

기능 정의 : 각 IA별 기능 정의 / 요구사항 정의 / 개발 리뷰 

서비스 프로세스 : 각 IA별 프로세스 / 정책 확정 / 개발 리뷰 

와이어프레임 : 화면 설계(UI) /  디스크립션 정의 / 개발 리뷰 

스토리보드 완성 : 개발 리뷰 최종 / 커뮤니케이션 문서 완성 

시스템 설계 / 퍼블 가이드 및 구현 / 디자인 가이드 및 구현 / 개발 범위 검토 

 

✅구현(개발)

디자인

퍼블리싱

개발

스토리보드 리뷰 : 각 파트 리뷰

스토리보드 현행화 : 현행화 및 고도화

단위 테스트  : 실시간 단위테스트

 

✅검수

검수 및 스토리보드 고도화 : 디자인 검수 / 퍼블 검수 / 스토리보드 고도화

단위 테스트 : 단테 시나리오 / 개발 단테 / 스토리보드 고도화

통합 테스트  : 통테 시나리오 / 개발 통테 / 스토리보드 고도화

성능 테스트 / 품질 검증 / 배포 준비

 

✅종료

문서 최신화 : 정책서 / 요구사항 정의서 / IA / 스토리보드

운영 메뉴얼 : 화면 별 운영메뉴얼 / UI가이드 / 운영가이드

인수인계 준비

안정화 준비

 

✅프로젝트 안정화

시스템 오픈 후 대응 : 사용자 대응 / 시스템 모니터링 / 이슈 지원

미진한 서비스 및 개발 보완 : 오류 및 이슈 보완

최종 검수 : 최종 시스템 검수 / 검수 확인서

 

 

 

 

 

---

이번 강의를 들으면서 개발자로 일했을 때의 경험을 떠올려봤다.

증권사의 SI 개발에 투입 됐을 때 처음으로 대형 프로젝트의 규모를 체감할 수 있었다.

그 때 총괄 PL이 작성한 문서들을 하나씩 다 보면서 산출물이 어떤 게 있는지도 알게 됐고, 

개발자는 문서작성 별로 안할 줄 알았는데 통테/단테 기간에 문서작성도 많이 했다.

프로젝트 한 번 하면 나오는 산출물이 진짜 많구나...그 때 처음 알았다🐱‍💻

 

기획자-개발자-디자이너-퍼블리셔 이렇게 매일 실시간으로 같이 일 하면서 알게된 점은

개발자라고 개발만 하고 기획자라고 스토리보드만 짜는 게 아니라 서로 협의점을 찾아내면서 수정하고 또 수정한다.

개발자들끼리 얘기하는 시간보다 현업 기획자랑 얘기한 시간이 훨씬 많았다.

스토리보드 보면서 개발자가 본인화면의 로직을 짜고 이렇게 되겠구나 분석을 해놓고 기획자랑 다시 리뷰한다

이렇게 프로세스 진행되는게 맞는지 확인하면서 코딩 작업한다. 중간에 수정되는 것도 많고 다 갈아엎은적도 있고 암튼 리뷰 진짜 많이했다.

개발자 입장으로 일할 때는 부실한 스토리보드 진짜 싫어했는데 지금 기획자 업무를 배우고 있는 입장에서 다시 생각해보니까

그 땐 담당 기획자의 최선의 버전이었고 계속 버전 업데이트를 해주셨긴 하다...

기획자 by 기획자로 어떤 담당 기획자는 진짜 기획의 신처럼 일목요연하게 정리 딱딱 명쾌하게 해주시고 도메인 지식도 뛰어나셨는데

어떤 기획자는 또 그런 역량이 부족해서 그런지 커뮤니케이션 하는데 좀 답답했던 적도 있었다.

(이래서 기획자랑 개발자랑 커뮤니케이션의 중요성이 대두되는거였음)

 

거의 경험담에 가까운 이야기이지만...일할 때 가장 중요한 것은 상대를 배려하면서 말할 수 있는 소프트 스킬의 중요성과

서로 암묵적으로 '알아서 해주겠지' 하는 안일한 마음을 버려야 한다는 것이다.

끝까지 서로 확인하고 더블체크하고, 놓친 부분은 없는지, 이 부분은 왜 이렇게 하는 것인지 납득할 수 있어야 하고

그런 모든 과정을 거치면서 일을 진행 해야한다.

그렇지 않으면 어느샌가 불신이 생기고 서로에 대한 신뢰를 잃게 되기 때문에 작업 퀄리티도 굉장히 많이 떨어지게 된다.

모두에게 호감 받을 필요는 없지만, 모두에게 미움 받을 필요 또한 없다.

항상 상대방의 입장을 생각하면서 논리 정연하게 의견을 전달할 수 있는 기획자가 되고 싶다!