한국 해커톤의 한 걸음 정도의 발전을 위한 제언 1/3
첫번째 제언: Product Management기술을 적극 활용/적용하기
지난 6월에 짧은 일정으로 한국을 다녀오면서 그 기간중 과분하게도 오픈핵 해커톤에 의도치 않은 멘토로서 참여한 후, 해커톤 참여 경험이 주로 유럽쪽에 있었던 제 개인적인 경험을 좀 공유하여 발전적인 제언을 해보면 어떨까 싶었습니다. 어느쪽의 무엇이 더 좋고, 나쁘고의 비교가 아닌, 다른 곳의 해커톤에서는 이런 스타일의 변화가 있는데, 이런 변화는 참여한 구성원들이 자연스럽게 발전적이라 느끼고 적용하는 것이니 그런것들을 한국의 해커톤에서도 심각하게 생각하지 말고 단순히 best practice 정도로 생각하고 한번 시도experiment 해 보면 또 다른 진보된 모습의 방향이 나타나지 않을까 싶어서 정리를 해 보았습니다.
아래와 같이 총 3가지의 제언을 해 볼까 합니다.
1. 프로덕트 매니지먼트 기술을 적극 활용하고 적용해 봅시다.
2. 개발의 전체 그림을 그릴 수 있는 디자이너를 키워내 봅시다.
3. 오픈 소스의 활용에서 Inner Source로의 변화를 시도해 봅시다.
오늘은 첫번째 제언인 '프로덕트 매니지먼트 기술 7가지를 적극 활용하고 적용하자' 하는 주제로 이야기를 시작해 봅니다.
1. 해커톤의 목적을 가감없이 순수하게 이해하기
General hackerthon process해커톤은 우리가 마주하는 일상 생활에서 '문제' problems 혹은 issues 를 선택하고, 극도로 단축된 시간제한 환경하에서 '해결'을 해 보는 것입니다. 우리의 일상생활에는 여러가지 수많은 직군, 연령대의 사람들과 함께 살고 있습니다. 그럼에도 우리가 매우 쉽게, 어쩌면 당연하게 생각하는 해커톤에 대한 오해는 개발자가 참여하는 행사라는 것입니다.
유럽에서의 초기의 해커톤 형태 역시 개발자가 중심이었습니다. 시간이 지남에 따라, 해커톤 참석자들이 일반 소프트웨어 프로덕트의 딜리버리 프로세스에 필요한 모든 직군이 이곳에도 필요하다는 것을 스스로 깨닫기 시작합니다. 그래서 개발자, QA 테스터, UX/UI Designer, 그리고 PM (Product management 가 가능한 역할을 수행하는 Product owner, Program manager, Delivery manager 등을 총칭해서 사용하고자 합니다. 대신 리소스/공정을 관리하는 Project manager의 역할과는 다름을 먼저 밝힙니다)등의 역할 필요성을 느끼고, 꼭 자신의 현업이 그 역할이 아니어도 그 역할을 수행하는 실험을 시작하고 연습한 후 지금은 어느정도 자연스럽게 정착이 된 상태입니다.
매번 기회가 있을때마다, 한국 소프트웨어 엔지니어링의 한 단계 도약을 위해서는 능력있고, 경험있는 프로덕트 매니저들이 많이 배출되어야 한다고 말을 해왔습니다. 물론 이미 한국에서 소프트웨어를 제작하고 서비스를 배포하는 많은 회사들에도 훌륭한 PM분들이 많이 있겠으나, 아직까지 자연스럽고 전문적인 역할 조직의 모습으로 또는 소프트웨어와 관련있는 전공 학생들에게도 PM의 역할이 잘 이해되고 있는지는 잘 모르겠습니다.
그런면에서라도 극도로 제한된 시간과 리소스 환경하에서 결과를 만들어 내야 하는 해커톤이야 말로 PM의 역할이 매우 필요하다고 생각하며 어떤면에서 PM의 역할이 해커톤에서 발전된 모습을 가져다 줄런지 밑의 6가지의 특징을 설명해 봅니다.
2. 시장의 요청사항을 함께 이해하고 유효화 합니다.
위의 소제목을 풀어서 설명드려보겠습니다.
시장이라 하면 목표마켓일 수도 아니면 기존의 고객이거나 잠재 고객일 수 있구요. 그들의 요구나 요청사항을 함께collaborately 이해/고민하고 계획하고 있는 프로덕트에 그 요청을 유효화 identify and validate 해서 기능으로 제공하기로 결정하는 것을 말씀드리는겁니다.
해커톤이 일반적인 소프트웨어/서비스를 제공하는 프로세스와는 다르지만, 좋은 해커톤이라고 평가할 수 있는 것은 처음 시작을 현재의 상황이나 사용자가 느끼는 '불편함, 거북함, 비효율'에 대한 충분한 이해에서 부터 출발하고, 그 해결에 대한 고민을 최고의 가치로 하면서 그것에 대해 심도있게 고민하고 토의가 되어야 할 주제는 것입니다.
이런 점에서 자연스럽게 PM의 역할이 요구됩니다.
개발자가 주축이 된 해커톤인 경우는 현재의 문제점에 대해 이야기가 되는 즉시 뛰어난 개발자의 머리에선 소스코드의 구성, 어떤 라이브러리의 사용, 어떤 딜리버리 채널을 사용하는지에 더욱 관심을 갖고 바로 코딩창을 열고 시작을 하게되죠. 그리고 그 아이디어 따라 디자이너와 나머지 스탭들이 움직이게 됩니다.
이때 PM의 역할이 들어간다면, 해커톤의 초기시간에는 각자의 역할을 가진 구성원들이 다 함께 현재의 고객이나 시장의 요구사항을 정확히 이해identify하고 유효화 validate하고 그 유효화 된 항목들을 모아서 우선순위를 정하는 priortize를 하는 시간을 매우 중요하게 생각해야 합니다. 이 시간이 바로 그 이후에 구성원들이 낸 해결 아이디어와 사용자 가치와 비즈니스 니즈를 종합하여 최종 딜리버리에 어떤것이 포함되고 포함되지 않을지 모든 구성원들에게 같은 내용을 이해하게 만드는 큰 장점이 있습니다.
이 부분을 부족하게 넘어가다 보면, 해커톤을 진행중에 서로간에 제품/서비스의 이해차이로 인해 작업시점을 되돌리는 경우가 있을 뿐만 아니라 더욱 큰 잠재적 손실은 사용자의 니즈에 부합하지 않는 결과물이 나올 수 있는 가능성을 내포하고 있습니다.
3. 상호간의 경계선과 협력선을 설정합니다
PM의 역할에 대해 경험이 부족한 구성원들의 경우에는 PM을 상위의 결정매니저라고 생각하기 쉬우나, PM의 역할은 각자의 역할에 집중할 수 있도록 상호간의 경계선과 협력선을 설정해 주고, 시장과 고객이 원하는 결과물을 만들 수있도록 하는 돕는 assistant 역할임을 명확하게 설명해 줘야 할 필요가 있습니다.
그러기에 'why'에 대해서 집중 설명하고, 'why'에 기반한 'what'을 구성원들과 함께 고민하고 우선순위를 만들겠지만, 'how' 라는 부분에선 각자 구성원의 능력이 최선으로 발휘되도록 돕는 역할만 할뿐 그 'how' 내용은 각자 구성원의 존중받아아햘 영역으로 남겨두는것입니다. 한마디로 정의하자면, 고객 또는 시장의 요청과 나올제품간의 'alignment', 엔지니어링 역할간의 'alignment'를 하는 끈끈이 glue 역할을 수행함을 항상 해커톤을 참여한 구성원들에게 이야기 해 줌으로 역할간 충돌이나 중복시간 투자를 방지 할 수 있습니다.
4. MVP 스코프를 명확히 정합니다.
저의 다른 글에서도 설명을 드렸든 MVP (Minimum Viable Product) 에서 가장 중요하게 강조하고자 하는 말은 viable이고 '생존 가능한'으로 해석이 될 수 있다고 하겠습니다. 해커톤 같이 짧은 시간안에 가치있는 솔루션을 보여준다는것이 정말 쉽지 않은 일임에 분명하지만, 그렇다고 해커톤이 끝난후에 쉽게 버려지고, 재활용이 어려운 결과물이었다면, 이것 또한 해커톤의 취지에 맞지 않는다고 생각합니다. 유럽에서의 해커톤 참가 경험을 비추어 봤을때, 이것에 대한 고민과 토론이 많았고, 그것에 따라서 현재의 결과물이 아무리 작고 초라하게 보인다고 해도 어떻게 하면 '생존 가능한' viable 솔루션이나 기능으로 발전될 수 있을까에 해커톤의 목표점이 변화해 가고 있습니다. 그런면에서 MVP를 해커톤 초기에 잘 설정하는 것이 가장 중요한 일이 되는데, 제 경험상 다음과 같은 3가지 상황이 해커톤 중에 팀을 가장 많이 곤란해 지는 상황이라고 생각됩니다.
1. 초기에 문제/요청/요구사항을 충분히 논의하고discuss 이해해서 identify결정하는 validate 시간을 충분히 갖지 않았을때
2. MVP에 근거하여 제품/서비스의 기능의 우선순위을 정할때 실패했을때
3. 시간이 지나감에 따라, 팀 구성원들이 정해진 스코프대로 진행이 잘 되는지 레귤러 하게 리뷰나 체크를 하지 않았을떄
소프트웨어나 서비스를 한번이라도 만들어 본 사람들이라면 누구나 초기에 정한 시간이라는것이 얼마나 실제와 차이가 나고, 틀렸는지에 대한 경험은 다들 있을것입니다. 그렇다고 초기에 시간을 정하는것이 무의미하다고 할 수는 없지요. 해커톤 같은 상황에서 매우 자세하고 상세한 타임라인 짜는것 역시 현실적이지 않다는것에 절대적으로 동의를 하기에 더욱 더 무엇이 viable할 수 있는지에 대한 우선순위 작업이 반드시 최우선으로 이루어 져야 하는것입니다. 이 우선순위은 해커톤 기간 동안 팀 구성원들 모두를 집중시킬수 있게 할 뿐만 아니라, 다른 여러 우선순위가 떨어지는 기능을 추후에 로드맵으로 구성하여 팀 스탭들을 한 목소리를 만들 수 있게 하는 큰 동력이 됩니다. 즉 모두가 공감하고 중요도를 인식하는 기능이 해커톤 끝나기 전에 어떻게든 동작이 되어 보여질 수 있다면, 그 외에 기능은 누구에게라도 로드맵이라는 이름으로 설명되고 이해될 수 있다는 이야기입니다. 소프트웨어가 일반 제조manufacturing와 확연하게 다른 부분이 이런 버전을 통한 지속적인 관리가 된다는 것, 즉 지속성sustainability과 일관성 consistency를 통해서 꾸준히 viable한 프로덕트를 만들어 간다는 점을 강조해야 하는것이다. 이런면에서 중재자와 비저너리로서의 PM의 역할이 대단히 필요하다고 생각합니다.
5. 팀멤버들의 커뮤니케이션 기술과 능력을 향상시킵니다.
커뮤니케이션의 중요성을 반복해서 이야기 할 필요은 없지만 그 이유는 간단힙니다. 팀웍과 생산성 productivity에 가장 중요한 요인이 그것이기 때문입니다. 특히 모든 시간과 리소스의 제약이 엄청난 압박으로 다가오는 해커톤 상황에선 커뮤니케이션의 품질이 더욱 더 순도가 높아야 하고, 그 순도는 명확도clear와 간결함concise이라 할 수 있습니다. 마감시간이 다가옴에 따라, 작은 커뮤니케이션의 실수나 오해가, 깜짝 놀랄만큼 좋은 결과를 만들어 낼 수 있는 상황을 한순간에 무가치한 시간낭비로 만들 수도 있기 때문입니다.
이런 제한되고 압박이 강한 상황에선 어쩌면 모든 사람들이 익숙해 있는 소프트웨어 프로세스는 시간대비하여 효과적이 아닐수도 있습니다. 즉 PM이 사용자 케이스를 정리하고, 스펙으로 등록하면, 개발자, 테스터, 디자이너가 동의하고, 그러면 실제 액션이 들어가는 이런 기존의 방법보다는 훨씬 agility에 근거해서 초기 방향이 정해지면, 빠르게 게릴라성으로 작업-이슈-짧은회의를 반복하고, 정해진 호흡 인터벌에 따라서 레귤러한 상황리뷰를 하는것이 효과적이었다 생각합니다.
이 부분은 사실 PM의 경험이 풍부하지 않고서는 기대하기 쉽지 않은 부분이지만, 여러번의 실습과 학습을 통하면, 팀 구성원들간의 커뮤니케이션 목표의식이 굉장히 빠른 시간동안에 발전할 수 있음을 경험해 보았습니다. 즉 reactive한 커뮤니케이션에서 proactive한 소통의 방법으로 발전하게 됩니다.
6. 초기 테스트에 참여하고, 우선순위를 리뷰하고 업데이트 합니다.
팀 구성원들의 노력으로 제품의 모양을 갖춰가면, 정식 테스트를 시작하기 전에, use cases를 정의한 PM에게는 프로덕트를 테스트할 수 있는 최적의 기회라 생각할 수 있습니다. 그게 아직 UI도 제대로 갖춰져 있지 않은 프로토타입일 수도 아니면 조금 더 나은 상태일 지도 모르지만, 여기서 중요한 것은 이런 상황일 수록 사용자테스트는 위력을 발휘합니다. 이것을 뒷받침 해주는 대단히 흥미로운 조사결과가 있습니다. Jakob Nielsen 과Tom Landauer의 조사에 따르자면 5명 정도의 테스터가 약 85%의 사용성의 문제를 찾아 낼수 있다는 보고가 있습니다. 다시 말하자면, 누군가 한명이라도 빨리 시작하지 않으면 사용성의 문제를 발견할 가능성은 전혀 없다고 보면 됩니다.
해커톤이라고 프로덕트의 품질이 수용되는 한계가 있는것이 아닙니다. 해커톤이 끝나고 그런 자질구레한 버그를 잡아야지 하는 마음자세는 절대 viable한 프로덕트로 성장할 수 없습니다.
레귤러 review meeting에서 당신이 발견한 문제를 공유하고 그것에 따른 우선순위를 재정렬 해야 합니다. 어쩌면 계속 현재의 우선순위를 지속적으로 운영하는것 보다, 발견된 문제를 해결하는 것이 생산성과 품질향성에 도움이 될 수 있기 때문입니다.
7. 팀 구성원및 다른 팀원들을 응원하세요
이런 시간이 쑥스러울 수도 있지만, 해커톤이 종료가 된 후엔, 어떤 인연으로 만나게된 해커톤 멤버이던 간에, 같은 목표를 갖고, 집중도가 높은 시간을 함께 보낸 팀 멤버들의 각각의 수고와 노력에 감사의 시간을 갖기 바랍니다. PM의 역할은 아직 남아있기에 이 시간을 최대한 효율적으로 끌어 올리려 노력합니다. 이 시간에는 표면적으로 감사의 말을 전하기 보다는 좀 더 구체적으로 내가 다른 멤버들로 부터 경험하고 본것들, 결정을 내릴때의 심정, 무엇을 얻으려고 무엇을 포기해야 했는지 등등을 나누면서 진솔하게 의견과 느낌을 공유하시기 바랍니다. 이 시간은 개발, 테스트, 디자인, PM등의 과정을 좀 더 진솔하게 간접 경험하면서 서로간의 업무에 대한 존중과 존경심을 가질 수 있고 이해의 폭을 넓힐 수 있는 기회가 됩니다. 같은 방법으로 다른 팀의 멤버들과도 의견을 나누시길 적극 권해드립니다. 보통 이런 관계는 단순히 일회성으로 끝나는 것이 아닌, 자신의 인적네트웍을 비약적으로 확대하는데 많은 도움이 되고, 자신을 좀 더 동적으로 노출 시키는데 도움이 됩니다. 어쩌면 해커톤에서 마지막 프로덕트 결과물의 품질보다 더 중요한 자산으로 사용될 수 있습니다.
마무리
위에서 나눈 오늘의 이야기 '프로덕트 매니지먼트 기술 7가지를 적극 활용하고 적용하자' 를 정리합니다.
여러 모양과 컨셉과 사이즈가 다른 해커톤이 있지만, 그 안에서 프로덕트매니지먼트의 기술과 장점들을 잘 활용하면 더욱 더 발전적인 모습의 해커톤이 될 수 있다고 생각합니다. 사실 해커톤의 대부분이 대학생들을 중심으로 이루어 지던지, 주니어 개발자들을 위주로 진행이 된다면, 경험있는 프로덕트 매니지먼트의 기술을 사용해 보는것은 사실 많이 어려운것이 현실일 것입니다. 그러기에 초기에는 현업에서 활동중이신 능력있는 프로덕트 매니저 분들이 멘토로서 혹은 직접 팀의 PM역할을 수행해 주시는것이 이러한 프로세스를 정착시키는데 큰 도움이 될것으로 생각됩니다. 사실 유럽의 해커톤에서도 초기에는 현업의 PM들이 참여하여 그 업무 노하우와 프로세스를 진행하면서 해커톤의 품질을 현재와 같이 끌어올리는데 큰 도움이 되었습니다. 이제는 이런 부분이 많이 정착되어, 대부분의 해커톤에서 PM의 역할이 꼭 필요하다는 인식이 생기게 되었답니다. 현업의 프로덕트 매니저들 역시, 실제 제품프로세스가 아닌 위험도가 적은 환경에서 창의적이고 혁신적인 솔루션들을 테스트 해 볼 수 있고, 코드의 신뢰성과 디자인의 접근성에 그렇게 많이 예민해 질 필요가 없습니다. 한가지 마지막 말씀드리고 싶은 점은, 반드시 지금 현업에서의 PM이 아니라고 해서 해커톤에서 그 역할을 잘 수행하지 못할것이다 라는 이야기는 절대로 아닙니다. 요즘은 손바닥안에 모든 최신 기술을 접할 수 있는 기회는 모든 사람에게 균등하게 주어져 있으니까요. 새로운 것을 시도해 보고 마무리 지어 보려는 노력이 발전을 만든다는 생각입니다. Done is better than perfect.
