'이슈'에 대한 소통
개발자는 어떻게 협업해야 할까
Copilot 생성 이미지"해당 '이슈'는 OOO님을 담당자로 지정해서 올려둘게요"
IT회사에서 일을 하다 보면 '이슈'라는 단어는 참 많이 듣고 보는 단어인 것 같습니다. 서비스를 개발하고 및 유지보수 하다 보면 묵혀있던 오래된 문제들이 튀어나와서 말썽을 일으키기도 하고, 신규로 추가되는 기능이 쏟아져 나오는데 일정은 빡빡하게 주어지는 경우도 허다하죠. 그 과정에서 기획, 디자이너, 개발 등 실무자들은 각자 할당된 시간은 받고 그 시간 안에 결과물을 도출해내야만 합니다. 그러다 보니 진행하는 과정에서 갑작스럽게 이슈들이 튀어나오곤 하는데 이에 대해 바라보는 관점과 태도는 사람마다 혹은 직군별로 제각각이죠. 이야기하며 문제에 대해 해결하는 방법을 논의해 보지만 각자가 이해하는 방식도 범위도 다르고 업무 용어도 통일되지 않으니 원활하게 되질 않습니다. 그럼 우리가 '이슈'에 대해서 조금이라도 원활하게 소통하기 위해서 우리는 어떻게 해야 할까요?
'이슈'에 대한 인식
위에서 얘기한 것과 같이 '이슈'는 직군 별로 인식하는 포인트가 조금씩 다릅니다. 저는 개발자이다 보니 다른 포지션의 사람들의 고충을 전부 이해할 수는 없지만 조금이라도 상대의 입장에서 생각하려 합니다.
예를 들어 버튼 하나를 추가하더라도 기획입장에서는 원래부터 제공이 되었어야 했었던 기능이 빠져서 추가로 기획을 한 것일 수도 있고 고객 요구나 제품 기획에 필요하게 된 이유가 있을 것입니다. 디자이너 입장에서는 전체적인 디자인을 고려하여 디자인 및 추가하면서도 수정사항 요청을 받아 지속적으로 시각화하는 작업을 할 것입니다. 개발자의 입장에서는 좀 더 구체적인 기능의 구현을 하며 그 이후의 상황을 예측하여 발생하는 또 다른 이슈들이 없을지 생각하고 전달할 것입니다.
때로는 디자인이 수정되는 것만으로 해결이 될 수도 있고 또는 이슈에 대한 정확한 인식이 부족하여 계속해서 수정사항이 생기며 딜레이가 될 수도 있습니다. 그러므로 업무에 임하는 직군들은 필요로 하는 기능이 무엇인지 또는 문제를 발생시키는 원인을 정확히 파악하고 공유되어야 하며, 어떠한 목표를 위해 업무를 해야 하는지에 대해 정확하게 인식을 한 뒤 작업을 할 필요가 있다고 생각합니다.
용어의 표준화
각 직군별로 사용하는 용어들이 다들 제각각이다 보니 서로 의사소통을 하고 있지만 알아듣지 못하는 경우가 많습니다. IT 쪽에서 일하게 된 지 얼마 안 되신 분들 같은 경우에는 특히나 개발자들이 하는 말들이 IT용어를 사용해서 하는 말이 많다 보니 무슨 말인지 못 알아들을 때가 많을 거라 생각합니다. 같은 개발자들끼리도 용어가 혼용돼서 쓰이는 경우가 많기 때문에 더더욱 이 부분은 서로 질문을 끊임없이 하고 이해한 뒤에 작업물에 반영이 되어야 나중에 문제가 덜 발생할 것이라 생각합니다. 개발자분들 중에서도 설명을 귀찮아하거나 잘하지 못해서 대충 하시는 분들도 계시기 때문에 쉽지 않을 것이라 생각하지만 그럼에도 서로의 간격을 좁히고 알고 있는 내용들이 공유가 되어야 좀 더 원활한 의사소통이 가능해질 것입니다.
주기적인 검토와 추적
프로젝트를 진행하다 보면 수정사항도 많이 생길 수 있고 바뀌는 부분이 많다 보면 놓치는 부분도 많이 생깁니다. 그렇기에 우리들은 이슈트래커 툴들을 이용해서 '이슈'의 히스토리를 남기고 지속적으로 관찰하고 필요에 따라 업데이트해 가면서 관리합니다. 이런 툴들을 이용하는 것도 어떻게 보면 비대면 소통이라고도 할 수 있을 것 같습니다.
서로 부족한 시간 속에 고군분투하며 프로젝트를 해나가는 과정에서 조금 더 적극적으로 소통하며 함께 방향을 잡고 협업한다면 우리 모두가 덜 고통받으면서 좋은 인상을 남길 수 있지 않을까 하는 마음에 끄적여 보았습니다.
