[회고록] 오픈소스 SW 기초 PM을 마무리하고...

들어가며

이번 블로그의 포스팅 목적은 2학기에 수강했던 오픈소스 SW 기초 과목에 관해서
프로젝트 PM으로 활동한 사항에 대해 회고 및 기록하기 위해서 블로그를 작성한다.

대학교를 들어오고 처음으로 맡는 그리고, 주도적으로 PM 자리를 하려고 마음먹고 경험한 것이기에, 내게 더 가치있다.

그래서, 이번 포스팅은 새로운 경험이자, 이전까지 경험해보지 못했던 것인 프로젝트 리더인 PM(Project Manager)로써 활동하면서 느낀점과 배운점을 기록하는 포스팅이다.

 

글을 들어가기 전 이번 포스팅을 통해 나에 대한 정체성을 더 알아낼 수 있었으면 좋겠다.

내가 블로그를 쓰는 목적이 누군가에게 보여주기식이 아닌, 나를 찾는 블로그이기에, 이번의 포스팅을 통해서 새로운 나를 발견하면 좋겠다.

사실 2학기 프로젝트 리더로써 활동을 하면서 말로 설명할 수 없을만큼 많은 것들을 배우고 경험한 건 사실이다. 하지만, 프로젝트 리더를 오픈소스 SW 기초 뿐만아니라, 프로그램 설계 방법론, 공학영어, 또래 튜터링을 포함하여 한 학기에 총 4개의 자리에서 PM을 맡았다.

그래서, 지금의 나는 매우 "지쳐있는" 상태이다. 종강하고 나서 아무생각없이 넷플릭스를 보면서 휴식을 취했지만, 그럼에도 먼가모르는? 아직까지 지쳐있는 상태이다.

계속해서 지쳐있을 수는 없기에, 블로그로 프로젝트 회고록을 쓰면서 PM 자리를 맡으며 복잡했던 생각들을 하나씩 해결해가며

얽혀있는 퍼즐들을 하나씩 풀어볼려고한다.

현재 내가 생각하기도, 프로젝트는 성공적으로 완수해냈지만, 프로젝트 리더로써 활동한 사항에 대해서 "정리"를 하지않고서 쉼을 가하니, 아무것도 얻지 못하는... 시간이 지날수록 더 지쳐지는 현재의 나의 상태이다.

 

따라서, 이번 프로젝트 리더로써 활동한 사항에 대해서 정리를 하면서 복잡했던 내 머릿속 생각을 달래볼 것이다.

그러면, 흥미진진한 세상에 유일한 새내기 소프트웨어학부의 "김동욱"의 처음맡는 프로젝트 리더로써 활동한 사항 중 하나인

오픈소스 SW 기초 PM으로 활동한 사항에 대해서 회고 블로그를 시작하도록 하겠다.

"즉흥적으로 쓰는 글이 이기에, 다소 난잡할 수 있으니 이 점 유념해서 글을 읽어주길 바란다.

그리고, 이 글은 나의 가치관에 따라서 PM으로 활동한 것들을 적어두었으니, 이것들이 완벽한 답이 아니고, 좋은 답안 중 하나라고 생각하면 서 읽어주길 바란다." - 인생은 정답이 없다.

---

프로젝트 설명 - "소프링의 게임랜드"

해당 프로젝트는 한양대학교 ERICA의 오픈소스 SW 기초 과목에서의 팀 프로젝트로 Java를 이용한 여러 종류의 게임을 즐길 수 있는 Application을 제작했다.

해당 프로젝트는 5명이서 팀을 꾸려 프로젝트를 진행했고, 여기선 내가 PM 자리를 맡아서 프로젝트를 이끌었다.

 

프로젝트 의의

우선 이번에 진행한 오픈소스 SW 기초 과목의 프로젝트 의의는 "협력"이다.
처음으로 진행하는 PM으로써의 프로젝트이기에 모든 팀원과의 협력을 수행하여 프로젝트를 완수시키기 위한 목적으로 진행했다.

정리하면, 팀의 프로젝트 방향성을 정하고, 정해진 방향성을 토대로 일관성있게 프로젝트가 진행되도록 관리하는 경험을 쌓는 것이
이번 프로젝트 의의이다. - 여름방학 때 웹 런칭 프로젝트를 하면서 배웠던 PM으로써의 행동과 프로젝트를 이끄는 방법들을 직접 사용해보고 프로젝트를 "직접"이끄는 경험을 쌓아보고 싶었기에 PM으로써 활동을 진행했다.

 

# 프로젝트 의의에 대한 세부설명 (가치관)

"프로젝트 개발 수준이 낮더라도, 모든 팀원이 일관성있게 참여하여 협업 능력을 중점적으로 사용하는 프로젝트를 진행하면

더더욱 값진 경험과 앞으로 있을 협업 프로젝트의 토대가 될 수 있다고 생각하여 이러한 프로젝트 방향성을 지니고 프로젝트를 진행했다."

- 건물을 지을 때 기초공사가 튼튼해야 높은 건물, 고층빌딩을 지을 수 있다. 우리의 인생또한 건물 공사와 같이 기초가 튼튼해야 더욱 수준높은 것들을 할 수 있다.

 

# PM 회고록을 작성하는 이유

PM을 경험하고 난 뒤의 글을 쓰는 지금 시점은 하기 전과 비교해보면, 이루말할 수 없이 엄청난 도약을 한 채로 가치관을 비롯해
마인드도 성장하였다. 하지만, 2학기에 맡았던, 과도한 도전 & 수많은 경험들에 의해서 현재는 많이 지쳐있는 상태이다.
글을 쓰는 지금 시점은 2학기 PM 활동이 끝난 뒤 아무 생각없이 휴식을 취하며 지쳐있는 상태를 푼 뒤, 다시 상태를 점검하고 PM 회고록을 작성하는 중이다.
이번 회고블로그를 작성하면서 생각없는 "쉼"이 아닌, 생각있는 "쉼"을 통해 나를 더 행복하고 값진 인생을 살아가도록 노력할 것이다. - 목표가 사라진 쉼은 "가치없는 쉼"
그리고, 이번 블로그를 통해 2학기의 나를 지치게 했었던 일들에 대해서 정리를 하면서 현재 지친 감정들을 도닥여주며,
나를 더 돌아볼 수 있는 계기로 만들 것이다.
- 책임감있는 PM으로써 최선을 다했으니, 이제 한번 내 자신을 돌아보며 성찰하고 또 성찰하자.
실천해야 비로소 내것이 된다.

 

프로젝트 기획 및 설계

프로젝트를 진행한 사항에 대한 회고록은

순서대로 프로젝트를 진행한 사항을 기록하며 회고록을 작성할 것이다.

그리고, 순서대로 글을 쓰면서 그때 느꼇던 감정들을 생각하며 새로운 경험을 기록해낼 예정이다.

 

# 프로젝트 시작

팀 프로젝트가 시작되며, 나를 포함한 소프트웨어학부 22학번 5명으로 팀을 꾸렸다.
평소에 프로젝트 리더로써 경험을 쌓고싶었기도 하고, 자신도 있었기에, 처음으로 "PM"자리를 맡게되었다.

 

우선, 프로젝트 PM으로써 첫 회의를 진행했다.

첫 회의는 구성한 모든 팀원을 비롯해 나 또한 서로 어색한 사이였기에, 분위기를 푸는 시간을 가졌다.

사실 이때 친해지려고 마음먹었지만... 생각한만큼 친해지지 못했다.
사람은 모두 다르니, 친해짐의 속도가 다름을 이때 한번더 깨달았다..ㅋㅋ

자기 소개를 하면서, 서로를 소개하는 시간을 통해 서로의 신분을 알고 난 후 본격적으로 팀 프로젝트 회의를 진행했다.

 

1 ) 첫번째 기획회의 - 프로젝트 방향성

첫 회의는 프로젝트 기획회의로 어떤 방향성으로 어떤 프로젝트를 진행할 것 인가에 대한 회의를 진행했다.

 

# 회의 전 회의록 작성

회의를 진행하기 전에 모든 팀원이 회의에 대한 공통의 방향성을 지니기위해
회의 전에 나는 Notion에 이번에 진행할 회의에 대한 안건사항을 정리한 회의록을 작성해두고,

작성해둔 사항을 회의 전에 팀원들에게 공유 후 팀원들과 시간을 맞추어 회의를 진행했다.

아래는 프로젝트 첫번째 회의인 기획회의 전에 작성한 회의록 안건사항이다.

친해지기

개발 스택 공유

개발 스택 확정

프로젝트 기획
- 프로젝트는 12/10일까지 임.

프로젝트 기획 확정 {방향성 & 구체화}

 

이처럼 회의 전에 진행될 회의에 대한 안건사항들을 PM이 정리하여 팀원들에게 공유하면, 회의 방향성을
회의하면서 정하지 않아도 되고, PM이 정한 방향성대로 프로젝트 회의를 진행할 수 있어서 방향성을 잃지 않는 회의를 할 수 있었다.

따라서, 회의를 진행하면서 회의 방향성과 다른 주제를 논의하는 것 즉, 딴 길로 논의 주제가 새는 회의를 방지할 수 있고, 그에 따라 회의내내 모든 팀원들이 몰입하여 회의를 진행할 수 있었다.

그리고, 방향성이 잡힌 회의를 진행함으로써 비교적 적은 회의시간을 들여도, 방향성에 부합하는 회의결과를 얻을 수 있었다.

이번 경험을 토대로 회의를 진행하기 전에 진행될 회의에 대한 안건사항 회의록을 작성 후 공유하는 습관은 모든 팀원들의 공통의 방향성을 유지할 수 있도록 돕는 좋은 수단임을 이번 PM으로 진행해보면서 깨달았다.

- 회의 전에 작성하는 회의 안건사항은 모든 팀원이 공통의 방향성을 유지하도록 돕는다.

 

 

 

# 회의 진행 및 회의기록

(회의 진행은 회의기록과 병행)

첫번째 기획에선 궁극적인 프로젝트에 관해서만 방향성이 정해져있기에, 팀원들의 의견 반영을 토대로 프로젝트 방향성을 정해나가야 한다.

그래서, 처음엔 모든 팀원들의 의견을 듣고 기록하며 프로젝트의 방향성을 정해나갔다.
팀원 중 한명이 제시한 방향성이 창의적이거나 혁신적이면, 그에 대한 방향성으로 회의를 진행한다. 그리고 그 이후부터는 해당 방향성에 관한 팀원의 의견 만을 수집해서 기록한다.
정리해서, 회의에 대한 방향성을 잡은 뒤 회의기록은 PM의 객관적인 프로젝트 방향성을 정할 때 도움을 준다. 그리고 회의기록하면서 찾아진 프로젝트 방향성을 토대로 부합하는 의견들만 수집해서 핵심적인 부분에 관한 프로젝트 기획을 할 수 있게 해줬다.

 

- 핵심 방향성대로 프로젝트를 기획해야 핵심 가치가 실현된다.

- 회의를 진행하면서 회의 방향성에 대해서 기록을 해두고, 이에 대한 방향성대로 회의를 진행한다.

 

 

(회의기록은 프로젝트 설계도)

회의를 준비하는 만큼 기록하는 것도 중요한 습관이라는 것을 깨달았다.

단순히 회의를 한 뒤에 의견만 일치하고 회의를 끝내는 것보다 회의에서 나눴던 의견들을 모두 정리하고, 최종적으로 수렴된 의견들을

기록해두는 것이 팀 전체 프로젝트 방향성을 잃지 않도록 도와준다.

그리고 앞서 말했듯이, 회의를 하면서 회의기록을 하게되면, PM이 회의에 대한 방향성을 객관적으로 판단할 수 있게되고, 이를 토대로
회의를 진행하면서 구체화된 "방향성"대로 PM을 비롯한 모든 팀원들이 회의를 안정적으로 진행할 수 있다.

정리해서, 회의기록은 회의하면서 PM이 방향성을 잃지않도록 도움을 주는 수단뿐만아니라, 회의 후 진행한 사항들을 일정한 방향성대로

기록한 회의기록을 토대로 모든 팀원들은 앞으로의 프로젝트 활동에 있어서 방향성을 유지할 수 있는 "버팀목"으로 작용한다는 사실을 깨달았다. (회의하면서 모든 팀원이 PM이 생각한 대로 공통의 방향성을 유지할 수 없다. 그렇기에, 회의하면서 정해진 방향성이 녹여진 회의록을 작성해서 회의 후 프로젝트의 방향성에 대해 감을 잡을 수 있도록 토대를 마련해주어야 한다.)

 

- 회의기록은 회의 후 PM을 비롯한 모든 팀원이 공통의 방향성을 유지할 수 있도록 도와주는 수단이자 방법

 

(회의기록은 회의할 때 PM의 지도)

그리고, PM이 회의를 하면서 회의록을 기록하면 팀원 각각이 나누는 의견들에 대한 방향성을 평가하고 기록된 사항들에 관해서 (기존에 논의하고 있었던 방향성과 )동등한 방향성을 지닌 의견인지, 방향성을 벗어난 의견인지를 객관적으로 평가하며 프로젝트의 방향성을 잃지 않은 채 의견을 수렴하여 프로젝트를 관리할 수 있게 도와준다.

즉, 회의기록은 단순히 회의 "기록"에만 한정되는 것이 아닌, PM이 회의를 주도하면서 자신을 비롯한 모든 팀원들이 회의를 하면서 방향성을 잃지 않도록 도와주는 수단임을 이번 PM을 맡으면서 깨달았다.

 

이번 PM자리로 첫번째 회의를 통해 깨달은 바는 회의할 때 회의기록을 해두는 것은 앞으로의 프로젝트 방향성을 유지할 수 있도록 돕고, 회의하면서 프로젝트의 방향성을 잃지않도록 돕는 수단이 된다는 것을 깨달았다.

처음으로 겪는 공식적인 "PM"자리 그리고, 주도적으로 PM 자리를 맡을려고 한 자리이기에, 책임감있게 최선을 다해 노력했다.
그래서 여름방학 웹 런칭 프로젝트 때 배웠던 PM으로써의 가치 & 행동들과 프로젝트를 안정적으로 이끌어나가는 방법에 대해 배운 것들은 총동원해서 나는 이번 PM 자리에 올라서 마음껏 직접 사용해보고, 적용해보았다 ㅋㅋ..
처음에는 많이 어설픈 점이 많아서 흔들거리는 점이 있었지만, 그래도, 포기하지 않고 책임감있게 PM으로써 필요한 바를 수행하려고 노력했다.
그러면서, PM을 하면서 실제로 적용했던 것들이 회의 전 안건사항을 회의록에 기록해두고 회의 진행 그리고, 회의를 진행하면서
회의기록하기를 해보았다. 처음에는 어렵고, 감이 안잡히고 힘들었지만, 여러번 회의를 진행해보면서 회의에 대한 방향성을 잘 잡고 진행하는 회의를 수행할 수 있었다. 이에 대한 토대는 "또래 튜터링, 공학영어" 라는 PM 활동을 통해 다져졌다.

정리하면, 이번 경험을 토대로 회의를 진행할 때 팀원 모두가 공통의 방향성을 지니는 방법에 관해서 터득하게 되었고, 그에 따라
안정적으로 회의를 준비하고, 회의를 진행하는 역량을 지니게 되었다 ㅎㅎ
아직 많이 부족하지만, "초심"의 상태를 유지하면서 최고의 PM이 되는 그날까지 끊임없이 노력할 것이다.

 

 

 

# 첫번째 기획회의 완료

• • 게임 코인
    • 초기 코인 : 10개
    • 게임을 진행하면, 코인 하나 소모
    • 게임을 이기거나, 성공적으로 완수하면 코인을 (임의로 정해둠)5개 제공
    • 코인이 0개가 되었을 때 알림창 띄우고 게임런처 종료
      • “코인을 다 사용하셨네요… 충전하고 이용해주세요.” 출력
      • 확장 가능성 {결제 서비스 도입}
  • 게임 점수기록
    • 최고점수, 현재점수
    • 최소 걸린시간, 현재 걸린시간
  • 게임 종류 {프설방}
    • 블랙잭 (점수 & 점수가 음수이면, 코인획득 없이 메인화면 & 점수가 양수이면, 수 만큼 코인 추가)
    • 슬라이드 퍼즐게임 (시간 & 중간 종료 시 코인획득 없이 메인화면 & 게임 클리어 시 코인 5개 추가)
    • 스도쿠 (시간 & 중간 종료 시 코인획득 없이 메인화면 & 게임 클리어 시 코인 5개 추가)
    • 짝 맞추기 게임 (시간 & 중간 종료 시 코인획득 없이 메인화면 & 게임 클리어 시 코인 5개 추가)게임 런처 {GameLand}
      
      

앞으로의 일정논의

• 프로젝트 설계회의 - 11/24 ~ 11/25
  • GUI 디자인 설계
  • MVC 아키텍처 설계
  • 개발 템플릿 구성
    • MVC 아키텍처 설계토대로 구성
  • 역할 분배 (역할 분배에 초점을 두지말고, GUI & MVC 디자인 설게에 초점을 맞춤)
• 개발 시작 - 11/27 ~ 12/10

# 사담
팀을 꾸리고, 공식적으로 PM자리를 처음 맡아서 첫번째 기획회의를 완료했다.
프로젝트 기획회의를 마치고 정리된 프로젝트 기획란은 다음과 같다.
처음으로 진행했던 PM자리로 기획회의를 마쳤는데, 생각한만큼 보다 훨씬 수월하게 회의를 마칠 수 있었다 ㅎㅎ
나름 첫번째 회의로 프로젝트 구체화 및 방향성이 존재한 기획란을 완성했다.

# 첫번째 기획회의 사항 정리
첫번째 기획회의는 PM인 (내가) 회의 전에 Notion에 기록해둔 안건사항을 토대로 회의를 진행했고,
안건사항에 적힌 순서대로 하나씩 회의를 진행하여 약 3주라는 길다면 길고, 짧다면 짧은 기간동안 진행할 개발 프로젝트에 대한 기획을 진행했다.
이처럼 기획회의를 마치고 1차로 기획을 완료한 사항은 다양한 분류의 게임을 하나의 App에서 이용할 수 있는 게임런처 App 제작 개발 프로젝트이다.
프로젝트의 핵심 방향성은 퍼져있는 게임을 하나의 App에서 즐길 수 있는 App 개발이다.
타겟 사용자는 즐겨하는 게임을 한 곳에 모여두고 플레이하기를 원하는 사용자이다.
이러한 방향성을 확정하고 개발 프로젝트 기획을 완료했다.

 

# 첫번째 기획회의 완료 후 (PM이 대표로) 기획 구체화 - 기획회의에서 정한 방향성을 토대로 기획 구체화를 진행함

• 게임 런처 {GameLand}
  • 게임 코인
    • 초기 코인 : 10개 {Java Application 게임 첫 실행}
    • 게임을 진행하면, 코인 하나 소모
    • 게임을 이기거나, 성공적으로 완수하면 코인을 (임의로 정해둠)5개 제공
    • 코인이 0개가 되었을 때 알림창 띄우고 게임런처 종료
      • “코인을 다 사용하셨네요… 충전하고 이용해주세요.” 출력 & 종료 { 추가 GUI를 띄움 }
  • 게임 정보출력
    • 게임런처 메인화면에서 게임하나 클릭 시 게임에 대한 정보를 알려주는 추가 GUI로 띄워짐.
  • 게임 점수기록
    • 최고점수, 현재점수 {블랙잭}
    • 최소 걸린시간, 현재 걸린시간 {슬라이드 퍼즐게임, 스도쿠, 짝 맞추기 게임}
  • 게임 종류 {프설방}
    • 블랙잭 (점수 & 점수가 음수이면, 코인감소 하여 메인화면 & 점수가 양수이면, 수 만큼 코인 추가)
    • 슬라이드 퍼즐게임 (시간 & 중간 종료 시 코인획득 없이 메인화면 & 게임 클리어 시 코인 5개 추가)
    • 스도쿠 (시간 & 중간 종료 시 코인획득 없이 메인화면 & 게임 클리어 시 코인 5개 추가)
    • 짝 맞추기 게임 (시간 & 중간 종료 시 코인획득 없이 메인화면 & 게임 클리어 시 코인 5개 추가)

기획 구체화는 팀원들과 함께 기획한 기획한 사항을 토대로 공유한 방향성을 토대로 기획 구체화를 진행했다.
해당 구체화과정은 프로젝트 기획에 대해서 구체화를 진행하여 프로젝트 기획에 대해서 확정짓는 과정을 거쳤다.

이번 과정은 명확하게 확정짓지 않은 기능들에 대해서 구체화하여 확정하는 작업이다.
기획은 뚜렷하게 확정짓는 작업이 필요하고, 모든 팀원들의 의견을 반영해서 기획을 애매모호하게 정해두는 것은
"하울의 움직이는 성"과 같은 기획이 완성된다.
그래서 공동의 프로젝트 방향성을 회의를 통해 정한 후 팀 중 대표로 PM인 내가 1차 기획회의를 통해 정해진 방향성을 토대로 기획을 뚜렷하게 구체화하는 작업을 거쳤다.
( 해당 기획에 대한 지혜는.. 여름방학 UMC 웹 런칭 프로젝트, CMC 해커톤을 참여하면서 PM분들의 기획하는 방법과 질문을 통해 깨달았다. )
- 프로젝트 기획은 되도록이면, 혼자 혹은 소수로 진행한다.

 

2) Flow 차트 구성 (기획 확정) - 앞서 구체화한 사항을 공유 & 피드백을 토대로 기획확정

• 게임런처 App 실행
  • 게임런처 실행 GUI
  • 유저 정보 입력
• 마이페이지
  • 유저의 게임 진행사항
    • 블랙잭
    • 슬라이드 퍼즐게임
    • 스도쿠
    • 짝 맞추기 게임
• 게임 런처 메인 페이지
  • 게임 정보
    • 블랙잭
    • 슬라이드 퍼즐게임
    • 스도쿠
    • 짝 맞추기 게임
  • 게임시작
    • 블랙잭
      • 코인 하나 소모
      • Chip 갯수 0개로 시작
      • 블랙잭 게임 진행
      • 블랙잭 한턴 종료
        • 유저 게임 진행 의사묻기
          • 추가 게임 진행
            • 블랙잭 게임 진행으로
          • 추가 게임 진행 X
            • Chip 갯수를 코인 갯수에 더함.
            • 유저의 게임진행 정보에 Chip 갯수 저장
            • 게임 런처 메인페이지로
    • 슬라이드 퍼즐 게임
      • 코인 하나 소모
      • 타이머 재기
      • 슬라이드 퍼즐 게임 진행
        • 퍼즐 게임 완료 && 타이머 시간 기록
          • 유저 정보와 클리어한 게임기록을 비교
            • 짧은 시간 게임기록 시 유저 정보 현재 게임정보로 업데이트
            • 긴 시간 게임기록 시 게임 GUI 종료
            • 게임 런처 메인페이지로
        • 퍼즐 게임 완료 X && 게임 종료
          • 게임 런처 메인 페이지로
    • 스도쿠
      • 코인 하나 소모
      • 타이머 재기
      • 스도쿠 난이도 통일
      • 난이도에 따른 스도쿠 게임 진행
        • 스도쿠 완료 && 타이머 시간 기록
          • 유저 정보와 클리어한 게임기록을 비교
            • 짧은 시간 게임기록 시 유저 정보 현재 게임정보로 업데이트
            • 긴 시간 게임기록 시 게임 GUI 종료
            • 게임 런처 메인페이지로
        • 스도쿠 게임 완료 X && 게임종료
          • 게임 런처 메인 페이지로
    • 짝 맞추기 게임
      • 코인 하나 소모
      • 타이머 재기
      • 짝 맞추기 게임 진행
        • 짝 맞추기 게임 완료 && 타이머 시간 기록
          • 유저 정보와 클리어한 게임기록을 비교
            • 짧은 시간 게임기록 시 유저 정보 현재 게임정보로 업데이트
            • 긴 시간 게임기록 시 게임 GUI 종료
            • 게임 런처 메인페이지로
        • 짝 맞추기 게임 완료 X && 게임종료
          • 게임 런처 메인 페이지로
• 게임 종료
  • 코인 갯수 0개
  • 게임 종료 GUI && 앱 종료

앞서 팀 전체 1차 기획회의를 토대로 기획 구체화를 진행했다. 그리고나서, 팀원들에게 해당 사항을 공유한 뒤
기획 구체화한 사항에 대해서 피드백을 받은 뒤 기획에 대한 확정을  짓고 Flow차트를 구성했다.
기획 구체화하면서 변동 및 추가된 사항은 유저 게임런처 마이페이지 추가 그리고 오락용 게임으로 게임 종료 후 코인을 얻는 것이 아닌, 코인을 소모시킴.
해당 사항으로 기획을 업데이트 한 후 기획한 기능사항들에 대한 Flow 차트를 구상을 완료했다.

# Flow 차트의 이점
Flow 차트를 구상해둠으로써 프로젝트의 기획한 사항에 대한 방향성을 한눈에 볼 수 있고, 기획한 기능들에 대해서 한 눈에 살펴볼 수 있다.
그리고, Flow 차트를 구성해서, 팀원모두가 공동의 방향성을 지닐 수 있도록 해준다.

 

 

3) 와이어프레임 구성 - Flow 차트를 토대로 GUI 디자인

프로젝트에 대한 방향성을 비롯해서 기능에 대해서 구체화한 Flow 차트를 완성한 후
GUI 디자인인 (와이어프레임)을 구성하였다.
이 부분에 대해선 PM인 내가 Flow 차트를 토대로 와이어프레임을 설계하였고, 완성된 와이어프레임을 팀원들에게 공유한 후
피드백을 받았다.

와이어프레임을 제작할 때는 앞서 기획회의 때 정한 프로젝트 방향성을 기반으로 와이어프레임을 제작했다.
팀원모두가 회의에서 공유한 공통의 방향성대로 와이어프레임을 설계를 진행했고, 이에 부합하는 와이어프레임을 완성하여
팀원들에게 공유하였다.
(한명이 대표로 공동의 방향성대로 기획 구체화를 진행하는 것이 프로젝트를 안정적으로 진행될 수 있도록 도와준다.)

 

 

4) MVC 아키텍처 설계 - 프로젝트 개발 설계

와이어프레임을 구성 후 MVC 아키텍처 설게를 진행했다.
해당 부분도 대표로 한명 or 두명이서 아키텍처 설계를 진행 후 팀원들께 해당사항을 공유를 하였다.

순수 객체 지향 프로그래밍 언어를 사용해 프로젝트에 대한 아키텍처를 설계하고 개발한 경험이 처음이기에,
MVC 아키텍처를 설계할 때 처음엔 많이 힘들었다...
순수 객체 지향 프로그래밍 언어는 모든 것들이 종속되어져 있어서, 아키텍처를 어떻게 짜야할 지 감이 안잡혔다.
즉, 팀원이 5명이기에 아키텍처를 어떻게 분담해서 구성해야되는지 감이 안잡혔다.
하지만, 이에 대해선 "프로그램 설계 방법론" 도교수님의 조언을 통해 감을 잡을 수 있었다.
객체 지향 개발 설계에 있어서는 "파트 분담"에 대해서 생각하지 않고, 우선 프로그램이 돌아갈 수 있는 MVC 설계도를 완성시킨 뒤
파트 분담에 대해서 생각해야된다는 것을 알려주셨다. 이에 대한 앎을 토대로 "파트 분담"에 대한 부담감을 없앤 뒤 MVC 설계도를 완성시켰고, 그에 따라 안정적인 MVC 아키텍처를 완성시켰다.

정리해서 처음해보는 MVC 아키텍처 설계였고, 안정적인 설계를 할 수 있었던 이유는 "파트 분담"에 대한 위압감을 없애고, 오로지 프로그램 완성을 위한 아키텍처 설계를 할 수 있었기라고 생각한다.
"프로그램의 아키텍처 설계는 소수가 진행하여 아키텍처를 구상한다. 그리고 "개발 파트 분담"에 대해선 생각하지 않고 설계를 진행한다."

# 아키텍처 설계를 하면서 PM에 대해 궁금했던 점 (PM으로 너무 많은 걸 관여하는 건 아닌가..?)
아키텍처 설계를 혼자서 완성하니, 프로젝트에 "내가" 관여한 시간들이 많다는 걸 느꼇다. 즉, 협업 프로젝트인데 혼자서 수행한 일들이 많다는 걸 깨달았다. 이 부분에 대해선 프로젝트를 진행하며 느꼈지만, PM에 대한 책임감으로 이야기할 수 있지만,
처음 해보는 PM이기도 해서 어느정도의 책임감을 지니고 활동에 임하는 지는 감을 잡지 못했다.
그래서 이번 프로젝트는 내가 어느정도 감수하면서 PM의 자리를 책임감있게 했지만, 다음에 프로젝트 PM을 이끌 기회가 생긴다면, 조금은 더 여유로운 PM 기획을 완수하는 역량을 쌓고 싶다.
그래서, 기획이나, 설계할 때의 PM이 맡아야할 부분에 대해서 좀 더 명확하게 알고 싶다.
"이번 PM은 처음 겪어보는 PM자리이기에 PM의 책임감에 대한 부분이 모호했다.
겨울방학 때 PM, 리더로써의 가치관에 대해서 알아보며 리더로써 이끌어 나갈때는 어떤 마음가짐으로 임해야되는지를 배워볼 것이다."

 

 

5) 개발 파트 분담회의 - 2차회의

개발 파트 분담은 종속성이 연결되는 부분끼리 연결해서 역할을 나누었다.

역할 분담은 GUI 개발자, 게임 개발자로 역할을 나누고 개발을 진행했다.

여기서, 역할 배분 시 앞서 구성한 MVC 아키텍처를 기반으로 개발 파트의 역할 배분점을 찾았고, 이를 토대로 개발 파트에 대한

역할 배분을 수행했다.

개발 파트 분담에는 답이 정해져 있지 않기에, 대표로 역할을 나눈 뒤 모든 팀원들에게 공유 후 개발 파트를 나누는 것이 가장 합리적이고,

효율적임을 깨달았다.

만약, 모든 팀원들의 의견을 모아서 역할 파트를 분담하면, 개발하기 어려운 통제하기 어려운 역할 분담이 될 것 같았다.

그래서, 프로젝트 개발 구조에 대해서 안정적이며, 개발하기 쉬운 형태로 파트 분담을 정해두고, 팀원들에게 공유 후 모든 팀원이 이에 관해서 이해 한 뒤 개발 파트 분담을 진행하는 것이 합리적이고 쉽고 빠르게 진행할 수 있다는 사실을 깨달았다.

 

- 다수의 의견을 모두 받을 수 없고, 대표로 한명이 합리적인 파트 분배를 진행시켜야 한다.

- 결국에는 결정되어야할 사항들, 이리저리 옮겨다니는 것보다 한번에 확정짓는 것이 시간적으로도 이득

- PM이 대표로 역할 분담 사항에 대해서 합리적으로 "확정" 짓고 개발을 진행해야한다.

- PM의 책임감..

 

 

6) 개발완료 후 병합회의

이 부분에 대해선 할 말이 많다...

Github를 토대로 PR만 날리는 자리에서

직접 PR을 받아서 merge 시키는 자리인 프로젝트 소스코드 관리를 해보니... 참 힘들고 어려웠다..

이전까지 프로젝트를 진행할 때 PR만 보낸 뒤 프로젝트 관리는 실력좋은.. 다른 분께서 직접해주셨다..ㅎㅎ (정말 감사합니다..)

하지만, 이번에는 내가 PM이 되어 프로젝트 소스코드 관리를 진행했다...ㅎㅎ

처음인지라, 어설픈 점이 참 많았다. 그래도 최대한 소스코드 관리를 책임감있게 수행했다.

1학년 협업 프로젝트이기에, 나를 비롯한 모든 팀원이 Github 소스코드 관리에 익숙치 않았고, 그에 따라 불확실하게 소스코드를 관리했다.

병합을 하면서 겪었던 시행착오를 쭉 나열해서 정리하겠다.

 

# 개발 첫 시작은 Github의 동일한 main 브랜치의 개발 템플릿 코드로 개발을 수행하자.

Github을 이용해서 소스코드를 관리할 시 "커밋 계층"이 동일해야지만, remote 브랜치에 Push를 진행할 수 있고, PR를 보낼 수 있다는 점이 이번 경험을 통해 깨달았다.

- 그래서, Github를 통한 개발 시 동일한 브랜치의 개발 템플릿을 pull 받아서 개발을 진행 후 remote에 push를 해야된다는 점..을

알게되었다.

 

Github를 사용한 소스코드 관리가 나를 비롯한 모든 팀원이 처음인지라, Git에서 제공하는 틀대로 개발을 하지 못했다 ㅎㅎ..

팀원 중 한명이 main 브랜치의 업데이트 한 사항을 한단계 이전의 커밋로그에 대한 소스코드를 pull 받아서 개발을 시작해서

merger할 때 다른 커밋로그에 대해선 PR을 하지 못하는 에러가 발생했었다.

그래서, 이번 경험을 토대로 Github를 이용한 소스코드 관리 방법은

대표로 한명이 (에러가 없는) 개발 템플릿을 확정 짓고 Github main 브랜치에 push해둔 뒤 안정적으로 구성되었을 때

팀원들에게 알리는 것이 모든 팀원이 혼란없이 개발을 시작하고 완수해낼 수 있다.

 

 

# Github 소스코드 관리 규칙을 정하자. (규칙은 Github에 대해서 많이 알고있는 사람이 정한다.)

Github 관리 규칙을 정해두고, 병합을 하면 안정적으로 소스코드를 main에 병합 후 이어서 프로젝트를 진행할 수 있다.

이번에 Github 관리규칙을 정해두지 않고, 병합을 해서 ㅎㅎ... 병합할 때 많이 애를 먹고 힘들었다.

 

병합하기 전에도 Github 소스코드 관리 규칙을 정해두는 것이 앞으로의 후속 개발에 있어서 혼란을 겪지 않고

팀원 모두가 작업한 사항을 병합하여 후속개발을 수월하게 진행할 수 있다는 점을 깨달았다..

개발하면서도, Github를 통한 관리규칙을 정해둬야 일정한 방향성대로 코드를 관리하고 후속개발을 진행할 수 있다.

 

7) 개발 완료 & 프로젝트 발표

개발이 완료되었다. 개발 이슈때문에,, 완전히 기획한 핵심사항이 완료되지 않았지만, 그 점을 제외하면, 개발 프로젝트를 안정적으로 완수해냈다.

(팀원 중.. 한명이 맡은 파트에 대해서 무책임..? 하게 완성해두고 마감 1일전에 push를 해뒀다.
물론, 1일전에 다른 프로젝트의 PM (프설방)이 남아있어서 어쩔수 없이 팀원 중 한명께 늦게 완성해준 팀원꺼를 merge해달라고 부탁했다.. 이 점에 대해선 나도 반성을 하고 있고, 그래도,,, 마감 1일전에 무책임하게 소스코드를 push해준건,,, 화가 좀 났었다. 그래도,

1일 전에 소스코드를 최종적으로 확인하지 못했던 내 책임이 있기에 난 이번 경험을 PM으로써의 값진 경험이라고 생각하고 있다.)

 

어쨋든, 이 점을 제외하곤 개발 프로젝트를 완성해냈고, 처음에 기획한 다양한 게임들을 App에서 즐길 수 있는 통합 게임런처 APP 제작을 완료했다.

 

우리가 완성한 프로젝트 진행사항에 대해서 궁금하다면, 아래의 노션 링크를 참고하자.

회의록

 

그리고, 완성한 프로젝트를 실행해보고 싶다면, 아래의 Github 주소를 남길테니 pull 받아서 Java 개발환경에서 실행해보길 바란다.

GitHub - ERICA-Open-GameLand/Game-Land: 한양대학교 ERICA 오픈소스 SW 기초

 

약 3주간 진행되었던, 개발 프로젝트를 완료하고, 발표를 진행했다.

발표는 PM인 내가 대학을 오고, 처음으로 "발표"를 진행했다.

고등학교 때 발표했던 기억들을 회상하면,,... 자신감이 많이 부족했던 터라 항상 발표하고 후회를 했었다...

하지만, 이번 발표는 발표하는 내내 재미있었고, 하고난뒤에도 후회보단 성취감 그리고 만족감이 가득했다.

이번 발표와 고등학교 때의 발표의 차이점은 단 하나 "자신감"이다. 이번 발표에선 자신감있게 나를 비롯한 모든 팀원들이 책임감있게 수행했었던 것들 토대로 그리고, 우리의 프로젝트 방향성을 인지하면서 발표를 준비했고, 그에 따라 발표에 대한 목적과 방향성이 생겼고, 그에 따라 발표를 준비하며 자신감을 얻을 수 있었다.

이번 발표에선 소프트웨어학부 22학번 새내기 개발자들 5명끼리 모여서 프로젝트를 진행하면서 다져나갔던 "협업" 절차에 대해서 나는 당당하게 발표하여 다른 동기들께 영감을 얻는 발표로 방향성을 잡고 진행했다.

그러면서 발표에 대한 자신감이 생겼고, 그에 따라 나름? 성공적인 발표를 해냈다. (솔직히 내가 발표하고도 안정적으로 발표를 해내서 뿌듯했다..ㅎㅎ)

 

정리해서 발표에 대한 목적과 방향성을 정해두니, 준비가 그렇게 많이 필요하지 않았다.

즉, 발표를 듣는 청중들인 (동기들)에게 발표를 통해 전하고자 하는 목적을 뚜렷하게 정해두니 안정적으로 발표를 수행할 수 있었다.

 

이번에 처음해본 PM으로써의 프로젝트 진행 그리고 발표까지 모든 과정들은 앞으로의 개발자 아니, 궁극적인 목표 여유있는 기획자가 되기위한 한걸음, 두걸음이 아닌 퀀텀점프와 같았던 경험이었다...
이 모든 과정들을 수행하기 전까지는 앞이 상상이 되지 않았고, 단순히 프로젝트를 완수해내는 상상만 하면서 책임감있게 노력했다.
그렇게, 끝내 PM으로써 안정적인 프로젝트를 완수해낼 수 있어서 더할나위 없이 뿌듯하고 좋았다.

 

첫 PM 프로젝트를 마무리하며..

이 부분에 대해선, 프로젝트를 전체적으로 돌아보면서 느꼇던 감정들, 새로운 경험들 그리고 배움들을 정리하도록 하겠다.

그러면서 성찰한 나의 가치관과 깨달은 새로운 가치관에 대해서 정의하며 나를 더 돌아보는 글을 작성해볼 예정이다.

(PM으로써 활동하면서, 나의 가치관을 비롯해서 나에 대해서 돌아볼 수 있었던 뜻깊은 경험들을 쌓았습니다..

진짜 PM으로 활동한 사항들을 모두 기록해보면서 제 자신을 블로그에 더 녹여낼 수 있도록 노력하겠습니다.

"김동욱"이 자기 자신 "김동욱"을 깨닫는 그날까지 열심히 그리고 열심히)

 

---

힘들었던 점 & 어려웠던 점

 

# 불필요한 팀원의 의견을 잘라내는 방법

기획회의를 하면서 팀원들의 의견들을 수렴하고 방향성에 부합하지 않는 의견들을 배제하는 방법이 어려웠다.

나는 PM으로써 활동을 하면서 팀원들의 의견을 수렴하고, 프로젝트에 있어서 불필요한 의견들을 걸러내는 행동들이 힘들었다.

평소에 나는 PM자리가 아닌, 팀원자리로써 의견을 제공하는 입장으로써 의견을 제시만 하면 되었다. 하지만, 이번엔 PM으로써 팀원들의 의견을 수집하고 수집한 의견을 토대로 프로젝트를 이끌어가야만 했다.

그래서, 프로젝트가 안정적으로 진행되기 위해선 프로젝트 방향성과 부합하지 않는 팀원의 의견을 걸러내는 행동들이 필요했고, 나는 이러한 경험들이 없었기에, 팀원에 제시한 불필요한 의견을 걸러내는 방법을 수행하는 법에 대해서 전혀 감이 잡히지 않았다.

감이 잡히지 않았던 원인은 팀원이 애써서 의견을 제시했는데, 내가 칼같이 의견을 잘라버리면, 팀원의 의지가 사그라들 것 같다는 생각이 들었고, 그렇다고, 불필요한 의견까지 수렴해가며 프로젝트를 진행시키는 건 "하울의 움직이는 성"이 되버리니 어떻게 팀원의 의견을 잘라야해내야 하는지 잘 몰랐다..ㅎ...ㅎ

정리해서, 팀원의 마음을 상하지 않은 채 불필요한 의견들을 객관적으로 잘라내는 방법을 몰라서 어려웠었던 것 같다.

이 점에 대해선 아직까지 감을 완전히 잡진 못했고, 불필요한 의견들을 잘라내는 경험을 해봤지만... 아직 팀원의 마음을 상하지 않고서 의견들에 대해서 잘라는 방법은 감을 잡지 못했다.

이 부분에 대해선, 더 많은 경험이나, 리더로써 성공한 사람들의 책에서 주는 지혜를 토대로 나만의 리더로써 "가치관"을 세워볼 생각이다.

- 나를 알아가는 기획 그리고 도약

- 새로운 경험을 통해 나를 더 알아가다...

 

 

 

# PM으로써 어떠한 역할까지 수행해야되는지
책임감있는 영역이 어떤 것인가?

 

 

 

# PM으로써 마인드 셋

 

 

 

# PM의 책임감있는 영역은 어디까지 인가?

 

 

 

# 내가 궁극적으로 원하는 건 무엇인가?

(열심히 PM으로 활동 후 무기력해진다?
행복을 위해서 사는데, 프로젝트가 끝이나고 무기력해지는 이유는 멀까?)

---

이글을 끝까지 읽어준 독자들을 위해

제 글은 PM으로써 활동하는 방법들에 관한 "완벽한 답"이라고 생각하지 말아주셨으면 좋겠습니다.

인생에는 답이 없듯이, 모든 활동에 관해서는 답이 없다라고 생각합니다. 그래서 제가 작성한 글에 대해선 참고사항으로 보는 것을 권장드립니다.

저도, 제가 쓴 글이 답이라고 생각하지 않고, 현재 느낀 바를 기록하고 정리해둔 것입니다.

제가 기록한 사항은 앞으로 더 멋지고 알찬 경험을 통해 더 발전시켜나갈 것이기에 이 글을 읽은 독자분들도 많은 경험 중 하나라고 생각하고 이 글을 읽어주시길 바랍니다!!

 

어설프지만, 최대한 노력해서 쓴 글을 끝까지 읽어주셔서 감사합니다 ㅎㅎ

당신도 "당신"을 정의하는 그날까지 열심히 화이팅입니다.