IT 회사에서 개발자와 대화하는 게 왜 힘든지 아세요?
개발자와 커뮤니케이션 효율을 높일 수 있는 방법들
IT 회사에서 본인의 일을 하는 것도 벅찬데, (불편한) 개발자와 대화해야 할 상황에서 우리는 머리가 깜깜해집니다. 본인이 구현하고 싶은 것을 알아서 정리해서 개발자에게 이해시키는 장치가 있다면 얼마나 좋을까요.
하지만 아무리 기술이 발전하더라도 우리의 생각을 남들에게 100% 정확하게 전달하는 장치는 만들 수 없을 거예요. 본질적으로 만드는 입장과 만들어주기를 원하는 입장은 다를 뿐만 아니라, 실제로 본인이 전달하려고 하는 생각들도 명확하게 정의되지 않을 때가 많기 때문이죠.
✋참고 : 개발자가 항상 옳다는 글이 아닙니다 ✋
문제정의
우리 (소) 통... 하는 거 맞지?보통 IT 회사에서는 아이디어를 제시하는 사람은 비개발 직군, 아이디어를 구현하는 사람은 개발 직군으로 나뉩니다. 물론 요새는 개발을 베이스로 해서 다른 직군에 포진하는 경우도 많아지고 있지만요.
많은 분들은 개발자와 커뮤니케이션이 잘 안 되는 이유를 개발 용어를 모르기 때문이라고 생각합니다. 하지만 개발 용어를 아는 것은 커뮤니케이션을 위한 하나의 수단일 뿐입니다. 실제로 우리가 영어를 할 때 핵심 단어를 몰라도 바디랭귀지, 아는 단어들만 잘 조합해서 이야기할 수 있는 것처럼 말이죠.
저는 개발자와 커뮤니케이션이 잘 된다는 것은 더 빠르고 정확하게 (개발해달라는) 의사를 전달할 수 있다는 거라고 생각해요. 그리고 이는 결과적으로 제품이 더 빠르고 정확하게 개발된다는 거로 연결될 수 있습니다. 결국 개발자와 커뮤니케이션을 잘하는 건 회사 입장에서도 굉장히 중요합니다! (확신)
저는 개발 커뮤니케이션 문제를 크게 3가지로 정의해봤습니다.
1. HOW 개발 프로세스를 잘 파악하지 못함
2. WHAT 정확히 뭘 만들어야 하는지 설명할 수 없음.
3. WHY 왜 개발해야 하는지, 어떤 임팩트를 줄 수 있는지 잘 모름
[1] HOW 개발 프로세스를 잘 모름
IT 회사를 다닌다면 본인이 속한 분야의 스페셜리스트가 되는 것만으로도 대단하다고 생각합니다. 현재 IT 시대에는 기술들이 빠르게 변화하고 있고, 계속해서 학습해야 하는 상황이 됐습니다. 그렇기에 퇴근을 하고도 발 뻗고 자기 힘들어진 시대가 왔죠 (기술이 발전할수록 더 바빠지는 건 기분 탓일까요..)
하지만 우리가 다니고 있는 IT 회사라는 곳은 IT 제품을 통해 수익을 내는 곳입니다. 여기서 IT 제품은 대표적으로 웹, 앱 서비스가 있겠네요. 결국 IT 회사에서 수익을 낼 수 있는 가장 표면적인 수단은 바로 프로그램이 됩니다. 결과적으로 회사에서 나오는 모든 아이디어는 제품을 통해 구현됩니다. 이 말은 IT 회사를 다닌다면 개발과 전혀 동떨어진 세상이 아니며, 알면 알수록 좋다는 거죠.
여기서 개발을 안다는 게 꼭 코딩을 알아야 할까요? 요새 '스파르타 코딩클럽' 같이 비개발자를 대상으로 코딩을 알려주는 곳도 종종 눈에 띄더군요. 실제로 코딩을 해서 프로젝트까지 진행해 봤다면 개발자와 커뮤니케이션도 수월하고 본인의 업무에서도 식견이 넓어질 거예요. 하지만 이 영역까지 도달하기에는 항상 시간이 문제죠. 이 시간에 본인의 커리어에 집중하는 게 더 나은 결과를 낼 수도 있고요.
개발자가 열심히 짠 코드가 합쳐지기까지제가 추천하는 방법은 바로 개발 프로세스를 이해하는 거예요. 실제로 개발자가 코드를 쳐서 테스트를 한 후 전체 코드를 합치기까지, 그리고 합쳐진 코드가 어떻게 배포되는지까지 전체적인 프로세스를 이해하는 거죠. 구체적인 개발 과정까지는 알 필요는 없어요. 다만 프론트엔드, 백엔드 API가 뭔지 등의 기본적인 IT 지식들은 이해하고 있어야 해요. 그래야 개발자와 커뮤니케이션을 할 때 효과적으로 정보를 습득하고 전달할 수 있겠죠.
그렇게 되면 개발자의 업무 흐름을 파악할 수 있는 동시에 본인의 아이디어가 어떻게 개발되는지를 이해할 수 있게 됩니다. "아이디어가 나왔을 때 어느 정도의 개발 리소스가 투입되는지", "아이디어가 더 빠르게 개발할 수 있도록 신경 써야 할 부분이 뭐가 있는지" 등을 알 수 있게 됩니다.
개발 지식 & 프로세스를 친절히 알려주는 자료집 made by 그랩
[2] WHAT 정확히 뭘 만들어야 하는지를 설명할 수 없음
유명한 개발자 유머 짤기획 단계에서도 커뮤니케이션을 많이 하지만, 제품이 개발되는 과정에서도 생각보다 많은 커뮤니케이션이 발생합니다. 보통 "이렇게 개발하는 게 맞아?"라는 질문이 잦은 편입니다. 즉 요구사항에 맞게 개발되고 있는지를 중간에 확인하고, 애매한 부분들을 물어보는 거죠.
대표적으로 '친구 초대' 기능을 개발한다고 했을 때를 예로 들어 볼게요. 화면 디자인과 함께 친구 초대 기능을 넣어달라고 한다면 보통 중간에 물어보는 것들은 아래와 같은 사항들이 생길 거예요. "친구 초대 링크가 얼마나 유효한지", "친구 초대를 몇 회 이상한 사람은 어떤 UI를 보여줘야 하는지", "초대를 받은 사람이 받은 포인트가 모든 결제에 쓰일 수 있는지"
위와 같이 중요한 비즈니스 로직을 결정해야 하는 상황에서는 정리되기 전까지 작업이 중단되게 됩니다. 그러면 개발자는 기다리는 동안 다른 작업들을 왔다 갔다 할 것이고 결국은 생산성 저하로 이어집니다.
만약 이런 상세 명세와 여러 상황을 고려한 처리가 잘 정리되어 있다면 어떨까요? 물론 나중에 기획이 변경될 수도 있겠지만, 적어도 작업을 진행하면서 나오는 불필요한 커뮤니케이션 코스트를 줄일 수 있을 거예요. 동시에 요구사항을 제대로 충족하는 결과물이 나올 수 있겠죠.
보통 개발자들은 코드 환경에서는 본인의 창의성을 발휘할 수 있지만, 요구사항을 구현해야 하는 상황에서는 그렇지 못합니다. 일반적으로 IT 회사에서는 개발자들에게 꾸준히 (많은) 태스크들이 할당됩니다. 그렇기에 빠르고 정확하게 처리하는 게 중요하죠. 결국 본인이 구현해야 하는 대상이 명확할수록 더 효율적으로 개발을 할 수 있게 됩니다.
저는 개인적으로 아이디어가 구현되기로 결정됐다면 해당 아이디어는 구체화되어야 된다고 생각합니다. "쓸데없을 정도로 구체적이네"라는 말이 나온다면 대성공입니다.
[3] WHY 왜 개발해야 하는지, 어떤 임팩트를 줄 수 있는지 잘 모름
요새 애자일 방법론이 핫합니다. 대표적으로 이 방법론을 진행하기 위해 스프린트와 스크럼 회의를 진행하곤 하죠. 여기서 제품팀(기획자, 개발자, 디자이너, PO 모두) 모두가 참여해서 동기화하는 시간은 정말 중요하다고 생각합니다. 여기서 동기화라는 건 모두가 진행할 태스크들에 대해 진행 현황뿐만 아니라 '왜' 이 작업들을 진행하는지 알게 되는 거예요.
개발자 납득이 : 납득이 되면 이렇게나 좋다구결과적으로 요구사항을 구현하기 위해선 납득이 되어야 합니다. 제품을 개발하는 사람은 단순히 시키는 걸 만드는 게 아니라 회사의 가치를 투영시키는 제품을 만드는 사람입니다. 그렇기에 특정 개발을 해야 하는 이유를 납득할 수 있다면, 요구사항에 걸맞은 결과물뿐만 아니라 코드의 품질도 달라지게 됩니다. 더 유연하고 미래의 상황에도 유연하게 대응되는 아름다운(?) 코드들이 나올 수 있을 거예요 :)
그렇기 위해선 본인이 이 기능을 개발해야 하는 이유 그리고 어떤 임팩트를 줄 수 있는지 꼭 알고 있어야 합니다. 만일 본인만 알고 있다면 이를 제품으로 구현하는 사람들에게도 꼭 알려줘야 합니다. 저의 경우 개발자와 제품 회의를 할 때 "왜 이것을 개발해야 하는지"를 가장 강조하는 편입니다. 결과적으로 고객들에게 임팩트를 줄 수 있는 제품을 개발한다는 건 대부분에게 기분 좋은 일이기 때문이죠.
만일 WHY 부분이 명확하지 않다면, 곰곰이 정의해 볼 필요가 있습니다. 이 태스크는 왜 개발되어야 하는지 그리고 고객(혹은 팀원들)에게 어떤 영향을 끼칠 수 있는지 말이죠.
[4] 정리
크게 3가지 관점에서 문제를 다뤘습니다. 한 번 정리해 보겠습니다.
1. 본인의 아이디어가 구현되는 과정, 개발 프로세스를 이해하라.
2. 본인이 요구하는 내용들은 최대한 구체적이어야 한다. 그럴수록 중간 커뮤니케이션 코스트는 줄어든다.
3. 왜 이를 개발해야 하는지, 개발하면 어떤 임팩트가 있는지를 정의하고 공유하라.
결론
내가 무슨 말을 했느냐가 중요한 것이 아니라,
상대방이 무슨 말을 들었느냐가 중요하다
피터 드러커 형님
사실 이 내용은 개발자와 비개발자의 커뮤니케이션뿐만 아니라 요구하는 자와 구현하는 자의 커뮤니케이션에 해당되는 이야기라고 생각합니다. 사람이 소통할 때 드는 로드(Load)가 5:5로 공평하다고 생각하지 않습니다. 얻고자 하는 것이 있을 때 조금 더 신경 쓴다면 결국 더 나은 결과로 돌아올 거라고 믿습니다
개발자도 마찬가지로 커뮤니케이션을 신경 써야 한다고 생각합니다. 단순히 "안된다"라고 하기보단 안 되는 이유와 함께 조금 더 이해하기 쉽게 이야기하면 결국 서로에게 좋은 시너지 효과가 날 거예요. 요구와 구현의 관계가 단순히 을과 갑에 머무르지 않았으면 좋겠습니다! 끝
