1장 관찰하기
001 팀장 밥
1990년대 초반, 오라클 컨설팅 부서에서 근무했고, 비행기를 타고 다른 고객사로 가서 오라클 기반 고객 애플리케이션 시스템이 빠르게 실행되게 도와주는 업무를 맡았다.
당시 내 매니저는 로버트였고, 밥이라고 불렀다.
일은 어려웠는데 기술적인 문제가 아니라 정치적인 문제였다.
고객사에 방문하면 사람들이 대부분 노골적으로 적대적인 태도를 보였다.
개인적으로 싫어해서가 아니라 내 명함의 오라클 로고가 싫었던 것이다.
소프트웨어 수정만이 문제 해결의 전부는 아니었다.
내 업무는 다음과 같은 4단계가 필요했다.
- 경청하기: 사람들이 분노와 불만이 가득한 이유를 설명하도록 일단 이야기를 들어준다.
- 진정시키기: 사람들이 좀 더 분명하게 생각할 수 있도록 마음을 가라앉힌다.
- 설득하기: 그들이 신뢰할 수 있는 절차를 내가 가지고 있다고 납득시킨다.
- 해소하기: 사람들의 분노와 불만을 해소시킨다.
002 필리스의 테스트
밥은 고객사에 가서 해야 할 일을 알려줬다.
시간이 지나자 스스로 어떤 작업을 수행해야 하는지 결정할 수 있게 해줬다.
어느 월요일에, 새 고객사에 가서 새로 구입한 디스크 드라이브에 데이터베이스 파일을 균등하게 배치하는 업무를 했다.
수요일 오후에 시스템을 테스트할 수 있다고 알렸는데, 매니저가 내게 필리스(가명)와 그녀의 동료 몇 명을 소개해줬다.
필리스는 회계 부서의 리더였는데 새 디스크 구매 비용과 컨설팅 비용이 불만이어서 현재 시스템을 마음에 들어하지 않았다.
필리스는 몇 가지 명령을 입력하고 결과가 빠르게 처리되지 않으면 파견 업무를 실패로 간주하겠다고 했다.
난 대체 필리스가 뭘 실행하는지, 월요일에 왜 아무도 내게 필리스에 대해 얘기해주지 않았는지 궁금했다.
몇 초 후에 필리스는 엄지를 들어올렸다.
필리스를 내게 소개해주거나 내 컨설팅의 목적이 무엇인지 말해주지 않은 건 그만한 이유가 있었다.
난 그저 파일을 재배치하는 일을 하러 온 사람일 뿐이엇고 결정권이 없었기 때문이다.
테스트가 실패했다면 내가 모든 비난을 받았을 것이다.
운이 좋아 필리스의 테스트는 성공적이었다.
만약 필리스의 작업이 느린 원인이 내가 파일을 재배치한 것과 무관한 다른 이유였다면 테스트는 실패했을 것이다.
운이 좋았지만 운빨로 경력을 이어가고 싶지 않았기에 밥에게 일어난 일을 설명했고 내 파견 업무를 결정하는 과정에 나도 참여할 필요가 있다고 얘기했다.
밥은 동의했고 이후 사전 준비 회의에서 내 파견 업무에 어떤 비즈니스 동기가 있는지 알 수 있게 됐다.
003 진짜 목표
고객은 새 디스크에 파일을 잘 배치하는 걸 원한다고 생각했다.
하지만 고객은 기술적인 것엔 관심이 없고, 자신들의 작업이 더 빨라졌는지에만 초점이 맞춰져 있었다.
파일 재배치는 필리스가 원하는 작업이 빨라질 것이라고 믿은 것이고 진짜 목표라기 보다는 누군가 제안한 해결책일 뿐이었다.
이 일화에서 배운 점은 한 마디로 표현할 수 있다.
관찰하자. Look at It
관찰에는 2가지 단계가 필요하다
- 관찰해야 하는 것이 무엇인지 알아낸다.
- 그것을 어떻게 관찰할지 방법을 알아낸다.
첫 번째 단계는 경청할 대상을 바꾸는 것이다.
두 번째 단계는 도구가 필요하다.
004 낸시의 좁은 칸막이 책상
낸시(실명)를 처음 만난 것은 1994년 콜로라도주 덴버였다.
파견 업무에서 여러 고객들의 문제를 들었지만 오라클 파이낸스 사이트에서 했던 6개의 아이템을 달달 외워서 실행하는 정도의 수준이었다.
내가 뭘 하게 될지는 이미 거의 알고 있었고, 파견 나갔던 고객사에는 동일한 문제를 반복해서 겪고 있었다.
제품의 설계상 설정 오류를 범할 수 밖에 없었고 사람들이 어떤 실수를 하는지 이미 알고 있었으며 그 문제를 고치는 방법도 알았다.
기술적인 요청을 했던 사람들에게 모두 연락해 문제를 해결했지만 낸시는 그렇지 못했다.
낸시의 업무는 청구서를 받아 납입을 하는 일이었다.
제록스 복사기 비용의 청구서를 매달 제록스에 납입하는데, 제록스 청구서를 싫어하는 이유는 한달에 한번만 납입하는 청구서 비용을 애플리케이션에서 불러와야 하는데 이름이 정확하게 기억나지 않는게 문제였다.
제록스 청구서에 공급업체 이름을 입력하기 위해 키보드에서 \ Q R을 차례로 입력했다.
Q는 검색 메뉴, R은 검색을 실행하는 키였다.
화면에 표시된 검색 결과의 첫 페이지는 A로 시작하는 공급업체 이름 12개가 출력되어 있었다.
그리고 오른쪽 검지로 다음 화면 키를 입으로 세면서 스물여섯번을 눌렀다.
제록스가 표시될 때 까지 다음 화면 키를 스물여섯번 눌러야 한다고 했다.
애플리케이션은 그 속도를 쫓아가지 못하고 있었다.
화면은 덜컥거리면서 갱신되고 있었고 화면의 반쯤 나왔다가 1초 정도 멈춘 후 다시 다음 페이지를 표시하기를 반복했다.
수십 초의 화면이 그렇게 진행됐는데 그 시간은 마치 영원처럼 느껴졌다.
마침내 제록스의 공급업체 이름이 나왔고 Xerox Corp 행을 선택했다.
사실 난 이 문제를 해결하는 방법을 알고 있었다.
하지만 너무 오랫동안 이 문제로 괴롭힘을 받은 사람에게 쉽다는 말을 함부로 꺼내면 무례하게 보일 수 있기 때문에 말을 조심해야 했다.
낸시에게 공급업체 이름을 필드에 입력하는 상황에서 x를 입력하고 리턴 키를 눌러보라고 했다.
짜잔, x로 시작하는 회사 3개의 목록이 바로 화면에 떴다.
낸시는
"어머나! 이게 뭐에요! 이런 게 된다고요?!" 라면 활짝 웃었다.
찾으려는 글자를 입력하고 리턴키를 누르면 패턴이 일치하는 결과를 표시하는 기능이 있다고 설명해주자 낸시는 같은 부서의 전체 인원이 똑같은 문제로 고생하고 있었다며 회의를 소집하겠다고 했다.
낸시는 이 문제 때문에 새 시스템을 싫어하고 있었다.
005 올바른 지점을 관찰하기
고객사 별 도메인 지식에 대해 많이 알고 있지 않을 수 있다.
하지만 연습을 하다 보면 사용자와의 대화가 습관이 되어 더 이상 부담스럽지 않게 된다.
기억하자.
"잘 모르겠습니다. 하지만 문제 해결을 도와드릴 순 있어요." 라고 말해보자.
그게 바로 리더십이 발휘되는 순간이다.
진짜 문제는 서버실이나 네트워크 케이블에 있지 않다.
서버실에서 문제를 제대로 보고 있었지만, 그 문제의 엉뚱한 부분을 바라보고 있었던 것이다.
우리는 문제의 증상 관점, 즉 사용자가 바라보는 방식으로 관찰해야 한다.
낸시가 타이핑하는 광경을 보지 않았다면 그 문제를 절대로 해결하지 못했을 것이다.
그러니, 증상이 처음 발현된 곳으로 가보자.
덴버에서의 교훈은 그저 관찰하라는 것이 아니라 문제의 증상에 주의를 기울이라는 것이었다.
006 관찰할 수 없는 상황이라면
그래도 답은 있다.
화면 공유
1994년에 Zoom이 있었다면 낸시의 사무실에 가지 않고도 문제를 해결할 수 있었을 것이다.
텔레메트리
소프트웨어를 사용하는 사람들이 어떻게 생각하는지 정말 알고 싶다면
그 사람들의 경험을 측정하고 기록해야 한다.
- 어떤 기능이 측정되고 있나?
- 기능의 실행이 언제 시작되었나?
- 기능의 실행이 언제 완료되었나?
- 누가 기능을 실행했는가?
- 기능의 실행이 어디서 이뤄졌나?
- 기능을 실행해서 얼마나 많은 업무가 이뤄졌는가?
- 기능 실행 후 리턴된 상태는 무엇인가?
누군가 형편없는 경험을 했을 때 데이터에 드러나게 될 것이고, 이 데이터를 증상의 관점에서 관찰할 수 있게 된다.
그리고 문제를 해결하면 그 결과도 데이터에 나타나게 될 것이다.
이와 같은 정보를 기록하면 애플리케이션을 더욱 용이하게 관측할 수 있다.
시뮬레이션
시스템의 사용자 경험을 시뮬레이션 하는 기능을 애플리케이션에 탑재한다.
예로 네트워크 연결 성능을 의도적으로 저하시켜볼 수도 있다.
사용자가 경험하는 대로 여러분의 시스템을 바라보는 것은 곧 여러분의 우선순위를 회사나 고객의 우선순위와 맞추는 방법을 알아가는 시작점이 된다.
1장 관찰하기
001 팀장 밥
1990년대 초반, 오라클 컨설팅 부서에서 근무했고, 비행기를 타고 다른 고객사로 가서 오라클 기반 고객 애플리케이션 시스템이 빠르게 실행되게 도와주는 업무를 맡았다.
당시 내 매니저는 로버트였고, 밥이라고 불렀다.
일은 어려웠는데 기술적인 문제가 아니라 정치적인 문제였다.
고객사에 방문하면 사람들이 대부분 노골적으로 적대적인 태도를 보였다.
개인적으로 싫어해서가 아니라 내 명함의 오라클 로고가 싫었던 것이다.
소프트웨어 수정만이 문제 해결의 전부는 아니었다.
내 업무는 다음과 같은 4단계가 필요했다.
002 필리스의 테스트
밥은 고객사에 가서 해야 할 일을 알려줬다.
시간이 지나자 스스로 어떤 작업을 수행해야 하는지 결정할 수 있게 해줬다.
어느 월요일에, 새 고객사에 가서 새로 구입한 디스크 드라이브에 데이터베이스 파일을 균등하게 배치하는 업무를 했다.
수요일 오후에 시스템을 테스트할 수 있다고 알렸는데, 매니저가 내게 필리스(가명)와 그녀의 동료 몇 명을 소개해줬다.
필리스는 회계 부서의 리더였는데 새 디스크 구매 비용과 컨설팅 비용이 불만이어서 현재 시스템을 마음에 들어하지 않았다.
필리스는 몇 가지 명령을 입력하고 결과가 빠르게 처리되지 않으면 파견 업무를 실패로 간주하겠다고 했다.
난 대체 필리스가 뭘 실행하는지, 월요일에 왜 아무도 내게 필리스에 대해 얘기해주지 않았는지 궁금했다.
몇 초 후에 필리스는 엄지를 들어올렸다.
필리스를 내게 소개해주거나 내 컨설팅의 목적이 무엇인지 말해주지 않은 건 그만한 이유가 있었다.
난 그저 파일을 재배치하는 일을 하러 온 사람일 뿐이엇고 결정권이 없었기 때문이다.
테스트가 실패했다면 내가 모든 비난을 받았을 것이다.
운이 좋아 필리스의 테스트는 성공적이었다.
만약 필리스의 작업이 느린 원인이 내가 파일을 재배치한 것과 무관한 다른 이유였다면 테스트는 실패했을 것이다.
운이 좋았지만 운빨로 경력을 이어가고 싶지 않았기에 밥에게 일어난 일을 설명했고 내 파견 업무를 결정하는 과정에 나도 참여할 필요가 있다고 얘기했다.
밥은 동의했고 이후 사전 준비 회의에서 내 파견 업무에 어떤 비즈니스 동기가 있는지 알 수 있게 됐다.
003 진짜 목표
고객은 새 디스크에 파일을 잘 배치하는 걸 원한다고 생각했다.
하지만 고객은 기술적인 것엔 관심이 없고, 자신들의 작업이 더 빨라졌는지에만 초점이 맞춰져 있었다.
파일 재배치는 필리스가 원하는 작업이 빨라질 것이라고 믿은 것이고 진짜 목표라기 보다는 누군가 제안한 해결책일 뿐이었다.
이 일화에서 배운 점은 한 마디로 표현할 수 있다.
관찰에는 2가지 단계가 필요하다
첫 번째 단계는 경청할 대상을 바꾸는 것이다.
두 번째 단계는 도구가 필요하다.
004 낸시의 좁은 칸막이 책상
낸시(실명)를 처음 만난 것은 1994년 콜로라도주 덴버였다.
파견 업무에서 여러 고객들의 문제를 들었지만 오라클 파이낸스 사이트에서 했던 6개의 아이템을 달달 외워서 실행하는 정도의 수준이었다.
내가 뭘 하게 될지는 이미 거의 알고 있었고, 파견 나갔던 고객사에는 동일한 문제를 반복해서 겪고 있었다.
제품의 설계상 설정 오류를 범할 수 밖에 없었고 사람들이 어떤 실수를 하는지 이미 알고 있었으며 그 문제를 고치는 방법도 알았다.
기술적인 요청을 했던 사람들에게 모두 연락해 문제를 해결했지만 낸시는 그렇지 못했다.
낸시의 업무는 청구서를 받아 납입을 하는 일이었다.
제록스 복사기 비용의 청구서를 매달 제록스에 납입하는데, 제록스 청구서를 싫어하는 이유는 한달에 한번만 납입하는 청구서 비용을 애플리케이션에서 불러와야 하는데 이름이 정확하게 기억나지 않는게 문제였다.
제록스 청구서에 공급업체 이름을 입력하기 위해 키보드에서 \ Q R을 차례로 입력했다.
Q는 검색 메뉴, R은 검색을 실행하는 키였다.
화면에 표시된 검색 결과의 첫 페이지는 A로 시작하는 공급업체 이름 12개가 출력되어 있었다.
그리고 오른쪽 검지로 다음 화면 키를 입으로 세면서 스물여섯번을 눌렀다.
제록스가 표시될 때 까지 다음 화면 키를 스물여섯번 눌러야 한다고 했다.
애플리케이션은 그 속도를 쫓아가지 못하고 있었다.
화면은 덜컥거리면서 갱신되고 있었고 화면의 반쯤 나왔다가 1초 정도 멈춘 후 다시 다음 페이지를 표시하기를 반복했다.
수십 초의 화면이 그렇게 진행됐는데 그 시간은 마치 영원처럼 느껴졌다.
마침내 제록스의 공급업체 이름이 나왔고 Xerox Corp 행을 선택했다.
사실 난 이 문제를 해결하는 방법을 알고 있었다.
하지만 너무 오랫동안 이 문제로 괴롭힘을 받은 사람에게 쉽다는 말을 함부로 꺼내면 무례하게 보일 수 있기 때문에 말을 조심해야 했다.
낸시에게 공급업체 이름을 필드에 입력하는 상황에서 x를 입력하고 리턴 키를 눌러보라고 했다.
짜잔, x로 시작하는 회사 3개의 목록이 바로 화면에 떴다.
낸시는
"어머나! 이게 뭐에요! 이런 게 된다고요?!" 라면 활짝 웃었다.
찾으려는 글자를 입력하고 리턴키를 누르면 패턴이 일치하는 결과를 표시하는 기능이 있다고 설명해주자 낸시는 같은 부서의 전체 인원이 똑같은 문제로 고생하고 있었다며 회의를 소집하겠다고 했다.
낸시는 이 문제 때문에 새 시스템을 싫어하고 있었다.
005 올바른 지점을 관찰하기
고객사 별 도메인 지식에 대해 많이 알고 있지 않을 수 있다.
하지만 연습을 하다 보면 사용자와의 대화가 습관이 되어 더 이상 부담스럽지 않게 된다.
기억하자.
"잘 모르겠습니다. 하지만 문제 해결을 도와드릴 순 있어요." 라고 말해보자.
그게 바로 리더십이 발휘되는 순간이다.
진짜 문제는 서버실이나 네트워크 케이블에 있지 않다.
서버실에서 문제를 제대로 보고 있었지만, 그 문제의 엉뚱한 부분을 바라보고 있었던 것이다.
우리는 문제의 증상 관점, 즉 사용자가 바라보는 방식으로 관찰해야 한다.
낸시가 타이핑하는 광경을 보지 않았다면 그 문제를 절대로 해결하지 못했을 것이다.
덴버에서의 교훈은 그저 관찰하라는 것이 아니라 문제의 증상에 주의를 기울이라는 것이었다.
006 관찰할 수 없는 상황이라면
그래도 답은 있다.
화면 공유
1994년에 Zoom이 있었다면 낸시의 사무실에 가지 않고도 문제를 해결할 수 있었을 것이다.
텔레메트리
소프트웨어를 사용하는 사람들이 어떻게 생각하는지 정말 알고 싶다면
그 사람들의 경험을 측정하고 기록해야 한다.
누군가 형편없는 경험을 했을 때 데이터에 드러나게 될 것이고, 이 데이터를 증상의 관점에서 관찰할 수 있게 된다.
그리고 문제를 해결하면 그 결과도 데이터에 나타나게 될 것이다.
이와 같은 정보를 기록하면 애플리케이션을 더욱 용이하게 관측할 수 있다.
시뮬레이션
시스템의 사용자 경험을 시뮬레이션 하는 기능을 애플리케이션에 탑재한다.
예로 네트워크 연결 성능을 의도적으로 저하시켜볼 수도 있다.
사용자가 경험하는 대로 여러분의 시스템을 바라보는 것은 곧 여러분의 우선순위를 회사나 고객의 우선순위와 맞추는 방법을 알아가는 시작점이 된다.