분석설계나 요구분석을 다룬 책을 보면 기법에 대한 지루한 설명으로 구성된다. 요구 분석 방법을 설명하기 위해서는 실제 벌어지는 현상을 시간 흐름으로 전개해야 한다. 그런데, 요구 분석에 집중하기 위해 예외적인 것은 배제된다. 그러다 보니 비현실적으로 느껴져서 지루해진다.
오래전에 고객사의 A, B팀의 팀장이 함께 앉은 자리에서 개략적인 요구사항을 들었다. A팀장은 요구사항을 경쟁사의 다른 도구를 중심으로 얘기했다. 간단히 요약하면, 경쟁사 제품에 버금가는 수준으로 '뽀대나게' 만들어달라는 것이다. 시간과 예산을 감안하면 바로 불가능하다는 답이 나왔다.
대안으로 고객사의 사정에 딱 필요하다 싶은 문제 해결을 화두로 올렸다. B팀장이 반짝이는 눈으로 이것저것 물어온다. A팀장이 얘기할 때 분위기가 차가운 연구실 분위기였다면, 오가는 질문, 답변과 공감대로 훈훈한 인간 냄새가 나기 시작했다. A팀장은 다소 당황한 기색을 보였고, 그의 제지로 애매한 선에서, 결국 누구의 만족도 끌어낼 수 없는 요구사항으로 귀결되었다.
어떤 책인지 기억나지 않지만 요구사항 수집과 분석을 elicitation이라고 표현했는데 딱 어울리는 표현이다.
시간이 지나고 알게 된 A팀장의 진정한 요구사항은 새로운 기획안을 든든히 지원해주는 도구가 필요했던 것이다. 윗 사람들의 시선을 확 사로잡는 그런 것은 만들지 못했고, 기획은 실패로 돌아가 팀장은 회사를 그만두었다. 고객사로써는 상당한 금액을 들인 프로젝트를 통해 몇몇 개발자의 스킬 향상에 이바지했고, 회사의 유휴인력에게 몇 개월 동안 일꺼리를 제공해줄 수 있었다.
누군가 똑같은 일은 겪게 된다면, 빨리 A팀장과 소주잔을 기울이는 기회를 마련해보라고 권해주고 싶다. 그리고, B팀장과도 저녁 한끼를 함께 해서 입장을 듣게 되면, 본인이 저녁을 쏜다고 해도 아깝지 않을 것이다.
고객이 진짜로 원하는 것이 무언이가를 알아내기 위한 기본은, 요구사항을 말하고 있는 상대를 이해하는 것에서 출발한다. 그 사람의 조직내에서의 위치를 이해하면, 요구사항이 얼마나 현장성이 있는지 알 수 있고, 얼마나 중요한 요구인지 가늠할 수 있다. 나아가서, 그 혹은 그녀의 관심사와 말하는 습관까지 알게 되면 본인의 관심에 편향된 요구를 하는 것인지, 설명은 얼마나 정확한 것인지 알 수 있다. 그런 것들 없이 기계적으로 수집한 요구사항이 얼마나 실효성이 있을까?
감리업체의 CBD 담당자에게 취조(?)를 받은 일이 있다. 내 눈을 똑바로 보지 않고, 공격적으로 들릴만큼 격양된 어투로 말을 하는 것을 보면 두 가지 정도를 짐작할 수 있었다. CBD를 책으로만 배웠거나, 프로젝트 경험이 없을 것이라는 점이다. 마치 학생에게 질문하듯 책에서 배운 것을 내개 다그쳐 묻는다. 지금 똑같은 자리가 마련된다면, 심호흡을 하고 편하게 말씀하시라고 대답해줄 것이다. 나도 잘 아는 것은 아니니까 걱정 말라고.
그의 질문은 요구사항이 나오지 않았는데 유스케이스 명세가 작성될 수 있냐는 것이다. 교수가 학생에게 묻는 것이었다면 그건 불가능하다고 경험해보지도 않은 것에 대해서 자신있게 대답할 것이다. 나는 학생이 아니었기에 이 친구에게 상황을 어떻게 설명해줘야 할지 막막하다. 현재로썬 그는 이해할 수가 없기 때문에 술한잔 하면서 마음을 열게 하면 방법이 생기겠지만, 감리 석상에서 소주를 깔 순 없다. ^^
특정 업무의 요구사항을 책임진 담당자가 장기 출장으로 공석이라면 어떻게 할 것인가? 다행히 대부분의 사람들은 논리만 따지고 언제 올지 모르는 담당자를 하염없이 기다리다 망부석이 되는 바보가 아니다.
