개발자가 소통을 더 잘해야 하는 이유
개발자에게 소통이 중요한 이유는,
위 그림과 같이 여러 직군과 소통을 해야 되기 때문이다.
그리고 그 소통을 한 결과로 제품을 만드는건 오로지 개발자에 몫이기 때문에,
소통을 잘해서 요구사항을 해결해나가야 하기 때문이라고 한다.
각각의 직군에서 요구하는 내용들이 서로 얽혀있기 때문에, 개발자는 소통을 하면서 전체적인 그림을 그릴수 있어야 된다고 생각한다.
(목적없이는 발전할 수 없다. 아직 주니어인 내가 전체적인 그림을 그릴수는 없겠지만, 소통을 하면서 여기 저기 얽힌것들을 고민해보는건 중요한것 같다)
함께 일하고 싶은 개발자가 갖고 있는 소통 노하우
-
한줄의 코드도 소통의 결과로 만든다.
음 나는 세부적인 설명을 듣고 "소통의 결과로 코드를 작성해라"로 이해를 했던것 같다. "문제의 본질을 파악해야 된다" 라고 말씀 해주셨는데, 예로 배민의 프로젝트에 대해 말씀하셨다. 배민에는 배달 늦게 오는것 같아요 라는 피드백이 자주 왔는데, - 배달이 늦게 오는거 같으면 식당이 빨리 음식을 만들어야지 - 배달이 늦게 오는거 같으면 배달 해 주시는 분들이 빨리 이동해야지 라는 생각이 아니라, 늦게 오는것 "같아요" 라는 것에 초점을 두고, 문제의 본질이 심리적 요인이라는걸 파악하여 주문 관제 시스템을 개발하고 사용자한테 지금 음식이 만들어 졌다, 이제 출발한다 등의 정보를 제공함으로써, 문제를 해결했다고 한다. 이처럼 소통을 통해 본질을 파악하고 그 결과로 코드를 작성해야 된다는 말씀이였다. --- 이 때 문제의 본질을 파악하는 방법을 익히려면 기술블로그 운영을 잘하는 회사의 글들을 확인하면 된다. 프로젝트를 잘 정리해놓고 이 프로젝트를 왜 진행했는지에 대해 써있는걸 읽어보라고 하셨다. -
기술적 지식을 이해하기 쉽게 설명한다.
그냥 안되요 라고 설명하게 된다면, 다음 소통을 하기 전에 다른 사람이 해결 방법을 찾을수 없다. 그건 소통을 혼자하는것과 다름이 없기 때문에 안되는 기술적 이유를 이해하기 쉽게 설명해야 한다. 그래서 평소에 전문적인 기술을 더 많이 탐구하고 이해해서, 내가 잘 설명할 수 있게끔 미리 준비하는게 중요하다고 하셨다. 개발자에게 업무 외적으로도 전문지식을 습득하기 위한 꾸준한 노력이 필요한 이유 인 것 같다.이 외에도 과정 중심적 사고에 대해 말씀해주셨는데, 느끼는 점이 많았다. 일반적으로 포트폴리오를 쓸때 결과만 쓰게 되는데 그건 과정 중심적 사고로 개발하지 않았다는게 된다고 하셨다. 과정 중심적 사고란, 1. "기술적 문제"를 만나고 2. 여러 "고민"을 하게 되고 3. 고민 중 하나를 선택해서 "시도"하게 되고 4. 이 과정을 반복하면서 얻은 "결과"가 나오게 된다. 이런 과정들을 생각하면서 포트폴리오를 작성해야 되고, 기술적 지식을 이해하기 쉽게 설명할 수 있다면, 더 많은 고민을 할 수 있기 때문에, 같이 생각해보면서 고민해보면 좋을 것 같다. 취업을 준비하면서 결과만 적은 내 이력서를 생각해보니 더 공감이 되는것 같다. -
협업안에서 문제를 해결한다.
회의 때 타직군이 제시한 문제를 듣고 따로 개발자끼리 모여서 어떻게 해결할 지 이야기 하는것이 아니라, 타직군과 함께 소통하면서 해결하기 위한 노력을 해야 된다는 말씀이었다. 개발자 답게 소통하는 법 - 1 에서 첫번째 내용 중에 언급했던 전략팀장님이 사용했던 방식인데, 문제를 만났을 때, 먼저 각각 의견을 들어본다. 그러면 의견을 듣고 직군에 관계없이 새로운 아이디어가 나오게 되고, 다시 한번 의견을 공유하게 되면서 정답(?)에 가까워 지도록 소통했었다. (물론 답이 잘 안나올때도 있었지만, 그러면 다음 회의까지 각자 찾아보고 다시 소통하는 방식으로 진행을 했다) 이런게 소통의 이점이고, 협업안에서 문제를 해결하는것 같다. -
의도를 이해할 수 있는 코드를 준비한다.
개발자끼리 회의 할때, 코드를 보며 이야기를 나눌 때도 있는데, 이때 내 의도를 이해 할 수 있는 코드를 준비하는것도 소통 능력이라고 하셨다. 실제로 개발하기 바쁜 스타트업에서 몇번 하지는 않았지만, 코드 리뷰를 할 때, 급하게 참석해서 준비를 별로 안했을 때는 이곳 저곳 이동하면서 확인을 했었는데 의도를 이해하기 편하게 준비를 해보니 회의가 원활하게 진행 되었다. 그래서 더 평소에 코드를 작성할 때 가독성을 신경쓰려고 노력하는것 같다. -
완성도와 동료를 배려한 일정을 제안한다.
내가 맡은 기능의 완성도를 고려하는것은 기능을 개발을 하고 테스트까지 어느정도 완료되는 시기를 생각해야 되는것 같다. "내일까지 됩니다"의 말은 "내일까지 기능 개발됩니다" 라는 말이 아닌, "내일까지 기능 개발하고 테스트 진행하고 QA 할 수 있게 준비할 수 있습니다." 라는 말이라고 생각한다. 그래서 내 일정을 생각할 때는 완성도를 고려해야 된다. 그리고 동료를 배려하는 것은, A개발자가 기능을 개발하고 B개발자가 그 기능을 사용해서 개발을 해야된다고 했을때, B개발자는 A개발자의 개발 기간을 배려해서 개발일정을 선정해야 된다. 나는 평소에 배려해서 일정을 선정한다기 보다는, 누구보다 자신의 능력은 자신이 잘 안다고 생각하기 때문에 선행되는 개발이 있을 때 물어보는 편이였다. 언제까지 완료되는지 일정을 물어보고 그 뒤에 내 작업에 대한 일정을 붙여서 말을 했었다. 이렇게 하면 잘못 선정해서 완성도가 떨어져 일정이 지연 되더라도, 고려하지 않은 상황보다는 훨씬 일정에 맞추기 수월했던거 같다. --- 사실 일정을 산정하는것이 절대 쉽지 않고, 나도 아직 잘 몰라 여유를 두고 말하는 편이다. 근데 이번 세미나에서 일정을 산정하는 훈련 방법을 알려줬는데 좋은 방법인것 같다. 방법은, 프로젝트마다 회고를 하는 것이다. 회고를 할 때 가장 먼저 할 것은 일정에 대한 회고를 먼저해야 되는데, - 이 일정이 동료에 대한 배려가 있었는지? - 이 일정이 적당했는지?(완성도와 능력에 대한 파악이 제대로 되었는지) 를 꾸준히 회고 하다보면 훈련이 된다고 한다. -
요구사항을 쌓을 수 있는 조각으로 만든다.
문구가 추상적이라, QnA 시간에 여쭤보려고 했는데 다른분이 먼저 용기를 내서 물어봐주셨다. 말씀해 주신 내용은 마케터나 기획자, 디자이너 등 여러 직군과 소통을 하면서 같은 것을 바라보는 소통이 될수 있도록 의견들을 일치시키면서 소통을 해야된다고 하셨다. 음... 내가 겪은 상황에 빗대어 생각해보면, 1분 30초마다 반복되는 코인차트를 보여주고, 가격을 예측 하는 서비스를 개발했는데 기획에서는 반복되는 사이클을 한 화면에 보여주면 가격 변동이 한번에 보여서 좋을것 같다. 라고 말씀해주셨고, 디자인에서는 확대해서 30초 구간이 이동하는식으로 디자인을 준비했다, 초마다 그래프가 바뀌는데, 예측한 사람의 대한 정보를 표현하면 너무 다닥다닥 붙어있기 때문이다. 라고 말씀해주신 상황에서 의견이 서로 상반되기 때문에 셋이 함께 회의를 하자고 제안했고, 하나의 의견으로 일치 시켰던 경험이 있었다. 이런걸 말씀하신거라고 생각한다. -
비난이 아닌 비판적 사고로 회고한다.
비난과 비판에 대한 차이를 말씀해주셨다. 비난은 "그거 아니잖아"와 같은 기준 없은 지적이며, 비판은 지금 상태에 대해 옳고 그름을 판단해서 잘못을 지적하는 것이라고 한다. 논리적인 근거를 가지고 비판하면 좋을거 같다. 비판적 사고력을 키우기 위해서는 분석을 많이 해봐야 한다고 하셨다. 개발을 하며 만나는 여러가지 내용들을 분석해봐야겠다.
마지막에 너무 공감되는 말을 해주셨다.
소통을 잘하는 사람은 평소에 고민을 많이 한다.
고민하고 있는 내용을 시도하고, 시도한 결과를 만든다.
소통을 못하는 사람은 평소에 걱정을 많이 한다.
걱정만 많이 하는건 결과에 아무것도 만들지 못한다.
내가 평소에 너무 걱정만 하지 않았나 되돌아보는 문구였고,
앞으로는 어떻게 하지? 보단, 이거 해결하려면 어떻게 하지? 라는 생각을 많이 하는 개발자가 되야겠다.
마지막으로 "장준"님께서 정의한 건강한 소통의 3가지 이점은
건강한 소통은
- 정확한 의사결정의 능력을 만듭니다.
- 필요한 협업의 결과를 만듭니다.
- 회사의 비즈니스 가치를 책임집니다.
였고 유익한 시간이였던거 같다.
제가 참고하기 위해 만든 블로그라 글을 편하게 작성했습니다. 틀린거 있다면 댓글 부탁드립니다.