2021. 2. 28. 04:43ㆍA 의 공부/Insights
기획자 북 스터디를 통해 매달 관련 서적을 읽는 중입니다. 두 번째 서적은 최원영님의 비전공자를 위한 이해할 수 있는 IT 지식입니다. 후에 참고할 수 있도록 주요 레슨을 제 생각과 함께 정리합니다.
지난 리뷰 서적: (사용자를) 생각하게 하지 마! - 스티브 크룩
Lesson 1. 커뮤니케이션을 위한 노력
IT 산업에서 일하는 기획자에게 가장 먼저 필요한 건 '파이썬'이나 '자바'가 아닙니다. 바로 '커뮤니케이션'입니다. (기획자는) 모든 구성원과 원활하게 대화할 수 있어야 합니다 ... 그래서 '커뮤니케이션을 위한 IT 지식'을 공부해야 합니다.
기획이나 PM 직무에 있는 모든 분의 공감을 살 수 있는 문장이라고 생각합니다. 기획은 모든 이해 관계자 협업의 중심이고 협업의 중개인입니다. 서비스 개선을 위한 판단을 내리는 것이 기획 업무의 한 꼭지라면, 다른 하나는 사내 커뮤니케이션에 사용되는 리소스를 최소화하는 역할을 하는 것이라 믿습니다.
사내의 이해 관계자는 모두 다른 언어를 사용합니다. 사업 / 마케팅 / 고객관리 / 기획 / 개발 그리고 디자인. 하나의 프로젝트를 완성하고 운영하는 데 필요한 각 부서들은 각자의 전문성을 가지고 있고, 그 전문성만큼이나 다른 언어를 사용합니다. 분야의 전문 용어는 부서내 업무 커뮤니케이션에 효과적이지만 은어적 성격을 가지고 있어 다른 부서와의 협업에는 허들이 됩니다.
그 허들을 넘기 위해 우리는 각 분야의 기초 지식을 필요로 하고, 이 책은 '개발'과 협업하기 위한 기초 지식을 습득하는 데 아주 효과적입니다. API 문서를 읽고 그 API 를 활용해 무엇을 할 수 있는지 안다면, 또 프로덕트에 문제가 생겼을 때 누구(서버 or 클라이언트)와 대화해야 하는지 알 수 있다면 충분합니다. 이해하는 만큼 적확한 표현으로 자신의 의견을 전달할 수 있고 기획의 전문성을 인정받을 수 있습니다.
책에서는 개념을 이해하고 개발자와 대화하는 것을 목표로 하였지만, 만약 이해한 개념을 다른 구성원이 쉽게 이해할 수 있도록 풀어내는 노력을 한다면 보다 경쟁력 있는 기획자가 될 것이라 생각합니다. 각 부서의 언어를 서로가 이해할 수 있는 방식으로 해석해 전달하고 설명할 수 있다면 그만큼 커뮤니케이션 비용은 최소화되고 리소스가 프로덕트에 집중될 수 있습니다. 각 분야의 전반적인 이해도를 높인 이후에, 리소스를 할애할 수 있다면 모두가 참고할 수 있는 일종의 용어 사전(glossary)을 만드는 것도 좋을 듯합니다.
Lesson 2. API 이해도
API 문서를 읽고 이해할 수 있다는 것은 협업하는 사람에게 많은 것을 묻지 않고도 스스로 진행 상황을 파악할 수 있다는 의미입니다.
이 책을 읽고 하나 얻어가야 하는 것이 있다면 분명 API 문서 혹은 API 명세를 읽는 방법일 것입니다. 모든 API 가 문서화되어 있고, 에러코드를 비롯해 기획자가 참고할 만한 정보가 잘 정리되어있는 조직은 드물겠지만 제한된 정보라고 해도 그 일부를 파악한 기획자와 아닌 기획자에게는 큰 차이가 있습니다.
사실 위의 문장에 적힌 것처럼 API 문서를 읽는 것을 통해 개발의 진행 상황을 파악하기란 쉽지 않습니다. 미완성된 API 문서를 실시간으로 확인하기는 어려울뿐더러 문서만으로 완성도를 기획이 판별하기란 불가능에 가깝습니다. 하지만 API 리스트를 아는 기획자는 지금 가지고 있는 API로 무엇을 할 수 있고, 무엇을 할 수 없는지 판단할 수 있습니다. 새로운 기능을 추가할 때, 기존 API를 일부 활용할 수 있다면 개발에 소모되는 리소스를 줄일 수 있고 현재 상황에서 완성할 수 있는 최선의 스펙을 고안할 수 있죠. 자신이 기획한 스펙을 개발하기 위한 리소스를 가늠할 수 있다면, 리소스 분배 역시 효율적으로 할 수 있게 됩니다.
CS 대응 혹은 버그 수정에도 API 이해도는 도움이 됩니다. 버그가 일어난 기능에 사용된 API 가 무엇인지 분별해내고, 담당 개발자가 누구인지 빠르게 추적할 수 있다면 그만큼 이슈 해결은 빨라집니다. 웹 서비스의 경우 개발자 도구를 통해 API 응답에 포함된 에러코드도 확인할 수 있습니다. 만약 에러코드가 잘못 내려오고 있다면 서버에게, 에러코드가 잘 내려오고 있지만 사용자에게 안내되는 메시지가 잘못되었다면 클라이언트 개발자에게 버그 수정을 요청합니다. 정확한 담당자에게 이슈 확인을 요청할수록 이슈 해결을 위한 커뮤니케이션 비용은 줄어듭니다.
한 기능에 사용되는 API 가 여러 개인 경우도 많기 때문에 모든 API 들을 완벽하게 숙지하는 것은 불가능합니다. 다만 API 리스트를 자주 확인하고, 필요시 어디에서 API 문서들을 확인할 수 있는지 안다면 분명 기획자로서 경쟁력을 가지게 될 것이라 확신합니다. 기능별로 사용되는 API 들을 별도로 정리해두는 노력까지 한다면 프로젝트에 기여할 수 있는 정도도 높아지게 될 것입니다.
Lesson 3. 툴에 대한 이해도(feat. 깃과 제플린)
개발자와 디자이너는 서로의 분야에 대한 공부가 필요합니다. 상대에 대한 배려가 더해진다면 더 좋겠죠.
이 책에 대해 인상 깊었던 부분 중 하나는 개발자의 툴인 깃(Git)과 디자이너의 툴인 제플린(Zeplin)에 대해서 간략하게나마 설명을 곁들였다는 것이었습니다. 분야의 지식에 대한 이해도를 높이는 것과 별개로 툴에 대한 이해 역시 협업에서 큰 차이를 만들어냅니다. 다른 이해 관계자가 어떤 툴을 사용하는지 알면, 그들이 어떤 방식으로 일하는지 알 수 있고 그에 맞춰 피드백을 하거나 협업하는 것이 가능합니다.
저의 경우에는 디자이너는 아니지만 어도비 XD 툴과 제플린을 다룬 경험이 있기 때문에, 협업 과정에서 제플린에 누락된 부분이 있거나 에셋이 등록되지 않은 경우가 있다면 개발자가 별도 확인요청을 하기 전에 디자이너와 피드백을 하는 편입니다. 자주 하지는 않지만 깃에 개발 담당자가 정리한 세부 개발 항목(To Do List)을 확인하고 설계서를 개선할 부분을 찾을 때도 있습니다. 툴을 완벽히 사용하지는 못하더라도, 다른 협업자들의 툴을 조금 이해하고 활용할 수 있다면 그것만으로 기획자는 성장할 수 있습니다.
저자는 개발자와 디자이너가 서로의 분야에 대해 공부하고 배려해야 한다고 적었지만, 기획자 역시 그 사이에 들어가 있어야 함은 분명합니다. 어디까지나 기획은 프로덕트의 오너십을 가지는 직무이며, 개발 및 디자인과 가장 밀접하게 소통해야 하는 역할이기 때문이죠. 분야의 이해도와 툴의 이해도를 모두 높이다보면 기획자로서의 전문성 역시 공고히 할 수 있으리라 믿습니다.
레슨과 별개로 이 서적에서 설명한 주요 개념들(API, 클라이언트, 서버, SDK 등)에 대해서는 언젠가 블로그를 통해서도 한 번씩 설명하도록 하겠습니다. UX 요소 공부 내용을 정리하는 것처럼 양질의 콘텐츠를 작성할 수 있도록 노력하겠습니다.
BOOK INFO
책이름 : 비전공자를 위한 이해할 수 있는 IT 지식
지은이 : 최원영
#개발과의 커뮤니케이션을 위한 PM 필수 지식
※ 주요 개념 이해에 도움이 되는 일부 목차를 따로 적어둡니다.
•3장 네트워크, 클라이언트, 서버
• 3-2. 한강에서 카카오톡을 다운로드하고, 실행하면 일어나는 일들
• 4장 API와 JSON
• 4-1. POST는 뭐고, GET은 뭐죠?(feat. 개발자의 암호문)
• 4-2. 요청과 응답을 주고받을 때의 형식
• 4-3. API 문서 살펴보기
• 5장 애플리케이션
• 5-1. 설치한 뒤 실행하는 애플리케이션의 특징
• 6장 웹(Web)
• 6-1. 웹은 어떻게 이루어져 있고, 어떻게 동작할까?
• 6-2. 웹 개발하다가 못해 먹겠다고 말하는 이유
• 6-3. 반응형으로 코딩하면, 더 비싸나요?(그게 뭔데요?)
• 6-4. 애플리케이션 이야기를 하는데, 왜 자꾸 웹 개발자에게 말하라는 거죠?
• 7장 데이터베이스와 이미지 처리
• 7-2. 클라가 들고 있다는 게 뭐죠?("클라에 저장돼요. 클라가 가지고 있어요")
• 7-3. 배너 좀 바꾸려는데, 자꾸 자기한테 말하면 안 된대요. (왜 자꾸 사람이 바뀌는 건데…)
'A 의 공부 > Insights' 카테고리의 다른 글
| [PM 서적 리뷰] 규칙 없음 (넷플릭스) (1) | 2021.03.31 |
|---|---|
| [UX 서적 리뷰] (사용자를) 생각하게 하지 마! - 스티브 크룩 (0) | 2021.01.28 |