협업이슈요?
아무일도 없었습니다..
이번에 사이드 프로젝트에서 팀 리더로서 작업을 했습니다. 사실 팀 리더로서 작업한 프로젝트는 2개지만 첫번째 프로젝트에서는 별다른 문제 없이 잘 끝났기 때문에 큰 어려움이 없었습니다.
하지만 두번째 프로젝트인 뽀모도로 프로젝트를 진행하고 부터는 여러가지 협업이슈들이 생겨나기 시작했습니다.
이번 글에서는 각각의 이슈들을 살펴보고 어떻게 해결해나갔는지 작성해보려고 합니다. 만약 비슷한 이슈가 생겼다면 제 방법을 참고해보시는 것도 좋을 것 같습니다. (흔한 일이 아닐수도..)
첫번째 이슈: 말 없는 지각
정해진 회의 시간에 말없이 지각한 사례
한 팀원이 정해진 회의 시간에 아무런 예고 없이 늦게 도착하는 문제가 발생했습니다. 늦거나 오지 않을 경우 미리 알려달라고 여러 번 요청했지만, 문제는 개선되지 않았습니다.
처음 협업 이슈가 발생했을 때, 사실 저는 '협업 중 문제가 생기면 좋겠다'고 생각했었습니다. 면접에서 협업 이슈에 대해 질문받을 때, 실제로 겪어본 경험이 없었기 때문입니다. 학창 시절 조별 과제를 할 때 의욕이 없는 친구들과의 어려움을 제외하면 말이죠.
처음에는 "야근도 하고 회사 일도 바쁜데, 잊을 수도 있겠지"라고 이해하려고 했습니다. 하지만 이 상황이 6번 반복되자, 도저히 이해할 수 없는 상태에 이르렀습니다.
그리고 한 번 더 반복되자, 평소와 다르게 좀 더 진지하게 대화를 이어나가기 시작했습니다.
나: "00님 또 말없이 오지 않으시는군요..
팀원: "야근한다고 못들어갈수도 있다고 말하는걸 못했네요. 죄송합니다."
나: "이게 반복되니까 문제입니다. 이걸로 스트레스도 많이 받아서요."
팀원: "말씀 못드려서 죄송합니다. 계속 신경을 쓴다고 해도 많이 부족하네요"
나: "이해를 해보려고 했는데 한마디 하는게 어려운가 싶더라고요. 프로젝트를 너무 가볍게 보고 계신건가 싶기도 합니다."
이렇게 진지하게 계속 이 주제에 대해 이야기를 나누다 보니, 팀원이 해결책을 하나 제안했습니다.
"카톡 일정 기능으로 회의 시간 15분 전에 참가 가능 여부를 체크하는 건 어떨까요?"
아니 그걸 왜 지금 말해..?!!
좋은 아이디어였습니다. 이걸 이제서야 얘기했다는게 조금(많이) 괘씸하긴했지만, 바로 적용하기로 했고, 만약 지각해야 하는 상황이라면 사유를 별도로 알리기로 했습니다.
다행히 이 아이디어를 적용한 이후로는 같은 문제가 다시 발생하지 않았습니다.
여기서 얻은 교훈은 약속을 지키지 않아 문제가 생겼을 때, 문제의 원인을 파악하고 어떻게 해결할 수 있을지 고민해야 한다는 것입니다. '다음에는 잘 지켜주세요.'와 같은 말은 실제로는 별 의미가 없었습니다. (주의, 사람마다 다를수도 있습니다)
예를들어 지금처럼 이런문제가 생기지 않도록 협업환경을 개선하거나 원인과 진짜 해결책을 찾는 것이 중요하다는 것을 깨달았습니다. 또한 문제가 생겼을 때 가능한 한 빨리 해결방안을 고민해야 한다는 점입니다.
계속 같은 문제가 발생할 때마다 약속을 지키지 않는 것에 대해 스트레스를 받았습니다. '왜 이걸 지키지 않지?'라는 생각과 함께, 누군가에게는 필요한 말이지만 말하기 불편한 지적을 계속하게 됐습니다. '이런거 잘못하셨는데 다음에는 잘지켜주세요' 팀을 관리해야 하는 입장에서 이런 상황은 더 큰 스트레스가 되었습니다.
이런 문제가 다시 발생하지 않도록 하기 위해서는 문제가 생기면 원인을 파악하고 근본적인 해결책을 찾아내야 한다는 것을 깨달았습니다.
정리
한 팀원이 정해진 회의 시간에 아무런 말 없이 지각한 사건이 있었습니다. 이 문제를 해결하기 위해 여러 차례 요청했으나 변화가 없어 스트레스를 받았습니다. 이러한 상황에서 진지한 대화를 통해 문제의 원인을 파악하고 해결책을 찾아냈습니다. 이를 통해 약속을 지키지 않는 문제를 해결하기 위해서는 문제의 원인을 파악하고 실질적인 해결책을 찾아야 한다는 교훈을 얻었습니다.
두번째 이슈: 컨벤션
프로젝트를 시작하기 전에 코드와 커밋 컨벤션을 미리 정했습니다. 처음으로 컨벤션을 작성해보았기 때문에 큰 틀과 기본적인 사항들을 정하고, 추가적인 사항은 작업을 진행하면서 결정하기로 했습니다.
그런데 문제가 생겼습니다.
정하지 않았던 부분을 결정하려고 했을 때, 그 이유가 없었던 사례
팀원 중 한 명이 프론트엔드에서 컴포넌트 이름을 StudyRoomList, StudyRoomListItem과 같이 작성하고 있었습니다. 저는 복수형과 단수형을 사용해 StudyRooms, StudyRoom과 같이 작성해왔기 때문에 이러한 방식이 다소 낯설게 느껴졌습니다.
이유를 물었을 때, 그저 회사에서 계속 사용해온 방식이고 개인적인 취향이라는 답변을 들었습니다.
그래서 제 의견을 바탕으로 설득을 시도해봤습니다. '가독성 측면에서 복수형, 단수형으로 나타내는게 좋지 않을까요, 예를 들어 ParticipantListItem 같은 경우, 참가자 아이템?이라는 인상을 줄 수 있어 이해하기 어렵습니다. 현재 방식이 더 나은 이유가 있다면 설명해주시겠어요?' 타당한 이유 없이 사용하고 있다면 더 나은 방법을 찾아야 한다고 생각했기 때문입니다.
그 결과, 별다른 이유가 없어서 제가 말한 방식으로 진행하기로 결정되었다가 새로운 프론트엔드 개발자분이 팀원으로 합류하셔서 의견을 받아본 결과 ListItem을 사용하는 쪽으로 결정되었습니다.
컴포넌트를 더 명확하게 구분할 수 있다는 점이 충분히 납득할 만한 이유였기 때문입니다. 또한 저도 원래는 프론트엔드 작업도 함께 했지만, 새 팀원이 오면서 백엔드에만 집중하기로 했기 때문입니다.
프론트엔드는 코드 리뷰를 통해 의견을 제시하기로만 했기 때문에 프론트엔드 팀원분들의 의견에 더 비중을 실어드렸습니다.
이 사례를 통해 깨달은 것은 최선의 방법이 따로 있는 것이 아니라, 팀원들과의 합의를 통해 서로 이해하고 문제가 없다면 그것으로 충분하다는 점이었습니다.
머리로는 알고 있었지만 이런 느낌이구나라는 걸 직접 깨달을 수 있는 사례였습니다.
미리 정해둔 컨벤션을 지키지 않은 사례
원래 PR과 Commit은 다음과 같은 형식으로 작성하기로 했습니다.
하지만, 정해진 형식을 따르지 않는 경우가 발생했습니다.
정해진 형식을 지키지 않았을 뿐만 아니라, 제목에도 많은 문제가 있어 리뷰를 달았습니다.
그랬더니 아래와 같이 커밋을 작성하셨습니다.
(?? ㅋㅋㅋ)
리뷰 후 수정 -> 리뷰 이후 수정
웃음만 나오는 상황이었습니다.
그래도 다행인 것은 커밋 내용으로 세부적인 내용을 적어주셨다는 것..! 조금이지만 전보다 나아졌습니다. 😂
지금은 계속 얘기하면서 조금씩 고쳐나가 좀 더 나아진 커밋을 작성해주고 계십니다.
정리
코드와 Commit 컨벤션을 미리 작성했으나, 팀원 중 일부가 이를 따르지 않았습니다. 가독성 측면에서의 차이를 설명하고, 다른 팀원들과의 합의를 통해 컨벤션을 수정했습니다. 또한, 정해진 형식을 지키지 않은 경우에 대해 리뷰를 통해 개선점을 제시하고 학습하도록 했습니다.
세번째 이슈: 기능 구현 이슈
미리 얘기해뒀던 기능과 전혀 다른 기능이 구현된 사례
프로젝트가 아직 MVP 기능을 진행 중이었기 때문에, 기능의 우선순위를 두지 않고 모든 MVP 기능을 작업하기로 했습니다. 그러나 예상치 못한 문제가 발생했습니다.
프론트엔드 팀원 중 한 명이 한번에 여러 기능을 진행했던 것입니다.
회의시간에는 타이머 작업을 한다고 했지만, 알고보니 그 타이머 작업에 3개의 기능이 합쳐진 것이었습니다.
타이머 작업 -> 스터디룸 조회 + 타이머 + 스터디 진행 (3개 기능)
이런식으로 기능을 나눠서 작성해뒀기 때문에 당연히 나눠서 할줄 알았는데 1개씩 작업해달라고 명확히 말을 안한 잘못이었습니다.
따라서 아래와 같이 말씀을 드리고 일단 코드리뷰를 위해 PR을 올려달라고 했습니다.
"작업하실 때, 기능진행 현황표에 나와있는대로 기능을 나눠서 작업해주세요. 합쳐서 하고 싶거나 더 세분화하고 싶으면 슬랙 회의 채널에 의견 나눠주시고요."
"여러 개를 한번에 작업하면 진행속도가 느려보여서 다른 팀원들이 봤을 때, 답답하고, PR이 너무 커집니다. PR이 커지면 코드 리뷰하기도 힘들고, 중간에 기능이 잘못 구현되었을 때, 파악하기도 어렵습니다. 코드 충돌이 생길 확률도 높아지고요"
이유를 들어보니 한 화면에 여러 기능이 들어가니 한번에 작업해야한다고 생각했던 것이었습니다. 그래서 다른 기능들은 임시로 동작하도록 하면된다고 했습니다.
그런데 코드리뷰를 해보니 앞서 말했던 PR이 커졌을 때 생길 수 있는 문제중 하나가 보였습니다.
원래라면 필요 없는 로직이 프론트엔드에 작성되어 있었던 것입니다.
간단히 설명드리자면, 계획 -> 공부 -> 회고 -> 휴식 단계로 이루어진 스터디에서 다음 단계를 진행하려면, 현재 단계를 body에 담아 요청해야 합니다. (중복 요청 방지)
그런데, 다음 단계를 계산하는 로직을 통해 현재 단계가 아닌 다음 단계를 보내준 것이었습니다.
"이렇게 하면 예외 처리를 해서 400을 반환할 텐데, 잘되나요? 왜 얘기해주지 않으셨나요?"
"아뇨, 아직 확인 안해봤습니다. 다른 기능 구현이 안끝나서요"
아..
이래서 기능을 나눠서 작업해야하는건데..
처음부터 잘못 이해한 건가?, 아니면 잊어버린 건가? 여러 가지 생각이 들었습니다.
원래는 현재 단계란걸 알기 쉽게 currentStep으로 보낼까 여쭤봤는데 step으로 해도 알아볼 수 있다고해서 step으로 변경한거라 아닐거라는 생각이 들었습니다. 본인이 얘기한걸 잊었겠어..?
잘못 이해한거라면 소통의 문제가 있었던 것이었기 때문에 개선방안을 찾아야했습니다.
그리고 이유를 확인해본 결과, 잊어 버린 것이었습니다.
처음엔 웃음이 나왔지만 일도 같이하면서 작업하는거니 까먹을 수도 있겠다라는 생각이 들었습니다.
그래서 이를 개선하기 위해, 기능 관련 논의가 이루어질 때 단순히 이해했다고 넘어가지 않고, 중요한 내용을 잘 기록해두며, 구현 시 업데이트된 요구 사항들을 확인하는 습관을 가지기로 했습니다.
또한, 매주 월요일에는 스프린트 회의를 진행하여 일주일 동안 작업할 기능을 정하고, 현재 어떤 작업을 하고 있는지 명확히 할 수 있도록 작업 중인 기능을 표시하기로 했습니다. 매일 회의에서는 그날의 작업 내용을 설명하는 시간을 추가로 가졌습니다. 서로의 작업 상황을 확인하고 잘못된 부분이 있으면 빠르게 고치기 위해서입니다.
프로젝트가 아직 MVP 단계인데 MVP에 속하지 않은 기능을 구현한 사례
그런데 스프린트 회의 다음 날, 회의에서 언급되지 않은, MVP에도 속하지 않는 기능을 구현 중인 것을 발견했습니다.
이유를 파악해본 결과, 문서 체크를 제대로 안했다는 게 이유였습니다.
그동안 회사에서 PM에게 업무를 따로 할당받아 진행하는 방식에 익숙해져 있어, 스프린트 방식이나 문서 작성 및 확인이 익숙하지 않았던 것입니다.
이 사례를 통해, 경험해보지 않은 새로운 작업 방식에 대해 팀원 모두가 적응하는 데 어려움이 있을 수 있다는 것을 깨닫게 되었습니다.
이 이후로는 잘 진행되고 있지만, 새로운 방식을 도입할 때는 모두가 빠르게 적응할 수 있도록 고민해봐야할 것 같습니다.
(물론 회의 때, 이미 동의를 받았던 부분이라 문서를 제대로 확인하지 않고, 얘기없이 작업을 바꾼건 본인 문제가 맞긴합니다..)
정리
프로젝트가 아직 MVP 단계인데 MVP에 속하지 않은 기능을 구현하는 일이 발생했습니다. 이는 팀원 간의 의사소통과 문서 체크의 부재로 인한 문제였습니다. 문서 작성과 팀원 간의 의사소통을 강화하여 이를 개선했습니다.
마치며
이 글은 앞으로도 현재 프로젝트에서 생긴 협업 이슈들을 업데이트 할 예정입니다. 문제가 안생겼으면 좋겠지만 그것또한 경험이니.. 하지만 제발 똑같은 문제만큼은 안생겼으면 좋겠네요
현재 팀원들이 모두 개선해 나가려는 의욕은 있어서, 처음엔 안좋았어도 어떻게든 좋은 방향으로 나아갈 수 있었던 것 같습니다. 그래서 이런 이슈들이 생겼을 때 처음엔 힘들었지만, 지금은 예전에 이런일이 있었는데 하면서 장난치면서 넘어갈수 있는 사이가 될 수 있었던 것 같고요.
이런걸 보면 어떻게 해결해 나가는지도 중요하지만, 어떻게 보면 좋은 사람을 뽑는게 중요하다는 것을 다시 한번 느끼게 되는 것 같습니다.
어느새 악덕 팀장으로 바뀐 제 프로필..
