[책 리뷰] 오늘도 개발자가 안 된다고 말했다.
개발자와 어떻게 소통해야하는지 궁금하신가요?
✅ 책 소개
이 책은 IT업계에 종사하고 있는 기획자, 디자이너가 개발자가 협업하면서 느꼈던 내용을 소개하는 책입니다. 막 IT업계에 발을 들인 사람이라면 필연적으로 개발자와 마주치기 마련인데요, 개발자, 기획자, 디자이너는 분명 같은 프로덕트를 작업하고 있지만 업무방식과 사고방식이 다르다는 걸 느꼈을 것입니다. 그 다름으로 인해 의사소통이 힘들었고 업무가 진척이 되지 않았던 던 경험이 분명 있었을 텐데, 이 책에서는 그 원인은 경험을 바탕으로 설명하고 어떻게 해결해 나갔는지 소개하고 있습니다. 이 글에서는 기획자 중심의 내용을 소개할 계획입니다.
✅ 주요 내용 [ P1 ~ P50 ]
1️⃣ 개발자와 어떻게 의사소통 할 것인가?
이 책은 기획자와 개발자 간의 커뮤니케이션이 프로젝트의 성공에 매우 중요하다는 것을 설명하고 있습니다. 이 중요한 커뮤니케이션이 어긋나는 가장 큰 이유는 개발자의 관점에서 이해되지 않는 기획서를 주요 원인으로 설명하고 있습니다. 단순히 개발자에게 이렇게 해주세요, 이런 작업을 하면 됩니다라고 하는 단순한 명령서와 지시서와 같은 기획서는 소통의 어려움을 불러옵니다. 기획자가 만드는 기획서는 개발자에게 어떤 작업을 수행하는 명령서, 지시서가 아닌 개발자와 소통하기 위한 커뮤니케이션의 도구로 생각해야 된다고 말하고 있습니다.
즉, 기획자는 개발자에게 이 작업을 왜 진행해야 하는지, 어떤 근거가 있는지 전달하고자 하는 의도가 명확하게 드러나야 비로소 개발자와 커뮤니케이션이 가능하다고 말합니다.
2️⃣ 개발자의 언어를 이해하는 방법
반대로 개발자는 개발과 관련된 언어소통방식을 가지고 있는 게 대부분입니다. 기획자가 개발자의 언어를 이해하지 못해 어려움을 겪는 건 흔한 사례입니다. 개발자가 사용하는 각종 전문용어로 인해 소통이 어렵다면 프로덕트의 성공이라는 공통의 목표를 향해 나아가기 힘듭니다. 따라서 이 책에선 기본적인 개발 구조에 대한 공부가 필요하다고 말합니다.
단, 주의할 것은 개발할 수 있는 능력이 아닌 개발이 이루어지는 과정을 이해하고 구조를 이해해야 한다고 말합니다. 그 이해를 바탕으로 기획자는 본인만의 언어로 재해석해서 이해할 수 있어야 합니다.
3️⃣ 개발자가 안 된다고 말하는 이유
개발자마다 성향이 다르기 때문에, 개발자가 '안된다’고 하는 뜻의 내포된 숨은 뜻을 잘 해석할 수 있어야 합니다. 이 책에서는 두 가지 개발자를 예를 들어 설명합니다. 어떤 작업이던 일단 개발이 가능하다는 개발자와 어떤 작업이던 일단 불가능하다고 말하는 개발자입니다.
언뜻 봐서는 어떤 작업이던 불가능하다고 말하는 개발자를 부정적으로 바라보기 쉽습니다. 하지만 이 불가능이 내포하고 있는 숨은 뜻을 잘 해석할 수 있어야 합니다.
개발자가 안 된다고 말하는 숨은 이유를 이 책에서는 다음과 같이 설명하고 있습니다.
- 개발을 할 수 있는 자원과 시간은 한정적이기에 모든 요구사항을 들어줄 수 없다.
- 이전에 발생하지 않았던 문제를 일으킬 가능성이 높아 많은 공수를 야기할 가능성이 있다.
개발자는 사실 무조건 안 된다고 말하는 것이 아닌 위 내용을 모두 고려하여 부정적인 의견을 표출하고 있을 뿐입니다. 언뜻 기획자가 요청한 추가 기능이 서비스의 높은 성장을 불러올 것 같거나 단순한 작업처럼 보이지만 개발자의 입장에서 바라보면 내면에는 많은 불안 요소가 잠재되어 있습니다.
기획자는 이러한 불안 요소를 고려한 기획서를 작성할 수 있어야 합니다. 이러한 잠재적인 불안요소에도 불구하고 이 서비스가 가져다주는 가치가 높다면 그 가치에 대해 설명하고 개발자를 설득할 수 있는 기획서를 작성해야 합니다. 또한 개발자는 이미 많은 개발 건을 작업하고 있을 가능성이 높습니다. 개발자들이 현재 진행하고 있는 작업을 고려하고, 우선순위를 파악하는 것 또한 중요하다고 말합니다.
위 내용을 바탕으로 결국 기획자는 개발자들이 고려하고 있는 잠재적인 불안 요소가 반영되고 서비스에 가져올 높은 가치에 대해 설득력 있는 기획서를 통해 개발자와 커뮤니케이션해야 합니다.
결국 개발자도 모두 회사의 성장을 위해 좋은 서비스를 만들겠다는 생각을 공유하고 있습니다. 이런 관점에서 개발자와 커뮤니케이션을 할 수 있다면 좋은 협업 관계를 발전시킬 수 있을 것입니다.
4️⃣ 개발자에게 하면 안 되는 말
이 책에서는 개발자에게 하면 안 되는 말을 3가지 소개하고 있습니다. 예를 들어 “간단한 거죠? 일단 해주세요”, “언제까지 개발해 주세요”, “타 서비스는 되던데?” 등이 있습니다.
이러한 말들은 개발자를 존중하지 않고 있다는 오해를 불러올 수 있습니다. 개발자는 요청하는 일을 단순히 처리해 주는 사람이 아닙니다. 협업하는 관계는 서로의 다양한 의견을 듣고 조율하는 는 과정을 통해서 완성됩니다.
따라서 기획자와 개발자 간의 원활한 커뮤니케이션을 위해서는 서로의 입장을 이해하고 존중하는 것이 중요합니다.
이 밖에도 이 책에서는 다음과 같은 내용을 소개하고 있습니다.
기획자로서의 서비스기획을 어떻게 바라볼 것인가?
기획자/디자이너/개발자의 일
기획자가 작성하는 기획서 : IA/목적이 있는 벤치마킹 방법/협업을 위한 화면 설계서
작성방법/의도를 명확히 전달하는 기획서의 조건
협업을 위한 기본 개발 지식과 생산성 있는 협업 툴 소개
현직 IT 종사자의 협업 사례와 인터뷰
현직에서 협업을 위해 어떻게 문서를 작성하는지 좋은 문서의 조건은 무엇인지 구체적인 사례와 함께 소개하고 있어 본인이 작성한 문서와 비교해 보며 좋은 내용은 직접 반영해 가며 읽어보면 큰 도움이 될 것입니다.
✅ 느낀 점
IT 업계에서 탄생하는 서비스는 절대 혼자서 만들어지지 않습니다. 많은 구성원들이 협업을 통해 만들어지고 좋은 협업을 위해서는 목표를 공유하고 다른 업무를 이해하는 것이 중요합니다. 이 책에서는 이러한 내용을 현직자의 관점을 살펴볼 수 있어 좋았습니다.
또한 협업을 잘하려면 나에 대해서도 잘 알아야 합니다. 나는 무슨 일을 하는지, 내가 무슨 기획을 하는지 생각해 보면서 책에서 소개하고 있는 좋은 협업 자세와 비교해 보며 나에게 적용하면 큰 도움이 될 것입니다.
하지만 이 책에서 소개하고 있는 내용을 맹신하는 것은 많이 위험하다고 생각합니다.(당연한 이야기지만) 협업의 업무는 회사마다 다르며, 서비스 비즈니스 기획 방향 설정에서 구체화할 방안 탐색, 실제로 산출물 생성되는 그 과정은 다양합니다.
예를 들어 이 책뿐만 아니라 많은 아티클에서 간혹 소개되는 작은 아이디어에서 출발한 아이디어를 어떻게 구체화하고 검증하는가에 대한 내용을 많이 찾아볼 수 있습니다. 하지만 저는 서비스가 아이디어에서 출발하면 안 된다는 의견이 개인적으로 있습니다. 아이디어에서 출발하는 기획은 Why가 아닌 What에 치중될 확률이 높습니다. 이러한 점을 경계하면서 본인에게 맞는 관점을 확립할 필요가 있습니다.
서비스가 시작되고 구현되고 완성되는 프로세스나 프레임워크는 회사, 기획자, 산업분야마다 모두 다릅니다.
이 책에서는 서비스가 어떻게 만들어지는지에 대한 설명이 있지만, 이를 공식처럼 이해할 필요는 없습니다. 또한 다양한 매체에서 소개하고 있는 서비스기획에 대한 내용과 프로세스의 정보가 과잉 습득된다면 부작용이 있을 수 있습니다.
본인에게 더 공감되고 자신의 관점을 어필할 수 있는 과정을 정립하는 것이 더 도움이 될 것입니다.
✅ 이런 분들에게 추천합니다
이제 막 IT업계에서 일을 시작한 사회 초년생입니다
나는 분명 기획자로서, 디자이너로서 일을 할 뿐인데 개발자가 날 싫어하는 것 같아요
개발자들에게 사랑받는 기획자, 디자이너가 되고 싶다.
나는 개발자인데, 기획자랑 디자이너가 어떤 일을 하는지 궁금하다.
