얼마전 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 ~ (~ 하기 위해서는 ~ 할 필요가 있다.)
로 읽어서 논리적으로 오류가 없어야 한다는 것과 하나의 기능으로부터 위로 올라가면서 각 기능(행동, 소원) 들이 논리적으로 묶여야 한다는 것 뿐입니다.
적용하기에 따라서 여러 용도로 사용될 수도 있습니다. 여러분은 어떤 용도로 사용하실 수 있다고 생각하시나요?
실제로 적용해 보시고 피드백을 주시면 고맙겠습니다.
바쁘다는 핑계로 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가지만 기억하시면 됩니다.
그러면 실제로 사용하는 법을 예제로 보겠습니다.
사용될 예제로 파일 삭제 및 복원 기능을 생각해 보겠습니다.
정해진 원칙은 없지만 소원의 나무를 만드실 때에는 멘탈모델 다이어그램처럼 인간이 취하는 행동만으로 만드시는 것이 조금은 이해하기 쉬운 나무를 만드실 수 있습니다.
파일 삭제 및 복원 기능에 대한 사용자의 소원(행동)으로 나무를 만든다면 아래와 같이 생각해 볼 수 있습니다.
위의 예제에서 본다면 '만약 파일을 삭제한다면 삭제된 파일을 확인한다.' 로 읽어야 하는데 이렇게 읽을 경우 문장에 매끄럽지 않습니다. 이렇게 만들어진 나무는 잘못 만들어진 것입니다.
사실 중간의 '삭제된 파일을 확인한다.' 필요없는 부분입니다.
필요없는 부분을 제외하고 읽어보면 '만약 파일을 삭제한다면 파일을 복원하고 싶다.' 가 되고, 반대로 읽으면 '파일을 복원하기 위해서는 파일을 삭제해야만 한다' 로 읽을 수 있습니다. 어느쪽으로 읽어도 논리적으로 타당하다면 제대로 그린 것입니다.
그럼 이렇게 그린 나무가 과연 어떤 의미가 있을까요? 이 나무 하나만으로는 아무런 의미가 없습니다. 이 나무는 대화를 위한 도구일 뿐입니다.
파일 삭제와 파일 복구 기능을 구현하기 위한 뼈대라고 생각하시면 됩니다.
일전에 윈도우와 리눅스의 파일 삭제 및 복원에 대한 사용성을 비교하면서 윈도우의 사용성이 좋지 않다라고 한적이 있습니다.
위 나무에서 생각해 본다면 파일의 삭제 및 복원은 단 한번의 클릭으로 가능해야 합니다. 하지만 실제적으로 윈도우에서 파일을 삭제하기 위한 행동은 아래와 같이 복잡하기만 합니다.
저는 테스트 케이스를 만드는 용도로도 사용하고 있습니다.
만약 제품을 기획하는 단계라면 아래와 같이 제품의 기능을 다듬고 생각해 보는 용도로 사용될 수도 있습니다.
필요하다면 마인드맵, 원인-결과 다이어그램, 제어흐름도, UML 어떤 도구와도 같이 사용하실 수 있습니다.
지켜야 하는 것은
1. If ~ then ~ (만약 ~ 하다면 ~ 하게 된다.)
2. It is necessary to have ~ in order to ~ (~ 하기 위해서는 ~ 할 필요가 있다.)
로 읽어서 논리적으로 오류가 없어야 한다는 것과 하나의 기능으로부터 위로 올라가면서 각 기능(행동, 소원) 들이 논리적으로 묶여야 한다는 것 뿐입니다.
적용하기에 따라서 여러 용도로 사용될 수도 있습니다. 여러분은 어떤 용도로 사용하실 수 있다고 생각하시나요?
실제로 적용해 보시고 피드백을 주시면 고맙겠습니다.
trackback from: 사용과 이용을 넘어...
답글삭제사전적으로 사용은 일정한 목적이나 기능에 맞게 쓰는 것이다. 그리고 이용은 대상을 필요에 따라 이롭게 쓰는 것이라고 한다. 어떤 서비스를 만들었을 때 쓰는 사람이 설계자의 의도대로 쓸때는 사용자이며 애초에 제공했던 의도가 아니라 다른 목적에 사용한다면 이용하고 있다고 할 수 있겠다. 당신은 이메일을 의사소통 용도로만 쓰고 있나요? 이메일을 생각해보자. 과연 이메일이 의사소통의 목적으로만 사용되고 있는지 떠올려보자. 그리고 그것을 위해서만 만들어졌다면..