개발 협업이 어려운 기획자를 위한 가이드북
오늘도 개발자가 안 된다고 말했다
오늘도 개발자가 안 된다고 말했다
오늘도 개발자가 안 된다고 말했다(저자: 김중철,김수지 / 출판: 디지털북스 / 발매: 2021.03.25.)이 책을 읽어야 하는 이유
PM 부트 캠프를 하면서 처음부터 끝까지 강조되었던 단어들 중 하나가 바로 '협업'이다. 부트 캠프에서만이 아니라 PM과 관련된 JD를 보면 역시 협업에 능한 사람을 찾고 있다는 것을 알 수 있다.
'사람 사는 곳이 다 똑같지 도대체 IT의 협업은 무엇이길래 이렇게 협업이라는 것을 강조하고 있을까'하는 궁금증이 계속 커질 무렵, 부트 캠프에서 서비스를 개발하면서 느낀 협업의 중요성과 어려움을 몸소 체험하고 있다. 목적어는 같았지만 다른 표현 때문에 서로 다른 이야기를 하고 있다고 생각했고, 업무와 관련된 이야기가 다소 상대방에게 상처를 줄 수 있음을 알게 되었다. 우리는 같은 이야기를 하고, 같은 목표를 가지고 있는데 왜 이런 불편한 일들이 발생했던 걸까.
책 제목에서부터 나의 궁금증 채워줄 것이란 확신을 강하게 주었던 '오늘도 개발자가 안 된다고 말했다'가 나의 커다란 물음표를 줄여주는 데 도움을 주었다. '안 된다'라고 하는 부정적인 답변 속에 회사와 직원들의 여러 가지 의미가 내포될 수 있고, '된다'라고 하는 긍정적인 답변도 생각보다 긍정적이기만 하지 않다는 것을 이 책을 통해 알 수 있었다. 더불어 중요한 것은 기획자라면 응당 알아야 하는 IT 지식과 협업이 필요한 정보들을 습득할 수 있다는 것이 가장 좋은 부분이었다. 한 마디로 표현하면 PM으로써 해야 할 일들을 머릿속에서 그려볼 수 있게 해주는 책이었다.
우리가 협업을 할 수 있었던 이유
무식하면 용감하다는 말이 있듯이 아무것도 몰랐기 때문에 개발자의 말에 더 경청할 수 있었고, 이해되지 않는 내용은 질문을 반복하면서 협업을 위해 알고 있어야 하는 정보가 무엇인지 빠르게 학습할 수 있었다.
특히 협업을 잘하고 싶어서 개발 언어를 공부하고 있는 사람이라면 다시 한번 고민해 볼 필요가 있다. 개발 언어를 배워도 직접 개발하지 않으면 금방 잊어버리고 이직을 할 때는 개발 언어도 업그레이드되어서 새로 배워야 할 가능성이 높다. 그러므로 공부를 시작하기 전에 개발자에게 질문을 하고 협업에 필요한 개발 지식을 우선 학습하는 것이 좋다.
안 된다는 말을 달고 사는 개발자안 된다는 말을 달고 사는 개발자
개발자들이 안 된다고 말하는 이유를 파악할 수 있다면 얼마든지 원활하게 협업을 할 수 있다. 여기에서는 '개발자의 부정'에 대한 대표 유형 3가지를 이야기해 보려고 한다.
첫 번째는 서비스 구조를 고려하지 않고 개발을 요청하는 경우다.
두 번째는 안정성에 영향을 주는 개발 건을 요청하는 경우다.
세 번째는 쌓인 일이 많을 때 개발을 요청하는 경우다.
무엇이든 가능하다고 말하는 개발자무엇이든 가능하다고 말하는 개발자
무한 긍정형 개발자와 협업을 할 때도 주의해야 할 점이 있다.
첫 번째는 기능의 구현 가능 여부만 놓고 대답하는 경우이다.
두 번째는 자신이 담당한 업무만 한정 지어 생각하고 가능하다고 말하는 경우가 있다.
따라서 모두 가능하다고 말하는 개발자와 협업할 때는 항상 조건들을 확실하게 붙여서 요청을 해야 한다. 이 유형의 개발자는 있는 그대로 보면서 개발하기 때문에 이상하다고 느껴지거나 부족한 부분을 따로 이야기해 주지 않는다.
대안을 제안하는 개발자대안을 제안하는 개발자
문제를 미리 발견하고 피드백을 주거나 대안을 제시해 주는 제안형 개발자가 있다. 보통 경력직인 경우가 많고, 협업 경험도 풍부하다.
이런 개발자를 만나면 신입 기획자/디자이너도 마음 편하게 일할 수 있다. 부족한 부분을 지적하기보다 채워주기 위해서 노력한다. 안 되는 이유도 하나씩 차근차근 설명해 주기 때문에 서비스를 이해하는 것도 훨씬 수월하다.
서비스 기획의 범위
첫 번째로 [대상에 따른 변화에 맞는 목적 확인]은 서비스의 비즈니스 방향을 찾는 단계로 볼 수 있다. 두 번째로 [목적을 성취하기 위한 적합한 행동 찾기]는 앞서 발견한 방향성과 목적과 맞게 구체화할 방안을 찾는 단계이다. 마지막으로 [설계하기]는 스케치를 실제 산출물로 만드는 단계이다.
서비스 기획자는 서비스의 방향성에 따라 목적과 기준을 정하고 구체적인 실행 방법을 설계하고 제안하는 역할인 것이다. 그렇기 때문에 누구보다 비즈니스에 대한 이해도가 높아야 하며 사용자 니즈 파악은 물론, 다양한 분석을 통해 문제를 발견하고 해결하는 능력까지 고루 갖춘 팔방미인이 되어야 한다.
이유와 기준이 있는 기획
협업을 할 때 기획자는 팀의 목표 달성을 위해 생각한 방법을 주장하고 구성원의 동의를 얻는 과정을 반복하게 된다. 기획자에게 있어 이유와 근거는 항상 우리 서비스와 고객에서부터 시작해야 한다. 협업의 기준을 잡는 가장 중요한 방향점은 회사의 성장이다.
서비스 구조를 쉽게 이해하는 방법
협업을 잘하기 위해서는 서비스 전체를 볼 수 있는 IA(Information Architecture)를 작성할 수 있어야 한다. 먼저 IA를 작성하기 위해서는 기능들을 구체적으로 리스트업 해야 한다. 참고로 기능 목록을 작성할 때는 눈에 보이는 메인 화면뿐만 아니라 보이지 않는 관리자 페이지까지 고려해야 한다.
기능 리스트업이 끝났으면 해당 기능들을 토대로 구조화를 시작한다. MECE(Mutually Exclusive Collectively Exhaustive)는 '항목들이 상호 배타적이면서 모였을 때는 완전히 전체를 이루는 것'을 의미하는데, 맥킨지에서 문제 해결 기법으로 사용하는 유명한 전략적 사고 기법이다.
하이라키(Hierarchy)는 상하 위계 구조를 의미하는데 각각의 정보들이 부모-자식 관계를 갖는 구조화된 형태를 말한다. IA에서 하이라키 위계는 Depth 또는 Level로 구분한다.
플로우차트(Flow Chart)플로우차트
(Flow Chart)
플로우 차트 또는 순서도는 사용자가 사용하게 될 서비스 화면과 프로세스의 흐름을 도식화한 것이다. IA가 전체 서비스의 구조를 볼 수 있는 것이라면 플로우 차트는 도식화를 통해 사용자의 행동 흐름을 직관적으로 파악할 수 있다. 서비스 사용 시에 발생할 수 있는 경우의 수를 고려하면서 작성하는 것이 핵심이다.
화면 설계서를 작성하는 이유화면 설계서를 작성하는 이유
화면 설계서는 개발 진행 시에 발생할 수 있는 이슈나 정책 보완점을 미리 고려하고 문제 발생 시에 다른 우회 방안을 찾는 등 협업자들의 의견을 수렴하고 개선하는 커뮤니케이션을 위한 문서다.
목적을 명확하게 전달하는 방법목적을 명확하게 전달하는 방법
설득력 있는 문장을 작성하려면 먼저 개발 요청 기능을 정의하고 제공 대상을 쓴다. 그리고 해당 기능을 제공해야 하는 이유와 목적을 쓴다. 그다음, 제공 이유에 대한 예시를 근거로 들어 논리를 뒷받침하고 무엇이 좋아지는지 기대효과를 쓴다.
설계 타이틀의 중요성설계 타이틀의 중요성
타이틀은 설계의 목적을 함축적으로 담는 가장 중요한 메시지다. 그리고 이 타이틀을 통해 개발의 범위를 예상한다. 설계서를 작성하기 이전에 앞서 잡은 설계의 목적을 토대로 설계서의 타이틀을 적어놓고 시작해야 한다. 이렇게 하면 단순히 전달을 위한 것뿐만 아니라 방향성이 정해지기 때문에 기획의 범위를 잡는 데 많은 도움을 얻는다.
디자인 기획 의도와 목적디자인 기획 의도와 목적
디자이너 사이에서 모두 공감할 수 있는 고충으로 "예쁘고 화려하고 심플하고 고급스럽게 해주세요."라는 말이 있다. 이 말이 어려운 이유는 사람마다 생각하는 예쁨, 화려함, 심플함, 고급스러움의 기준이 다르기 때문이다. 가장 중요한 목적을 잃고 디자인을 하면 "왜 이렇게 디자인했어요?"라는 말에 대답하기 어렵다. 프로젝트의 목적, 기획자의 의도, 서비스를 사용하는 대상자를 떠올리고 설득할 수 있는 디자인을 하는 것이 중요하다.
웹/앱 디자인과 UX/UI 디자인웹/앱 디자인과 UX/UI 디자인
UX/UI 디자인에 정답은 없지만, 사용자에게 편리한 디자인과 불편한 디자인은 존재한다. 편리함과 불편함의 차이는 디자이너의 단순한 감으로 디자인을 하는 것이 아닌 수많은 데이터 수집과 분석, 사용자 테스트 등으로 객관적으로 판단을 함에 있다.
