[Requirement Engineering] 이해관계자(Stakeholder)와의 대화

이해관계자(Stakeholder)는 어떠한 소프트웨어 시스템에 관심이 있거나 관여된 사람들을 말합니다. 고객이 될 수도 있고, 개발팀과 연관된 검증팀, 디자인팀, 기획팀의 사람이 이해관계자가 될 수도 있습니다.

이해관계자(Stakeholder)는 명확하게 자신이 원하는 바를 모를 수 있다.

소프트웨어 시스템 설계에 앞서 고객, 또는 시스템과 연관된 Stakeholder들과의 대화, 회의는 필수적입니다.
설계자가 이해관계자들과 대화없이 스스로 생각한 바를 설계해 나간다면 결과물은 이해관계자들의 생각과는 전혀 다른 방향이 될 수 있습니다. 그렇기에 이해관계자와의 대화는 매우 중요합니다.

이해관계자들과 대화를 하다보면 명확하게 어떤 결과물을 원하는지 모르는 경우가 많습니다. 특정 어플리케이션을 개발한다고 가정을 해봅시다.
'저는 A, B 기능이 있는 어플리케이션이 필요해요', 라는 이해관계자의 요구사항을 기반으로 A, B 기능만을 가진 어플리케이션을 만들어서 시연을 하였습니다. 그랬더니, 'C 기능은 없네요?', '내가 말한 A기능은 이런게 아니였어요, A1처럼 바꿔주세요' 등등 다양한 피드백이 발생할 수 있습니다.
개발이 진행된 후에 이러한 피드백은 소프트웨어 구조의 근간을 흔들수도 있습니다. 그렇기에 아키텍트는 최대한 이해관계자들과 대화하면서 고객의 니즈를 반영한 시스템 설계를 진행해야 합니다. 그렇다고 고객의 니즈만을 반영할 수 는 없습니다. 다른 이해관계자들과의 논의도 필요하죠. 통상적으로 이해관계자는 한 명이 아닙니다. 팀이 이해관계자 그룹이 될 수도 있습니다.

이런 다양한 이해관계자 그룹과 회의를 진행하다보면 서로 의견이 다르고 가치가 충돌하는 경우도 발생하게 됩니다. 아키텍트는 최대한 서로 합의에 이르도록 도와줘야 합니다.

원하는 정확한 Needs 를 어떻게 끌어낼 것인가?

아키텍트는 어떻게 이해관계자들을 이해시키고 합의에 이르도록하며, 정확한 고객의 니즈를 끌어낼 수 있을까요? 소프트웨어 시스템은 비니지스 목표가 존재합니다. 비지니스 목표는 소프트웨어 설계 시 최우선으로 고려해야 하는 사항이며 이 목표가 기준이 되어 서로 충돌하는 요소에 대해 우선순위를 정하게 됩니다.

여기서는 저의 경험을 하나 예로 들려합니다.

프로젝트 진행 시 기획 단계에서 고객과 대화 시 '즐겁게 운동할 수 있는 컨텐츠가 필요하다' 라는 모호한 요구사항을 전달받았습니다. 그 컨텐츠가 어떤 운동인지, 즐거움의 요소는 게임인지 아니면 커뮤니케이션인지 어떠한 정보도 없습니다. 고객과 점차 대화를 하다보면 조금씩 원하는 요구사항을 말하게 됩니다. '게임 보다는 커뮤니케이션 기능이 있었으면 좋겠어요.' 라던지 '커뮤니케이션 기능에서 내 캐릭터를 꾸밀 수 있었으면 좋겠어요.' 등등의 요소들 입니다.

고객들에게 포스트잇을 나눠준 후, 소프트웨어에 필요로 하는, 또는 있으면 좋을 것 같은 기능들을 포스트잇에 작성해서 칠판에 자유롭게 붙힐 수 있도록 하였습니다.
3명의 고객은 다양한 기능과 의견을 작성하였고 일정 시간이 흐른 후 작성된 포스트잇을 모두 모아 유사 기능에 맞춰 카테고리를 나눠 분류를 하였습니다.

그럼 캐릭터 / 게임 / 커뮤니케이션 / 공유 등 다양한 카테고리로 분류가 되었고 중복되는 내용은 제거 또는 상세하게 보충하게 되었습니다. 그리고 깔끔하게 표로 정리하였습니다. 그 후 특정 카테고리 내에서 좀 더 상세하게 어떠한 기능인지 정리하게 되었습니다. 

위 과정 이후에 더 다양한 활동들이 있지만 여기서 줄이겠습니다. 고객은 정확히 자신이 뭘 원하는지 설명하지 못하는 경우가 많기에 그 정보를 끌어내고 정리하기 위해 다양한 활동이 필요할 수 있습니다. 아래 나열한 것들은 그 활동들 중 일부입니다.

• 설문조사
• 인터뷰
• 워크샵
• 브레인스토밍
• 스토리보드
• 롤 플레잉
• 프로토타입

이러한 과정을 통해 필요로한 정보를 최대한 이끌어내고 정리를 할 수 있습니다. 위에 나열한 활동들은 기회가 된다면 상세하게 설명하는 글을 작성하겠습니다.

읽어주셔서 감사합니다.