이게 말이야.. 딱 하고 말이야..

고객 : 이게 지금 딱 안나와버리는데 이게 이게...
나 : 어떤게 안되신다는 말씀이신가요?

고객 : 그러니까 진행이 이게 안되버리는데...
나 : 결제가 안되신다는 말씀이신가요?

고객 : 그렇지요. 그러니까 딱 누르면 딱 되야 하는데 딱 안되서 이게...
나 : ...현재 보이는 글자가 있으면 읽어주시겠어요?

고객 : 그러니까 그거야 이렇죠 뭐 이게 딱....그러니까...음 딱...
나 : ....

고객 : 이게 할려고 해도 이게 안되고 뭔가 뜨는데
나 : 그 뜨는거가 뭔지 알려주시겠어요?

고객 : 이게 이렇게 어렵게 말고 그냥 이게 돈만 보내면 딱 알고 보내주는 그런거 없습니까?
나 : 저희는 사이트에서 주문을 해주셔야 해서요.

고객 : 그럼 이게 이렇게 딱 하면 되면 되는데 이게 이게
나 : ....

이분 말에서 '이게'와 '딱'을 제외하면 엄청나게 압축되거나 아무것도 안남을 것 같다 -_-

이 블로그의 인기 게시물

프로젝트의 3요소 - Project Management

프로젝트는 예산, 일정, 품질 3가지 요소로 이루어진다고 볼 수 있다. 물론 위 3가지 요소 외에도 개발 범위, 팀워크, 자원 조달 등 여러가지 요소들도 고려해 볼 수 있지만, 가장 중요한 요소를 꼽는다면 예산, 일정, 품질일 것이다. 위에서 말한 여러가지 요소들은 프로젝트를 계획하여 완료하는 순간까지 복합적으로 작용해서 프로젝트의 성과를 제한하게 된다. 위의 요소들을 잘 통제한다면 성공적인 프로젝트가 되는 것이고 그렇지 못한다면 실패하거나 사라지게 될 것이다. 프로젝트 관리란 그런 면에서 제한된 자원을 가지고 목적한 바를 제한된 기간내에 최소의 비용으로 완수할 수 있도록 하는 것으로 정의할 수 있을 것이다. 이것을 도식화 한다면 아래와 같은 그림으로 표현할 수 있을 것이다. 위의 그림에 보는 것처럼 일정과 품질, 예산은 우리의 프로젝트가 목적하는 바를 달성하도록 하기 위해 상호 연관되어 작용하게 된다. 우리가 접하게 되는 많은 방법론들의 가정에는 위의 요소들을 어떻게 관리할 것인가에 대한 기본적인 가정들이 설정되어 있다. 조직에서 어떤 특정한 방법론을 도입한다는 것은 그런 가정에 동의하는 것이고 그러한 철학을 받아들인다는 것이기 때문에, 방법론을 채택하기 전에 조직의 근본 문제와 문화에 대해 점검해 볼 필요가 있다. 그리고 위의 요소들 외에 고려해 볼 사항은 위의 요소들은 변동성과 불확실성을 내포하고 있다는 것이다. 특히 비용과 예산, 목적은 프로젝트를 진행하면서 가변할 가능성이 매우 큰 요소들이다. 대부분의 방법론은 이러한 변동성에 대한 안전장치들을 가정해서 세워져 있다. 변동성의 측면에서 위의 요소들을 다시 살펴본다면 아래와 같이 가정할 수 있다. 위의 그림을 일부 해석해 본다면 일정이 늘어난다면 비용은 늘어나게 된다. 범위가 변경되어도 비용은 늘어나게 된다. 범위와 일정은 상호 의존적이 된다. 만약 위 3가지 요소의 변동성을 통제하지 못하게 된다면 프로젝트는

자세한 내용 보기

QA 부서는 필요한 것인가?

많은 프로젝트 관리 방법론과 조직론에서 항상 얘기하는 것이 QA 부서를 독립적으로 두는것에 대해 강조하는 편이다. 테스트 역시 테스트 조직을 별도로 두는 것에 대해 강조하는 편이다. 이러한 QA 부서 또는 테스트만을 전담하는 조직이 꼭 별도로 존재해야 하는 것일까? 테스트의 경우에는 개발자와 다른 시각을 가진 사람들의 테스트의 필요성을 강조하기 위해서 테스트 조직을 별도로 두는 것을 강조하는 편이다. 만약 테스터가 개발이나 영업, 운영과 같은 조직의 하부 조직이 되다 보면 정치적인 독립성에 따라 자신만의 독립적인 시각이나 의견을 피력하기 힘든 점이 있기 때문이다. QA 부서는 어떨까? 여기서 먼저 생각해 볼 것이 있다. 그것은 QA 부서가 과연 무슨 일을 하는 부서인가? 하는 문제이다. 여러분의 회사에서 QA 부서는 과연 어떤 일을 하는가? 여러분은 QA 부서에 대해 얼마나 호감을 가지고 있는가? 펼쳐두기.. 회사마다 회사의 정책이나 전략에 따라 QA 부서의 역할은 매우 판이하다. 그리고 그 역할에 따라 회사 내에 QA 부서의 호감도도 매우 달라지는 편이다. 만약 여러분이 QA 부서에 대한 호감도가 낮다면 아래와 같은 문제가 있는 것은 아닌지 한번 고민해 보시고 댓글이나 트랙백등으로 의견을 주셨으면 하는 바람이다. 먼저 일반적으로 QA 부서가 하는 일은 제품의 품질을 측정하고 제품의 품질을 향상시킬 수 있는 모든 활동을 계획하고 제어하는 일을 한다. 그런데 문제는 소프트웨어의 품질이 문제가 된다. 먼저 공장과 같은 하드웨어를 제조하는 회사의 경우에는 품질 부서가 독립적으로 존재한다. 이 품질 부서에서 제품의 품질을 측정하고 제품의 품질을 개선하기 위해 집중하는 곳은 하드웨어 그 자체이다. 하드웨어는 각각의 부붐의 품질이 100인 제품이 모여서 하나의 제품을 구성하게 되었을 때 그 제품의 품질은 역시 100이다. 이것은 매우 명확한 사실이다. 소프트웨어를 만드는 회사의 조직과 관리 방법 역시 이러한 하드웨어를 만드는 회사의 조직과 관리 방법을

자세한 내용 보기

xper 11월 정기 모임에 다녀와서

국내에서 가장 활발하고 가장 유명한 Agile 커뮤니티 하면.. 역시 김창준님이 메인 시삽으로 계시는 xper가 아닐까 싶다.. 여담으로 테스터들의 가장 큰 커뮤니티는 sten이다.. xper는 매달 한번씩 모여 사례공유를 하는 정기 모임을 얼마전부터 가져오고 있다. 그런데 이 정기 모임은 한달은 평일에 그 다음달은 주말에 이런 식으로 퐁당 퐁당 운영되고 있다. 난 요즘 주말마다 교육을 받고 있기 때문에 지난 달에는 참석하지 못하고(솔직히 지난 달이 더 참석하고 싶은 내용이었다. ㅠㅠ) 이번달 정기 모임에 어제 참석하고 왔다. 사실 어제 아침부터 다시 편도선이 붓고 혀가 부으면서 감기가 심해져서(지난주부터 도무지 감기가 떨어지지 않는다. 체온도 아주 미열로 올라갈뿐.. 별다른 증상은 없어서 그냥 감기약으로 버티고 있는데.. 이 무슨 돌려 막기도 아니고 목감기에서 몸살감기로 그 다음에는 코감기로 가더니 지금은 두통에 시달리고 있다..ㅠㅠ) 가지 말까? 싶기도 했다. 그러던 차에 김기웅님하고 TOC 모임에 대해 메일을 주고 받으면서 모임에서 만나기로 하는 바람에 죽기 아니면 까무러치기로 참여하게 되었는데.. 막상 김기웅님하고는 말 한마디 섞어보지 못했다..ㅡㅡ 뭥미? 어쨌든 어제 모임에는 정말 많은 사람이 참여했었고 2분의 발표자가 사례를 공유해 주셨다. 첫번째 발표자 분은 드래곤플라이의 스페셜포스 2의 팀장이신 고성원님이었다. 고성원님은 팀에 스크럼을 도입했던 사례를 발표해 주셨다. 흥미있는 발표였고 무엇보다 고성원님의 포스가 정말 팀장님의 포스였다. 발표 내용만으로도 정말 저런 팀에서 한번 일해보는 것도 좋지 않을까? 하는 마음을 갖게 만드는 발표셨다. 게임업계에서 사회 생활을 시작했지만 지금은 한 가정의 아버지로서 허구헌날 돈 벌어 처자식을 먹여살리느라.. 예전에는 1년에 2번도 하던 컴퓨터 업그레이드는 고사하고 게임 한번 제대로 못하는 나에게 게임 업계는 일종의 향수병과 같은 느낌이 남아있다. 하지만 정작 지금 게임업계로 돌아가겠느냐고 묻는다면.. 글쎄요?

자세한 내용 보기

테스팅 히치하이커를 위한 안내서

이 블로그 검색