2012년 8월 30일 목요일

요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다.

소프트웨어 개발 프로젝트에서 스펙을 제대로 적지 않는 회사들에게 그 이유를 들어보면 여러가지가 있다.

1. 프로젝트 기간이 너무 짧아서 스펙을 적을 시간이 없다.
2. 프로젝트가 너무 복잡해서 적어야 할 것이 너무 많아서 적을 수 없다.
3. 요구사항을 계속 바꿔서 스펙을 적을 수가 없다.

위의 어떠한 이유도 적절한 이유가 되지는 않는다. 오직 한가지 이유가 될 수 있다면 다음과 같은 것이 있을 수 있다.
"우리는 분석역량이 떨어져서 스펙을 적을려고 해도 제대로 적을 수 없다. 그래서 그냥 개발한다."

위 1,2,3번의 이유 때문에라도 스펙을 적어야 하는 것이다.
이중에서 3번 "요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다"에 대해서 얘기를 해보고자 한다.

99%의 소프트웨어 프로젝트는 분석 기간은 당연하고 설계, 구현 중에도 요구사항이 계속 바뀐다. 단지 프로젝트마다 바뀌는 정도의 차이가 있을 뿐이다.

스펙을 제대로 적었다는 전제하에 스펙을 결정한 후에도 요구사항이 계속 바뀌는 이유는 다음과 같은 것들이 있다.

1. 시장 상황의 변경
2. 경쟁 업체의 신제품 출시
3. 기술 환경의 변화
4. 미처 파악하지 못한 비즈니스 요구사항 발견
5. 예상치 못한 개발 상의 난관 봉착
6. 경영진의 변덕
7. 영업, 마케팅 부서의 끊임 없는 요구

이런 저런 이유로 요구사항 변경 요구는 계속 되기 마련이다. 스펙을 제대로 적어 놓지 않으면 이러현 변경 요구가 관리되지 않는다. 또한, 변경 프로세스를 적용하면 좀더 합리적인 변경 관리가 가능한다.

프로세스라고 하니까 뭔가 매우 부담스러워하고 특히, 영업과 마케팅 부서는 싫어하는 경향이 있다. 과거에는 코딩 중이라고 하더라도 친한 개발팀장에게 추가로 요구를 하면 잘 들어 줬는데 변경 프로세스를 밟으라고 하면 싫어하기 마련이다. 하지만 중요한 프로젝트의 일정과 품질에 영향을 줄 수 있는 결정에 큰 Risk를 안으면서 그냥 결정할 수는 없다.

변경 프로세스의 핵심은 "변경 영향 평가"이다. 이것도 그렇게 거창한 것은 아니다. 새로운 요구사항이 프로젝트에 어떠한 영향을 주는지 정량화하는 것이다. 일정이 더 필요할 수도 있고, 오히려 줄어들수도 있다.(드물지만) 또한 기술적인 위험이 증가할 수도 있다. 짧게는 10분, 길면 몇시간 걸리는 일이다. 스펙을 제대로 적어 놓지 않았다면 요구사항 변경으로 인해 아키텍처에 어떠한 영향을 주는지 파악하기 어렵고, 일정에 미치는 영향도 판단하기 어렵다. 그래서 스펙이 필요한 것이다.

변경 영향 평가가 되었다면 이러한 영향이 있는데도 불구하고 새로운 요구사항을 반영해야 하는지 투명하게 판단을 해야 한다. 어떤 요구사항은 정말 간단한 것 같은데 프로젝트에 큰 악영향을 주는 것도 있고, 커보이는 요구사항이 프로젝트에 문제 없이 포함될 수 있는 것도 있다. 즉, 요구사항 변경이 합리적으로 결정될 수 있다.

변경이 쉽지 않다는 것을 잘 알기에 스펙을 제대로 적고 철저히 리뷰하는 문화가 더욱 견고해지는 것이다.

이러한 프로젝스와 문화가 정착된다면 개발자들도 터무니없는 기능 추가 요청에 일정은 절대 안바꿔주는 비합리적인 요구는 줄어들게 된다. 스펙을 제대로 적고 변경을 관리하는 것이 회사에도 이익이지만 개발자에게는 더욱 좋은 문화임에도 많은 개발자들이 거부하는 경향이 있다. 이는 개발자들 탓이 아니다. 그동안 개발환경이 근거없는 일정 강요와 야간에 내몰리다보니 하루라도 빨리 코딩을 해야 한다는 생각에 내몰린 것이다.

또한, 무리한 요구사항 변경 요청에 "아키텍처를 너무 많이 바꿔야 한다". "몇달이 더 필요하다"라고 하면 개발자들은 항상 안된다고 주장한다고 치부를 해버리곤 한다. 그래서 무리한 변경 요구에 개발자들이 주로 약자가 되곤 한다.

스펙이 잘 작성된다면 일정, 리스크, 비용 등 모든 것에 근거가 생기고 합리적으로 결정할 가능성이 훨씬 높아지게 된다. 

스펙은 프로젝트가 끝날 때까지 계속 바뀌게 되어 있다. 그래서 스펙은 계속 업데이트가 되어야 한다. 하지만 합리적으로 변경 관리가 되어야 한다.

댓글 4개:

  1. Budget, Time은 변경할 생각이 없으면서, 요구사항은 수용해야한다고 생각하는 고객이 문제입니다.

    프로세스를 FM대로 하려면 고객도 FM에 따라주면 좋겠지만, 그런 고객은 못만나 보았습니다.

    아키텍처에 영향을 미칠정도의 요구사항변경은 On Time, on budget에서는 무리라는건...

    변경관리를 하지 않아도 파악되어야 한다고 생각합니다.

    아키텍처에 영향이 없는 폰트변경, 버튼위치변경 요청까지 명문화하여 관리하기엔 인생은 그리 길지 않은것 같습니다.

    답글삭제
  2. SI PL님 안녕하세요.

    스펙을 토대로 계약을 해야 하는데, 우리나라는 계약 후에 스펙을 작성하기 때문에 스펙 변경에 전혀 부담을 없어하죠. 그게 가장 큰 문제 중에 하나라고 생각합니다. 오타수정이나 누가봐도 너무 사소한 변경은 상식적으로 변경관리하지 않는 것이 맞으나 미 국방부 프로젝트라면 그런 것도 허용하지 않죠. ^^

    우리나라에서는 환경이 열악한 것은 사실인 것 같습니다. 그래도 이미 그런 것을 알고 감수를 하면서 프로젝트에 뛰어 든 것이지요. 그래서 사실 SI 프로젝트의 수익성이 그렇게 좋지 않습니다. 10건 성공해도 큰것 1건 폭탄을 맞으면 적자가 나기도 합니다. 그래서 분리발주를 법제화하려고 하는 이유중 하나입니다. 모든 것의 전제 조건은 분석 역량이 뛰어나야 하는 것인데 아직 해야 할 일이 많습니다.

    답글삭제
  3. 들고온 스펙이 너무 허접하면 어쩌죠..?ㅎㅎ

    답글삭제
  4. 안녕하세요. KIH
    약간 헷갈리네요. 고객이 준 스펙이 허접하다는 얘기 인가요?
    개발을 의뢰했는데 개발사가 스펙을 허접하게 작성했다는 얘기인가요?

    첫번째로 생각하고 의견을 말씀드리겠습니다. 일반적으로 고객은 스펙을 작성하지 않습니다. 고객이 스펙까지 다 작성하고 설계/구현만 발주하는 경우는 많지 않습니다. 고객이 소프트웨어 회사인 경우는 종종 있는 경우 입니다.

    분리발주인 경우 스펙을 작성하는 분석 프로젝트를 별도로 발주하기 때문에 스펙이 잘 작성된다고 봐야 겠죠.

    보통 프로젝트인 경우 고객이 스펙을 작성하지 않습니다. 설령 스펙이라는 이름으로 준 문서도 "요구사항"으로 보면 됩니다.
    요구사항과 스펙은 다릅니다. 고객이 허접한 스펙을 주면 분석을 다시 해서 스펙을 작성해야 하는 상황입니다. 원하시는 답이 되었는지 모르겠네요. ^^

    답글삭제