앱 또는 웹 개발을 위한 요구 사항 원칙

여러 개발 프로젝트를 경험하면서 잘 되거나 문제가 있는 프로젝트의 경우 요구 사항에 차이가 있는 것을 알 수 있습니다. 물론 아무리 요구 사항이 잘 되어 있어도 이를 개발하지 못한다면 의미는 없습니다. 그러므로 이 케이스들은 개발자들의 역량은 충분하다는 것을 조건으로 합니다.

 

 

요구 사항이라 무엇인가?

 

앱/웹 개발 프로젝트는 계약 이후 진행됩니다. 보통의 계약은 대상과 금액과 함께 해야 할 업무를 지정하게 됩니다.

 

앱/웹 개발의 경우 특정 기능과 화면을 가진 앱/웹을, 정해진 금액으로, 계약된 기간에 개발 완료하여 인도하는 것을 목표하게 됩니다. 

 

이러한 개발 계약 특성상 요구 사항은 특정 기능과 화면의 앱/웹에 대한 것이 돼야 합니다. 요구 사항은 해당 프로젝트 투입 개발자가 개발해야 할 앱/웹을 정의하는 것인 것입니다.

 

 

설악산과 지리산 등산과 쿠팡과 워드프레스 쇼핑 앱 개발

 

일반인에서 설악산과 지리산은 그냥 멋진 산으로 크게 다를 것이 없을 수는 있습니다. 그냥 산에 갔다 왔다고 다른 사람에게 말할 수 있습니다. 그러나 등산가가 이번에 설악산을 등반했으면서 이번에 지리산을 올랐다고 다른 사람에게 말한다면 잘못된 것입니다.  

 

일반인인 사용자에게 쇼핑 앱은 그냥 스마트폰으로 쇼핑할 수 있는 앱일 수 있습니다. 어쩌면 같은 상품인데 더 저렴하게 구매할 수 있는 앱이 더 좋을 수도 있습니다.

 

그러나 개발자에 쿠팡을 개발한 것과 워드프레스 쇼핑 앱 개발은 완전히 다른 것입니다. 웨드프레스 앱에서 쿠팡보다 더 싸게 상품을 판매하더라도 개발적으로는 완전 다른 이야기입니다.

 

이 말을 조금 다르게 생각해 보면 쿠팡과 같은 앱 개발의 요구 사항과 워드프레스 앱 개발의 요구 사항은 다른 것일 수 있음을 의미합니다.

 

요구 사항이 그냥 말과 글로되어 있어 쿠팡 개발, 워드프레스 개발 등 간단히 표현될 수 있지만, 이는 상당히 다른 의미를 내포하고 있는 것입니다.

 

그리고 이에 따라 개발의 규모와 내용, 기간, 금액 등이 모두 달라집니다.

 

요구 사항의 힘은 개발의 구체적 내용을 규정하게 되는 것입니다. 그리고 이는 투입 개발자 규모와 개발 완료 목표를 달성하기 위한 분할되는 하위 작업의 내용과 종류, 개발 기간 등의 차이를 만들게 됩니다.

 

  

이런 이유로 인해 발생되는 원칙

 

이러한 앱/웹 개발 시 요구 사항의 영향 때문에 몇 가지 원칙이 존재합니다. 이 원칙에 대한 것은 제가 경험하면서 만든 것입니다.

 

• 개발 프로젝트 목표 지향의 원칙

종종 요구 사항은 앞으로 개발하고자 하는 최종 앱/웹에 맞추어 전달되는 경우도 있습니다. 그러나 이는 내부적으로 관리되어야 하는 계획 프로세스이고, 현재 개발 프로젝트에서는 지금 개발할 목표에 대한 것만 들어 있어야 합니다.

 

 현 계약된 개발 프로젝트 외의 요구 사항은 개발 진행을 방해할 뿐입니다. 오히려 완성도가 저해되어 전체 플랜에 도움이 안 될 수 있습니다.

 

특히 외주 개발의 경우 이런 요구 사항은 더욱 의미가 없습니다. 외주 개발자와 하등 상관이 없는 것이기 때문입니다.

 

그러므로 이번 프로젝트 요구 사항은 이번 개발 목표에 포커스되어 있어야 합니다. 

 

• 명확성의 원칙

때로는 개인적인 취향이나 선호를 요구 사항에 반영하고 싶어하기도 합니다. 그러나 이는 다른 사람에 의해 해석될 때 변질 될 수밖에 없습니다. 심지어 애인이나 부인의 취향이나 선호도 모르는 경우도 있는데 아무리 고객이라도 취향이나 선호를 알 수는 없습니다. 

 

이런 류의 추상적 내용은 요구 사항에 포함시키지 않는것이 좋습니다.

 

결론적으로 설계와 정의가 가능한 명확한 내용만 요구 사항으로 하는 것이 좋습니다. 예를 들면 자바로 개발해라, 파이썬으로 개발해라 등 요구 사항은 구체적으로 명확해야 합니다.

 

• 변경 불가의 원칙

한번 정의된 요구 사항은 되도록 변경하지 않는 것이 좋습니다. 만약 변경이 꼭 필요하다면 계약의 내용도 함께 수정해야 합니다.

 

때때로 전체 개발에 영향이 미미한 요구 사항 변경이 있을 수도 있습니다. 이 경우도 설계와 개발 진행 담당자와 협의를 해서 수용 가능한지 크로스 체크 후 PM이 결정합니다.

 

고객과 좋은 관계를 위해 무작정 요구 사항 변경을 받아주는 경우가 있는데, 이런 프로젝트의 대부분은 실패합니다. 계약을 넘어선 요구 사항 변경을 받아주는 것은 일반적으로 개발에 문제가 있기에 그러는 것일 가능성이 큽니다. 아니면 굳이 잘 진행되는 개발을 스스로 망칠 이유가 없기 때문입니다.