[요구사항정의] "왜 우리의 프로덕트는 완성되지 못하는가?" - 1

최종 수정일: 2024년 5월 15일

소프트웨어 프로젝트를 진행하다 보면, 종종 프로덕트가 계획대로 완성되지 못하는 경우가 있습니다. 이는 여러 가지 요인이 작용할 수 있지만, 그 중에서도 가장 핵심적인 원인은 바로 '요구사항 정의'의 부재 또는 미흡함에 있습니다.

1. 요구사항이란 무엇일까요?

요구사항이란, 프로젝트를 통해 구현하고자 하는 소프트웨어의 기능, 성능, 인터페이스 등에 대한 명세를 의미합니다. 마치 건축에서 설계도가 필요한 것처럼, 소프트웨어 개발에서도 요구사항 명세서는 프로젝트의 청사진 역할을 합니다.

요구사항이 명확하지 않으면, 마치 목적지 없이 항해하는 배와 같습니다. 방향성을 상실한 채 표류하다 보면, 결국 프로젝트는 지연되거나 좌초되고 맙니다. 반면, 요구사항이 구체적으로 정의되어 있다면 모든 팀원이 같은 목표를 향해 나아갈 수 있습니다.

2. 요구사항은 어떻게 만들어지나요?

안타깝게도 요구사항을 작성하는 표준화된 방법론은 없습니다. 다만 대략적으로 어떤 기능이 필요한지를 기술하는 것이 핵심입니다.

예를 들어, "이러이러한 기능이 있는 교육 플랫폼을 만들어 주세요."라는 막연한 요청 대신, 아래와 같이 상세한 요구사항을 제시할 수 있습니다.

이처럼 구현하고자 하는 기능을 여러 개의 문장으로 세분화하여 표현하는 것이 좋습니다. 모호한 표현은 지양하고, 되도록 구체적이고 측정 가능한 수준으로 기술해야 합니다.

3. 요구사항은 누가 작성하나요?

이상적으로는 해당 소프트웨어를 기획한 사람이 직접 요구사항을 작성하는 것이 가장 바람직합니다. 서비스의 핵심 가치와 비전을 가장 잘 이해하고 있는 사람이기 때문입니다.

다만 현실적으로 외주 개발을 의뢰하는 경우, 고객사의 담당자가 외주 개발사와 미팅을 통해 요구사항을 전달하고, 개발사에서 이를 정리하는 경우가 많습니다.

하지만 이 경우, 미팅 과정에서 요구사항이 누락되거나 왜곡될 가능성이 있습니다. 담당자의 머릿속에 있는 모든 아이디어와 상상을 짧은 미팅에서 100% 전달하기란 쉽지 않기 때문입니다.

따라서 고객사의 담당자가 직접 요구사항을 상세히 작성하고, 개발사 PM과 이를 리뷰/보완하는 과정을 거치는 것이 이상적입니다.

4. 요구사항 없이 프로젝트를 진행하면 어떻게 되나요?

요구사항이 명확히 정의되지 않은 상태에서 UI/UX 기획 또는 개발이 진행될 경우, 매우 비효율적인 상황이 연출됩니다.

기획자나 개발자의 주관적인 판단에 따라 임의로 요구사항을 추정하여 작업이 진행되고, 이후 프로젝트 중간이나 완료 시점에 고객사의 피드백이 들어오게 되는 것이죠.

"이런 게 아니었는데..."

"저는 이런 식으로 상상했거든요."

이렇게 고객사의 눈높이에 미치지 못하는 산출물이 나오게 되면, 수정 사항이 발생하고 일정은 지연될 수밖에 없습니다. 요구사항을 사전에 명확히 하지 않은 채 진행한 프로젝트는 실패할 확률이 높다고 볼 수 있습니다.

5. 중간에 요구사항이 변경된다면 어떡하죠?

분명 프로젝트 중간에 새로운 아이디어가 떠오르거나 환경 변화로 인해 요구사항을 수정해야 할 때가 있습니다. 이 경우 가장 좋은 방법은 우선순위가 낮은 사항들을 제외하고 변경사항을 최소화하는 것입니다.

완벽한 프로덕트를 목표로 무리하게 요구사항을 추가하기보다는, 핵심 기능 위주로 릴리즈하는 전략을 취하는 게 현명합니다. 에릭 리스가 언급한 것처럼 "완벽한 제품이 없는 것이 문제가 아니라, 고객의 손에 들어가지 않는 것이 문제"라는 철학으로 접근할 필요가 있습니다.

초기 출시 버전의 경우 일부 기능이 빠져도 크게 문제될 것이 없습니다. 오히려 사용자의 피드백을 받아 빠르게 개선해 나가는 것이 더 중요합니다.

요구사항 정의는 프로젝트 성패를 가르는 가장 핵심적인 요소입니다. 장대한 항해를 떠나기에 앞서 정확한 항로를 그리는 것처럼, 소프트웨어 개발의 시작점인 요구사항 정의에 심혈을 기울여야 할 것입니다. 그래야만 우리는 고객이 만족할 만한 프로덕트를 완성할 수 있습니다.

최근 게시물