소프트웨어 기업에서 경영진의 관여도에 따른 프로젝트 성공 여부 연구

우리는 매일 많은 소프트웨어를 사용하고 있다. 아이폰, 아이튠즈, 윈도우, 포토샵, 페이스북, 구글 등 그 종류 또한 다양하다. 그리고 이 소프트웨어들은 애플(Apple), 마이크로소프트(Microsoft), 구글(Google) 등 여러 회사에서 개발된 제품이다. 이미 알려진 바와 같이 이 기업들은 초기에 한두 명의 창업자로 부터 시작되었다. 애플은 스티븐 잡스(Steve Jobs)와 워즈니악(Steve Wozniak)이 마이크로소프트는 빌게이츠(Bill Gates)가 구글은 래리 페이지(Larry Page)와 세르게이 브린(Sergey Brin)이 그 인물들이다. 이 기업들은 현재 직원 수가 애플 8만 명(2013년 기준), 마이크로소프트 8만 9천 명(2009년 기준), 어도브 8천 6백 명 (2009년 기준), 페이스북 3천 명 (2011년 기준)으로 상상할 수 없을 정도로 증가했다. 그리고 이 기업들은 때로는 실패하기도 하지만 아직도 많은 성공적인 제품을 개발해내고 있다.

창업 초기에는 창업자 등의 뛰어난 능력을 갖춘 의사 결정권자가 모든 프로젝트에 관여할 수 있었다. 그리고 회사의 모든 역량을 쏟아부어 프로젝트를 추진할 수도 있었을 것이다. 하지만 회사의 규모가 커짐으로써 여러 프로젝트가 동시에 진행되고 있기 때문에 경영진들이 모든 프로젝트에 깊게 관여하는 것은 사실 불가능하다. 이들은 대안으로 많은 프로젝트에 낮은 관여를 할 수도 있고 상대적으로 적은 프로젝트에 깊은 관여를 하고 있을 수도 있다. 또는, 다른 대리인을 통해서 결정을 위임할 수도 있다. 하지만 이 방법은 의사 결정이 경영진의 방향과 같지 않을 수 있다는 위험 부담이 있다.

프로젝트의 성공을 다루거나 소프트웨어 개발을 다룬 유명한 책들인 짐 콜린스(Jim Collins)의 ‘좋은 기업을 넘어 위대한 기업으로’, 톰 드마르코(Tom DeMarco), 티모시 리스터(Tim Lister)의 ‘피플웨어’, 게리 린(Gary S. Lynn)의 ‘블록버스터’ 등의 책을 보면 프로젝트에 성공하기 위해서는 경영진의 전폭적인 지지가 필요하다는 것에는 이견이 없다. 하지만 이와 같은 관여로 인해 어떠한 경우에는 프로젝트를 성공으로 이끌지 못하는 경우도 있다는 점에서는 의견일치도 없고 관련연구도 부족하다. 실제로 현업에서 일하고 있는 나와 동료들의 경험에 비춰봐도 경영진의 관여와 프로젝트 성공에는 어떠한 인과관계가 존재하고 있음을 경험을 통해서 알 수 있었지만 명확한 인과관계 요소는 찾지 못하였다.

관여도는 비록 소비자 행동 분석에서 사용되는 개념이다. 하지만 회사를 일종의 작은 시장으로 보고 경영진 또는 의사 결정권자가 시장에서 소비자이고 프로젝트는 소비자가 구매하는 제품의 한 종류라고 생각하면 적용이 가능하다. 따라서 경영진의 관여도가 프로젝트의 성공 여부와 어떤 관계가 있는지 흥미를 가지고 연구해볼 가치가 있다. 2장에서는 관여도와 소프트웨어 개발 절차에 대해서 설명한다. 3장에서는 본 연구를 진행하기 위한 제안하는 방법을 설명하고 4장 결론으로 마친다.

소비자 행동 분석에서 관여도의 개념은 여러 연구에서 매개변수로 이용되어왔는데 연구자에 따라서 관여의 정의와 측정 방법은 상이하다. 관여도는 개인 특성이나 상황에 따라서 달라지며 중요성과 관심 등과 관련된 개념이라는 사실에는 연구자들 간의 의견 일치가 있었으나 관여가 무엇이고 관여도 연구의 범위는 어디까지 이며 명백한 개념이 무엇 인지에 대해서는 이직까지 의견 일치 되지 않았다^{1 2}. 관여도는 개인, 상황, 제품, 메시지 등의 4가지와 상호 관련성이 있다. 관여도를 결정하는 것은 제품, 상황 및 메시지 등의 특성 그 자체가 아니고, 이들 원인 변수들 사이의 관련성에 대한 개인적인 해석³이라고 설명할 수 있다.

사회적 판단 이론(Social Judgement Theory)의 자아 관여에 두고 있으며, 크루그만(Krugman, 1965)이 소비자 행동 분야로 도입하여 광고 효과 연구에 처음으로 사용한 이래, 그에 관한 많은 연구가 이루어졌다. 최근의 연구들을 살펴보면 광고 처리 과정에서 동기의 개념을 상품에 대한 소비자의 관여도로 그리고 능력의 개념을 상품에 대한 (전문)지식으로 개념화하는 경우를 자주 볼 수 있다⁴. 즉, 높은 관여도를 가지고 있다는 것은 어떤 상품에 대해 높은 정보처리를 가지고 있음을 나타낸다. 이것은 사용자들은 상품이 제시하는 정보를 이해할 수 있는 능력이 뛰어나다는 것을 의미한다.

관여가 되는 것은 대상 자체가 아니라 대상에 대해 개인이 부여하는 개인적 의미나 중요성이다. 따라서 관여도의 수준을 결정하는 것은 자극 자체가 아니라 자극에 대한 개인의 해석이기 때문에, 사람들 간에는 동일한 자극에 대해서도 관여도 상의 차이가 나게 된다. 즉, 동일한 제품에 대해서 계층 별, 연령 별에 따라 제품에 대한 관여가 고, 저관여로 다르게 나타난다.

소프트웨어 개발 단계(System Life Cycle)는 요구 사항 분석(Requirements Analysis), 설계(Design), 프로그래밍(Programming), 테스트(Testing), 사용(Use), 유지 보수(Maintenance)로 나뉜다. 각 단계를 설명하면 다음과 같다. 요구 사항 분석은 소프트웨어 개발 전 개발자가 사용자의 정확한 요구 사항, 즉, 입 출력 처리 등의 정보를 파악하고 사용자와의 대화와 업무 범위를 파악하는 과정이다. 설계는 개발될 프로그램을 설계한다. 분석 단계보다는 좀 구체적인 과정으로 프로그램의 흐름, 데이터 내용에 관한 설계가 된다. 객체의 표현 방식을 택하고 각각의 명령들을 위한 알고리즘(Algorithm)을 작성한다. 프로그래밍 단계는 설계된 논리를 직접 프로그램 언어로 바꾸는 작업이다. 테스트 단계는 작성된 프로그램을 실제 데이터나 모의 데이터를 이용하여 검증한다. 사용 단계는 프로그램을 사용자가 받아서 사용한다. 유지 보수 단계는 프로그램을 사용자가 받아서 사용하는 중에 발생하는 오류(Bug)나 새로 추가될 프로그램 기능 운영체제 변경(Upgrade)을 재개발하는 과정이다.

각 단계에서 필요한 사항들을 살펴보면 요구 사항 분석 단계에서는 필요한 개발 내용을 정확하게 프로그래머에게 전달해야 한다. 설계 혹은 디자인 단계에서는 설계 도구의 필요하다. 프로그래밍 혹은 코딩에서는 좋은 프로그램 언어의 필요하고 어떻게 하면 빨리 개발을 할 것 인가를 고민해야 하며 정확한 프로그램을 만들 것 인가와 빨리 수행되도록 할 것인지 그리고 입력 데이터나 프로그램 내의 자료를 어떻게 구성할 것인지, 프로그램을 다른 사람이 쉽게 알아볼 수 있도록 작성 테스트 단계에서는 여러 가지 데이터에 대하여 검증이 필요하다. 그리고 실험 데이터를 생성해야 한다. 유지 보수 단계에서는 프로그램의 변경이 필요할 때 효과적으로 재개발하는 방법의 고민이 필요하다.

소프트웨어 프로젝트 진향 정차를 도메인별로 아키텍처, 설계, 구현, 테스트로 나눌 수 도 있다. 도메인 영역 활동은 제품이나 제품 개발을 위한 자산에 대한 요구 사항을 시장과 관련 이해 당사자들로부터 수집하고 체계적으로 구성하여 개발할 시스템의 예상되는 기능과 품질에 대한 포괄적인 범위와 내용을 결정하고 제품 계열 아키텍처와 특정 제품의 아키텍처를 유도할 수 있는 기반을 마련하는 것이다. 아키텍처 영역 활동은 시스템을 구성하는 소프트웨어와 하드웨어 컴포넌트들의 전체 구조를 정의하는 시스템 아키텍처 설계를 통해 충돌 가능한 시스템의 요구 사항들을 조정하기 위해 시스템 구성 요소를 식별하고 요소들 간의 구조를 설계하고 검증하도록 지원한다. 설계 영역 활동은 아키텍처의 결정 사항을 반영하면서 시스템의 구조 및 행위를 모델링하여 시스템의 구조를 정의한다. 구현 영역 활동은 아키텍처와 설계 영역 활동에서 정의된 제품 특성에 맞도록 컴포넌트들을 구현하여 제품의 특성에 맞게 설정하고 생성한다. 테스트 영역활동은 분석, 설계된 결과대로 개발되었는지 확인하는 것으로써 분석모델과 설계모델에 대한 검토와 구현물에 대한 테스트를 통하여 확인한다⁵.

본 연구를 진행하기 위해서 먼저 소프트웨어 개발 과정에서는 경영진의 관여도가 프로젝트 성공에 영향을 준다는 것을 보다 효과적으로 확인하기 위해서 구체화한 가설을 설정하였다. 소프트웨어 개발 진행 절차에 따라서 요구 사항 분석, 설계, 프로그래밍, 테스트 그리고 사용 항목으로 나누었다. 유지 보수 항목은 프로젝트가 완료된 이후 시점에 해당하므로 가설에서 제외하였다. 프로젝트의 성공 여부 측정은 프로젝트가 예정된 시간 안에 완료 되었는지 여부와 그리고 발생하는 오류 빈도를 사용하였다. 실제 프로젝트가 가져오는 이익 즉, 매출 등은 외부 요인에 따라 달라질 가능성이 크고 적절한 기간으로 한정하기 어렵기 때문에 평가 항목에서 제외하였다.

프로젝트의 관여도는 얼마나 해당 항목 단계에서 프로젝트 팀원과 관련 내용을 논의하기 위한 접촉의 빈도로 정의하였다. 예를 들어 설계 단계에서 회의에 참석하였거나 테스트 단계에서 사용성 개선에 대해서 팀원과 이메일로 의견을 주고받은 등의 빈도를 포함 시켰다. 가설은 경영진을 가설의 독립 변수로 설정하고 각 프로젝트의 단계를 조절 변수로 설정하였다. 설정된 가설은 다음과 같다.

H1. 경영진의 관여도에 따라 시간, 오류의 빈도가 다르게 나타날 것이다. H2. 경영진의 요구사항 분석 단계의 관여도에 따라 시간, 오류의 빈도가 다르게 나타날 것이다. H3. 경영진의 설계 단계의 관여도에 따라 시간, 오류의 빈도가 다르게 나타날 것이다. H4. 경영진의 프로그래밍 단계의 관여도에 따라 시간, 오류의 빈도가 다르게 나타날 것이다. H5. 경영진의 테스트 단계의 관여도에 따라 시간, 오류의 빈도가 다르게 나타날 것이다. H6. 경영진의 사용 단계의 관여도에 따라 시간, 오류의 빈도가 다르게 나타날 것이다.

본 연구의 조사 방법은 총 3개의 기업의 각기 다른 2개의 팀 그리고 2명의 팀원 총 12명에게 설문조사와 심층 면접으로 진행할 것이다. 기업을 3개로 팀도 2개로 한 이유는 상황에 특화되어 나타나는 데이터를 구분하기 위해서 이다. 설문조사 항목에서는 각 프로젝트 단계마다 경영진의 참여 빈도를 표시하도록 할 것이다. 그리고 심층 면접을 통하여 경영진의 참여가 어느 정도 깊게 일어났는지 즉, 고관여인지 저관여 인지를 분석하여 설문 결과 점수의 가감 점수 항목으로 설정하였다.

본 연구는 시간 상의 이유로 보다 더 폭넓게 연구하지 못하고 제안하는 단계에 그친 것을 아쉽게 생각한다. 하지만 소비자의 관여도라는 개념을 새롭게 알게 되었고 관심 있었던 분야에 적용해 볼 수 있었다는 것에 의미가 있다고 생각한다. 또한 본 연구는 그 동안 경영진의 프로젝트 참여가 긍정적인 것인지 또는 부정적인 것인지에 대한 논란을 관여도의 관점에서 해석할 수 있다는 가능성에 큰 의미가 있다고 할 수 있다. 비록 지금은 초안 수준이고 연구 결과도 실제로 진행하지 못하여 확인하지 못하지만 앞으로 부족한 점은 보완하고 좀 더 다듬어서 정식 연구로 발전시켜 볼 생각이다.

References