아래 그림은 언젠가 이메일을 통해서 뿌려졌던 사용자 요구사항에 대한 그림입니다. 개발자라면 무척이나 공감하는 이 그림은 당시 빠르게 퍼져나갔었죠. 처음에는 그냥 공감이 가는 웃음으로 대했지만 현실을 너무나도 잘 반영한 이 그림을 보고 한참을 고민했었습니다.
지난주에 프로세스에 대한 교육을 받는 중에 이 그림이 다시 등장을 했습니다. 강사님은 그림의 한컷 한컷을 집으면서 사용자 요구사항 수집의 중요성을 강조했었습니다.
- 최초에 고객은 3단짜리 나무판이 있는 그네를 얘기했다.
- 설계자의 디자인은 고도의 기술을 사용하여 설계를 하는 경향이 있다. 그림에서는 나무가 공중에 떠있고 두개의 가지가 나무를 받치고 있는 멋진 기술을 이용한 설계를 보여주고 있다.
- 프로그래머는 설계자의 의도를 파악하지 못하고 자신이 이해하는 수준으로 개발을 진행하고 코드는 짜임새 있지 못해서 프로그래머의 그네처럼 줄이 축 늘어져 그네의 역할을 하지 못한다.
- 프로젝트가 끝났을 때 쓸만한 문서는 남아 있지 않다.
- 하지만 사용자가 진정 원한것은 타이어가 묶여있는 그네였다.
- 그러므로 개발을 시작하기 전에 사용자의 요구사항이 충분히 수집이 되어야 한다.
- 기획팀이 요구사항 정의서를 완벽하게 만들어 오기 전에는 개발을 시작하지 말 것.
이런식이 었습니다.
사용자 요구사항에 얼마나 중요한지에 대한 강의를 잘 이해를 하면서도 한편으로는 현실을 반영하지 못한 정말 교과서에만 나오는 얘기를 해서 실망을 했었습니다.
강의 내용에는 실전에서 통하지 않는 '사용자 요구사항에 대한 몇 가지 환상'이 있었습니다. 아래 3가지가 바로 그것 입니다.
- 환상 1 : 프로젝트의 시작단계에서 사용자 인터뷰를 통해서 요구사항을 수집할 수 있다.
- 환상 2 : 요구사항은 개발이 시작되기 전에 기획단계 또는 영업단계에서 확정이 되어서 개발팀에 전달 될 것이다.
- 환상 3 : 요구사항은 개발 초기에 정해지면 절대 변경되면 안된다.
위의 그림에서 한가지 더 주목할 것이 있습니다. 사용자가 진정 원했던 '타이어 튜브 그네'는 제일 마지막에 나온다는 것입니다. 사용자는 최초 요구사항 수집 단계에서 3단짜리 나무 판이 있는 그네를 설명했습니다. 사용자는 자신이 진정 원하는 것을 말하고 있지 않습니다.
실전에서도 그렇습니다. 사용자 또는 고객은 개발이 시작되기 전에 정확한 요구사항을 주지 못합니다. 개발이 진행되면서 그 요구사항이 정돈되고 구체화되는 경향이 있습니다. 특히 개발 중간에 데모가 있으면 데모가 끝남과 동시에 요구사항을 마구 쏟아내기도 합니다. 최악의 상황에서는 개발이 종료되는 시점에 아주 중요한 요구사항을 내놓기도 하죠.
이런 상황이 사용자와 우리의 고객들이 뭘 잘 모르거나, 개발자를 괴롭히고 싶어하거나, 프로젝트를 망치게 하기 위해서 또는 원래 못된 성격이라서 발생한 것이 아닙니다. 사용자는 원래 그렇습니다. IT 개발 경력 7년동안 일관되게 그랬었습니다. 우리 개발자들은 그런 현실을 인정해야 합니다.
사용자 요구사항을 이렇게 표현하고 싶습니다.
사용자로 하여금 자신이 진정으로 원하는 것을 말하게 하는 과정, 사용자 자신이 진정으로 원하는 것이 뭔지를 찾을 수 있도록 도와주는 과정이 바로 개발이다.
사용자가 개발의 중간에 요구사항을 추가로 내거나 중요한 변경을 해도 결코 노여워하거나 슬퍼하지마세요. 그들은 원래 그랬으니까. 기획팀에서 영업팀에서 요구사항 문서를 부실하게 만들어 줘도 이해해 주세요. 개발 과정에서 구체화시키고 완성시키면 되니까.
사용자 요구사항 수집에 대한 현실을 인정해야 합니다. 우리의 건강을 위해서 그리고 프로젝트가 성공하기 위해서...
