간단 총평
만족스러웠다. 왔다 갔다 하는 교통편이 좋지 않았음에도 감수할만 했었다.
밋업 정보
[지금 무료] 판교 퇴근길 밋업 with 인프런 #04 사이드 프로젝트 | 인프런 - 인프런
인프런 | , [사진] 옆자리 동료와 함께 성장하는 시간🍀 판교 퇴근길 밋업 with 인프런 🍀 판교 퇴근길 밋업 #04 사이드 프로젝트 안녕하세요, 인프런 입니다. 6월 퇴근길 밋업에서는 테오의 스
www.inflearn.com
밋업 시간표 상으로는 30분 발표에 20분 질의응답인데, 발표자인 테오님께서 알차게 준비해 주셔서 1시간동안 발표를 해 주셨다. (무려 발표 슬라이드만 120장.. 무료로 이 강의를 들어도 되는건가요..🙄)
밋업은 인프랩 오피스에서 진행되었다.
판교 직장인들에게는 퇴근길일 수 있으나, 강남 직장인에게는 머나먼 여정이었다.
하지만 이 또한 내가 선택한 길. 높은 경쟁률을 뚫고 60명 안에 당첨된 것에 기뻐하며 발걸음을 옮겼다.
신청 계기
간단하게 내 소개를 하자면 아래와 같다.
- 5년차 개발자
- 3년은 금융권 웹 시스템 SM
- 2년은 백엔드 API 개발 (ing)
- 기술 스택 다양 : Java, Spring, Kotlin, JavaScript, TypeScript, Node.js 등등..
- 취업한 이후 사이드 프로젝트 해 본적 없음
- 해봤자 개인 github.io나 스터디만 했지, 사이드 프로젝트를 각잡고 해보지는 않음
- 왜 여태까지 사이드 프로젝트를 하지 않았는지?
- 기술적으로 부족한 부분은 스터디를 통해 해결 (책, 강의 등등)
- 이외에 별도로 사이드 프로젝트를 진행할 여유가 없었음
- 팀을 꾸려서 사이드 프로젝트를 하는 것에 대한 부담감
- 나도 여유가 없는데, 다른 사람들과 감정소모하면서까지 하고 싶진 않다.
- 팀원들의 기대를 충족시켜주지 못할 것 같은 부담감
- 혼자 하려고 해도, 사이드 프로젝트는 뭔가 프론트엔드 개발을 잘 해야 할 것 같다.
- 하지만 난 나약한 백엔드 개발자..
아무튼, 이런저런 이유로 사이드 프로젝트를 미루고 있던 차에 해당 밋업을 보게 되었고, 밋업에 참가하게 되면 사이드 프로젝트를 같이 할 팀원을 구한다던가, 사이드 프로젝트를 어떻게 하면 잘 이끌어나갈 수 있을지 등등, 동기부여가 될 것 같아 신청하게 되었고, 운이 좋게 선정이 되었다.
밋업 신청 Tip.
대부분의 밋업 공고를 보면 추첨이라고 되어있다.
하지만 이 추첨은 완전한 추첨이 아니라는 사실!
밋업 신청서에 자기소개나 궁금한 점 등등이 있는데, 이 내용들을 잘 쓴다면 당첨 확률이 상당히 높아진다.
해당 밋업 뿐만이 아닌 다른 밋업에서도 통용되는 사실로, 밋업 신청 시에는 자기소개를 잘 쓰도록 하자!
밋업 내용
물론 밋업을 현장에서 듣는 것이 더 생동감 있고 유익했지만, 내 나름대로 밋업 내용을 정리해보고자 한다.
사이드 프로젝트는 누군가가 시켜서 하는 것이 아니라 내 의지로 하는 것.
혼자 하면 쉽게 질릴 수 밖에 없고, 내 시간과 에너지가 소모되는 것이 당연하다.
그러므로 보통은 사람들과 모여서 사이드 프로젝트를 많이 진행하게 되는데, 이 과정에서 동기부여를 얻을 수 있다.
사이드 프로젝트는 왜 실패하는지?
구성원과 생각이 다르고, 강제성이 없고, 보수가 없기 때문 => 지속할 이유가 없으며, 원래 안 되는게 맞다.
크게는 아래의 세 가지 이유가 있다.
1. 기대의 불일치
- 내가 사이드 프로젝트에서 기대하는게 충족되지 않으면 하기 싫어진다.
- 나는 React를 쓰고 싶은데 프로젝트는 Vue로 진행된다면? 하기 싫어진다.
- 나는 사이드 프로젝트를 가볍게 하고 싶은데, 동료는 이걸로 사업을 하고 싶다면? 너무 힘들어서 하기 싫어진다.
2. 안전감의 상실
- 서로에게 솔직하고 신뢰를 가져야 한다.
- 말 꺼내는게 불편해지면 안 된다.
3. 소속감의 부재
팀 빌딩을 어떻게 해야 하는가?
서로의 목적을 공유하고, 서로가 바라보는 기대를 맞추는 것이 중요하다.
목적(방향)이 같아도 목표(도착점)은 다를 수 있으며, 반대로 목적(방향)이 달라도 목표(도착점)은 같을 수 있다.
이러한 것들이 달라도 서로를 알고 있으면 맞출 수 있고, 팀빌딩 시간에 이것을 진솔하게 이야기해야 할 필요가 있다.
팀빌딩의 조건
1. 기대를 조율하기
- 성공이 무엇인지 정의해야 한다.
- 추측하는 것과 실제로 아는 것은 다르다.
- 내가 하고싶은 것이 무엇인지 파악해야 한다.
2. 안전감 만들기
- 신뢰 쌓는것이 중요. 어디까지 솔직해져야 하는지?
- 솔직함과 친절함은 배타적인 것이 아니다.
3. 소속감 만들기
- 이름/목표/규칙/문화/추억 등으로 소속감을 만들자.
이런 것들을 직접 챙겨도 되지만, 잘 만들어진 도구들을 활용해서 팀빌딩을 하면 좋다.
Team Canvas - Bring Your Team on the Same Page
The Team Canvas is Business Model Canvas for teamwork. It is a free tool for leaders, facilitators and consultants to organize team alignment meetings and bring members on the same page, resolve conflicts and build culture, fast
theteamcanvas.com
teamcanvas를 활용하면 2시간이면 팀빌딩 가능하다.
어떻게 하면 꾸준히 사이드 프로젝트를 지속할 수 있는지?
사이드 프로젝트는 취미의 영역이지, 숙제가 아니다.
각자의 열정과 사정이 다르므로, 서로 이를 이해해야 한다.
굳이굳이 시간을 내서 하기 보다는, 정해진 시간을 못박아두고 그 시간에 하는 것을 추천함 (마치 헬스장 가는 것 처럼)
어떻게 하면 동기부여를 할 수 있을까?
불편함이나 강요를 이용한 외적동기를 만들지 말자.
지지부진해질 때면 다시 초심으로 돌아가자.
릴리즈 경험은 좋은 외적동기가 될 수 있다 => 어떤 것을 목표로 삼을지 모르겠다면, 릴리즈 하는 것을 목표로 잡아보자.
- 최고의 동기부여는 사용자 반응이므로 릴리즈가 중요하다.
- 테스트가 가능한 최소한의 형태가 릴리즈.
- 완벽함보다는 그럴싸함을 목표로 하자.
일정을 산정하기보다는 정기적인 체크가 되어야 한다. (현업에서도 일정 산정이 제일 힘든 것 처럼..)
결정의 순간이 온다면?
실제 업무와는 다르게 PM이라는것을 딱 정하고 들어가는 것이 아니다.
하다 보면 어쩌다보니 지분이 가장 높은 사람이 되기도 한다. 이렇게 하기 보다는 처음부터 정하는 것이 낫다.
결정의 순간이 올때 잘 해결해야 하며, 결정을 하는 과정에서 충분히 합의가 이뤄져야 한다. (결정의 과정에서 모두 동의)
서로 의견이 다르다면 어떻게 해결해야 할까?
- 결정하지 말고, 힘을 빼고, 순수하게 "왜"로 문제 인식 하기. 해결법과 의도를 분리하고, 의견과 판단과 인식을 분리한다.
- 그래서 어떻게 하면 둘 다 만족시킬 수 있는지.
결정을 잘 하기 위한 마인드셋
A vs B가 아닌 A+B = C임을 인식하기.
- 두 의견이 비등비등할 경우, 어차피 뭘 고르든 크게 차이가 없는 상황.
- 이럴 경우 지지부진하게 끌지 말고 신속하고 강직하게 결단을 내려야 한다.
=> 결정의 내용이 아닌 결정 방법과 합의가 필요하다.
아이디어 및 BM 찾기
아이디어 찾기
- 나의 Pain Point를 찾고 개선하기
- 내 관심사 또는 주변의 관심사에서 발견하기
- ProductHunt 참고 : https://www.producthunt.com/
Product Hunt – The best new products in tech.
Product Hunt is a curation of the best new products, every day. Discover the latest mobile apps, websites, and technology products that everyone's talking about.
www.producthunt.com
아이디어/주제는 생각보다 중요하다. 개발하는데 있어서 내가 재미가 없으면 안 된다.
BM 합의가 필요하다.
- 만약 BM이 중요하다면 무리해서라도 덕지덕지 붙여야 한다.
- 광고를 다는데 거리낌이 없어야 한다.
- 무리하게 떡칠을 해야지 어느 포인트에서 BM이 되는지 평가가 가능하다.
그래도 BM을 모르겠다면? 장르적 문법을 따라가자. 내 서비스 카테고리에 맞는 BM은 분명히 존재한다. (창의적인 BM을 생각할 줄 알았으면.. 애초에 여기 있질 않겠지 😇)
발표 마무리
사이드프로젝트 자체로는 깊이가 있기 힘들다. 이걸 이직에 쓰기 보다는 하던 일을 잘 정리해서 어필하자.
열정은 식는 속도가 다르지, 결국엔 식는다. 따라서, 열정에 대해 기대나 강요를 해서는 안 된다.
어떻게 사이드 프로젝트를 잘 마무리할지 생각하자.
나의 소감
이런저런 핑계로 사이드 프로젝트를 하는 것을 미뤄 왔기에, 나도 사이드 프로젝트를 해 봐야 하나~ 라는 생각을 가지고 있었다.
적지 않은 연차이지만 기술 스택이 얕고 넓어서 걱정했었고, 이를 잘 갈고 닦으려면 사이드 프로젝트만한 것이 없다고 생각했기 때문이다.
내가 내린 결론은, 이를 잘 갈고 닦으려면 굳이 사이드 프로젝트의 형태로 갈고 닦을 필요는 없다는 생각이 들었다.
강연자분께서 말씀 주셨듯이, 본업이 더 깊이가 있을 수 밖에 없기에, 본업을 하면서 궁금한 것을 딥다이브 하는 방식으로 파고 들어가야 할 것 같다.
내가 사이드 프로젝트를 주저했던 이유 중의 하나는, 내가 너무 몰라서, 나는 아직 사이드 프로젝트를 할 실력이 되지 않았을 것 같다는 생각에 사이드 프로젝트를 하는 것을 주저했던 것 같다.
이런 점에 있어서도 부담감을 내려놓고, 편한 마음으로 취미로 사이드 프로젝트를 시작해봐야 겠다는 생각은 들었다.
네트워킹, 마무리
비슷한 관심사를 가진 사람들끼리 모여서 네트워킹 시간을 가졌다.
우리 조는 "사이드 프로젝트에서의 일정 관리"라는 공통 관심사를 가지고 있었고, 어떻게 하면 사이드 프로젝트를 진행하는데 있어서 일정을 효율적으로 관리할 것인지에 대해 이야기를 나눴다.
그 외에도 서로 관심 있는 기술이나 개발 관련된 얘기를 나눴고, 좋은 시간을 가졌다.
(마무리는 역시 링크드인 교환으로)
밋업 관련 굿즈도 나눠주었다.
활용도 높은 에코백과 귀여운 스티커까지 받을 수 있었다.
여러모로 유용한 밋업이었다.
밋업 후기 끝!
