로그인|회원가입|고객센터
Top
검색버튼 메뉴버튼

Mckinsey Quarterly

시장분석?제작?품질검사까지 한 팀이… 워크셀, 복잡한 IT시스템 구축에 최고!

스리람 찬드라세키란 | 162호 (2014년 10월 Issue 1)

Article at a Glance – 운영

복잡한 IT 시스템을 구축할 때워크셀이라 불리는 다기능팀을 활용해 폐쇄적인 조직 구조(silo)를 허물어뜨리면 성공 가능성이 높아진다. 기존 프로젝트 팀이 소비자 요구분석, 개발, 품질검사 등의 기능 부문별로 나누어진 데 비해 워크셀은 특정 모듈을 처음부터 끝까지 책임지는 형태로 구성된다. 워크셀을 이용하면 팀원들의 책임감이 높아지고, 다른 업무를 맡은 팀원들 간의 커뮤니케이션이 좋아지며, 개발과 테스트 간의 피드백 시간이 짧아진다. 

 

편집자주

이 글은 <맥킨지쿼털리>에 실린 ‘Achieving Success in Large, Complex Software Projects’를 전문 번역한 것입니다.

 

여러 산업에서 비즈니스 가치를 창출하고 전략적 역량을 구축하는 데는 기술 중심적인 변화 프로그램의 활용이 중요하다. 많은 조직들이 IT 예산의 약 절반가량을 응용 프로그램(application) 개발에 투자하고 있는 만큼 대부분의 변화 프로젝트를 성공적으로 진행하기 위해서는 적은 비용을 들여 좀 더 신속하게 소프트웨어 프로그램을 실행하는 능력이 필요하다. 하지만 실행의 질은 아직 개선돼야 할 부분이 많다. 맥킨지와 옥스퍼드대는 공동 연구를 통해 규모가 큰 소프트웨어 프로젝트들이 평균적으로 예산을 66% 초과하며 예정된 기한을 33% 초과한다는 사실을 발견했다. 뿐만 아니라 기업의 생존 자체를 위협할 정도로 형편없이 진행되는 프로젝트가 무려 17%에 달한다는 사실도 밝혀졌다.1

 

대규모로 진행되는 일부 응용 프로그램 개발 프로젝트는 특히 까다로운 편이다. 복잡성이 높은데다 업무흐름(work stream) 간의 상호 의존도가 크기 때문이다. 통신요금 청구, 보험금 청구, 세금 납부, 핵심 소매 금융 플랫폼 등을 지원하는 시스템을 개발하기 위한 프로젝트가 여기에 포함된다. 이런 프로젝트를 진행하려면 긴밀한 조정이 필요하다. 맨 처음에 제시된 사용자 요구사항이 수정되는 빈도가 잦기 때문이다.

 

프로젝트를 긴밀하게 조정하려면 응용 프로그램 개발 과정에서 흔히 관찰되는 폐쇄적인 조직 구조를 무너뜨려야 한다. 애자일(민첩한) 소프트웨어 개발 접근법(agile software-development approach)이 폐쇄적인 조직 구조를 무너뜨리는 데 도움이 되는 경우가 많다. 하지만 애자일 접근법은 주로 소규모 프로젝트에 적용된다. 소규모 프로젝트의 경우, 사전에 미리 정해져 있는 사용자 요구사항이 많지 않은데다 이런 요구사항들을 병행 가능한 다수의 하위 프로젝트들로 깔끔하게 나눌 수 있기 때문이다.2

 

애자일, (lean) 기법3 을 따르며 검사 중심적인 개발 방식4 에서 비롯된 반복적인 응용 프로그램 개발 방식(iterative application-development practice)을 구성하는 여러 요소들은 앞서 언급한 복잡한 프로젝트에서 중요한 역할을 할 가능성이 크다. 그동안 필자들이 경험한 바에 의하면 복잡하고 규모가 큰 프로젝트를 성공적으로 진행할 때는 이런 접근방법을 다기능팀(cross-functional team)으로 대변되는 새로운 조직 구조와 결합시켜야 한다. 필자들은 이런 팀을워크셀(work cell)’이라 부른다.

 

필자들은 연구를 통해 규모가 크고 복잡한 응용 프로그램 개발 프로젝트를 진행할 때 기능을 중심으로 팀을 나누는 구조가 비생산적이라는 사실을 발견했다.

 

응용 프로그램 개발 과정에서 등장하는 조정 문제

응용 프로그램 개발 프로젝트에 참여하는 3개 부문, 즉 비즈니스 분석, 개발, 검사 부문은 폐쇄적으로 활동하는 탓에 서로 간의 정보 흐름이 비효율적인 경우가 많다. (그림 1) 응용 프로그램 개발 프로젝트의 규모가 작을 때는 폐쇄적인 업무 방식이 별다른 문제가 되지 않는다. 하지만 프로그램의 규모가 크고 복잡해지면 의사소통 문제가 심각해진다. 응용 프로그램과 관련된 사용자 요구사항을 수집하는 프로젝트 관리자와 비즈니스 분석가들은 국내에 있고 개발자와 검사자는 해외에 있는 경우에는 위험이 더욱 커진다. 실제로 이런 경우가 많다. 이런 환경에서는 의사소통 속도가 더욱 느려진다. 시간대가 다른 탓에 서로 겹치는 업무 시간이 제한적이기 때문이다. 뿐만 아니라 응용 프로그램 개발에 참여하는 여러 부문들이허브 앤드 스포크방식으로 정보를 교환한다. 예컨대, 검사자가 검사 과정에서 찾아낸 코드 결함을 고위급 응용 프로그램 개발자에게 전달하면 고위급 응용 프로그램 개발자가 다시 나머지 팀원들에게 코드 재작업 업무를 맡기는 식이다. 이처럼 여러 차례에 걸쳐 업무를 전달하는 일이 반복되면 의사가 제대로 전달되지 않고 병목 현상이 발생할 가능성이 크다.

 

가입하면 무료

인기기사

질문, 답변, 연관 아티클 확인까지 한번에! 경제·경영 관련 질문은 AskBiz에게 물어보세요. 오늘은 무엇을 도와드릴까요?

Click!