기본 콘텐츠로 건너뛰기

만드는 사람이 행복해야 쓰는 사람도 행복하다.(소원의 나무 - UXcampSeoul 발표자료)

얼마전 UXcampSeoul 에서 소원의 나무 만들기라는 세션을 진행했습니다.

바쁘다는 핑계로 PT 자료를 만들지도 못했고 소원의 나무라는 것 자체가 아직까지는 저도 컨셉만을 가지고 있고 적용사례도 저 혼자이기 때문에 준비되지 못한 발표에 많은 분들에게 폐를 끼친 것은 아닌지 반성하게 되는 계기였습니다.

발표가 끝나고 발표자료를 PT로 만들어 볼까 몇차례 고민해 보았지만 PT까지 만들 자료는 아닌 것 같고 그렇다고 발표자료를 공유하지 않고 지나가자니 저 자신도 제 생각을 정리하고 다시금 돌아보는 기회를 놓치는 것 같아 이 포스팅을 발표자료로 갈음하는 바입니다.

소원의 나무라는 컨셉에 대해 읽어보시고 적용해보고 싶으시거나 의견이 있으시면 댓글이나 "murian.mentor 골뱅이 지메일 닷컴" 으로 연락주시기 바랍니다.

필요한 분이 계시다면 컨설팅이나 강연도 해드립니다.

그리고 소원의 나무는 제약이론을 수정한 개념으로 혹시 IT 조직에 제약이론을 적용하기 위해 제약이론을 같이 공부하기 원하시는 분은 "IT와 TOC의 융합을 연구하는 사람들" 에 가입해 주시면 고맙겠습니다.

소원의 나무의 출발점은 "콘웨이의 법칙" 에 대한 고민쯤부터입니다.

"콘웨이의 법칙" 에 대해서는 제가 이전에 적었던 글을 읽어보시기 바랍니다.

처음 콘웨이의 법칙을 적을 때 저는 콘웨이의 법칙에 대해 '팀의 프로세스가 복잡할수록 소프트웨어는 매우 복잡해진다.' 라고 소개했습니다.

그럼 이번에는 이걸 UX라는 관점에서 바꾸어 생각해 보면 이렇게 소개할 수 있을 것 같습니다.

"팀 구성원들의 사용자 경험이 나쁠 수록 소프트웨어 사용자의 경험은 더 나빠진다."

우리는 UX에 대해서 이야기 할때 많은 경우 User 즉, 사용자에만 집중합니다. 사용자가 더 나은 경험을 할 수 있게 하기 위해서 어떻게 할 것인지에 대해 논의합니다.

그 과정에 제품을 만드는 사람들의 경험은 빠져 있습니다.

그런데, 사람의 감정은 전염병이나 하품처럼 아주 쉽게 전염됩니다.

우리가 어떤 가게에 들어가서 그날따라 기분이 좋지 않았던 주인 아주머니로부터 불편한 대우를 받았을 때 그 감정이 쉽게 사그라들지 않는 것처럼 감정은 눈에 보이지 않지만 어떤 형태로든 제품에 반영되어 사용자에게 전달됩니다.

즉, 행복하지 않은 사람이 만든 제품은 고객조차 불행하게 만들 수 있다는 것이 제 생각입니다.

여러분은 소프트웨어를 개발하면서 얼마나 행복하신가요?

물론, 행복한 마음으로 즐겁게 직장생활을 하면서 소프트웨어를 개발하시는 분들도 있고 그런 조직도 있다고 전 믿습니다.

하지만 실제로 주변에서 듣는 얘기로는 계속되는 야근과 철야로 불행해진 가족관계라든지 격렬한 업무로 자신의 목숨을 끊는 직장인의 얘기를 어렵지 않게 떠올릴 수 있습니다.

그 사람들이 과연 행복했다고 얘기할 수 있을까요?

그렇다면 그런 불행한 일이 왜 생기는 것일까요?

왜 우리는 제품을 만들면서 행복하지 못한 것일까요?

여러가지 원인이 있을 수 있겠지만 제가 생각하는 원인은 정보의 병목때문이라고 생각합니다.

투명하지 않은 조직, 투명하지 않은 의사결정, 투명하지 않은 의사전달 등 조직 안에서 발생되는 수많은 정보들과 고객으로부터 전달되는 수많은 정보들이 효율적으로 효과적으로 공유되지 못하는 것에 그 원인이 있다고 생각합니다.

각각의 부서들이 각자의 사일로 갇혀 정보가 흐르지 못하는 것이 조직을 행복하지 못하게 하는 하나의 원인이라고 생각합니다.

그렇다면 제품 개발에 관여하는 수많은 이해관계자들이 왜 각자의 사일로에 갇혀 있는 것일까요?

저는 그 원인이 "지식의 저주" 다른 말로 "바벨탑의 저주" 라고 생각합니다.

예를 들어, 소프트웨어 개발에서 살펴보면 크게 '기획', '디자인', '설계', '개발', '마케팅', '영업', '인사' 등 수많은 부서들이 연관되어 있습니다.

하지만 그 많은 부서들이 하나의 방법론, 하나의 프로세스, 하나의 도구를 사용하는 경우는 많지 않습니다.

기획에 관련된 프로세스, 사용자 조사에 대한 프로세스, 사용자 인터페이스를 구축하는 도구, 개발 도구, 개발 언어, 테스트 방법론 등등 하나의 조직안에는 수도 없는 방법론과 프로세스, 도구들이 마치 흙탕물마냥 뒤섞여 있습니다.

기획 문서가 설계팀으로 넘어가면 기획 문서는 설계팀의 언어와 프로세스, 도구에 따라 변형되고 그 변형된 정보는 다시 개발팀으로 넘어가면 또다시 개발팀의 언어와 프로세스, 도구에 따라 그 다음 부서로 전달됩니다.

그렇게 정보가 오고가면서 필연적으로 언어, 도구, 프로세스의 차이로 인해 실제 정보는 변질되고 핵심은 사라지게 됩니다.

그러한 과정에서 싹튼 오해들은 결국에는 각각의 부서간의 정치적인 싸움과 알력싸움으로 번집니다.

하나의 목표로 나가야할 조직이 각각의 부서들의 탐욕을 위한 전장터에서 뒹구는 조직이 되어버립니다.

이런 조직에서 누가 사용자의 경험을 고민하고 그것의 개선을 위해 고민할 수 있을까요?

그래서 생각한 것이 소원의 나무입니다.

제품을 개발하는 모든 조직이 단 하나의 언어, 단 하나의 도구로 생각 할 수 있도록 도와주는 배우기 쉽고 쓰기도 쉬운 도구를 만들고 싶었습니다.

그리고 한가지 더 고민한 부분은 범용성입니다.

많은 경우 우리가 조직 안에 새로운 프로세스나 방법론, 도구를 도입할 때 기존의 모든 것들을 다 버리고 새로운 것을 도입하면서 겪는 엄청난 폐혜를 전 많이 봤습니다.

새로운 방법론에 대한 적응, 도구에 대한 학습 등으로 낭비되는 많은 자원들과 시간만큼 아까운 것은 없습니다.

어찌됐든 성공적으로 도입이 되면 다행이지만 만약에 도입이 실패로 끝날 경우 그에 대한 상실감과 허무함 그리고 실패에 대한 두려움등으로 다른 개선을 위한 시도에 대한 의지마저 상실된다면 그에 대한 손실은 정말 어마어마 합니다.

때문에 소원의 나무라고 해서 기존에 조직에서 사용되던 수많은 도구들을 모두 대체하는 용도가 아니라 그 수많은 도구들을 이어주는 일종의 번역기와 같은 역할만을 하도록 하는 것에 초점을 맞추었습니다.

즉, 제가 "소원의 나무"라고 이름 붙이 이 방법론 또는 도구의 특정은

1. 쉽게 배우고 쉽게 쓸 수 있다.
2. 기존의 도구나 방법론을 모두 사용할 수 있다.

가 되겠습니다.

그렇다면 "소원의 나무"를 만드는 방법에 대해 알려드리겠습니다.

"소원의 나무"를 만들기 위해서 알아야 할 것은 딱 2가지입니다.

1. If ~ then ~ (만약 ~ 하다면 ~ 하게 된다.)
2. It is necessary to have ~ in order to ~ (~ 하기 위해서는 ~ 할 필요가 있다.)

우선은 위 두가지만으로 소원의 나무를 만드실 수 있습니다. 사실 소원의 나무는 지금도 계속 개선되고 만들고 있는 과정에 있고 실제로는 조금 더 많은 방법들이 있지만 처음 시작하실 때에는 위의 2가지만 기억하시면 됩니다.

그러면 실제로 사용하는 법을 예제로 보겠습니다.

사용될 예제로 파일 삭제 및 복원 기능을 생각해 보겠습니다.

정해진 원칙은 없지만 소원의 나무를 만드실 때에는 멘탈모델 다이어그램처럼 인간이 취하는 행동만으로 만드시는 것이 조금은 이해하기 쉬운 나무를 만드실 수 있습니다.

파일 삭제 및 복원 기능에 대한 사용자의 소원(행동)으로 나무를 만든다면 아래와 같이 생각해 볼 수 있습니다.
읽는 법은 아래에서 위로 If ~ then ~ 을 적용해서 읽고, 다시 반대로 위에서부터 아래로 It is necessary to have ~ in order to ~ 로 읽어서 어느쪽으로 읽어도 거부감이 들지 않을때까지 다듬으시면 됩니다.

위의 예제에서 본다면 '만약 파일을 삭제한다면 삭제된 파일을 확인한다.' 로 읽어야 하는데 이렇게 읽을 경우 문장에 매끄럽지 않습니다. 이렇게 만들어진 나무는 잘못 만들어진 것입니다.

사실 중간의 '삭제된 파일을 확인한다.' 필요없는 부분입니다.

필요없는 부분을 제외하고 읽어보면 '만약 파일을 삭제한다면 파일을 복원하고 싶다.' 가 되고, 반대로 읽으면 '파일을 복원하기 위해서는 파일을 삭제해야만 한다' 로 읽을 수 있습니다. 어느쪽으로 읽어도 논리적으로 타당하다면 제대로 그린 것입니다.

그럼 이렇게 그린 나무가 과연 어떤 의미가 있을까요? 이 나무 하나만으로는 아무런 의미가 없습니다. 이 나무는 대화를 위한 도구일 뿐입니다.

파일 삭제와 파일 복구 기능을 구현하기 위한 뼈대라고 생각하시면 됩니다.

일전에 윈도우와 리눅스의 파일 삭제 및 복원에 대한 사용성을 비교하면서 윈도우의 사용성이 좋지 않다라고 한적이 있습니다.

위 나무에서 생각해 본다면 파일의 삭제 및 복원은 단 한번의 클릭으로 가능해야 합니다. 하지만 실제적으로 윈도우에서 파일을 삭제하기 위한 행동은 아래와 같이 복잡하기만 합니다.
즉, 소원의 나무를 사용성 개선을 위한 도구나 멘탈모델 다이어그램을 검증하는 용도로 사용할 수도 있습니다.

저는 테스트 케이스를 만드는 용도로도 사용하고 있습니다.

만약 제품을 기획하는 단계라면 아래와 같이 제품의 기능을 다듬고 생각해 보는 용도로 사용될 수도 있습니다.
이와 같이 소원의 나무는 여러 용도로 사용될 수 있는 일종의 대화 도구라고 생각하시면 됩니다.

필요하다면 마인드맵, 원인-결과 다이어그램, 제어흐름도, UML 어떤 도구와도 같이 사용하실 수 있습니다.

지켜야 하는 것은

1. If ~ then ~ (만약 ~ 하다면 ~ 하게 된다.)
2. It is necessary to have ~ in order to ~ (~ 하기 위해서는 ~ 할 필요가 있다.)

로 읽어서 논리적으로 오류가 없어야 한다는 것과 하나의 기능으로부터 위로 올라가면서 각 기능(행동, 소원) 들이 논리적으로 묶여야 한다는 것 뿐입니다.

적용하기에 따라서 여러 용도로 사용될 수도 있습니다. 여러분은 어떤 용도로 사용하실 수 있다고 생각하시나요?

실제로 적용해 보시고 피드백을 주시면 고맙겠습니다.

댓글

  1. trackback from: 사용과 이용을 넘어...
    사전적으로 사용은 일정한 목적이나 기능에 맞게 쓰는 것이다. 그리고 이용은 대상을 필요에 따라 이롭게 쓰는 것이라고 한다. 어떤 서비스를 만들었을 때 쓰는 사람이 설계자의 의도대로 쓸때는 사용자이며 애초에 제공했던 의도가 아니라 다른 목적에 사용한다면 이용하고 있다고 할 수 있겠다. 당신은 이메일을 의사소통 용도로만 쓰고 있나요? 이메일을 생각해보자. 과연 이메일이 의사소통의 목적으로만 사용되고 있는지 떠올려보자. 그리고 그것을 위해서만 만들어졌다면..

    답글삭제

댓글 쓰기

이 블로그의 인기 게시물

테슬라 구매 과정 후기

올해 제 인생 최대 지름이 될.. 테슬라 구매를 했습니다. 스파크만 13년을 몰았는데... 내자분이 애들도 컸고.. 이젠 스파크가 좁고 덥고 힘들다면서... 4월 6일 하남 테슬라 전시장에서 새로 나온 업그레이드 된 모델 3를 보고 4월 7일 덜컥 계약을 해버리게 되었습니다. 이후에 4월 11일에 보조금 설문 조사 문자를 받았습니다. 그리고 다시 기다림의 시간이.. 사실, 처음에 하얀색을 계약을 했다가 하얀색은 관리하기가 너무 힘들거 같아 4월 20일에 블루로 변경을 했었는데.. 다른 사람들은 하나 둘 차량을 인도 받는데.. 아무리 기다려도 인도 일정이 배정이 되지 않아서... 혹시나 하고 4월 25일 하얀색으로 변경하자마자 VIN이 배정되고 4월 29일 인도 일정 셀프 예약 문자가 왔습니다. 파란색이 정말 인기가 없었나 봅니다. (그런데, 소문에 듣자하니.. 파란색은 5월 첫주부터 인도 일정 셀프 예약 문자가 왔었다고 합니다.. 크흑.. ㅠㅠ) 덕분에 기다리고 기다리긴 했지만 아무 준비도 없던 와중에 이제부터 정말 실제 차량을 인도받기 위한 질주가 시작되었습니다. 4월 30일 셀프 인도 예약 완료 문자가 왔고 5월 2일 오전 10시 5분에 전기자동차 구매지원 자격 부여 문자가 오고 오후 3시 5분에 전기차 보조금 지원 대상자 확정 문자를 받았습니다. 사실 기다림의 시간이 제일 힘든건.. 보조금을 못받으면 어떻게 하지?라는 초조함이었습니다. 얼마 안되는 보조금이라고 하더라도 한푼이 아쉬운 입장에서는 정말 필요한 돈이었는데.. 다행히 큰 문제 없이 지원 대상자가 될 수 있었습니다. 그리고 5월 2일 오후 4시 12분에 차량 대금을 후다닥 결제를 진행했습니다. 유투브와 네이버 카페 등을 열심히 읽어두었지만 막상 진행해보니 다른 설명과는 좀 다르게 진행되어서 불안했었는데.. 큰 문제 없이 결제가 완려되었습니다. 이미 차량 인도는 5월 14일로 결정되었기 때문에 이제는 차량 등록에 대한 기다림이 시작되었습니다. 드디어 5월 8일 오후 2시 23분에 등록 대행 비용 및

테스트 케이스와 체크리스트의 차이가 뭐여?

테스트 실무에서 가장 혼돈되어 사용되는 용어 중 하나가 테스트 케이스와 체크리스트입니다. 많은 경우 체크리스트를 테스트 케이스로 사용하는 경우가 많습니다. 실제로 인터넷 커뮤니티나 블로그, ISO, IEEE, ISTQB 등등을 검색해보시면 테스트 케이스와 체크리스트에 대한 구분이 다 제각각입니다. 각각에 대한 정의가 다 제각각입니다. 사정이 이러하다보니 많은 사람들이 테스트 케이스와 체크리스트를 잘 구분하지 못하고 혼동해서 사용하는 경우가 많습니다. 물과 기름처럼 테스트 케이스와 체크리스트를 정확하게 구분할 수는 없겠지만.. ISTQB를 기준으로 말씀드리면 설계 기법을 통해 도출된 것은 테스트 케이스 그렇지 않은 것은 체크리스트라고 생각하시면 쉽습니다. 예를 들면 아래는 결정 테이블 테스팅 기법을 통해 도출된 테스트 케이스의 예제입니다. 실제 테스트 케이스는 위보다 복잡하겠지만 어쨌든 얘기하고 싶은 것은 위와 같이 설계 기법을 통해서 도출된 것은 테스트 케이스라고 합니다. 그런데 딱 보시면 아시겠지만 실제 테스트에서는 저 정도로는 테스트 커버리지를 충분히 만족했다고 얘기하기 힘듭니다. 그렇습니다. 어떤 분들은 테스트 케이스가 전가의 보도, 은 총알 쯤으로 생각하시는데.. 테스트 케이스는 일종의 마지노 선이라고 보시면 됩니다. 최소한 제품을 테스트 할때 이정도는 해줘야 한다는 최후의 방어선 정도라고 보시면 됩니다. 전쟁에서 최후의 방어선은 물러설 수 없는 마지막 보루입니다. 하지만 최후의 방어선만 지킨다고 전쟁에서 승리할 수는 없습니다. 프랑스는 마지노 요새만 믿고 있다가 독일에게 깔끔하게 발렸던 과거가 있지요. 전쟁에서 승리하려면 앞으로 나가야하고 치밀한 전략과 전술이 뒷받침 되어야 합니다. 더 높은 커버리지를 도달하고, 충분히 좋은 테스트가 수행되려면 테스트 케이스는 기본이 되어야 하고 거기에 더해서 체크리스트가 따라와 줘야 합니다. 이러한 체크리스트는 팀의 경험과 과거 프로젝트의 데이

비츠 스튜디오 버즈 플러스(투명) 사용 후기

제 내자분은 아직도 유선 이어폰을 쓰고 있습니다. 그게 좋다고 하시더라구요. 작년에 혹시나 해서 앤커 사운드코어 라이프Q35를 구매해서 조공해봤지만 결국은 안쓰시더라구요. 그래서 작년 추운 겨울에 제가 귀마게 용으로 잘 사용해왔는데.. 여름이 되니.. 와.. 이건 너무 덥고 무거워서 못쓰겠더라구요. 아이폰도 사고 애플 워치도 샀으니.. 다음은 에어팟인데.... 노이즈 캔슬링이 된다는 에어팟 프로 2는 ... 네... 너무 비싸더라구요... 이건 내자분께 얘기해봐야 결제가 될리가 없어서... 고민하고 있던차에.. 네.. 저는 봐버리고 말았습니다. 비츠 스튜디오 버즈 플러스의 그 영롱한 투명 버전의 자태를... 급 뽐뿌가 왔지만.. 여전히 20만원의 고가더라구요... 초기 출시 시기에 이벤트로 16만원 정도 했던거 같은데.. 그정도 가격이면 선 결제 후 보고 하면 될거 같은데.. 20만원은 너무 너무 비싸서 침만 삼키던 차에.. 당근에 15만원에 올라온 물건을 덥석 물었습니다. 애플 뮤직 6개월 프로모션 코드도 사용하지 않은 따끈따끈한 제품이라서 그냥 질렀습니다. 이상하게 인터넷이 실제 리뷰 게시물을 찾기 힘들어서.. 고민을 잠깐 했지만.. 그 투명하고 영롱한 자태에 그만... 어쨌든 구매하고 한달 정도 사용해본 후기를 간단하게 남겨봅니다. 1. 노이즈 캔슬링은 기대한 것과는 좀 다르고 앤커 사운드코어 라이프Q35 정도 되는 것 같습니다. 노이즈 캔슬링은 활성화하면 이게 소리를 막아준다기보다는 주변의 작은 소음만 제거해준다고 생각하시면 됩니다. 그러니까 옆에서 소근 거리는 소리나 선풍기 바람 소리 같은 작은 소리들이 사라지고 음악 같은 내가 듣고자 하는 소리가 굉장히 뚜렸해지만 지하철 안내 방송 같은 조금 큰 소리는 그냥 들립니다. 그래서 주변음 허용 모드를 켜보면 너무 시끄러워서 안쓰게 되더라구요. 전 에어팟 프로 2를 사용해 본적이 없어서 비교할 수는 없지만.. 아주 못쓸 정도의 성능은 아니라고 생각됩니다. 2. 저는 귓구멍이 너무 작아서 XS 사이즈의 이어팁