고객이 요구사항을 너무 자주 바꿔요.

우리나라 소프트웨어 시장을 너무 비관적으로 과대평가하는 경우를 종종 봅니다.

예를 들면 전세계 유래가 없는 까다로운 고객 요구 수준, 시도 때도 없이 바뀌는 요구사항, 엄청나게 낮은 금액, 제품의 Output과는 상관없이 작업 시간을 통제하는 관행

일부는 공감을 하기도 하지만, 어느 나라를 가던지 각 나라만의 특징이 있다는 측면으로 바라보고 싶습니다. 우리나라 고객은 요구사항을 정말로 외국에 비해서 더 자주 바꾸는 것인지는 생각해 볼 필요가 있습니다. 어딜 가던지 고객은 요구사항을 항상 바꾸기 마련이고, 그것이 고객의 습성이라고 볼 수 있습니다. 그런데, 외국에서는 관행적으로 문화적으로 스펙을 근거로 계약을 하고, 분석 능력이 뛰어난 엔지니어들도 많이 있습니다. 하지만 그런 저변이 상대적으로 부족한 우리는 개발을 하는 쪽이나 고객이나, 일단 대충으로 요구사항으로 개발을 하고 나중에 서로 맞춰나가는 것이 상당 부분 관행화된 측면이 있습니다.

개발회사와 개발자가 요구사항을 분석하고 통제하는데 능력을 갖추고 있다면 100%는 아니지만, 고객의 요구사항 변경을 상당부분 통제 가능한 범위 안으로 가져올 수도 있습니다. 

스스로가 주먹구구 식으로 개발을 하면서 고객에게만 덤터기를 씌우는 것은 스스로에게 이득이 될 것이 없습니다.

Track me, if you can

"요구사항 추적"이라는 말을 들어 보셨을 겁니다.

요구사항, 기능, 컴포넌트(클래스), 파일, 함수들의 연관관계를 추적하여 특정 요구사항에 관련된 컴포넌트나 소스코드들을 추적하고, 거꾸로 함수가 바뀔 때 이 변경에 영향을 받는 요구사항을 알아낼 수 있습니다.

왠지 근사해 보입니다.

실제로 요구사항을 추적하려고 노력하는 회사를 종종 보게 됩니다. 하지만 요구사항을 추적할 필요도 없는 작은 소프트웨어이거나 엉터리로 하고 있는 경우가 대부분입니다. 아니 100%입니다.

요구사항 추적이라는 것이 말만 근사해 보이지, 대부분의 역량으로는 거의 불가능합니다. 또 요구사항 추적툴 없이 엑셀파일에 끄적거려서는 할 수 없는 일입니다. 

요구사항 추적은 사람의 생명을 다루는 소프트웨어이거나 엄청난 비용과 테스트가 불가능한 우주선을 만들 때나 사용하면 됩니다. 이 경우는 감히 비용대비 효과를 논하기가 어려우니까요.

우리가 접하는 대부분의 소프트웨어는 요구사항 추적이 필요 없습니다. 실제로 요구사항 추적이 대단히 어려울 뿐만 아니라 요구사항 추적을 해서 얻는 것이 별로 없습니다. 요구사항 추적을 해보신 분들은 아시겠지만, 실제로 어설픈 문서라도 만들어 놓고 써본 적도 별로 없을 겁니다. 또, 요구사항이나 컴포넌트가 변경이 되어도 요구사항 추적 문서를 갱신하는 것은 대단히 어렵습니다. 오히려 방해 요소가 됩니다.

대부분의 소프트웨어는 요구사항 추적을 하지 않아도 별 문제없을 만큼 작거나 테스트로 충분히 커버가 됩니다.

단 하나, 고객이 요구사항 추적 문서를 꼭 원할 경우 설득을 해보고 안되면, 엉터리 문서라도 만들어 주는 것이 좋겠죠. 이때는 어차피 요구사항 추적 문서를 활용하기 위한 것이 아니니 최소한으로 간단하게 만드는 것이 좋을 겁니다.

이렇게 문서를 꼭 만들어야 하는 상황이 아니라면 근사해 보인다고 괜히 요구사항을 추적해볼 필요는 없습니다. 추적한다고 추적이 되는 것이 아니니까요. 그런 노력을 테스트를 제대로 하는데 들이는 것이 훨씬 더 효율적입니다.