유감스럽지만 개인적으로 너무 힘든 협업이었고 협업 이렇게만 하지 않으면된다! 라는 큰 교훈을 얻은 스프린트 였기 때문에 회고를 정리 하지 않을 수 없었다.
이미 최종 회고에서 좋았던 점, 배웠던 점, 부족했던 점, 앞으로 해 볼 점, 이렇게 네가지를 짚어가면서 진행했지만 이번 회고는 내 개인적인 입장에서 느꼈던 것을 정리하는 느낌으로 진행 해보려한다.
이번 스프린트가 나에게 준 가장 긍정적인 영향은 활력
을 불어 넣은 것이다.
무수한 탈락에 지친 나날들을 보내고 있었던 나는 예전에 있었던 열정이 식어버린지 오래였고, 어떤 길을 가야하는지 캄캄했던 찰나였다. 그런 나에게 이번 스프린트는 굉장한 자극이 되었다. 다양한 사람들을 보면서 나를 되돌아 보게되고 프로젝트를 하면서 여러가지 기술적인 고민을 하게 되는 계기가 되었던 것 같다.
두번째로 좋았던 점은 "피그잼으로 협업하는 방법"을 알게 된 점이다. 인턴 때의 경험을 미루어 봐도 실제로 현업에서 코드를 짜는 시간보다 회의하는 시간이 압도적으로 많았다. 그렇기 때문에 성공적인 회의는 성공적인 일처리로 가는 지름길과 같다라는 느낌을 많이 받았다. 또한, 코로나 때문에 재택 근무가 많이 자리잡으면서 회의도 대면회의 보다 비대면 회의가 많았던 것 같다.
피그잼을 이용하여 text 로 의견을 주고받고 모든 것을 기록하는 방법은 효율적인 비대면 회의를 이끌어 나갈 수 있는 key idea 가 될 수 있을 것 같다.
마지막으로 가장 큰 좋은 점은 "열정있는 사람들과 좋은 경험을 했다는 것", 프론트엔드 개발자 분들과 커뮤니케이션 할 수있는 장이 또 하나 늘었다는 것이라고 생각한다.
스프린트가 끝나고 오프더 레코드로 테오와 같이 협업에 부족했던 것들을 허심탄회하게 말하였다. 위에서도 말했 듯이 이번 협업이 힘들어진 이유를 찾는게 이번 협업에 굉장히 큰 의미가 될 것 같다라는 생각을 했다.
⇒ 회의가 피그 잼이였기 때문에 가장 크게 잘 활용 할수 있는 장점이였으나 잘 활용하지 못했던 것이다. 다른 분들이 이야기 하실때 그 이야기가 어떤 이야기 인지 요약해서 피그 잼에 적어두지 않아서 휘발되는 아이디어가 많았다.
예를 들면, 밥 파티를 구해서 먹는 아이디어를 이야기 할 때, 맛잘알이 파티를 꾸려서 클래스 형태로 다른 분들에게 잘 먹는 방법을 알려주는 밥파티
이런 좋은 아이디어를 발산만 하고 구체화 하지 못했다.
지도를 그려 낼 재료인 질문들을 생각해 낼 때, 구체적으로 질문을 하지 못했다.
"어떻게 하면 사람들이 서비스에 만족할까요"라는 질문에 "좋은 경험을 하는게 재사용을 높인다"라는 말은 도돌이표 답변이다. 이런 답변들은 최대한 하지 않고 좀 더 나아가서 "우리 서비스"에서 어떻게 해야할까를 고민해봐야 했었다.
아이디어를 발산하면서 A+B=C 를 해야할 때는 각각의 아이디어로만 생각해서 투표로 결정지었었다.
사실 이런 투표 없이도 각자가 생각하는 궁극적 목적을 "워드 클라우드"에 적어보고 하이라이팅하거나 스티커를 붙이는 방법으로 자연스럽게 인기있는 궁극적 목적들이 두드러졌다.
하지만 디자인을 "결정" 할때는 빠른 결정이 필요했다.
우리팀은 모두가 다 다른 하지만 많이 비슷한 디자인을 만들고 있었고 어떤 디자인으로 가야하는지 많은 논의를 했었다.
(이제 와서 생각하는 것 이지만서비스의 궁극적 목적에 벗어나지 않는다면 가운데 캐릭터가 있던 배고파라는 글자가 있는 것은 큰 결정 상황은 아니라 생각한다)
내가 PL 이었지만 PL 역할을 온전히 다 못했다. 기획을 끝내고 코딩을 들어가기 시작했을때 과제전형에 걸려서 (이제는 떨어진...) 과제 전형을 하느라 온전히 프로젝트에 힘쏟지 못했다.
이 때, 내가 못해 줬던 일들을 다른 분들이 나눠서 이것저것 해주신 것에 감사드린다.
PL로써 부족하게 했던 역할들을 알기위해 다른 조의 PL 분이 팀을 위해서 지속적으로 노력했던 것을 여쭈어보았다.
그 분이 대답하시길,
지속적인 일정관리
팀원들의 업무 진행도를 매일 채크하시고, 매일 게더에서 정기적으로 시간에 스크럼하시면서 팀원들의 상태를 체크하셨다.
팀원들의 업무 분담
지속적인 업무 관리 뿐아니라 지속적으로 다음 스텝을 위한 업무 분담도 신경써주셨다고 한다. 각 팀원분들의 특성이나 기술역량에 따라서 다른 업무들이 주어지고 그 업무를 해결 할 수 있도록 옆에서 최대한 도우셨다고 합니다.
지속적인 팀 목표의 상기
각 스프린트 회의때 할 이야기들을 슬랙에 먼저 공지 하므로써 어떤 목표로 회의가 진행 될 것인지 알려주었다.
이 세가지 모두 슬랙에서 text로
원활하게 소통이 되었다는 것이 인상적이었다.
개인적으로 많이 배웠던 점은 피그마에 대해 많이 배웠던 것 같다. 이전 회사에서 프론트 엔드 개발자가 피그마를 잘 다루면 득 볼것이 많다라고 조언해주신 동료분이 있었는데, 왜 그런 말씀을 하셨는지 조금이나마 이해가 되었던 계기가 되었다.
오토레이아웃을 이용해서 파티 디테일 페이지를 내가 스스로 디자인 해 보았다.
오토레이아웃을 사용하다보니 실제로 내가 리액트를 사용하여 웹을 꾸미는 것처럼 레이어를 구상할수 있게 되었고 figma 의 inspect 탭에서 padding 이 유추되어 나왔다.
좀 더 유연하고 레이어 중심적으로 컴포넌트 설계를 할 수 있었다. (내가 디자인해서 그런진 모르지만)
갈피를 못 잡고 있을 때, 테오가 오셔서 "우리가 만들고 싶은 서비스의 궁극적인 목적이 무엇인가요?" 라는 핵심 질문을 던져주시고 워드클라우드로 각자의 생각을 마구마구 적도록 하셨다.
(좌) 우리가 워드 클라우드로 적었던 궁극적 목적
(우) 다른 팀이 우리 결과물을 사용하고나서 쓴 좋았던 점
"메뉴 골라준다" 라는 아이디어와 "밥 친구를 구해준다" 라는 아이디어들을 빌딩할 때 나는 두 가지가 공존하지 못한다고 생각했다. (비지니스 타겟팅이 다르기 때문에) 그러나 회의는 A+B=C 를 한 번 믿고 둘 다 해보자! 라는 흐름으로 흘러갔고 앱이 나왔을 때는 오히려 "즐길 거리가 풍성해서 좋았다." , "컨텐츠가 많아서 오래 머물고싶은 사이트였다" 라는 피드백들을 받았다.
풍부한 컨텐츠를 제공해 준다 역시 단일 목적이 될 수 있겠구나 라는 생각이 들었다.
다음 협업에서는 일정관리를 좀 더 세부적으로, 유동적으로, 각자 공유하도록 해보고 싶다.
내가 팀원 인 경우에는 어떻게 다른 팀원들에게 나의 업무 진행도를 공유드릴 건지 고민해 보아야겠다.
생각의 꼬리무는 방법(좋은 질문을 던지는 방법)을 혼자 프로젝트 진행해보면서 좀 더 갈고 닦아야겠다.
이몬의 회고 기다리고 있었어요 😁 실감 나게 글을 잘 쓰시는군요. 저는 보통 회고라고 하면 좋은 점 위주로 쓸 줄 알았는데 맨 위에서 "유감스럽지만, 개인적으로 너무 힘든 협업이었고"라고 시작해서 상당히 힘드셨다는 생각이 들더라고요. 좋기만 한 프로젝트는 없다는 것을 또다시 깨닫는 순간이었어요.
저는 이몬이 말했던 것 중에 <text로 따라 적는 게 굉장히 중요하다>고 한 부분에서 굉장히 공감했어요. 제가 이끄는 다른 사이드 프로젝트에서는 제가 리더인데, 매번 회의할 때마다 제가 전달하고 팀원들이 이야기 듣고 하는 게 마치 학교 다닐 때 아침 조회시간 같더라고요. 선생님이 전달하고 애들은 네~ 하는 거 같은 느낌? ㅋㅋ 그래서 지금은 구글 미트 + 피그잼으로 시간 내에 의견을 적고 이에 대한 피드백을 동시에 남기는 작업을 적용하고 있어요. 그냥 가만히 있는 것보다는 내 의견을 전달하고 빠르게 피드백 받는 게 좋았어요! 아직 2번밖에 해보지 않아서 엄청난 효율이 있었다! 라고 자랑은 못 하겠지만, 첫 시간에 팀원들이 "재밌다, 다음에도 이렇게 하자"고 하더군요. 우리가 정말 좋은 것을 배웠어요 👏
도돌이표는 우리 팀에서도 겪은 문제였어요. 아무래도 우리가 이제까지 발산하는 식의 회의를 별로 못해본 게 드러나는 순간이지 않았을까 싶은데요, 우리는 이제까지 살면서 빠르게 의견내고 결정해서 무언가 만들어내는 데 굉장히 급급했다고 생각해요. 우리가 이제는 수렴과 발산을 알아차리려 노력해야 할 때가 아닌가 싶어요.
PL의 역할에 대해 고민을 많이 하셨군요. 저도 이번에 퉁이리를 보면서 많이 느꼈어요. 우리가 가져야할 마인드를 상기시켜줘야 한다는 것, 우리가 해야 할 것을 명확하게 말해줘야 한다는 것 등이요. 저는 실제로 퉁이리가 "우리는 완성이 아니라 최고를 위해 달린다"라는 말을 해줬을 때 정말 열심히 했어요. (사실 계속 열심히 했어요 ㅋㅋ) 저도 이런 리더가 되고 싶더라고요. 이몬정 도면 충분히 잘할 거 같아요.
저는 오토레이아웃을 써본 적이 없는데 이번에 한 번 해봐야겠어요. 테오 블로그에 felxbox와 오토레이아웃을 익히며 css를 배우면 좋다고 적혀있더라고요. 알아서 뭘 잡아주는 건가? 싶네요. 해봐야겠네요 우하하
우리가 코다닥 팀의 결과물을 보면서 가장 많이 느꼈던 것은 "스토리가 있어야 한다"는 것이었어요. 저는 이제까지 개발할 때 디자인을 먼저 봐서 항상 디자인 중심적으로 개발을 시작했거든요. 지나고 보니 데이터 연동과 디자인을 왔다 갔다 했어야 맞았더라고요. 너무 데이터 중심적이어도 못생겨서 화나고 너무 예쁜 거에 치중하면 사용자가 경험할 거리가 없고. 퉁이리가 계속 배고파 얘기하면서 "스토리가 좋다~ 어쩐다~" 할 때 많이 샘났어요... 우리 것도 좋아해 주지...
"앞으로" 내용이 좋네요. 사실 공유하는 게 제일 중요하죠! 나중에 이몬이랑 함께 프로젝트 해보고 싶네요. 이몬의 글 잘 봤어요 👍
이몬 충분히 좋은 PL이셨습니다. 제가 옆에서 많이 도와드리고 했었어야 되는데 협업도 처음이고 개발도 서툰 코린이라 많은 도움이 되지 못한것 같아요... 날이 갈수록 회의가 싫어졌던건 사실이고 이걸 바꿀 어떤게 있어야 했는데 제가 선뜻 나섰어야 됐는데 지금와서야 후회스럽네요. 앞으로 계속 공유해요 서로!!
몬하~! 이몬은 최고의 PL ! 이몬을 만날 수 있어서 너무 좋았어요. 공유에 대해 고민을 많이 하셨네요요. 저도 공유를 어떻게하면 효과적으로 잘할지 항상 고민하는데 어렵네요. 정답을 찾으신다면 알려주세요! ㅎㅎ 오늘도 좋은하루~