요약본
요약본으로 빠르게 보기
프로젝트 보러가기
드디어 2차 프로젝트 끝! 첫 프로젝트때 프론트엔드에서 웹서비스를 구현하면서 시각적으로 보이는 기능들을 완성하는 것보다 이번 2차 프로젝트에서는 보이지않는 데이터를 console로 나타내며 포스트맨으로 확인하는 과정들이 즐거웠다.
이번에 보다 확실히 나는 서버 관련이 더 재밌다는 걸 느꼈고 남은 일정보다 백엔드 기능들을 일찍이 끝낸 덕에 nginx와 pm2를 이용해 vm 배포 등 서버 관리도 해 볼 수 있었다.
깃랩을 이용해 협업을 하면서 지속적인 서버 코드를 vm에 업데이트하면서 자동배포(github action, gitlab CI/CD)에 관한 관심이 생겼다. 전 프로젝트에서보다 금방 맡은 파트를 끝낼 수 있어 프로젝트 진행 과정을 기록하거나 프론트파트와 더 잘 소통할 수 있는 문서화 작업을 하는데 집중을 하게되었다. 딱 하나지만 너무 아쉬웠던 점은 A님이 다른 팀원들(나 포함)을 오해함으로 일어난 갈등(?)! 식겁했다..
1차 프로젝트때는 팀원들도 정말 좋았고 다 함께 밤을 새어가며 수시로 진행상황 공유하며 열정 넘치게 보낸 덕분인지 프로젝트 기간 동안 밤을 새는 것도 즐거웠다. 당연한 말이지만 2차 프로젝트하면서 느낀 점은 팀원간의 소통도 중요하고 같은 상황 속에서도 개개인이 느끼는 부분이 너무나도 다르다는 것이다.
어떤 갈등이 있었고 해결과정이 궁금하다면?
아래 내용부터는 조금 감정적일 수 있는 내용이 들어있음으로 주의!
오해와 갈등
- 협업에 있어서 의견 조율해가는 과정이 중요하다 생각한다. 누군가 의견을 내는데에 주저하거나 망설이는 분위기가 조성된다면 최악으로 갔을 때 그 프로젝트는 결국 누군가 독단으로 결정하는 대로 진행될 것이다.
본인이 생각하는 원인(?)
-
누군가 의견을 냈을 때 누군가 부정적으로 대답하는 분위기는 처음 프로젝트를 시작하는 기획단계에서부터 형성이 되었고, 결국 의견을 내던 사람도 처음에는 설득하면서 본인 의사를 확고히 표현했지만 여러번 같은 상황이 반복되자 사람들은 점점 채팅방에서 말을 하지 않게 되었다. 기획이 마무리 되고 나서는 각자 맡은 파트에 집중하느라 스크럼 때도 딱히 대화가 오가지않았다.
-
그 중 주로 의견을 많이 내어오시던 A님은 사람들이 대답이 없고, 각자의 스레드 내에서 소통을 하자 소외감을 느껴오던 것 같다.
쭉 A님이 써오시던 글들을 보고 느낀 결론이 소외감이다...
근데 해당 스레드에서는 사적인 대화는 없고 전부 백엔드 관련 이야기였음
갈등
- 결국 빠방 폭발해서 본인이 느끼던 부분을 풀어 놓기 시작하였고 사람들이 어떤 부분에서 그렇게 느꼈는지, 오해를 풀자는 식으로 말을 하자. 이제와서 얘기하는 것은 의미없다며 나에게 본인의 역할을 맡겼고 자신은 스크럼 참여없이 프론트 작업에만 집중하겠다하였다.
풀리지않은 채 쌓여갔던 오해
- 팀원들은 최대한 프로젝트를 잘 끝내고 싶었기에 A님의 의견을 존중해 스크럼 시 전체 전달 내용은 단체 디스코드방에 전달하고 A님은 따로 스크럼에 참여하지 않으시고 본인 작업현황을 디스코드에 남겨주시는 방법으로 남은 프로젝트가 진행되는 듯했다. 그런데 누군가 따로 A님께 스크럼 내용을 전달하면서 또 A님의 분노 포인트를 눌렀고 다시 A님 혼자만의 오해와 함께 팀원 한명한명을 저격하며 분노하기 시작했다.
- 앞 전에도 이런 식의 분노에 많이 지쳐있던 다른 팀원분 중 한분은 그럴거면 A님이 맡고 있는 부분을 내려놓고 확실히 집고 가자라고 하셨다.
심지어 얘기 꺼내신 분이 항상 배려 넘치는 말투로 분위기도 잘 풀어주시던 분...
- 마지막 A님의 폭발에 주 저격 대상은 나였지만 어찌되었건 갈등 또한 프로젝트를 통해 성장하는 과정이라 생각하였다. A님이 먼저 사실 확인을 하셨다면 좋았겠다는 씁쓸함이 있었지만 그래도 프로젝트는 다함께 잘 마무리 되었으면 좋겠다는 마음에 오해라며 당시 스크럼 상황을 설명하며 갈등을 풀려하였다. 하지만 A님은 혼자만의 감정을 표출한 채 프로젝트가 이틀 남은 시점에 잠수를 타버렸다.
갈등 해결 과정
부제 : 프로젝트 마무리를 위하여
- A님은 처음 프론트 파트를 책임지고 진행하겠다며 도움을 거절하시긴 하였지만 마냥 연락이 안되는 사람을 계속 기다릴 수는 없었다. 빠르게 진행해야겠다는 생각에 팀원들에게 A님이 온전히 작업하겠다 한 것들을 분담하여 프로젝트 마감을 향해 달렸다. 후에 나는 백엔드 포지션이었음에도 불구하고 프론트 포지션에 투입돼 에러와 남은 기능 구현과 함께 문서화 작업, 발표 준비 등등을 진행하였다.
- 마감 하루 전날 밤 A님과 따로 얘기를 나눴고 내가 이때까지 느껴오던 팀내 분위기가 다랐던 점과 A님과 내가 서로 느끼는 부분이 다른 만큼 다른 팀원들도 마찬가지였을 거라는 이야기를 음성채팅으로 전했다. 그 과정에서 오해로 얽혀있던 감정이 풀린 듯했다. 대화 끝에는 A님께서 발표는 마무리 한다하셨고 A님이 생각해오시던 역할이었던만큼 내가 준비해오던 발표 준비를 A님이 받아 마무리 짓게되었다.
느낀 점
- 모든 과정들을 벨로그에 다 적지는 못하지만 이런식으로 자꾸 혼자만의 오해만 쌓아가고 본인이 그렇게 느꼈던 부분에 대해 명확하게 얘기를 해주는 것도 아니고, 당사자에게 사실 확인도 안한 채 계속 분노하는 팀원을 보면서 느꼈다. 이번 일은 작은 오해가 하나, 둘 쌓여 소통 불능이 되며 벌어진 결과이다.
- 처음에는 이런 A님의 분노에 책임감이 그만큼 강한 분이어서 그런 것이라 생각했다. 하지만 본인이 책임지겠다 했던 부분을 내던지고 잠수를 타버리는 모습에 이해해보려했던 마음도 사라졌던 것 같다. 그 동안의 A님의 비판에 좋게 잘 풀어가려는 노력들이 다 무의미했다는 생각도 들었다.
- 끝은 다함께 프로젝트 마무리를 위해 무사히 마무리를 지은 듯하였지만 이번 회고를 작성하면서 다시 돌아보니 이런 팀원의 예민함을 발견했을 때, 나의 대처 또한 부족하다 느꼈다.
- 이럴 때를 대비하여 협업 소통(?) 가이드라인 문서화도 필요하겠다.
주저리 주저리
-
처음에는 A님이 터진 이유는 프론트 파트 안에서 다른 팀원분들이 협조도 제대로 하지않고 혼자 프론트를 이끌고 있는 것에 대한 부담감과 프로젝트 일정에 있어 너무 쫓기듯이 하고 계신 심리적 압박감 때문이라 생각했다. 나름 백엔드 파트안에서 일찍 내 할 일을 끝내고 난 뒤라 먼저 도와드릴까요? 라고 물어보았다. 스크럼 때는 함께하는 프로젝트에서 혼자 너무 스트레스 받으며 A님이 끙끙거리는게 보였기 때문이다. A님은 정말 감사하다며 잘 부탁드린다고 하였다. 후에 프론트에 투입되어서 User 프로필 기능 구현을 끝내 저녁 쯤 작업 완료한 것을 작업 브랜치에 올려두었다. 하지만 중간 작업과정에서 서로 git에 대한 이해가 달라 괜히 스트레스 덜어주려다 스트레스만 주었다는 생각이 드는 일이 있었고 작업한 부분까지만 구현을 끝내고 더 이상은 관여하지 않기로 했다.
최대한 빨리 끝내야겠다 생각으로 내가 맡은 부분은 그날 밤샘 작업으로 끝내두었다.
-
프로젝트를 최소한 그럴싸해보이는 서비스로 구현해두고 싶은 욕심을 내려둬야했던 걸까. 애초에 팀원의 예민함을 발견 했을 때부터 더 이상 나서면 안됐던 걸까. 하는 생각도 들었고 앞으로 이런 사람을 만났을 때 어떻게 대처를 해야할까에 대한 고민을 많이 하게 된 거 같다.
-
이런 노력에도 불구하고 A님은 위에 언급했던 누군가의 스크럼 내용 중 일부를 잘못된 전달을 하여 A님은 오해로 인한 분노를 표출하고 프로젝트 마감 이틀전 잠수를 타서 프론트 에러 처리는 내 몫이었다.
결론
다시 이런 일이 생기지 않게 하려면?
- 만약 다음 프로젝트에서도 개인의 오해로 끙끙 앓다가 터져버려서 다른 팀원들의 말조차 듣지않고 꽁꽁 숨어버리는 사람을 만나면 어떻게 해야할까?
- 함께하는 팀원이 예민함을 들어낸다면 어떤 식으로 대화를 하면 좋을까?
- 이번 팀원처럼 혼자 분노를 표출하고 다른 분들의 의견을 듣지않는다면?
프로젝트 보러가기
데이터 분석 프로젝트 회고 부록 예고편
- 다음 프로젝트나 훗날 책임자로써 프로젝트를 맡게 되었을때 협업태도라던가 마인드셋을 글로 미리 정리해두면 좋을거 같다는 생각이 들어 부록을 쓸 계획이다.
- 협업에 있어 의견 조율이란?
- 최선의 협업을 위한 프로젝트 소통 방법
- 예비 개발자로써 처음 프로젝트를 진행할 때 어떤 마음으로, 어떤 태도로 프로젝트를 진행하면 좋을지?
- 협업에 있어서 서로 다양한 의견이 나오는 만큼 서로 기분 상하지않고 의견조율을 잘 하려면 어떻게 해야할까? 누군가에게는 당연한 말이겠지만 누군가 의견을 낼 시 본인이 이해한 내용이 맞는지 확인 후 해당 의견대로하면 어떤 장점이 있는지 물어보고 본인의 방법이 더 좋다 생각하는 경우에는 확고하게 팀원들에게 의견을 주장하는 것도 방법이다!
- RESTFul한 Git 협업 방법!