우리가 모인 첫날
협업툴 마림바이야기#08
#마림바 #협업툴 #비대면 #팀워크숍
팀원들이 속속 모이기 시작했다. 시간은 조금 걸렸으나, 모두가 기존의 업무에서 성공적으로 빠져나와 새로운 팀에 합류할 수 있었다. 이는 이 회사에서 일반적으로 일어나는 일은 아니다. 강력한 경영진의 스폰서십이 있어야 가능한 일이었다.
드디어, 제품 개발의 시작부터 끝까지 모든 액티비티를 수행할 수 있는 팀원들이 모였다. 기획, 디자인, 개발이 가능한 구성원들이 한 사무실에 앉아 있었다. 2명의 프로덕트 매니저, 2명의 디자이너 그리고 4명의 개발자가 새로운 사무실에서 짐을 풀고 있었다.
프로덕트 매니저는 다른 팀에서 개발하던 협업 내부 툴 도메인의 핵심적 역할을 해오던 인력들이 있었다. 이들은 시장에 대한 감각이 있었고, 제품에 필요한 기능에 대한 가치를 정의할 수 있었다.
디자이너들은 사용자의 피드백을 제품에 녹이고 서비스 디자인을 하는데 매우 익숙한 경험자들이었다. 개발자들은 프런트 개발, 서버 개발 및 클라우드 활용에 익숙하며 존과 오랜 기간 애자일, 린 스타트업 방식으로 함께 일해온 인력들로 구성되었다. 모두가 어디 하나 빠지지 않고 자신의 역할을 잘 소화할 수 있는 사람들이었다.
존은 이들과 함께라면 무엇이든 할 수 있을 것 같았다.
존은 당장 상품기획을 시작하고 싶었다. 그가 먼저 만든 아이디어가 실제 시장에서 가치가 있는 것인지 증명하고 싶었다. 하지만, 이제는 혼자가 아니라 팀으로 움직여야 한다. 그렇다면, 팀원 한 명 한 명이 이 일에 애정을 갖고 성과를 위해 노력할 수 있게 환경을 만들어야 한다.
가장 먼저 목표에 대한 공감대를 형성해야 한다. 왜 이 일을 하고 있으며, 우리가 어떠한 목표를 향해 가고 있는지 서로 이야기해야 한다. 이를 통해 예상 못한 문제가 발생했을 때 흔들리지 않는 목표와 함께 팀원들이 함께 문제를 해결할 수 있다.
"우리 팀 모두가 참여하는 워크숍이 필요한 것 같아요."
마침, 개발자인 켄이 팀 워크숍을 제안했다. 켄은 팀원 모두가 모여 팀이 가야 할 목표와 현재 상황에 대한 공감대를 갖자고 말했다.
"좋은 생각입니다. 하나 현재 우리의 사무실 말고 분위기가 좀 다른 곳에서 하면 좋겠어요. 이를 통해 우리의 공동의 목표에 대해 우리 팀원들의 다양한 생각을 듣고 함께 결과를 낼 방안을 고민하면 좋겠어요"
프로덕트 매니저인 에피는 위와 같은 의견을 냈다.
"네 제가 장소를 구해보죠"
존은 위와 같이 말하고 짧은 고민 끝에 적당한 장소를 구했다. 공유 오피스인 W사의 10명 규모 회의실을 빌렸다.
다음날이 되었다. 새로운 팀의 모든 팀원들은 공유 오피스에 10시까지 모였다.
W사는 늘 가장 좋은 건물에 위치하고 사무직 직원들을 위해 다양한 편의시설(커피, 맥주, 필기도구) 등을 구비하고 있었다. 또한 카페처럼 꾸며진 공간도 있었다. 이곳으로 음식을 주문하여 팀원과도 먹을 수 있었다. 모든 것이 이러한 이벤트를 하는데 안성맞춤이었다.
첫 번째 세션을 시작했다. 존은 이야기를 시작했다.
"저도 이 일을 시작한 지, 일주일밖에 되지 않았습니다. 그만큼 현재도 이 상황이 어색합니다. 이러한 일을 갑자기 새로운 팀을 꾸려 일해 본 경험은 아무도 없으리라 생각합니다. 제게도 그러니까요. 우리는 앞으로, 우리는 오로지 시장의 실사용자들을 만나며 제품을 만들 겁니다. 그리고 그들에게 '이거 정말 좋은데요?'라는 반응을 얻어내기 위해 최선의 노력을 다 할 겁니다."
팀원들의 눈빛은 빛나고 있었다. 그들은 이 일에 충분한 동기부여를 가지고 있었다.
존은 경영진에게 설명한 문제와 솔루션을 화이트보드에 적었다.
---------------------------------------------------------------------
- 사용자 대상
. 20명 이하 스타트업의 프로덕트 매니저
- 문제
. 대중성: 협업 SW 사용자 10만 회사('17년) --> 100만 회사('27년)
. 성장성: 협업 SW 시장 매년 5.9% 성장,
리모트 최근 3년 근무자 159% 증가
. 긴급성: 다양한 툴을 쓰고 있어 사용 툴을 중간중간 바꿀 때
시간 낭비가 많다.
- 솔루션
. 실시간 협업 화이트보드 + 비디오 콘퍼런스 + 태스크 매니지먼트
---------------------------------------------------------------------
그리고 문제와 솔루션을 보고할 때 경영진의 코멘트를 전달해 주었다. 가장 먼저 오랜 경험으로 개발 관련된 일을 수행해온 콜이 다음과 같이 이야기했다.
"존, 이거 시작부터 너무 무리한 계획을 세운 것 같습니다. 태스크 매니지먼트 기능을 개발해본 적은 있지만, 우리 개발자 모두는 화이트보드를 구현해본 적이 없습니다. 그리고 비디오 콘퍼런스도요. 이 두 가지는 제가 판단컨대 성능이 매우 중요한 시스템일 겁니다. 6개월 내에 우리 개발자 4명으로 아이디어 기획부터 시작해서 이 3가지를 모두 개발한다는 것은 불가능합니다."
다른 개발자들도 콜에 말에 고개를 끄덕였다. 존은 조심스레 다음과 같이 말했다.
"콜, 저도 그 말에 동의합니다. 아마도 이 3가지를 모두 개발한다는 것은 불가능할 거예요. 저도 제가 적은 문서를 보고, 처음부터 범위를 너무 크게 잡았다고 생각했어요. 하지만, 안타깝게도 우리는 범위를 크게 잡아야 합니다. 왜냐하면 우리 툴은 스위트(2개 이상 속성의 조합) 형태가 되어야 하니까요. 메신저, 메일 등의 한 가지의 속성만으로는 세상에 이미 나온 툴 들이 정말 훌륭해서 우리의 장점을 표현할 수 없습니다. 사용자들은 타 설루션들과 비교하며 해당 속성의 기본 기능이 뭐가 안된다는 불평만 하게 될 테니까요."
존은 말을 이었다.
"그리고 지금 이 시점에 우리가 제대로 정의한 기능이 없기 때문에 어디까지 할 수 있다는 팀이 배워가며 정의해야 한다고 생각합니다. 그리고 여러분 모두가 6개월 뒤 경영진에게 보여줄 시장에서의 증명을 위해 최선의 노력을 다 해줄 것이라 믿고 있고요. 지금은 이렇게 말해두죠. 이 세 가지가 모두 필요한지 필요 없는지는 저도 지금 모릅니다. 이는 얼마든지 바뀔 수 있다고 생각해요."
"그렇다면, 우리가 기능에 대해 다시 정의할 수도 있다는 거죠?"
콜은 다시 물었다.
"네 물론입니다."
MVP는 일반적으로 실제 구현한 제품 이전에 최소 기능으로 가치를 나타내는 제품을 의미한다. 때문에 SW의 경우 실제 동작하는 제품이 아닌 파워포인트 슬라이드, 비디오, 데모와 같이 단순한 표현일 수 있다.
조금 더 구체적으로 수준을 가지고 설명하자면, MVP는 완성도가 낮은 경우(Low fidelity)와 완성도가 높은 경우(High fidelity)로 나뉜다.
완성도가 낮은 MVP는 최소한의 기능으로 실제 제품 형태를 모방한 것인데, SW의 경우 랜딩 페이지, 구현 대신에 종이나 파워포인트 형태만 구성한 목업(Mock up)으로도 MVP의 구성이 가능하다. 반면에 완성도가 높은 MVP는 실제 제품에 가깝게 구현된 MVP로 예를 들어 특정 솔루션의 핵심 기능들을 구현하고 생산품의 데모 버전으로 실제품에 가까운 형태로 구현한다.
구현의 수준은 달라도 MVP를 만드는 목적은 같다. 실제 우리가 초점을 맞춘 '문제'가 실제인지 확인하고 우리가 낸 제품 아이디어 속에 녹인 '솔루션'으로서 우리의 아이디어가 올바른지를 검증하는데 활용한다.
하지만, 담당하는 역할에 따라 또는 주어진 환경에 따라 MVP의 정의가 달라지는 경우가 있다. MVP의 M은 미니멈(Minimum)은 '가장 최소'라는 의미이다. 때문에 업무를 주는 스폰서들은 '가장 빠른' 시간에 결과물을 가져오길 기대하는 경우가 있다. 반면 개발팀은 MVP의 M을 '가장적은''의 기능이라 생각하는 경우들이 있다. 그래서 정해진 기간에 최소한의 기능을 만드는 것을 생각한다. 특히나 스폰서와 개발팀 사이에 신뢰가 적은 경우는 이러한 생각의 충돌이 문제를 일어난다.
이를 효과적으로 해결하는 방법은 개발팀의 리더가 자주 가고자 하는 바를 스폰서와 소통을 통해 이야기하는 것이다. 그리고 개발팀의 구성원들은 필요한 결과를 제때에 준비해줘야 한다. 이때 매주 또는 격주로 진행하는 쇼케이스는 매우 효과적인 소통 방법이다. 스폰서와 개발팀의 리더, 개발팀 구성원이 서로 노력하고 고민한 업무의 경과가 그대로 공유된다.
