[지디넷코리아]다양한 업종의 계약 관계에서 고객 또는 사용자의 요구사항이 불분명한 경우가 많지만, 소프트웨어 프로젝트 분야만큼 요구사항이 불분명하거나 동적으로 변화하는 분야도 많지 않을 것이다. 패키지 소프트웨어보다 SI(시스템 통합)과 관련된 프로젝트들이 특히 그렇다.

요구사항이 계속 변하는 프로젝트로 인하여 심각하게 마음의 고통을 받은 경험이 있는 IT 인력들이라면 아마 고객에 대한 원망을 품은 적이 있을지도 모르지만, 프로젝트에 존재하는 기운(생물이 살아 움직이는 원기, 대세가 어떤 방향으로 향하려는 움직임)의 상호작용 원리로 볼 때 고객에 품은 안 좋은 생각은 반드시 프로젝트의 실패(내지는 실망스러움)으로 귀결되게 마련이다.

그러므로 용역을 제공하는 입장의 IT 인력들은 결코 고객에 대해 원망을 가져서는 안 되는 것이다. 악한 기운이 프로젝트를 망칠 것이다. 그렇다고 필자의 이러한 말이 무지몽매(無知蒙昧)하거나 비합리적이고 일방적인 희생을 강요하는 고객의 모든 요구를 감수하라는 뜻은 결코 아니다. 고객에 용역을 제공하는 전문가로서 가장 바람직한 태도와 능력은, 그들을 이해하고 또한 올바른 방향으로 인도할 수 있는 '영향력'을 갖는 것이다. 그러한 영향력을 갖기 위해서는 정치적 판단 능력과 커뮤니케이션 스킬이 요구된다.

우리 프로젝트에 긍정적인 영향을 미칠 수 있는 사람은 누구인가?

누가 우리 프로젝트에 부정적인 영향을 주고, 더 심한 경우 프로젝트를 망칠 수 있는가?

그러한 핵심 이해관계자와 어떻게 커뮤니케이션을 하고 영향력을 가질 것인가?

위의 내용은 '이해관계자 관리'이며, 프로젝트 전반을 지배하는 중요한 개념이다. 순박한 IT 인력들은 이것을 나쁜 의미의 정치로 치부하며 외면하는 경우도 있지만, 이것은 프로젝트를 올바른 방향으로 이끌어가기 위한 좋은 의미의 정치이므로 잘 하지 않으면 프로젝트의 성공을 보장할 수 없다.

하지만 대부분의 IT 인력들은 자신이 해야 된다고 생각하는 일(대부분은 코드 작업, 그리고 스크린을 바라보는 일)을 할 뿐, 고객의 마음에는 관심을 가지지 않는다. 고객과 IT 인력과의 관계는, 스테디셀러인 존 그레이 박사의 '화성에서 온 남자 금성에서 온 여자' 서적의 컨셉과 흡사하게 이해될 수 있다. 그들은 서로 본질적으로 세계관과 의식 구조가 다르며, 서로 사랑해야 할 존재이지 미워하고 상처를 주고받는 존재가 아닌 것이다. 다음은 지극히 일반적이고 정상적인 고객의 행태이다.

프로젝트 착수 시점에 고객이 하는 말.

"음.. 나는 내가 원하는 것을 모두 말로 설명하거나 글로 표현할 수는 없지만, 어쨌든 나는 내가 원하는 것을 알고 있어요. 나는 그것을 눈으로 보면 확실히 알 수 있어요. 이렇게 저렇게 만들어주세요. 혹시 빠진 부분이 있을 수도 있지만, 그것은 전문가인 당신이 잘 파악하여 해결해 주셔야 합니다. 그것을 위해 전문가인 당신을 고용한 것이 아니던가요?"

그로부터 6개월이 지난 어느 날

"맙소사, 이것은 내가 원하는 것과는 차이가 있어요. 왜 이 기능이 이렇게 동작하는 것이죠? 이 메뉴를 동작시키기 위한 옵션은 적어도 3가지가 있을 것인데, 내 눈에는 한가지 밖에 보이지 않네요. 또한 왜 저 텍스트박스는 저기에 있는 것이죠? 왜 저 곳의 색상은 노란색인가요? 우리 사장님께서는 노란색을 싫어하십니다!"

고객은 프로젝트의 착수 시점에서 자신이 원하는 것을 구체적으로는 알지 못하거나 설명하기 힘들며, 단지 그것을 추상적으로 알고 있을 뿐이다. 그것은 고객의 잘못이 아니며, 삶이 원래 그런 것이다. 물론 발주처가 군사용도, 원자력 발전, 생명 공학 등의 정밀한 특정 분야는 예외일 것이고 또 그래야만 하겠지만, 대개의 비즈니스 업계의 고객들은 원자력 발전소 가동에 필요한 소프트웨어 개발을 맡기려는 경력 20년의 박사는 아닌 것이다.

현업 업무를 맡고 있는 고객이라 해도 단지 업무 프로세스를 이해하고 있을 뿐이지, 그것을 실제 소프트웨어 UI 상에 배치하고, 필요한 기능을 적절한 위치에 삽입하고, 예외/오류 처리를 하는 것에 대해서, 명확하고 구체적인 절차와 요구사항을 제시하기 힘들다. 그러한 상황에서 IT 인력은 이제 막 업무 프로세스를 처음으로 이해했을 뿐인데, 그것을 소프트웨어와 최적으로 결합시켜 고객을 만족시켜야 하는 어려운 미션을 갖고 있는 것이다. 중간에 버퍼 역할을 하는 또 다른 전문가가 있을 수 있겠지만 커뮤니케이션 단계가 늘어난 것을 고려한다면, 잘 된다고 할지라도 그 효과는 제로섬(zero sum)에 가까울 것이다.

프로젝트 요구사항의 변경은 단지 고객의 변덕에 의한 것이 아니며, 더 나은 제품을 위한 추가 및 변경, 시장 환경의 변화, 잘못 파악된 부분의 제거, 새로운 사실의 발견 등에 기인할 수 있다. 어떻게 보면 고객의 요구사항은 변화하기 위해 존재하는 것이다. 변경을 수용한다고 할지라도, 핵심 이해 당사자들 간의 합의되지 않은 요구사항은 곧바로 재앙의 요인이 되므로, 우리는 그것을 결코 간과해서는 안 된다.

그러므로 요구사항에 대한 철저하고도 체계적인 통제가 중요한데, 그렇다고 해도 소프트웨어 공학자 또는 요구사항 관리 도구를 판매하는 업체들이 얘기하는 것처럼 이것이 단지 절차와 방법론, 멋진 매트릭스를 제공하는 프로그램으로 해결되는 것은 아니다. 그것보다는 프로젝트가 어떤 대내외적 환경에 놓여있는지 전체 흐름과 기운을 이해하고, 조직의 정치적 상황을 파악하고, 고객 및 핵심 이해관계자들의 만족감을 유발하는 커뮤니케이션 및 프레젠테이션 능력을 갖추고, 프로젝트에 올바르다고 생각되는 방향으로 끌고 갈 수 있는 판단력 및 정치력이 우선적으로 중요하다. 그러한 프로젝트의 흐름과 기운을 이해하고 프로젝트에 대한 거시적인 지배를 달성하였을 때, 각종 방법론과 통제 도구는 그것을 보조하는 수단이 될 것이다.

고객은 애증의 대상인가? 아니다. 고객은 마치 연인을 대하듯이 그들의 행동과 애로사항 깊숙이 이해되어야 하고, 우리가 만든 프로젝트 결과물을 이용하여 더 나은 비즈니스 생산성을 추구하고, 결과적으로 만족과 행복을 얻어야 하는 존재이다. (필자는 당연히 사기꾼 또는 협잡꾼은 고객의 범위에 포함하지 않는다) 그러한 상호작용을 통해 고객이 만족감을 얻는다면, 다음 번 프로젝트에는 더 나은 신뢰와 금전적 보상으로서 IT 인력을 대할 것이고 그것은 모두에게 좋은 일이다. 세상은 단 한번의 행동에 의해 나아지지 않는다.

IT 인력들(개발자, 엔지니어, 디자이너 등)은 오로지 자신이 해야 된다고 생각하는 일, 자신이 올바르다고 믿는 일을 위해 열심히 일하고 야근을 하기 보다는(그것이 누구를 위한 것인가?), 매니저 및 고객의 관점에서 그들을 만족할 수 있는 것이 무엇인지를 생각하는 시간을 충분히 가져야 한다. 그리고 커뮤니케이션을 시도해야 하고, 사후 보고보다 사전 합의를 이끌어내야 한다.

그러한 고객의 마음에의 집중을 통하여 고객을 만족시킬 수 있는 묘안이 발견된다면 몹시 좋은 일이다. 하지만 만일 묘안을 찾지 못한다고 할지라도, 당신의 고객을 향한 집중은 좋은 기운이 되어 프로젝트에 활기를 불어넣고 또한 고객에게 상냥한 마음을 전달해 줄 것이다. 똑같은 고민이라고 할지라도 대상에 대한 애정의 고민인가, 원망의 고민인가가 중요한 것이다. 프로젝트의 흐름과 기운에 대한 충분한 이해, 그리고 고객에 대한 깊은 애정, 그것에다 효율적인 통제 도구까지 갖춘다면 프로젝트가 어찌 실패할 것인가? @