학교에서 컴퓨터 공학을 배우면서,  소프트웨어에 대해서 쓸 고객에 대해서 정말 고민한적이 있나요? 이 소프트웨어는 이러 이러한 것들을 제공하기때문에, 정말 좋아요. 라고 컴퓨터를 모르는 사용자가 알아들을 수 있게 가치를 설정하고 전달하도록 고민해 본적이 있을까요?  아마 우리는 공돌이기 때문에 이러한 것들을 몰라도 된다고 위안을 삼고 싶겠지만, 여실하게 대기업에서도 전 이 문제점과 부딪혔습니다.

실제 고객을 한번도 만나보지 않고 기획이나 UX팀에서 날라온 공급자 중심의 설계, 그리고 고객들의 불만을 대응하기 위해 일정에 쫓겨가며 헐레벌떡 기능을 구현하게 만들고, QA팀과 이건 버그가 아니다라고 실강이 한 기억들이 납니다.  저의 고객은 임원인 경우가 많죠.

사실 저도 이러한 부분과 거리가 멀었고,  소프트웨어 마에스트로 과정을 통해서 깨닫게 되었습니다.

알람몬을 만든 김영호 사장님이나,  Sleep if you can의 신재명군과  같이 그들이 얼마나 고객의 피드백을 받아가며, 그리고 사업적으로 살아남기 위해 여기 저기 뛰어나닐수 밖에 없는 모습을 보며, ” 나는 저 나이에 저런 열정이 있었나?” 라며 되돌아 보게 됩니다. (이 친구들과 같이 한 정부 과제가 있는데 그중 일부가 여기에 있으니 참고하세요)

NHN NEXT의 휴먼 디자인 프로젝트나  소프트웨어 마에스트로 과정은 비록 리얼 월드는 아니지만, 최대한 그것에 가깝게 갈려고 많은 교수님들과 멘토님들이 날카롭게 질문을 합니다. (아무리 가깝게 할려고 해도 자기돈으로 하는 사업이 아니니 리얼월드가 아닌점은 사실이구요. 하지만 노력을 많이 가하고 있다는 점을 알아 주셨으면 합니다.)

기술을 학습하기 위해 억지로 만든 프로젝트가 아닌.  사용자에게 줄수 있는 핵심 가치(우리 프로젝트의 가치)가 무엇이고, 그걸 어떻게 찾아가는지에 대해서 많은 협의및 고민을 합니다. SK 컴즈 CEO 셨던 주형철 부학장님이나, 저와 많은 코웍을 하시는 장선진 멘토님에게  전혀 다른 두가지 입장 (거대한 기업을 이끌었던 경험과,  스타트업에서 정말 얻는 고충)들을 곁에서 많으 조언과 코치를 받았습니다.

평가 시즌을 거치면서 우리가 만든 소프트웨어의 가치는 무엇이고, 이 가치를 팀원 모두가 잘 공유하고 있고, 이게 프로젝트가 끝날때 까지 잘 유지되어서, 핵심 가치를 잘 전달할수 있는 소프트웨어가 될수 있을까? 에 대한 고민을 가지게 되었고, 결국 상품기획, 개발자, 디자이너 성향을 가진 종합 예술인(?) 분을 모셔서 어렵게 코칭을 받았습니다.

그 과정을 어떻게 하나 하나 진행했는지를 이번 포스트에서 공유하고자 합니다. 소마에 과정의 예산으로 한 것이라, 당연히 외부에 공유가 되어야 할거고, 지금 NHNNEXT 학생들도 이 주제에 대해서 크게 고민을 하고 있을거 같아 적어 봅니다.

프로젝트 상황 (Context) 

저희가 가치를 찾기 위한  프로젝트에 대해 설명드리면, 제가 세미나나 포스팅을 통해 여러번 소개를 드렸던 STAN4J를 Web 형태로 보여주는 프로젝트 입니다. 이것들을 저렴하게 또는 오픈소스로 만들어서  Jenkins 플러그인과 서비스로 배포한다는 지극히 개발자 적인 마인드로 접근을 했습니다.

하지만 파고들다 보니 SQAM 이라는 시장이며 고가 제품군들이 포진하고 있으며, 사용자 조사를 통해서 저희만의 강점과 여러가지 pain point를 찾았습니다.  그 부분은 여튼 저희만의 무기니까 먼 훗날 소개를 하도록 하구요.   M1 기능을 구현한 버전을 직접 보시도록 하시죠.

위 Stanly M1 단계를 만든후 여기 저기 피드백을 받으니, 경쟁 제품과의 차별화 포인트를 찾고 우리가 가야할 가치에 대해서 좀더 다듬을 필요가 있다고 생각이 들었습니다.

프로젝트 가치 찾기 워크샵 절차와 숙제

스타트업이라면 모든 팀원이 모여서 하시는게 좋습니다.   모든 팀원의 이 프로젝트가 추구하는 가치와  우리는 이러한 어플리케이션을 만들구나 라고 명확하게 서로간에 Consensus를 이루게 만들수 있는 좋은 장치지요.

다음과 같은 절차로 프로젝트의 핵심 가치 찾기를 하는 워크샵이었습니다 .

1. 목적과 목표 수립
2. why & why not buy?
3. simple value proposition
4. user profiling -> opportunity 도출
5. convergence
6. 핵심 concept 및 value 도출
7. summary

애자일 종합 예술인 께서 위와 같은 절차는 다음과 같은 큰 프레임 안에서 움직이는 절차라고 말씀해 주셨습니다.

시작 – Divergence – Convergence – Divergence – Convergence 라는 절차 즉 아이디어를 막 내다가, 다시 모아서 정리하고, 또 다시 정리된 아이디어에서 더 다양한 것들을 찾기 위해 아이디어를 확산하고, 다시 재정리하는 것이지요.

이 프로젝트를 하기 위해선 다음과 같은 사전 숙제가 필요합니다.

1. target customer 도출 : 누가 stanly를 살건지 2~3명 정의
2. 정의한 customer의 persona 만들기 :어떤 사람이고 어떠한 성향인지등 상상해서 작성. 예) “david은 30살의 IT 엔지니어로서 평소에 아키텍쳐에 관심이 많은 사람이다.”
3. stanly를 고객이 왜 사는지(why buy?) 왜 안사는지(why not buy?)에 대해서 이유를 각각 30개씩 적어오기. 
4. 본인이 생각하는 stanly의 awesome한 기능 “딱 하나만” 선정해오기.

소마에 멘티인  양현철(Y), 정승수(J), 오혜성(O) 친구들이 한 숙제입니다.  이 친구 다 순수 개발자이기 때문에,  기술위주,  기능위주라고  애자일 전문가 (종합 에술인)께서 피드백을 주셨습니다. 모법 답안은 아니지만 많은 개발자에게 도움이 될거 같아 공유합니다.

다른 사람에게 프로젝트의 가치를 설명하기 위해서.. 

개발자가 흔히 빠지는 오류

• 일반인 : 개발자에게 너 뭐하냐?  
• 개발자: 클라우드 개발해요.
• 일반인 : 클라우드하고 뭐하세요?  
• 개발자 : MySql Sharding을 통해 1억개의 노드를 핸들링해요.

일반인이 알고 싶은것은 Sharding까지해서 뭘하는지 실제 고객에게 어떤 형태로 서비스가 되는지가 더 중요하다는 것을 이야기 못하지요. 만약 이 일반인이 VC라면?   개발자는 대단하겠다고 하지만..  일반인, 투자자는 이해 못합니다. 이 사람들에게 명확하게 이해할수 있는 단어로 요약 정리할 수 있는게 중요합니다.

타겟 유저 선정과 페르소나 구하기(실제는 관찰하고 고민해야 하지만, 가상으로 정의함) 

페르소나 (Persona): 특정 타겟 Customer를 정한 다음, 그 사람의 생활 패턴들을 정의하고, 사용 시나리오를 도출하는 것을 말합니다.  Stanly라는 소프트웨어를 누가 사고, 어떻게 사용할 것인가?  사실 타겟 고객의 관찰을 통해서 페르소나를 구해야하며, 다음과 같이 페르소나를 구하는 절차들이 있습니다.

실례:

절차를 거쳐 위와 같이 고객의 Persona를 만들어야 합니다. 하지만 저희는 나름대로 시장을 조사해서 다음과 같이 Y,O군의 고객의 페르소나를 구했습니다.

Y군:

•  안드로이드 어플리케이션을 만드는 프로그램 아르바이트를 하는 손오공군. 아르바이트를 의뢰한 업체에 결과물을 전달할때 Stanly로 분석한 결과(개발과정 중에 프로그램의 구조, 오염도의 변화)도 함께 전달하여. 추후 의뢰업체에서 유지보수를 용이하게 할 수 있도록 함
•  안드로이드 어플리케이션을 만드는 중소 SI업체 안드로만드로, 소프트웨어 구조를 파악하여 개발자마다 담당 업무를 분담하기 위하여 사용, 개발자마다 끼친 코드 오염도 표시하여 적절함 갈굼에 사용
• 자바 오픈소스 프로젝트 파운더, 오픈소스는 많은 사람들이 커밋을하여 구조가 복잡해 질 수 있으므로, 구조가 유지될 수 있도록 감시용으로 사용

O군 :

•  중견기업의 들어온지 얼마 안된 개발자: 존은 어느정도 자리잡은 중견기업(D 회사)에 취직한 초보 개발자이다. 처음 들어와 프로젝트에 참여하기 위해 전체적인 구조를 파악하여 팀에 빠르게 적응하기를 원하는 사람
• 중견기업의 프로젝트의 리더 개발자(?) : 칼은 중견 기업에 상당히 큰 규모의 프로젝트를 장기간 진행하면서 서비스하는 프로젝트의 개발자이다. 서비스가 장기화되면서 기능의 추가나 유지보수 등의 작업으로 인해 프로젝트의 구조를 개선할 필요가 있어진 개발자
• 오픈소스 개발자 : 론은 오픈소스 커밋터로 활동하고 있다. 오픈소스 활동을 하면서 다양한 사람들이 기능을 추가하거나 유지보수 하는 경우가 많아서 프로젝트의 구조가 자주 변경되어서 프로젝트의 구조가 꼬이는 상황이 자주 발생하여 해당 상황을 해결하고 싶어하는 개발자
• 초보 개발자 : 콘은 대학교 3~4학년에 재학중인 개발자 지망생이다. 기초적인 개발은 할 수 있지만 보다 프로젝트의 좋은 구조를 구성하기 위해 패턴등과 같은 기법에 많은 관심을 가지고 있는 개발자

팀원, 또는 이해당사자들의 프로젝트 목적(Purpose)과 목표(Goal) 

프로젝트의 목적과 목표에 대해서 각 팀원들이  생각하는 바를 적습니다.  목적과 목표를 나누어서 이해하실 필요가 있습니다.

• 목적 (purpose) 은 : Jolt award 빛나는 최고의 분석 툴 (끝이 없다. 쉽게 말해 Approach를 말한다.)
• 목표 (goal)는 : 100  copy ( 달성하면 끝나는 것 )

이 프로젝트를 통해서 서로 얻고자 하는 목적과 목표를 적습니다. 저희팀은 아래와 같이 나왔습니다.

목적을 정할때. Scope을 정하면 가야할 방향을 정하기가 쉽습니다.  단기, 중장기 전략을 구해야 하지만, 좀더 현실적인 단기적인 목적을 쉽게 결정하기 위해 scope을  남은 3개월 프로젝트에서 라고 정하였습니다.  

이때 나온 몇몇 문제들을 공유하자면. 개발자가들은  머리속에서 어느정도  구현 강도를 알기 때문에, 당장 구현할 수 있는 범위에서 이 목표를 정하는 우를 범합니다.  원래는 모든 소프트웨어가 우리것을 적극 활용할수 있게 하자고 했는데, 한 멘티가  그건 힘들거 같으니 오픈소스 프로젝트를 분석한 결과를 갤러리 같이 보여주는 정도가 어떻겠냐고 말을 했습니다.   그래서 애자일 종합 예술인께서 Why라는 카드를 꺼냈습니다.  그 대답은 홍보였습니다.  홍보가 우리 프로젝트의 목적은 아니라는 것을 알고 있었고, 그래서 다시 수정을 하여 조기에 프로젝트의 문제를 해결해 줘서 사용자가 Stanly 에게 감사해한다 라고 목적을 정했습니다.

그리고 easy to use, easy to understand는 좋은 목적이 되지 못합니다. 너무 추상적이기 때문에  어렵다는 거죠. 일종의 함정같은 미사어구라고 종합예술인(애자일 마스터) 이 말씀해 주셨습니다. 좀더 자세히 설명해야 하는데, 이 부분은 다음 단계에서 이야기를 나누어 좀더 구체화 하기로 했습니다 .

Why Buy & Why not Buy

고객은 왜 우리 Stanly를 살까? 왜 안 살까? 에 대해서 각자 30개씩 적었구요. 3명이 적었으니 3* 60 = 180개를 소리내어 읽어가며 마음에 드는 단어들을 postit에 적게 했습니다. 소리를 내어서 읽는 이유는  말이 되는지 안되는지, 어떤 의미인지 그리고 다른 사람들을 집중하게 만들수 있게 만들기 위해서 입니다.

why buy에 해당하는 단어는 파란색 post it으로 why not buy에 해당하는 단어는 빨간색으로 post it으로 적었습니다. 그래서 post it들을 그룹화 하고 재 배치를 했습니다.

이러한 툴을 모르는 대부분의 학생들이 아이디어를 발굴할때, 서로의 아이디어를 비교하고 서로 오랜 설득끝에 하나의 아이디어를 내는데,   과정 과정 하나가 어떻게 도출되었는지 이해하기 어려운 면이 있습니다.  그래서 그 과정이 제대로 되었는지 다시 되돌아서 확인을 해야하고, 그것 자체를 불쾌하게 생각하는 친구도 있씁니다.

토론을 통해서 하는 방법은 다양성을 죽이고 하나만 살리는 방법이라면, 이러한 툴을 사용하니, 서로의 생각들을 모아 그룹화함으로써, 협력하여 자연스럽게 의견을 모아내는 힘이 아닌가 쉽습니다.   그냥 이런 툴을 써서 아 이렇구나 도출된다고 볼수 있지만, 전자 후자를 다 겪어보는 저의 입장에서는 마찰없이 자연스럽게 의견이 도출된다는 점이 감사했습니다. 여튼 짜잔 다음과 같이 사는 이유 (파란색) , 안 사는 이유 (빨간색)으로  큰 상위 개념으로 그룹화되어서 나왔습니다.

왜 사야 하는지, 왜 안 사는지에 대한 잠재적인 수요가 나왔습니다. (판매되는게 아니라면 왜 쓰는지, 왜 안쓰는지로 하시면 될듯 해요. )

Simple Value 발굴 (Bottom Up 으로) 

왜 사는지, 안 사는지 (Why Buy &  Why not buy) 를 통해서 기능들을 Offers 에 더 그룹화하거나 핵심 요소를 찾아 매핑을 하고 이걸 모아서 Value 찾아보는 방법을 취해 보았습니다. 가치 2개는 Why Buy에서, 가치 1개는  Why not buy에서 뽑도록 권고했습니다.  이때 발생한 문제는 offers를 들어간 것들을 찾기가 쉽지 않았습니다. 다시 한번 적절하게 그루핑하고, 버릴걸 버린다는게 쉽지 않더라구요.

애자일 종합 예술인께서 옆에서 계속 도와 주었습니다. 5 Whys 기법과 적절한 어휘 선정등에 대해서요.    이건 추상화하면서 명시적으로 표현하는 것을 다 만족하기가 쉽지 않은거 같습니다.

페르소나에서 돌아와 User Profiling ,  Opportunity (기회 요소) 도출, Convergence 

모든 이해 당사자가  1명이 제시한 3개의 페르소나에서 가장 우선순위가 높은 페르소나 1개를 선정합니다.  이전에서 했던 정보들을 가지고 가장 우선 순위가 높은 Persona를 선정하는 것이지요.  저희가 투표해서 다음과 같이 선정되었습니다.

• Y군 : 자바 오픈소스 프로젝트 파운더, 오픈소스는 많은 사람들이 커밋을하여 구조가 복잡해 질 수 있으므로, 구조가 유지될 수 있도록 감시용으로 사용
• J군 : 기업에 다니다가 중견기업 프로젝트 매니져로 들어온 매니저 b씨 대기업에서 비싸고 좋은 툴들을 사용해봄
• O군 : 론은 오픈소스 커밋터로 활동하고 있다. 오픈소스 활동을 하면서 다양한 사람들이 기능을 추가하거나 유지보수 하는 경우가 많아서 프로젝트의 구조가 자주 변경되어서 프로젝트의 구조가 꼬이는 상황이 자주 발생하여 해당 상황을 해결하고 싶어하는 개발자

선정된 3사람의 유저 시나리오를 딥하게 작성해 보았습니다.

3명이서 각자 작성한 시나리오를 가지고  Opportunity를 도출합니다.  각 문장을 쭉 읽어가면서, 마음에 드는 단어를 Post it에 적고 다시 이렇게 그룹화 합니다.

다음과 같이  Opportunity를  서로 엮어서 Convergence를 도출했습니다.

• 아키텍처 파악
• 공유
• 원인 파악
• 방향성 유도
• 아키텍처 관리

핵심 Concept및 Value (가치) 도출

지금까지 데이터를 다시 조합하고 고민해서, 위의 칸에 데이터를 넣어서 핵심 개념과 가치를 도출해야 합니다. 5시간을 쉬지 않고 달려서 그런지 친구들이 이 문장을 보고 멍해지더라구요.  이걸 어떻게 채워야 할지 고민을 하고,  지금까지 쌓아온 여러 지표들을 다시 보고 또 다시 보면서 고민을 했습니다.  이 마지막 핵심 가치를 뽑기 위해서 정말 많은 고민을 했습니다. 명확하며, 가치를 잘 표현할수 있는 문장을 뽑아내는 작업을 해야만 했습니다.

누구에게나 딱 맞는 소프트웨어를 만들고 싶어요 라고 하면? 감이 오시나요?  오지 않죠. 그래서 몇번을 지우고 다시 적으면서 찾았습니다.

타겟 유저(고객)은 편하게 찾았으나 가치를 찾기가 역시 고민이었습니다. “문제점을 한번에 보여주는 뷰”   한번에.. 이게 무슨 의미이지?   한번에라는 말은 너무 추상적인 단어입니다.  그래서 5 Whys 방법으로 다시 파고 들었습니다.

서로 협업하여, 한발 한발 근본적인 원인을 찾아갔습니다. 아마 이게 디테일의 힘 아닐까 쉽습니다.

결국 서로 협의해서 “문제점을 조기에 알려주는 기능 (Early Warning)” 으로 서로 협의하고 찾아내었습니다.

역시 다른 것도 이렇게 한발 한발 찾아나갔습니다.  말싸움이지만 가치를 찾는 싸움을 계속 합의하고 고민하고 찾아 나갔습니다.

결국 오랜 시간 동안 힘들게 다음과 같은 가치를 도출했습니다.!!

Stanly는 0) 소프트웨어 개발 팀 에게  핵심 가치로   1) 소프트웨어를 확장 가능한 구조로 유지하고, 2) 문제점을 조기에 알려주고, 3) 직관적이고 명시적인 문제원인과 분석결과를 공유하는 가치를 제공한다.

정리하며.. 

지금까지 저희들은 stan4j 비슷한거라고 서로 머리속에 그림을 그려오기는 했으나, 각자 세부적인 생각들 즉 지향점이 다른  상태에서 시스템이 만들어 왔다는 것을 깨달았습니다.

일반사람도 쉽게 짧은 시간 안에 이 소프트웨어는 이러한 것을 하기 위해 만들어 졌구나 라고 하는 핵심 가치를 발굴하고 이 가치가 그대로 소프트웨어 개발 끝까지 가게 하는 것.  다른 생각들을 그룹화하고 모으고, 다시 흩어 뜨리고 다시 모으는 작업을 하면서 더 단단하게 만드는 작업을 했습니다.

물론 전략적 수정이 있을순 있으나, 그래도 시작지점에서 모두 동일한 가치를 깨닫고 갈수 있다는게  이 워크샵을 통해 얻을수 있었습니다.  Stanly 팀원 오혜성, 정승수, 양현철 만세!!  NHNNEXT 만세!!