말도 많고 탈도 많은 프로젝트였다. 부족한 팀장이었지만 믿고 따라와준 팀원들께 감사할 따름이다.
부족한 점을 많이 느낄수록 역설적이게도 배우는 부분도 비례해서 생기는 것 같다. 이번 글에는 그러한 점들을 회고하고 정리하는 시간을 가지려 한다.
유독 갈등을 다른 팀원들과 많이 겪는 분이 계셨다. 안타깝게도 도중에 팀을 이탈해버렸고, 결국 끝까지 함께 마무리 하자고 했던 약속은 지켜질 수 없었다. 갈등의 발단은 생각보다 복잡하지 않았다. 오히려 너무 단순했다. 기술스택을 정하던 도중 팀원간의 마찰이 있었고 격해진 감정은 걷잡을 수 없을 정도로 커졌다. 팀원 한명이 잠시 없었을 때 배포를 vercel에서 aws로 변경을 했었고 그 부분에 대해 공지를 못 받은 팀원이 서운한 부분을 말하며 시작되 었다. 언제 터질지 모르는 불발탄 처럼 갈등은 묻히게 되었고 터지지 않고 조용히 지나가길 바랄 뿐이었는데, 항상 생각대로 되면 좋겠지만 몇 개의 갈등이 더 생기고 결국 앞에서 말한 것과 같은 일이 일어났다.
처음에 틀어진 마음들을 바로 잡았었더라면 하는 생각이 든다. 그때는 그렇게 까지는 틀어지지 않았을 테니까 말이다. 그때 마찰을 겪었던 두 분의 이야기는 갈등이 일어나고 바로 듣긴 했지만 근본적인 해결책을 내놓지도 못했고 그럴 여유도 없었다. 그렇게 묻어둔 것이 후회가 된다. 물론 버그가 있는 코드를 고치는 것도 쉬운 일은 아니지만 사람의 마음은 더 그렇다. 좋은 마음에서 시작된 프로젝트가 그러한 결과를 완전히 낳지 못한 것에 대해 아쉽다. 내 마음이 다른 사람의 마음과 같지 않다는 것 그렇기 때문에 상대의 마음을 대할 때 더 조심히 다가가야 한다는 것을 다시 느끼게 되었다.
항상 팀원의 입장에서 일했기 때문에 주간 마다 혹은 일간 마다 하는 업무보고가 의미 없고 번거롭게 느껴졌다. ‘어차피 마감일 까지만 완료하면 되는거 아닌가?’ 하는 속 깊지 않은 생각 때문이었다. 막상 팀을 이끌어 나가는 입장에 서니 업무보고 라는 것이 왜 필요하고 또 그런 것을 관리하기 위한 전용 툴인 jira, flow 라는 툴이 왜 존재하는지 더욱 느낄 수 있었다.
업무를 관리하는 관리자 입장에서는 업무의 진행상황을 파악해야 한다. 보고를 위해서도 있지만, 빠르고 효율적인 프로젝트를 위해서는 더 필요하다. 물론 각자 맡은 부분은 담당자가 제일 잘 알고 있겠지만, 그 상황을 일일이 듣고 또 정리하는 것은 시간이 많이 소요될 뿐더러 또 듣는 사람 입장에서 정리가 되기 때문에 보고와는 다르게 정리가 될 수 있다. 또 업무를 관리자가 중앙에서 관리하지 않으면 동일한 기능을 여러 사람이 만드는 경우가 생긴다. 실제로 업무관리를 했었지만 나의 부족한 점 때문에, 한 사람이 작업을 하면 공통으로 쓸 수 있는 기능을 여러 사람이 작업했었다. 그리고 문제가 생기면 조기에 발견해서 더 유연하게 대처 할 수 있다는 장점이 있다. 개발을 하다보면 실력과는 무관하게 어떤 부분에서 작업이 오래걸려 다른 작업을 못 하는 경우가 생기고 프로젝트의 지연으로 이어질 수도 있는 경우가 생긴다. 이 부분은 관리가 되고 있었기 때문에 여유가 있는 팀원에게 작업에 어려움이 있는 팀원과 기능을 같이 봐달라는 부탁을 해서 지연 없이 해결하게 되었다.
‘어차피 가벼운 프로젝트인데 노션에서 한일 할일 완료된 일 이렇게 정리하면 되지 않을까요?’ 라는 생각에 노션에서 제공하고 있는 칸반보드 라던지 일정관련 프로세스는 없었고 업무보고 템플릿 밖에 없었다. 이렇게 되니 일정이 시각화가 안되고 눈에 들어오지 않아서 같은 내용을 물어보고 또 물어보는 번거로움이 생겼다. 초기에 jira를 쓰긴 했었으나 제대로 사용하는 방법을 잘 몰랐기 때문에 템플릿 하나로 관리하려고 했었는데 어쩌면 일정관리를 너무 우습게 봤던 것 같다. 시간이 더 걸려 보이는 길일지라도 사람들이 가는 길로 가는 것이 맞다.
회고를 하다보니 참 짧은 2개월이었다. 항상 곁에서 코딩을 같이 하던 분들이 생각난다. 함께 해서 즐거웠고 다시 생각할 수 있는 좋은 기억들을 남겨줘서 고마웠다. 다들 다음에 볼 때는 더 성장한 모습으로 웃으며 볼 수 있기를