화성에서 온 개발자, 금성에서 온 고객

THE MOON AND ITS NEIGHBORS by c.fuentes2007

개발자들이 통상 고객과의 커뮤니케이션을 수행할 때, 많은 부분이 왜곡되거나 생략될 수 있습니다. 개발자가 고객의 관점에서 대화하고, 요구사항을 이끌기란 여간 어려운 일이 아닙니다.

그런 차원에서 유스케이스에서 액터의 식별은 이러한 어려운 과정을 겪는 일 중에 하나입니다. 유스케이스에서의 액터는 바로 시스템과의 접점에 있는 작업을 수행하는 역할로 규정되긴 하지만, 액터와 사람을 혼동한다거나, 실제 시스템을 사용하는 액터는 따로 있고, 이 액터에게 전달하는 이해관계자를 바로 액터로 규정하는 경우도 있습니다.

이러한 대표적인 예가 안내데스크에 있는 시스템을 사용하는 액터들이 바로 그렇습니다. 이 액터들은 바로 시스템을 사용하기는 하지만, 그 목적에 있어서는 그 시스템을 활용해서 이용하려는 고객과는 사뭇 다릅니다. 이 사람들에게 필요한 기능은 고객에게 빠른 정보 전달을 하고, 최대한 대기열 수를 줄이는 것이 목적이 됩니다. 즉, 비즈니스 상황을 고려해볼때, 이들의 요구사항은 빠른 업무 처리와 최대한 대기열 수를 줄여 전체적인 비즈니스 흐름이 원활하게 수행되는 것입니다. 

이해관계자와 대화를 할 때, 이러한 액터들에게까지 필요하지도 않은 데이터를 제공하기 위한 기능까지 고려하는 경우가 발생됩니다. 즉, 너무 많은 정보와 너무 많은 링크를 통해 업무 처리에 대한 효율성을 저하시키는 시스템을 만드는 경우가 있습니다.

또 하나는 개발자가 이해하고 있는 시스템과 고객이 이해하고 있는 시스템의 영역이 전혀 다른 경우입니다. 고객은 최종 결과만을 바라보고 시스템을 이해하는 반면에, 개발자는 시스템을 만들어가는 그 과정을 바라보고 이해하고 있습니다. 결국 이러한 과정에서 개발자와 고객의 시각차를 좁히는 것이 관건이 되며, 이는 곧 요구사항 식별 단계에서의 고객과의 합의점에 이르는 과정이기도 합니다.

이와 같이 고객과 개발자의 시각차로 인해서 요구사항은 다양한 형태로 왜곡되고 변형됩니다. 이러한 변형이 발생되는 지점이 비즈니스를 매끄럽게(seamless) IT로 연결하는 지점이 됩니다. 즉, 시스템 개발이라는 것은 결국 사람을 이해하고, 그 사람의 생각과 의견을 어떻게 내가 이해하느냐에 달려있다고 해도 과언이 아닙니다. 고객이 '무슨 시스템과 같이 만들어주세요.' 라는 말의 뒷면에 왜 그러한 말을 했는지를 생각해볼 필요가 있습니다. 단순하게 고객의 요구사항을 곧이 곧대로 받아들이는 것은 전체적인 맥락(context)을 이해하지 못해서 전혀 다른 결과를 만들 수 있는 오류 중에 하나입니다.