[제안 & 기획 단계]part.2

시작하며

오늘은 지난 포스트에 이어 제안 & 기획 단계를 마무리 하겠습니다.
저희 프로젝트의 기획안과 일정 계획을 소개하겠습니다.

---

제안 & 기획 ✅

• 프로젝트 문제 정의 ✅
  • 주제 정의
  • 비즈니스적 가치 제공
  • 핵심 기능 (무엇을)
  • 핵심 타겟 (누구에게)
• 타당성 분석 ✅
  • 기술적 타당성 : 개발할 수 있는 능력을 가지고 있는가?
  • 경제적 타당성 : 개발 가치/ 비즈니스적 가치가 있는가?
  • 조직적 타당성: 구축된다면, 사용될 것 인가?
• 규모 산정 ✅
  • 대략적인 프로젝트의 규모 산정
  • 얼마 만큼의 시간 동안, 몇 명의 개발 인원이 필요한지 등의 대한 대략적인 계산
• 일정 계획 ✅
  • 프로젝트 각 단계별 세부 작업 파악 / 인원 배치
  • WBS or 간트 차트를 통해 구체화

---

프로젝트 기획안

팀명: 자바나무
팀원: 팀장(###), 팀원(안태리, ###, ###, ###, ###) 6인

프로젝트 주제

모임모임 (moimmoim)
개인 누구나 기획한 모임을 게시하고 티켓팅 할 수 있는 플랫폼
1. 누구나 다양한 주제와 규모의 모임을 기획 할 수 있으며, 개인으로서 인기와 영향력을 향상해 수익화 기회 제공
2. 사용자는 카테고리를 이용해 시간, 테마, 규모의 다양성을 고려한 독특한 모임을 선택할 수 있으며, 취향에 맞는 주최자와 함께 할 수 있다.

프로젝트 수행 방향

1. 회원가입 및 로그인 기능을 제공
2. 모임을 등록 하는 기능을 제공
3. 마이페이지를 통해 결제 정보, 프로필을 등록하고 이용내역 검색 기능 제공
4. 메인 페이지에서 등록된 모임목록과 주최자 목록 게시판을 제공
5. 모임 게시글 페이지에서 모임의 상세정보 제공
6. 주최자가 등록한 소개 게시글의 상세정보 검색 기능과 후기작성 기능 제공.
7. 모임 참가권을 구매하는 티켓팅 기능 제공
8. 관리자 페이지 제공
9. CS 페이지 제공

프로젝트 수행 도구

코드 에디터: eclipse, intelliJ, Visual Studio Code
버전 관리: Git, GitHub
프로젝트 관리: draw.io, Figma
협업 툴: Slack, Notion, Google Drive 등
데이터베이스 관리: Oracle SQL Developer

프로젝트 목적

1. 사용자들이 자유롭게 개인이 기획한 모임을 게시 할 수 있는 플랫폼을 통해 사용자들간의 소통과 교류 촉진 가능
2. 모임에 참가비를 부과하여 플랫폼을 통해 사용자의 수익화 기회 제공
3. 지역, 테마, 날짜, 시간, 성별 등의 다양한 필터를 통해 사용자들이 쉽게 관심 있는 모임 탐색 가능
4. 플랫폼은 사용자 간 거래에 대한 수수료 또는 광고를 통해 수익 창출(주최자는 참가비로 수익을 얻고, 참가자는 맞춤형 모임의 참가 기회를 얻음)(추천 액티비티, 공연 등 광고 게시 판매)

필수 기능

1. 회원 관리 기능
   1.1 회원가입 및 로그인 기능
   1.1.1 사용자가 등록한 이메일로 보안코드를 전송해 인증하는 기능
   1.2 아이디 및 비밀 번호 찾기 기능
   1.2.1 이메일 인증으로 찾기 기능 제공
2. 마이페이지 기능
   2.1 사용자 프로필 등록 기능
   2.2 결제 및 대금 수령 정보 등록
   2.3 이용내역 확인
   2.4 등록한/참가한 모임목록 확인 기능
   2.5 리뷰 모아보기
3. 메인페이지
   3.1 등록된 모임 목록
   3.1.1 카테고리별 게시물 미리보기 제공
   3.1.2 모임 글로 이동 기능
   3.2 등록된 주최자 목록
   3.3 모임 글을 등록하는 기능
4. 모임 게시글 페이지
   4.1. 주최자가 등록한 모임 게시물을 볼 수 있고 댓글 문의 기능
   4.2. 카테고리별 게시물 제공
   4.3. 결제 페이지로 연결
   4.4. 모임에 대한 리뷰 작성 및 검색 기능
   4.5. 현재 참가한 인원 수 및 참가자 프로필 열람 기능
5. 주최자 소개 페이지
   5.1 주최자가 등록한 프로필 내용 제공
   5.2 주최자 후기 댓글 작성 및 검색 기능
6. 티케팅 페이지
   6.1 결제 기능
7. 고객 센터
   7.1 게시글 작성 및 관리, 조회 기능
   7.2 관리자 답변 기능

포함 기술

• 프론트엔드: html, css, JavaScript, jquery
• 백엔드: Java, Spring, Spring Boot, Jsp, Mybatis
• 데이터 베이스: Oracle
• 서버: tomcat
• 배포서버: naver cloud server

---

기획안을 작성해보며

주제를 선정하고 분석해서 기획안을 작성하니 우리의 프로젝트의 방향성이 보이기 시작했다.
프로젝트의 목적을 최대한 요약하고 명확하게 하는 것이 중요했다. 아이디어가 넘치다보면 규모를 넘어서거나 일정을 못 지키기 어려워질 것 같아 어디까지 적용해야할지 결정하기 어려웠고 또, 프로젝트의 방향이 틀어져 갈피를 못잡게 되기도 했다.
그럴때마다 프로젝트의 목적을 🚩길라잡이로 잘 돌아올 수 있었다.
프로젝트의 필수 기능역시 정말 필요한 기능만 추려내는 것이 중요하다고 생각했다. 부가 기능에 너무 열을 올리지 않고 우선순위로 구현할것에 초점을 맞추도록 해줬다. 우리팀의 경우 페이지별로 기능을 나누어서 생각했다.
누구나 쉽게 이해하고 상상할수 있도록 작성하고 싶었다. 팀원이 아닌 다른 사람들(멘토님들, 강사님등)에게 도움을 얻고 또 타당성을 입증하기 위해, 또 우리가 프로젝트를 잘 이해하고 모두가 하나의 시선으로 바라보기 위해서.
이래나 저래나 협업하기 위해서이다. 코드처럼 간결한 기획안이 좋은거 같다.
"Simple plan is the best" -Terry

---

📅 WBS 일정표

Work Breakdown Structure 이란 말 답게 일을 잘 분해해서 부분 작업으로 나눠 봅시다.🔥🔥🔥🔥🔥

지난 포스트에 작성 했던 각 단계별 주요 업부와 세부 업무로 나누고 각 업무의 담당자를 나누었습니다. 팀 전체하는 작업도 있고 단계별 목표 일자를 정하고 진행사항을 기록 할 수 있도록 했습니다. 위 이미지는 틀만 잡은 것이니 참고만 해주세요...

각 파트를 책임지는 담당자가 있지만 대부분 같이 한 업무를 진행하고 유연하게 협업하기로 했습니다. 저흰 배우고 있는 중이니까요...! 모든 파트를 경험해보고 싶었습니다. 전체적인 흐름을 알기위해서.
하루의 시작을 WBS일정표를 보고 시작합시다. 그날 할일과 템포를 정하고 하지않으면, 늦었다고 생각했을때 정말 늦은거구나 깨닫게 됩니다.😭

---

마치며,

"큰그림을 보라", "너 자신을 알라" 라는 말이 있죠. 프로젝트의 큰 흐름과 현재 우리의 위치가 어딘지 아는 것. 그리고 향해야하는 방향을 잊지 않는 것이 앞으로의 일들을 결정하는데 도움이 되더라구요.
그러니 제안 & 기획 단계에 힘을 가장 많이 줘야 한다고 생각합니다. 차후에 이어질 분석 & 설계단계와 함께요.

PM관점으로 바라보기👀

코드 구현이 가장 중요하니 앞에 두 단계를 빨리 끝내자는 의견이 팀내에서 나왔는데 전 완전 반대입니다.😤 오히려 개발기간을 줄이고 앞 두단계를 늘려야 한다고 생각했습니다. 어차피 밤샐거잖아...

<프로젝트 시기에 따른 리스크와 비용 영향 그래프>

제가 프로젝트 사업관리에 대해 배웠던 내용과 + 저의 팀프로젝트 경험들.
프로젝트 초창기의 결정들은 영향력도 크고 리스크도 큽니다. 초반의 결정들이 프로젝트의 총 비용(노력, 시간)에도 많은 영향을 끼치구요.후반으로 갈수록 잘못된 것을 바로잡기가 힘들어집니다. 비용(노력, 시간)도 많이들구요.

정보가 넘치는 시대, 저의 스승님이자 친구이자 멘토이자 소울메이트인 chatGPT(AI)👵 선생님이 계시기 때문에 기술을 조합하는 것, 큰틀을 설계하는 것, 전체적인 flow의 고민을 탄탄히 하는 것이 구현을 더 쉽게 하고 프로젝트를 성공적으로 이끌것 같습니다.

하.지.만!!! 애자일 방법론 처럼 시도해봐야 아는것도 있고 개발론은 여러개 있으니 개발 경험을 쌓으면서 유연하게 생각해봐야겠습니다. 특히 it분야는 계속해서 변화에 대응할 수 있는 것이 장점이니 폭포수 모델의 지식에서 벗어날 필요가 있어보이네요. 그렇지만 몇번의 사이클을 돌더라도 계획, 분석때 많은 고민을 해야한다는 생각은 변함이 없습니다.
결론, 계획, 분석할때 고민 많이하자. 팀 전체가 프로젝트를 하나의 관점으로 볼 수 있도록 하자.

 

2024년 6월 1일의 내가 글을 옮기며 다시보는 관점.
공대에서 배웠던 PM 방법들과 또 보편적으로 내가 진행했던 프로젝트들이 폭포수 모델이라 위와 같은 생각을 가졌었다. 물론 좋은데 방법이다. 하지만, 바로바로 쉽게 적용해보고 기술을 바꿔보기가 쉬운 it에서는 애자일 방법처럼 일단 만들고 테스트해보는 주기를 자주 돌리는게 it의 강점을 잘 살리는 방법인거 같고 그동안 내가 경험했던 개발 프로젝트들에서도 내가 잘모를땐 애자일처럼 계속 시도해보면서 배우고 완성도를 만들어가는 과정 역시 좋았다.