Project 2- 1일차(1) : 1차 Sprint Meeting, PMPO 선정

첫 주차의 1차 Sprint Meeting

[1일차 진행 방식]

분석과 기능 구현, 티켓 제작 및 분배를 위해,
프론트엔드와 백엔드가 하루종일 함께 sprint meeting과 연이어 planning meeting을 했다.

 

[그렇게 진행한 이유]

pm 으로의 역할이기도 하지만, Pm 되기 전부터 이런 방식으로 리드했다.

 

아무래도 추석 연휴가 껴있고, 막판에 데드라인 앞에서

밤새거나 연휴에 모이는 불상사가 없기 위해서

초반부터 달렸다. 

달리기만 한 게 아니라, 달리기 전에,

공통으로 해야 할 것, 

백엔드가 할 것

프론트에 해야 할 것들을 리스팅하고 구조화하고, 

추석 전에는 어디까지 해야하고,

2주차 화요일까진 어디까지 구현될 것인지 타임라인을 잡았다. 

 

일정을 맞추기 위해 전반적인 흐름을 잡고 모든 팀원들이 allign 하는 것이 중요하다고 생각했다. 

흐름을 예상하기 위해, 기술적인 리드를 하시는 pm의 도움을 받았다. 

 

초반부터 잡아야 팀원들도 자체휴강(빠지거나 휴강)을 하지 않고, 각자 맡은 업무에 책임감을 얻고 임할 수 있다고 판단했다.  

 

그리고 1차 프로젝트 때 처음부터 분업을 하지 않아서, 혼자 다 하게 되어 너무나도 힘들었는데, 

2차 프로젝트에는 어떤 일이 있어도 무조건 분업부터 해야겠다는 결심으로. 

 

 

하지만, 쉬는 시간이 적게 강행하면서도

팀원들의 컨디션을 살피고 동의를 구하고 여쭤보면서 진행했다. 

내가 주로 리드했지만, 독단적으로 진행하진 않았다. 다른 팀원들에게도 직접 의견을 말할 기회를 주었다. 

 

(여기에서 인지한 것은, 리더를 서포트하며 본인 목소리를 내고 싶은 사람도 있고, 리더에게 따르고 싶은 성향도 있다는 것.

개발에도 사람의 성향과 니즈 파악을 하면 좋겠구나 싶었다. 고객의 니즈를 파악하는 동시에, 팀원들과 함께 일하니.) 

 

연장자이신 분도 옆에서 서포트 하시고 점심 시간을 몇시에 가지고

다시 모일지를 정해주셔서 팀원들의 동의와 마음을 얻을 수 있었다. 

내가 PO로서 개인적 기록 보면서 바로 기록 못할 때 

기록해주셔서 감사했다. 

 

---

프로젝트가 단순 코드가 아니기에,
product 분석부터 하기로 했다. 

 

<우리팀의 차별력>

다른 팀은 product 선택부터 하고 하나를 분석한 것에 비해, 
우리 팀은, 이번 프로젝트에서 다른 기술 스택을 추가해서 심화하는 것보다,

이번 프로젝트의 주된 핵심인 'product분석 / user입장에서 생각하는 개발을 위한 '고객 친화적' 분석/ business modelling'에 

집중하는 것이라고 생각했다. 

 

그래서 멘토님께서 주신 11개의 기업을 모두 분석해보기로 했다. 

 

시작 전에, 우선 이번 프로젝트의 목표와 방향을 알아야한다고 생각했기에! 

 

 

<배경> 

프로젝트 시작 전, 전주 금요일에 우리는 business modelling 세션으로

product(웹페이지) 서비스와 기능을 분석해보았고

기술블로그와 회고의 중요성도 강조 받았기에, 

나의 제안에 모든 팀원들이 동의하였다. 

 

팀원들이 포트폴리오에 욕심을 내며, 부트캠프에서 아직 사용하거나 배우지 않은 

다른 기술 스택을 배우면서 프로젝트에 녹여보자는 의견이 나왔고,

그 부분에 대한 우려를 비치는 팀원들도 있었다. 

 

그에 대한 나의 제안이 여러모로 설득력이 있었다. 

 

---

<이번 프로젝트 기능> 

구현해야 할 기능이 무엇인지 파악했다. 

회원 (로그인, 회원가입) - 상품 - 주문 - 결제  
5가지 핵심 요소를 구현하기를 생각하며

11개의 기업/ Product 분석을 해보기로. 
 

<이번주에 있는 백엔드 세션>
이번주 세션이 어떤 게 있는지를 생각하며, 이것을 어떻게 우리의 프로젝트에 연관시킬 수 있을지 생각하며 

분석하기로 방향을 잡았다.

• Modeling Review
• EC2(Elastic Compute Cloud)
• RDS(Relational Database Service)
• VPC(Virtual Private Cloud)
• Restful API

 

분석을 리드하고 진행할 pm 을 선정하게 되었는데,

본래는 project manager와 product manager를 1명 씩 총 2명 선정하는 것이다. 

 

우리팀만 유일하게 다른 방식으로 자체적으로 선정했다. 

---

<선정 과정> 

일단, 백엔드 팀 중에, 백엔드 실력도 좋으시고, 현업에서 프론트엔드로 2년 경력이 있으셔서,

백엔드와 프론트엔드 모두 리드 가능한 분이 계시는데 

product에 대한 이해가 적어서, project manager를 생각하셨다. 

그리고, 내가 product에 대한 이해가 보다 깊다고 생각하셔서,

내가 product manager를 하면 좋겠다는 생각을 하셨다고. 

 

나의 경우에는, 일정 관리와 데드라인 관리, 전반적 흐름관리를 하고 싶었고, 그것은 project manager라고 생각했고

product manager는 기술적으로 잘 알아야한다고 생각했다고 전달했다. 

그래서, 우리끼리 그 정의를 어떻게 할 것인지를 결정해야겠다고 말했다.

 

팀원들은 기술을 잘 다루는 사람이자 알려줄 수 있는 사람이 pm을 해야 한다고 말하기도 하고,

일정 관리 및 진행 리드를 하는 사람이 pm을 해야 한다고 말하기도 했다.

 

아무래도 윗분과 나는, 개발자들과 일하면서 pm, po에 대한 이해가 있어서 그런듯했다.

윗분께서 보통 현업에서는 제품과 일정 관리 모든 걸 하는 걸 po라고 하는데

po를 추가하고, 내가 하면 될 거 같다고 하셨다. 

 

나도 미래에, po가 꿈이기에, 수긍했다. 

그리고 윗분은 pm을 맡으셨다. 기능 구현과, 개발에 대한 것을 맡고

나는 우리의 product이 처음 설계했던 것과 다른 방향으로 갈 때에, 

방향성을 잡아주는 역할과 

전반적 일정 관리 

 

팀원들은 Pm에 대한 이해가 없어서, 나에게 대장님이라고 해서,

나는 기업 문화이자 올바른 조직 문화를 형성해야 한다고 했다

 

(나는 역시 조직문화에 관심이 많아)

---

<인상 깊었던 선정 과정>

 선정 과정에서 

일단 본인의 의견을 표한 뒤, 상대방의 의견은 어떤지 먼저 물어보며 

존중과 배려를 바탕으로, 어른들답게

서로의 의중을 이해하고 풀어나가는 방식이 너무나도 마음에 들었다. 

 

나를 포함해 이번 팀은 

현업에서 있던 재직자였던 분들로 구성되어서 그런지,

일을 진행하는 방식이 감정적이지 않고, 

이성적이고 모두 현명하게 대처했다. 

---

<오늘의 회고>

나보다 나이가 있으신 30대 중후반?의 분들도 계시는데,

나에게 대장님이라고 하며

나의 리더십을 좋아해주셔서 감사했다. 

 

또한, 내가 기업 분석이나, 회의를 할 때에,

대화의 주제가 다른 길로 새거나

한 주제에 오래 머무를 때 다음 단계로 진행하며 

회의 내용과 시간을 조율하는 모더레이터의 역할을 했다. 

 

이 과정에서, 다른 길로 새는 이야기를 자르기도 했고, 

서기의 역할을 맡은 분이 잠시 멍을 떄리거나 쉴 때, 집중을 요구하고, 

집중과 흐름을 위해 쉬는 시간도 적게 했는데, 

 

진행하며, 기분이 좋지 않은 경우도 있을 수도 있었을텐데 

모두 팀을 위한 방향임을 이해해주시고

믿고 따라와주셔서 감사했다. 

 

---

그리고 매일 아침 회의시간은 고정하기로 하고, 

다음날 회의 있음을 안내 하고 회의를 마쳤다. 

1차 프로젝트에는 그런 기본적 업무 방식 및 매너가 안 돼서 힘들었기 때문이다. 

---

<덧붙이기>

우리가 생각하는 드라마 속의 개발자 이미지가 있다.

 

그러나,

개발자는 하루종일 방에 틀어박혀 코드를 작성하는 것이 아니라,

전체적 비전과 목표를 이해하고 ’문제를 해결하는 사람‘이다. 

 

엘리베이터의 속도가 느리다는 컴플레인을 해결하기 위해, 엘리베이터의 속도를 바꾼 것이 아니라, 거울을 배치한 것과 같이, 

우아한형제들이, 배달 속도가 느리다는 고객의 불만족을 해결하기 위해, 위치를 확인할 수 있는 시스템을 개발한 것과 같이,

문제를 해결하고자 구조화 하고 생각하는 시간이 코딩을 직접 치는 시간보다 더 적다. 

어떨 때는 코딩을 하지 않고도 문제를 해결하기도 한다. 

 

’코딩 잘하는 사람들은 자세도 바르고 말도 잘하고 연애까지 잘한다’는

개발자 베스트 플레이어들과, 150개의 해외 파트너를

own 하는 대표님, 가까운 지인의 말을 듣고,

 

임원들과 소통하며, 임원 회의를 진행할 때에 갖추었던 비즈니스 매너와 비즈니스룩을 가졌던 것처럼, 

내가 사회에서 쌓았던 이미지와 방식을 버릴 필요가 없겠단 생각이 들었다.

 

어쩌면, 내가 프로페셔널한 이미지로 첫 날 다가갔기에

팀원들이 나를 신뢰한 게 아닐까라는 생각도 든다. 

 

<pm 으로서의 하루 회고>

아무래도 pm 으로 할 일이 많았다

 

의견 종합 및 정리, 회의 진행, 

적당히 끊고 다음 스텝으로 넘어가기 (그러기 위해선 대화에 다 집중)

동시에 기록하기,

서기 정하기, 

서기를 정했지만, 혹시 모르니 역할 분담 및 내용 정리 

팀의 효율성을 위해 집중력이 떨어지는 팀원 챙기며, 메모하라고 하고,

나중에 물어보지 말고,다른 팀원들도 2번 일하면 안된다고 지금 이해하셨는지 여쭤보기 

팀원 동기부여 (스스로 이상하게 말 던지는 거 같다고 하는 분에게 경청과 존중하며 이야기 하기)

 

 

그래서 나는 1차 프로젝트 땐 없었던 서기의 역할의 중요성을 깨달았다. 

sprint meeting에 진행과 기록하기에 버거웠기에.

 

 

Project 2- 1일차 (2) : 후보 기업 분석, Business Modeling

 

pm의 의향이 조금 있었던 분께서 역할을 원하시는 거 같고, 개인적으로 기록을 하고 계셔서,

PET 분석과 planning meeting에 서기로 임명하고 동기부여를 했다.

그리고 서기를 맡으신 분이 잠시 집중력을 잃으면, 집중력을 찾도록 메모하시라고 말씀 드렸다.

그리고, 서기 분이 정리하시느라 시간이 조금 걸릴 경우, 내가 메모를 하다가 다시 토스하고,

 

요약 정리를 위해 chatgpt를 활용하고자 하는데, 한 번 이용한 뒤 그것이 더 걸리는 것을 팀원들이 인지한 후에는, 

직접 요약을 하시기를 상황정리해드렸다.

 

그 분의 성향을 파악하였는데, 살짝의 스파트라 방식이 필요하고, 그것을 좋아하는 것 같았다.

 

서기의 역할이 마음에 드셨는지,

회의가 끝난 후, 남아서 회의 요약과 회의록을 노션에 남기고 가시겠다고 하셨다. 

열정이 보기 좋았다. 

(pm 분께서도, 우리가 개발에 대해 여쭤보는걸 미안해하니, 가르쳐 드리는 건 얼마든지 할 수 있고, 의지가 있는게 좋다고 중요하다고 하셨는데 이런 의미이구나 하고 깨달았다.) 

 

그런데, 다음날 아침에 이렇게 남겨주셔서,

1일차에 했던, "대장님의 리더십에 감사드립니다."라는 게

빈말이 아니였구나 하고 힘이 났다. 

이전 직장에서도, 리더십과 팀원 동기부여에 나에게 감사해했던 팀이 생각났다.

 

팀 노션 다 있는 페이지에 이렇게 보이니, 민망하면서도 기분 좋다

<리더십>

나는 po의 역할이 많기에, 리더는 일을 팀원에게 나눠주고 분업을 해야 한다는 많이 듣던 말을 직접 깨달았다. 

 

그래서 서기 분에게 기록 및 분석 회의 진행을 맡고,

나는 회의 주제 전환 및 다음 단계로 넘어가는 보조를 하며, 

나의 개인적 기록을 할 수 있게 되었다. 

 

기록이 더디면, 내가 서포트 하기도 했다. 

내가 타이핑이 빠르고, 말하는 동시에 바로 적을 수 있기 때문이였다. 

(평소 내가 강의를 들으면서 타이핑 기록을 하는데, 멘토님도 놀라신다. 어떻게 듣는 동시에, 이해하면서, 기록을 하느냐고.

멀티에 강하다)

 

그리고 트렐로도, 티켓은 내가 빠르게 다 만들고 

나머지 각자 맡은 것은 각자 라벨을 달라고 분업을 했다. 

 

po라고 해서 모두 내가 다 할 필요 없음을,

분업, 함께하는 리더십을 배우는 중이다. 

 

Project 2- 1일차 (2) : 후보 기업 분석, Business Modeling